Related: thread 28078. Our start_date is now stored correctly, but the scheduled actions still shift by one day for subscriptions created after midnight UTC.
Setup: CreateSubscription with start_date 2026-12-01, timezone America/Chicago, a monthly plan variation with 3 periods, billed on the 1st, STATIC pricing, card on file. Location timezone is America/Chicago. API version [fill in].
Production example: subscription 48048b4d-aa1e-403e-94f3-e41c7eda30d8, location LR083AESKCVMW, plan variation UGCGDYERXBV3ND7K3BPDL4YG, created 2026-11-03 at 10:03 pm Central (04:03 UTC on Nov 4). Stored: start_date 2026-12-01 and billing anchor 1 (both correct), but the anchor action is dated 2026-12-02 and COMPLETE is 2027-03-02. A subscription created in daytime in sandbox shows 2026-12-01 and 2027-03-01.
Also shifted by a day when created in the evening (sandbox): an explicit canceled_date (we sent 2027-03-01, it stored 2027-03-02), an explicit monthly_billing_anchor_date, and ChangeBillingAnchorDate (stored a day late, and it added a duplicate anchor action). It still happened after we set the sandbox location’s timezone to America/Chicago.
Questions: (1) Is this the same issue as 28078, and does the fix cover actions? (2) For an affected subscription, can the late COMPLETE cause a 4th charge on Mar 1, or the late anchor action a prorated charge on Dec 2? (3) Is there a supported way to create subscriptions in the evening without the shift? (4) Will existing subscriptions be corrected?
The earlier fix corrected returned start_date values, but did not cover these action dates. Those fields still use the UTC calendar date.
For your production example, the original start and anchor-change events share one timestamp: December 1 at 10:03:32 p.m. Chicago time. Original expiry is March 1 at the same local time. There is no one-day gap between start and anchor change, and COMPLETE reflects a stopping event rather than a separate billing job. These date labels alone do not establish an extra charge. Please refer to the table below how the date/time is converted from Chicago time to UTC for anchor action and COMPLETE:
Event
Stored UTC instant
America/Chicago
Start and anchor change
December 2, 2026, 04:03:32Z
December 1, 10:03:32 p.m.
Original expiry
March 2, 2027, 04:03:32Z
March 1, 10:03:32 p.m.
I also found a cancellation accepted about five minutes after creation, with subsequent records scheduling billing and entitlement to stop at the original start instant. That changes this example’s original schedule.
Thanks, Jaeha. The conversion table clears up the date labels. Our evening sign-ups store an instant that is still Dec 1 and Mar 1 in America/Chicago, and the dates only show a day later because they’re labeled by UTC date. (API version: 2026-09-16, and the cancellation you saw was our own test, cancelled on purpose.)
A few follow-ups so we can plan around this:
The last period. For a 3-period monthly subscription billed on the 1st with no proration, created at 10:03 pm Chicago: can you confirm that billing stops after exactly 3 charges (Dec 1, Jan 1, Feb 1), and that no invoice is made on Mar 1 local time before the 10:03 pm stop?
When the charges run. Is each period’s invoice made at the start instant (10:03 pm Chicago in this example), or at a fixed time on the local billing day?
Explicit dates. When we sent canceled_date 2027-03-01 from an evening request, it was stored as 2027-03-02. Is that the same labeling, meaning the cancel takes effect on Mar 1 local time? Or does the cancel actually move a day later?
Going forward. Is there a plan to label action dates in the subscription’s timezone? And is there a supported way to create subscriptions in the evening that avoids the mismatch? For now we create evening sign-ups the next morning, when the UTC and Chicago dates match.
Thanks for confirming the cancellation was intentional.
The expected recurring bills are indeed Dec 1, Jan 1, Feb 1, covering service through March 1. It will have 3 recurring base charges with no new March 1 renewal. The March 1 evening expiry does not create an extra billable day or require invoicing to wait until 10:03 p.m. to recognize the end.
Billing is normally scheduled around the subscription’s creation time-of-day which is 10:03 p.m. in this example, instead of a universal midnight run. Processing delays can affect invoice and payment timing, so that is not an exact card-charge time.
The returned March 2 date is consistent with the same UTC-date conversion where it March 2 UTC date simply represents March 1 locally. IT didn’t move a day later.
I don’t have a confirmed release ETA for the action/cancellation date labels. The start_date will display the local time where others can still default to UTC.