> the runtime's embedded ICU/tzdata via Intl.DateTimeFormat I assume that it uses Node.js, which has been updated to 2026c in v26.6.0 <https://github.com/nodejs/node/blob/main/doc/changelogs/CHANGELOG_V26.md#2026-08-03-version-2660-current-aduh95:~:text=update%20timezone%20to-,2026c,-(Node.js%20GitHub> (2026-08-03). Do check whether your runtime uses that version, or whether you can update to it.
If your issue reproduces in v26.6.0, please file a bug there. On Tue, 25 Aug 2026 at 17:45, Vahid Shaik via tz <[email protected]> wrote: > Hi all, > > I maintain a prayer-times site (https://waqtazan.com). All our Moroccan > cities sit on Africa/Casablanca. We are a plain downstream consumer of > tzdata, not a redistributor. > > I have been tracking the 2026c change — "Morocco goes to plain UTC on > 2026-09-20", per the [PROPOSED] thread of 2026-07-04 — and wanted to offer > one concrete propagation data point now that the date is close. > > Our production runtime is Cloudflare Workers, which resolves zones through > the runtime's embedded ICU/tzdata via Intl.DateTimeFormat. Queried today, > it still returns UTC+01 for Africa/Casablanca on dates after the transition: > > 2026-09-19 maghrib 19:36 local / 18:36Z -> +01 (correct) > 2026-09-21 maghrib 19:34 local / 18:34Z -> +01 (stale) > 2026-10-15 maghrib 19:02 local / 18:02Z -> +01 (stale) > > The underlying UTC instants are right, since those depend only on latitude > and longitude. It is the civil-time rendering that would be an hour late. > > (The proposal also covers Western Sahara. We do not serve those cities, so > I > have no data point for Africa/El_Aaiun.) > > My question is about practice rather than data. For a consumer pinned to a > runtime's embedded tzdata, with no way to upgrade it independently and no > visibility into the vendor's update cadence, is there an established > recommendation? The options I can see: > > (a) wait, and hope the vendor ships before the transition; > (b) carry a small application-level override for the affected zone > across the transition date; > (c) stop relying on the platform zone database and ship our own. > > (b) makes me uneasy — an override that outlives the vendor's update becomes > a second source of truth and a future bug. But (a) is not a plan when the > date is fixed and the failure is silent. > > If this is out of scope for the list, happy to be told so. > > Thanks for the database. It does a lot of quiet work. > > Vahid > https://waqtazan.com >
