#Matty - Subscription Timing
1 messages · Page 1 of 1 (latest)
FYI... when I say time zone set, I mean in the Stripe dashboard.
Hello! The start date of a Subscription will be on the second you specify using the timestamp passed in. The timestamps used in the API are timezone independent and are not impacted at all by the timezone you have selected in the Stripe Dashboard.
For the .NET SDK, I can only pass in a DateTime object or the SubscriptionScheduleStart enum with a value of "Now". I can't pass a UNIX timestamp which would make this a moot point since that would be the proper time in seconds.
How are you creating the DateTime object?
Here is an example:
sub_sched_1KTD5zBBamLIIR3ZyieghOMD
No, I mean in your code, how are you creating the DateTime object?
var DT = DateTime.Parse("2/15/22 8:00AM");
DT = DateTime.SpecifyKind(DT, DateTimeKind.Utc);
^^ here is how the time was created for the example sub above.
I think that's going to use whatever timezone is set on your server. To clarify, you want to be able to specify 2/15/22 8:00AM UTC?
For testing, I am setting the time to 8am because that will be 12am PST. However, it was scheduling for 8am PST which was incorrect.
Also, just to clarify, you can't specify a timestamp as an integer? The sample code shows that:
StartDate = 1645481175,
Nope. It's a DateTime type... unfortunately. 🙂
What happens if you specify an integer like that? What error do you get?
You get a type conversion issue. It not an integer based field.
I'll keep messing with it and see what I can come up with. I assume I am doing something incorrectly. I can just keep creating tests in the test environment until I get it right.
Try doing this to specify the date and time in UTC to avoid time zone issues: DateTimeOffset.Parse("2022-02-14 16:00:00Z").UtcDateTime
Appears to be the same result. I think I have a good workaround though. Thank you again for your help!