Edge runtime's ICU time-zone data predates tzdata 2026e; America/Winnipeg is wrong from 2026-11-01 #759

Activity

1. AbdelkbirNA commented on Oct 29, 2026

   

   AbdelkbirNA

   on Oct 29, 2026

   More actions

   Another zone already affected: Africa/Casablanca. Morocco moved to permanent UTC+0 on 2026-09-20 (IANA tzdata 2026c), and the runtime still applies UTC+1. Any "local day" computed between 23:00 and 00:00 UTC is a day ahead.

   new Intl.DateTimeFormat("en-GB", { timeZone: "Africa/Casablanca", hour: "2-digit", minute: "2-digit", timeZoneName: "shortOffset" })
     .format(new Date("2026-09-21T12:00:00Z"))
   // got 13:00 GMT+1, expected 12:00 GMT

   Which tzdata the binary carries, answering part of the ask: the ICU TZVersion string (UTF-16) inside /usr/local/bin/edge-runtime reads 2024a with ICU 74 on supabase/edge-runtime v1.71.2, v1.74.0, v1.74.2 and v1.77.9. I cross-checked the method on Node binaries with a known process.versions.tz (22.23.0 → 2026a, 22.23.4 → 2026e).

   Workaround until a new build ships: ICU reads ICU_TIMEZONE_FILES_DIR first. Mount the four files from unicode-org/icu-data/tzdata/icunew/2026e/44/le/ (zoneinfo64.res, timezoneTypes.res, metaZones.res, windowsZones.res; format 44 = ICU 74) and set the variable:

   functions:
     environment:
       ICU_TIMEZONE_FILES_DIR: /tzdata-icu
     volumes:
       - ./volumes/tzdata-icu/2026e:/tzdata-icu:ro

   Tested on self-hosted v1.71.2 and v1.74.0: Casablanca reads 12:00 GMT on 2026-09-21, and historical rules are kept (Ramadan 2026 still UTC+0, the surrounding dates UTC+1). This should fix America/Winnipeg as well, since 2026e is the version that carries that change, though I have not checked that zone. It only helps self-hosted setups, so deployed functions still need a runtime build with tzdata ≥ 2026e.
2. johnstonmatt

   self-assigned this

   on Oct 30, 2026