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

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:

The expected offsets come from IANA timezone 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, Alberta and Manitoba 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 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 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.