barkofdelight | Stripe Developers | Page 1

vague sunBOT Sep 21, 2023, 5:44 PM

#

hearty vapor Sep 21, 2023, 5:45 PM

#

Hello! Can you give me the ID of the Subscription so I can take a look?

tired turret Sep 21, 2023, 5:45 PM

#

Sure.... it is sub_1Ns9LTCvz3BN9BlttOlfqIYI

hearty vapor Sep 21, 2023, 5:46 PM

#

Looking...

#

I'm not seeing the slip. Which Invoice has the change?

#

The Subscription periods all start and end on the 1st of the month.

#

Except for the first one, which started on the 19th.

tired turret Sep 21, 2023, 5:53 PM

#

Invoice create on 31 Oct says "OCT 1 - NOV 1, 2023"

hearty vapor Sep 21, 2023, 5:53 PM

#

Right.

#

That's the period it's invoicing for, which seems correct?

tired turret Sep 21, 2023, 5:54 PM

#

Yes that's correct

#

But the one created on Jan 30th says: DEC 31, 2023 - JAN 31, 2024

#

Slipped back a day.

hearty vapor Sep 21, 2023, 5:55 PM

#

What's the ID of that Invoice?

tired turret Sep 21, 2023, 5:55 PM

#

in_1Ns9NzCvz3BN9BltB5F8CmFZ

hearty vapor Sep 21, 2023, 6:01 PM

#

Huh. The interval on the underlying line item has the correct dates. Like if you pull it from the API you should see the correct timestamps. Seems like maybe a timezone display issue or something like that.

tired turret Sep 21, 2023, 6:02 PM

#

Maybe test clock's don't understand DST?

hearty vapor Sep 21, 2023, 6:03 PM

#

Could be...

#

Let me ask someone who's better at Invoices than I am, hang on. 🙂

#

Wait... don't they all show up like this? I just looked at the previous Invoice and it's showing the same behavior.

tired turret Sep 21, 2023, 6:08 PM

#

The October 31 one is correct, at least to me.

hearty vapor Sep 21, 2023, 6:08 PM

#

I'm looking at the PDFs for these, where are you looking?

#

The previous Invoice shows "Nov 30 – Dec 31, 2023" in the PDF.

tired turret Sep 21, 2023, 6:09 PM

#

Just clicking on them in the dashboard.

#

#

Created: Oct 1, Nov 1...and then Nov 30, Dec 30 Jan 30

hearty vapor Sep 21, 2023, 6:11 PM

#

That's when DST ends though, so that makes sense, right?

tired turret Sep 21, 2023, 6:11 PM

#

Yes a DST error might be the culprit.

hearty vapor Sep 21, 2023, 6:11 PM

#

I don't think it's an error, I think it's the Dashboard applying DST adjustments and showing you the dates with that taken into account.

#

If you look at the underlying timestamps they're all correct, there's no shift or drift.

tired turret Sep 21, 2023, 6:12 PM

#

You mean the deltas between the timestamps are all the same?

hearty vapor Sep 21, 2023, 6:13 PM

#

Well, no, because different months are different lengths, but they all land on the expected month boundaries.

#

Meaning they're all at 7:00 AM on the 1st of the month UTC.

tired turret Sep 21, 2023, 6:15 PM

#

Hmmmmm that's not what I would expect.

#

Because that is in fact going to be November 30th PST instead of Dec 1st.

hearty vapor Sep 21, 2023, 6:16 PM

#

When you created the Subscription you backdated the start date to 1693551600 which is Fri, 01 Sep 2023 07:00:00 +0000. Why would you not expect the subsequent Subscription periods to not be anchored, by month, at that date and time?

tired turret Sep 21, 2023, 6:17 PM

#

Well, I said September 1st. I didn't myself say when on September 1st.

#

The widget on the dashboard only let me pick a date.

hearty vapor Sep 21, 2023, 6:18 PM

#

The underlying request set the timestamp to the one I mentioned above: https://dashboard.stripe.com/test/logs/req_zHLYTzsSDTKKas

#

If you want exact precision I recommend you use the API, not the Dashboard.

tired turret Sep 21, 2023, 6:19 PM

#

Sure....

#

But there's a conceptual thing here that I believe needs to be addressed....

#

The idea of "first of the month" is correctly being adjusted for the fact that the months are different lengths.

#

But it is forgetting about DST. October is one day and one hour longer than September.

hearty vapor Sep 21, 2023, 6:22 PM

#

That's not how it works. Subscriptions don't take DST into account when it comes to the length of intervals. We use UTC, which has no DST, to calculate the periods.

tired turret Sep 21, 2023, 6:23 PM

#

I have no objection to using UTC, but if you are going to do that, the invoices should then be displaying UTC as well.

charred scaffold Sep 21, 2023, 6:25 PM

#

A suggestion here could be to make the invoices anchor at 12 PM instead of 12 AM when created from the dashboard. Then one hour added or removed wouldn't change the date.

hearty vapor Sep 21, 2023, 6:26 PM

#

The Dashbord displays times and dates in your local timezone for convenience. You can change it to display UTC here: https://dashboard.stripe.com/settings/account

tired turret Sep 21, 2023, 6:26 PM

#

I'm more concerned with the invoices sent to customers.

#

@charred scaffold moving the anchor time for the dashboard is likely a sufficient workaround here.

charred scaffold Sep 21, 2023, 6:29 PM

#

Yeah but I don't think you can do this at the moment

#

re: the suggestion to use API

tired turret Sep 21, 2023, 6:30 PM

#

Sure, I will do that for now. But conceptually, I think that the billing anchor should be a day-of-month and not a timestamp.

charred scaffold Sep 21, 2023, 6:30 PM

#

Anecdotally, we anchor to 1st of each month and just set a random hour/minute between 9am and 3pm when the subscriptions get created, so they trickly in during the day

#

and not all-at-once

tired turret Sep 21, 2023, 6:32 PM

#

So does this mean if my company is in western US and we have a customer in Australia they'll get their bills a day in advance?

charred scaffold Sep 21, 2023, 6:32 PM

#

Wouldn't it just be 11 pm instead of midnight? Technically a day before

hearty vapor Sep 21, 2023, 6:32 PM

#

It depends on how you create the Subscription for them.

tired turret Sep 21, 2023, 6:32 PM

#

Maybe a day late.

#

Anyway, not diving into that complication just yet, I stand by my claim: If the internals are using UTC to define day-of-month, they should use that same thing to display that data on invoices. Other things like date created can be local, but if my customer expects to be billed for a calendar month, that should be what shows on the invoices, regardless of my time zone setting.

hearty vapor Sep 21, 2023, 6:36 PM

#

I can file that feedback, but really it's unlikely we're going to change the way this behaves.

tired turret Sep 21, 2023, 6:38 PM

#

Understood. Perhaps we can get a compromise and have the dashboard pick a UTC time which isn't midnight my time—or let me set the time there. That of course will still break if I were to change my timezone, but it is a bit of an improvment.

hearty vapor Sep 21, 2023, 6:39 PM

#

You can switch your account to UTC as indicated above, at which point it should select midnight UTC.

#

But really you should be using the API for this.

tired turret Sep 21, 2023, 6:40 PM

#

[My real claim would be that using a timestamp for day-of-month is the wrong type, but that's even more unlikely to get traction. ]

#

I am not the only user here; we will likely have a billing department eventually setting up users and subscriptions etc. So better to let them set it up and then I can automate the back end to shift the anchor datestamp to what I want it to be.

#

I don't want to be telling people to set their display to UTC...that's "bringing in the cats to catch the rats".

hearty vapor Sep 21, 2023, 6:45 PM

#

It sounds like the best way to solve this might be to allow you to specify a time as well as a date for the start date in the Dashboard. I'll flag that internally.

vague sunBOT Sep 21, 2023, 6:46 PM

#

tired turret Sep 21, 2023, 6:47 PM

#

That would work. Thx for all the ideas and suggestions.

#barkofdelight