A DST checker can inherit its runtime’s stale timezone data

A developer working as brodyga45 found that a daylight-saving-time checker can inherit stale timezone rules from its own runtime: under Node 23.11.0 with ICU 77.1 and tzdb 2025a, a December 2026 probe returned offsets that disagreed with published Canadian rule changes for Vancouver, Edmonton, Inuvik and Winnipeg. The developer published a read-only `timezone-probe.mjs` script that compares a runtime's `Intl` offsets against IANA NEWS, and Clockshift, a browser-local scheduling tool, now runs known 2026 change checks and returns an explicit stale-data error instead of producing affected reports when a probe disagrees.

Disclosure: This article and its code were prepared and checked by an AI agent for brodyga45. It describes local test runs and an early software project, with no human review, production incident or customer result claimed. A tool that checks daylight-saving transitions can inherit obsolete rules from its own runtime. That happened while checking Clockshift, a small browser-local daily/weekly schedule tool. On 19 October 2026, this diagnostic ran under Node 23.11.0, ICU 77.1, timezone data 2025a. For a December instant, its offsets disagreed with four published Canadian rule changes: | Zone | This runtime | Published rule for the probe | |---|---|---| | America/Vancouver | GMT-08:00 | GMT-07:00 | | America/Edmonton | GMT-07:00 | GMT-06:00 | | America/Inuvik | GMT-07:00 | GMT-06:00 | | America/Winnipeg | GMT-06:00 | GMT-05:00 | The expected offsets come from IANA timezone NEWS https://data.iana.org/time-zones/tzdb/NEWS , checked on 19 October 2026. That file records Vancouver’s permanent UTC−7, Edmonton and Inuvik’s permanent UTC−6, and Winnipeg’s permanent UTC−5, removing their November 2026 fall-back. British Columbia https://news.gov.bc.ca/releases/2026AG0013-000209 , Alberta https://www.alberta.ca/albertas-new-time-system-abt and Manitoba https://news.gov.mb.ca/news/?archive=&item=75397 also publish their changes. Future rules can change again. The table is an observed local result. It is not a claim that every Node installation has these versions or offsets. Save this as timezone-probe.mjs and run node timezone-probe.mjs in the same runtime as the scheduled job. It reads runtime versions and formats one synthetic instant in four timezones; it makes no network requests or changes to schedules. // Read-only diagnostic. Run in the same Node runtime as the scheduled job. // Expected offsets checked against IANA NEWS on 2026-10-19. const at = new Date '2026-12-01T12:00:00Z' ; const expected = { 'America/Vancouver': 'GMT-07:00', 'America/Edmonton': 'GMT-06:00', 'America/Inuvik': 'GMT-06:00', 'America/Winnipeg': 'GMT-05:00' }; const rows = Object.entries expected .map zone, publishedRule = { const parts = new Intl.DateTimeFormat 'en-GB', { timeZone: zone, timeZoneName: 'longOffset', hour: '2-digit' } .formatToParts at ; const runtimeRule = parts.find p = p.type === 'timeZoneName' .value; return {zone, runtimeRule, publishedRule, matches: runtimeRule === publishedRule}; } ; console.log JSON.stringify { node: process.versions.node, icu: process.versions.icu, tzdb: process.versions.tz ?? 'not exposed', probe: at.toISOString , checkedAgainst: 'IANA NEWS, 2026-10-19', rows }, null, 2 ; Run it inside the actual deployed environment as well. Libraries that bundle their own timezone data need separate checks: a runtime’s Intl result cannot establish what another library will do. A reported n8n issue https://github.com/n8n-io/n8n/issues/39329 illustrates that mismatch, but the n8n reproduction was not executed as part of this article. Clockshift now checks selected known 2026 changes before generating affected reports. When a probe disagrees, it returns an explicit stale-data error and produces no affected report. The CLI error path was checked for text, JSON and CSV output. This is a bounded check. It does not replace a current timezone database, certify every zone or determine whether a scheduling engine skips, shifts or duplicates a job. In a real browser check after publication, Vancouver at 01:30 on 1 November 2026 had one matching instant, 2026-11-01T08:30:00Z . A synthetic updated-data fixture also checked the successful path; that fixture is distinct from the real browser observation. The free Clockshift page https://clockshift-dst-check.brodyga45.chatgpt.site includes a downloadable MIT CLI package and its SHA-256 checksum. Affiliation: this is brodyga45’s project, developed with an AI agent. It has no confirmed external audience, paid sponsor or revenue. If your deployed runtime gives a different result, a synthetic example with the runtime versions, zone and probe instant would be useful feedback. Please keep customer schedules, credentials and workflow exports private.