Description

mjradwin

opened on Mar 18, 2026

Issue body actions

Version

v25.8.1

Platform

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

Subsystem

No response

What steps will reproduce the bug?

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: eggert/tz@8b46071

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.

How often does it reproduce? Is there a required condition?

Always reproducible, no required conditions

What is the expected behavior? Why is that the expected behavior?

$ 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',
  hour: '2-digit', minute: '2-digit'
}).format(new Date('2026-11-01T09:00:00Z')))"
2026-11-01, 02:00 a.m. MST
$

What do you see instead?

$ node -e "console.log(process.versions.tz)"
2025c
$ 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')))"
2026-11-01, 01:00 a.m. PST
$

Additional information

No response

Activity

1. richardlau commented on Mar 18, 2026

   

   richardlau

   on Mar 18, 2026

   Member

   More actions

   Fix: Update deps/icu-small to include tzdata 2026a per the process documented in maintaining-icu.md.

   This has already been done via #62164. It has yet to go out in a release.

   Note also ICU 78.3 mentions updates to timezone data 2026a

   I've run our updater workflow, which has picked up ICU 78.3 and opened #62324. This would have run at the weekend on the usual schedule for the workflow.

   Reacted by René

   Reacted by Michael J. Radwin
2. legendecas

   added

   icuIssues and PRs related to the ICU dependency.Issues and PRs related to the ICU dependency.

   on Mar 18, 2026
3. albertyw commented on Mar 27, 2026

   

   albertyw

   on Mar 27, 2026

   Contributor

   More actions

   tzdata 2026a does not contain updates for America/Vancouver. It contains other changes. The BC DST update will be released in tzdata 2026b or later, discussion in https://lists.iana.org/hyperkitty/list/[email protected]/thread/667WE5QTIA7MP2E7NC7T3SO7VLMZLVZS/.

   After a new tzdata is released, then it can be incorporated into node through the process @richardlau described.
4. richardlau commented on Apr 23, 2026

   

   richardlau

   on Apr 23, 2026

   Member

   More actions

   More info

   • https://lists.iana.org/hyperkitty/list/[email protected]/thread/LZIJFAY2K4OXXCAGFMIYQD3INX6K6FV4/
   • https://lists.iana.org/hyperkitty/list/[email protected]/thread/VX2Z3CBO6KHTYZNBBKFFWM7ZCI6TVCXP/

   The 2026b release of the tz code and data is available. As Tim mentioned
   yesterday[1], this release’s main impetus is British Columbia’s decision
   to stop changing its clocks and stay on permanent UTC-07, which affects
   BC’s UTC offsets starting 2026-11-01 at 02:00. Since this change will
   likely cause problems downstream as CLDR’s latest release cannot handle
   it, we’re pushing out this release now so that downstream has some time
   to test and reprogram. Quite possibly we’ll need another release soon to
   accommodate proposed changes in Alberta and Northwest Territories.

   Our update scripts pull the tzdata from ICU so we'll need them to update first (we don't need an ICU release but the tzdata must be in their upstream repository) before we can update Node.js.

   Reacted by Michael J. Radwin
5. richardlau commented on Apr 23, 2026

   

   richardlau

   on Apr 23, 2026

   Member

   More actions

   Refs: unicode-org/icu-data#52
6. richardlau commented on Apr 23, 2026

   

   richardlau

   on Apr 23, 2026

   Member

   More actions

   We'll also need to watch out for the CLDR wrinkle, and whether that would prevent us being able to take the tzdata without a corresponding ICU update.
7. mjradwin commented on May 11, 2026

   

   mjradwin

   on May 11, 2026

   Author

   More actions

   Looks like this is fixed in Node 26

   mradwin@w44:~$ node --version
   v26.1.0
   mradwin@w44:~$ node -e "console.log(process.versions.tz)"
   2026b
   mradwin@w44:~$ 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')))"
   2026-11-01, 02:00 a.m. PDT
   mradwin@w44:~$ 
   
8. Renegade334

   closed this as completedon Jun 28, 2026
9. elementmikem-rgb

   added a commit that references this issue on Sep 17, 2026

   Pin Node to >=24.15.0 for BC's permanent-DST tzdata fix

   6a8984e

Issue actions