You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I noticed that new timezone data is added occasionally in Node releases, but these updates don't seem to follow any specific schedule.
Also, newer versions of the tzdata are updated in the latest Node releases, but not necessarily in maintenance releases. For example, right now Node 24 is using tzdata 2026b, while Node 22 is still using version 2026a.
Is there a specific schedule for these updates? Also, are newer versions of the tzdata generally not backported to maintenance releases of Node?
Node.js releases pick up their changes based on what lands on nodejs/node main branch, it's not up to the Release WG what lands there (we can decide to filter out commits that landed on main as not suitable for a Node.js release, but not the other way around). I haven't looked into it, so I might be wrong, but it's likely that there's simply no one contributing to maintaining tzdata – so if you care about it, I'd encourage you to contribute on nodejs/node (i.e. making sure there's automation to open PRs on new versions, making sure those bot PRs get reviews and are flagged to be included in LTS releases).
I'm going to optimistically close this, assuming I've answered your question, but let me know if I've missed something or if you need more info
Thanks for the reply @aduh95. Before contributing to nodejs/node I would like to better understand how is this tzdata maintenance managed because sooner or later it seems to be taken care of. There is a new update from a few weeks ago nodejs/node#64588 for example. They seem to come from a bot and later introduced into the different version branches v24 and v22.
So what triggers this bot to create the PR with the new version of tzdata?
Once the changes land on main, then they're subject to usual Node.js rules for changes (i.e. they are treated the same as other changes and there is no special cases or scheduling for the timezone updates). Which by default means that changes need to go out in a "current" (e.g. at the moment Node.js 26.x) release for two weeks before being considered for the older Long Term Support (LTS) release lines. That doesn't mean they'd be released in LTS releases two weeks later, just that there is an expected minimum wait time. Release frequency of the LTS lines depends on Releaser availability.
FWIW nodejs/node#65448 does appear to include the update to tzdata 2026b.
As I can see, version 2026c was added to icu-data 2 months ago but Node 22 still has pending to introduce 2026b. So I imagine 2026c will still take a few more months to be introduced. That's currently a quite critical situation given that there will be important timezone changes in Morocco and Canada in the following weeks and Node runtimes with outdated data can produce wrong time calculations.
Is it at least possible to manually update a Node service with more recent timezone data in case of need?
Activity
aduh95 commentedon Aug 30, 2026
Node.js releases pick up their changes based on what lands on nodejs/node
mainbranch, it's not up to the Release WG what lands there (we can decide to filter out commits that landed onmainas not suitable for a Node.js release, but not the other way around). I haven't looked into it, so I might be wrong, but it's likely that there's simply no one contributing to maintaining tzdata – so if you care about it, I'd encourage you to contribute on nodejs/node (i.e. making sure there's automation to open PRs on new versions, making sure those bot PRs get reviews and are flagged to be included in LTS releases).I'm going to optimistically close this, assuming I've answered your question, but let me know if I've missed something or if you need more info
arnaugm commentedon Sep 7, 2026
Thanks for the reply @aduh95. Before contributing to nodejs/node I would like to better understand how is this tzdata maintenance managed because sooner or later it seems to be taken care of. There is a new update from a few weeks ago nodejs/node#64588 for example. They seem to come from a bot and later introduced into the different version branches v24 and v22.
So what triggers this bot to create the PR with the new version of tzdata?
richardlau commentedon Sep 7, 2026
The timezone data is baked into ICU's data, so we pick up timezone updates when ICU does.
This workflow only runs for
main.Once the changes land on
main, then they're subject to usual Node.js rules for changes (i.e. they are treated the same as other changes and there is no special cases or scheduling for the timezone updates). Which by default means that changes need to go out in a "current" (e.g. at the moment Node.js 26.x) release for two weeks before being considered for the older Long Term Support (LTS) release lines. That doesn't mean they'd be released in LTS releases two weeks later, just that there is an expected minimum wait time. Release frequency of the LTS lines depends on Releaser availability.FWIW nodejs/node#65448 does appear to include the update to tzdata 2026b.
arnaugm commentedon Sep 15, 2026
As I can see, version 2026c was added to icu-data 2 months ago but Node 22 still has pending to introduce 2026b. So I imagine 2026c will still take a few more months to be introduced. That's currently a quite critical situation given that there will be important timezone changes in Morocco and Canada in the following weeks and Node runtimes with outdated data can produce wrong time calculations.
Is it at least possible to manually update a Node service with more recent timezone data in case of need?
richardlau commentedon Sep 15, 2026
The proposal for 22.23.3 contains both tz 2026b and 2026c commits.
ICU has some environment variables to point at a directory containing the
*.resfiles containing the data:arnaugm commentedon Sep 15, 2026
True, I missed that sorry. And is there any estimation of when this proposal will be accepted?
I will look into this, thanks.