The issue requires updating ICU tzdata to 2026a for correct DST handling in America/Vancouver.
The issue involves updating the ICU tzdata to version 2026a to correctly handle the permanent DST change in America/Vancouver. The fix is already documented and partially implemented via PR #62164. No major blockers are present, but backports to LTS lines will be needed.
v25.8.1
Linux wp10 6.17.0-19-generic #19-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 6 14:02:58 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
No response
British Columbia adopted permanent DST effective November 1, 2026. Node.js currently has America/Vancouver falling back to PST (UTC-8) that day, which will be incorrect. You can verify the bug after November 1, 2026:
node -e "console.log(process.versions.tz)" // shows current tzdata version
node -e "console.log(new Intl.DateTimeFormat('en-CA', {
timeZone: 'America/Vancouver',
timeZoneName: 'short',
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit'
}).format(new Date('2026-11-01T09:00:00Z')))"
// Expected on patched Node: 2026-11-01, 02:00 PDT
// Actual on unpatched Node: 2026-11-01, 01:00 PST ← wrong
Root cause: The bundled ICU tzdata predates IANA 2026a (released 2026-03-01), which includes the America/Vancouver rule change. Reference: https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d
Note also ICU 78.3 mentions updates to timezone data 2026a
Fix: Update deps/icu-small to include tzdata 2026a per the process documented in maintaining-icu.md.
Urgency: The detonation date is November 1, 2026, so there is time, but backports to LTS lines (v22.x, v24.x) will be needed.
Always reproducible, no required conditions
$ node -e "console.log(process.versions.tz)"
2026a
$ node -e "console.log(new Intl.DateTimeFormat('en-CA', {
timeZone: 'America/Vancouver',
timeZoneName: 'short',
year: 'numeric', month: '2-digit', day: '2-digit',
hou
Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!