slashdash11

[drowsy forum]

Hi 👋 when was that request made?

Asking because the time provided is currently in the past:

1692662400 Tuesday, August 22, 2023 12:00:00 AM

[alpine folio]

yeah the time is an example from yesterday evening, the user tried to create subscription on Aug 21, 9PM EST

[drowsy forum]

Can you share an ID of a request that encountered the reported error?

9PM EST is after 12AM UTC (the following day) due to the 4-hour difference between the two regions.

[alpine folio]

unfortunately, I don't have the id of the request and we're not logging or saving that on our side. I'm wondering if I can get that anywhere else?

that's right. But as far as I'm aware, we're always comparing the time in UTC?

FWIW, we're only seeing this issue for users that tried to create a subscription after 8PM and to start for the next date.

[drowsy forum]

Yes, you can view the list of requests you've made to the Stripe API and their responses in your Stripe dashboard, and those results can be filtered to failed requests:
https://dashboard.stripe.com/test/logs?success=false&method[0]=post&method[1]=delete&direction[0]=self&direction[1]=connect_in&showIP=false

[alpine folio]

I will get back to you with the request id. Thanks

[drowsy forum]

If it only happens after 8PM for EST based customers, then it sounds like there is something off with the timezone conversion or timezone being used.

[alpine folio]

here's a couple of the requests i've made last night req_WlbyQoHyYBXvCe, req_z0pmyEI94almBE

[drowsy forum]

Yeah, looks like you're passing 12AM UTC after that time is in the past.

If you're always trying to set the anchor to midnight UTC on the "following day", you'll need to add a check to make sure that time isn't technically in the past and push the calculation out one more day.

If instead you're trying to set the billing cycle anchor for midnight in the customers time zone, you'll want to find that local time first and then convert it to utc.