#Matty - Subscription Timing

1 messages · Page 1 of 1 (latest)

hollow juniper
gusty nest
#

FYI... when I say time zone set, I mean in the Stripe dashboard.

hollow juniper
#

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.

gusty nest
#

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.

hollow juniper
#

How are you creating the DateTime object?

gusty nest
#

Here is an example:
sub_sched_1KTD5zBBamLIIR3ZyieghOMD

hollow juniper
#

No, I mean in your code, how are you creating the DateTime object?

gusty nest
#

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.

hollow juniper
#

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?

gusty nest
#

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.

hollow juniper
#

Also, just to clarify, you can't specify a timestamp as an integer? The sample code shows that:

StartDate = 1645481175,
gusty nest
#

Nope. It's a DateTime type... unfortunately. 🙂

hollow juniper
#

What happens if you specify an integer like that? What error do you get?

gusty nest
#

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.

hollow juniper
#

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

gusty nest
#

Appears to be the same result. I think I have a good workaround though. Thank you again for your help!