Octa Engineering Notes Christian Elías Request for Comments: OCTA-20 octa.page Category: Informational June 2026 Timezone Propagation: How IANA Changes Reach Your Application Abstract How IANA timezone changes travel from the tzdb release through CLDR, OS updates, and language runtimes — including Node.js's Date/Intl split where the same environment can produce two different answers, and the British Columbia permanent DST workaround. Status of This Memo This memo documents timezone notes for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. The canonical version lives at https://octa.page/doc/timezone-propagation-flow/ and the machine-readable source at https://octa.page/doc/timezone-propagation-flow.md When the IANA timezone database makes a decision about how time works in a region, that change doesn't instantly reach your JavaScript "Date" object or your Python datetime library. Instead, it travels through a complex ecosystem of standards bodies, operating systems, language runtimes, and third-party libraries—each with their own release cycles, prioritization strategies, and sometimes their own interpretations of the rules. This journey can take weeks, months, or in extreme cases, never happen at all. Understanding that pipeline is essential for anyone building systems that rely on reliable timezone handling. 1. The Propagation Pipeline graph TD tz["IANA tz Database
(tzdb)"] cldr["CLDR/ICU
(Unicode Consortium)"] os["Operating Systems
(glibc, Windows)"] thirdparty["Third-Party Libs
(Moment, Day.js, Luxon)"] bundled["Language Runtimes
(Node.js, Java, Go,
bundled CLDR/ICU)"] apps["User Applications"] tz -->|"CLDR adoption
(1-2 months)"| cldr tz -->|"OS updates
(varies)"| os tz -->|"Direct adoption"| thirdparty cldr -->|"Runtime releases
(weeks-months)"| bundled os -->|"System updates
(varies)"| apps bundled -->|"Direct dependency"| apps thirdparty -->|"Library updates"| apps 2. Timeline: From IANA Decision to User System tz release (immediate) o IANA releases a new rule via the tz mailing list [1] and updates data.iana.org/time-zones/tzdb/ [2] o Published in the NEWS file CLDR adoption (typically 1–2 months) o Unicode CLDR interprets the tz change and integrates it into its schema o CLDR includes not just tz rules but also metadata: display names, exemplar cities, etc. o Not always a 1:1 mapping (CLDR sometimes applies its own interpretation) OS updates (highly variable) o Linux distributions: 1–3 months (depends on distro policy) o macOS: aligned with CLDR releases, typically 1–2 months o Windows: can lag significantly; Microsoft maintains its own TZDB mirror but updates are not automatic o Android: depends on the OS version and manufacturer updates Language runtime releases (weeks to months) o Runtimes with bundled CLDR (Node.js, Java, Go) release updates on their own schedule o Some runtimes are more aggressive (quick releases); others batch changes Third-party libraries (unpredictable) o Some libraries depend on CLDR and are updated automatically o Others maintain their own timezone data o Maintainer activity is critical—abandoned libraries can lag for years 3. Node.js: The Duality Problem Node.js presents a unique and often overlooked situation: it has two simultaneous sources of timezone information. 3.1. Source 1: Native "Date" (from the Operating System) The JavaScript "Date" object relies on the system's tzdata: const now = new Date(); now.toString(); // Uses the OS tzdata to determine local timezone offset When you call "new Date()" and ask for the local representation, Node.js queries the operating system's timezone database (via "libc" on Unix-like systems, the Windows Registry on Windows). If your OS hasn't updated its tzdata yet, your "Date" object won't reflect the latest rules either. 3.2. Source 2: "Intl.DateTimeFormat" (from Bundled ICU) The Intl API is built on ICU (International Components for Unicode), which is bundled into the Node.js binary: const formatter = new Intl.DateTimeFormat('ca-AD', { timeZone: 'Europe/Andorra', }); // Uses bundled ICU data, which can differ from OS data This formatter uses the CLDR/ICU data that was compiled into your Node.js binary at build time. If your Node.js version was built 6 months ago and tz made a change last week, the "Intl" API will use outdated data until you upgrade Node. 3.3. The Mismatch The same JavaScript environment can give you two different answers for the same timezone: // Example: hypothetical timezone rule change const d = new Date('2026-06-15T12:00:00Z'); // Using Date (OS-based) console.log(d.toLocaleString('en-US', { timeZone: 'America/New_York' })); // May use outdated rules if OS hasn't updated // Using explicit Intl (ICU-based) const formatter = new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York' }); console.log(formatter.format(d)); // May use different rules if Node.js binary is newer than OS This split is a well-known pain point in JavaScript environments. Different environments handle it differently—some prefer OS consistency, others prefer Intl consistency. 4. Case Study: British Columbia's Permanent Daylight Time British Columbia (Canada) announced in late 2023 that it would permanently observe daylight time—effectively staying on "summer time" year-round. This created a problem that exposed the limits of CLDR's design. CLDR's mental model assumes regions transition between a standard time and a daylight time. Every year, the clock springs forward and falls back. But British Columbia doesn't follow this pattern anymore. It stays on daylight time constantly. When a region stops participating in the normal DST cycle entirely, CLDR has no natural way to represent it. The schema assumes transitions happen periodically (spring forward, fall back). A permanent shift breaks that assumption. 4.1. IANA's Workaround Rather than wait for CLDR to redesign its schema, IANA's timezone maintainers invented a solution: a fictional future DST transition. The tz database now schedules a fake DST transition far in the future. On that date, the region transitions from "summer time" to... "summer time" again. The net effect: no actual time change, but the CLDR rules engine processes it as a normal transition and produces the correct output. From the "tzdata" NEWS file: A region that wants to stay on permanent daylight time can be represented as having a DST transition that loops back to itself, effectively freezing the clock in the DST state. This is a clever hack, but it reveals an important truth: the timezone database is constrained by the tools that consume it. IANA doesn't just define rules; it also has to work around limitations in the systems that implement those rules. The specific discussion: o IANA tz mailing list thread on British Columbia [3] o IANA tzdb NEWS file [4] (search for "Canada/Vancouver" or "permanent") 5. Why Propagation Matters The reality of timezone propagation creates several practical implications: 1. You can't rely on immediate consistency. A timezone rule change made today won't be reflected everywhere in your infrastructure for weeks or months. 2. Cross-system mismatches are possible. Your web server (running a freshly updated OS) might calculate time differently than the user's browser (running an older version of Node or Chrome). 3. Library choice matters. Moment.js might reflect changes faster than the native "Date" object, or vice versa, depending on when maintainers push updates. 4. CI/CD and testing become essential. If you care about correct timezone behavior, you can't just trust whatever system you're testing on. You need explicit tests for known edge cases and irregular transitions. 6. What to Do If you're building systems that handle timezone-dependent logic: o For coordination: Always store and transmit times in UTC. Conversion to local time is a display concern, not a storage concern. o For testing: Don't assume your system's timezone data is current. Write tests that explicitly test known edge cases and transitions. o For Node.js: Be aware that "Date" and "Intl" can disagree. For critical applications, pick one and stick with it, or synchronize them explicitly. o For production: Monitor timezone-related issues in your observability stack. A timezone propagation delay is invisible until someone tries to book a flight. 7. References [1] https://lists.iana.org/hyperkitty/list/tz@iana.org/ [2] https://data.iana.org/time-zones/tzdb/ [3] https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/NZCHEWN5WZWIC3OQDNHBX4U7Z4PTCJYY/ [4] https://data.iana.org/time-zones/tzdb/NEWS Christian Elías Informational [Page 1]