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
