2058419 - Update to tzdata2026c

Status: ASSIGNED

(Core :: JavaScript: Internationalization API, task, P1)

Description

[André Bargull [:anba]]

Update to tzdata 2026c.

Important changes:

• Alberta moved to permanent -06 on 2026-06-18.
• Morocco moves to permanent +00 on 2026-09-20.

Release notes:

• https://lists.iana.org/hyperkitty/list/[e-mail]/thread/NVHSX2PAQIT44U5FCCEVNJJYXQMMTJSA/

Comment 1

[André Bargull [:anba]]

Attachment: Bug 2058419 - Part 1: Update to tzdata 2026c. r=#spidermonkey-reviewers!

Comment 2

[André Bargull [:anba]]

Attachment: Bug 2058419 - Part 2: Clobber for tzdata update. r=#spidermonkey-reviewers!

When locally building in a fresh build, the updated icudata file wasn't correctly
included for some reason. Only after deleting the sccache directory (~/.cache/sccache)
the new icudata file was correctly linked to the new build. A similar issue appears
to be present for try-runs, because "jsreftest" builds fail the "timeZone_version.js"
test. (Browser only issue across different platforms, shell builds aren't affected.)

Let's see if a clobber avoids this. (It didn't help for try-runs, though!)

Comment 3

[André Bargull [:anba]]

Attachment: Bug 2058419: Update to tzdata 2026c (ESR140). r=#spidermonkey-reviewers!

Backport for ESR140.

Comment 4

[André Bargull [:anba]]

Attachment: Bug 2058419 - Part 2: Clobber for tzdata update (ESR140). r=#spidermonkey-reviewers!

When locally building in a fresh build, the updated icudata file wasn't correctly
included for some reason. Only after deleting the sccache directory (~/.cache/sccache)
the new icudata file was correctly linked to the new build. A similar issue appears
to be present for try-runs, because "jsreftest" builds fail the "timeZone_version.js"
test. (Browser only issue across different platforms, shell builds aren't affected.)

Let's see if a clobber avoids this. (It didn't help for try-runs, though!)

Comment 5

[André Bargull [:anba]]

I'm not yet sure what to do about ESR 115. In https://bugzilla.mozilla.org/show_bug.cgi?id=2034823#c3, Ryan asked about updating ESR 115, but at that time ESR 115 was about to get phased out, so I didn't update tzdata for it. But now that ESR 115's support window got extended, that doesn't apply anymore.

It appears that ESR 115 is still stuck at tzdata 2024a (https://github.com/mozilla-firefox/firefox/blob/esr115/intl/tzdata/VERSION), which means updating to tzdata 2026c is more risky, because it will include several tzdata updates at once (2024b, 2025a-c, and 2026a-c). I also don't know if Microsoft or Apple still support updating time zone information for Windows 7-8 resp. macOS 10.12-14. If they don't provide time zone updates, the users' clocks will be off anyway for some regions (Paraguay, Aysén region in Chile, Morocco, and parts of Canada).

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/120389865529
https://hg.mozilla.org/integration/autoland/rev/b66ce88bda86
Part 1: Update to tzdata 2026c. r=spidermonkey-reviewers,dminor
https://github.com/mozilla-firefox/firefox/commit/427c2da10235
https://hg.mozilla.org/integration/autoland/rev/2a3044d68490
Part 2: Clobber for tzdata update. r=spidermonkey-reviewers,dminor

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d3fdc9df5e8c
https://hg.mozilla.org/integration/autoland/rev/3a81984e1fd4
Revert "Bug 2058419 - Part 2: Clobber for tzdata update. r=spidermonkey-reviewers,dminor" for causing multiple failures

Comment 8

[rperta]

Backed out for causing multiple failures
Backout link
Push with failures
Failure log1(s)
Failure log2(s)

Comment 9

[André Bargull [:anba]]

That's the issue I've hit locally, too. The sccache hash key doesn't get updated, so the old ICU data file is used by sccache, which leads to a test failure, because the test expects the ICU data file contains the new tzdata version number.

Hash key for ICU data file with tzdata 2026c [1]:

[2026-07-29T07:21:16.954Z DEBUG sccache::compiler::compiler] [icu_data.o]: Hash key: c413b573e21c3f915c77392aebcbe47035c43e96d953c331f44a4b2a83007cee

Hash key for ICU data file with tzdata 2026b:

[2026-07-29T11:44:38.661Z DEBUG sccache::compiler::compiler] [icu_data.o]: Hash key: c413b573e21c3f915c77392aebcbe47035c43e96d953c331f44a4b2a83007cee

Same hash key, so sccache uses the stale ICU data file.

When renaming the ICU data file to force a different hash key, all tests pass:

[2026-07-29T06:48:56.346Z DEBUG sccache::compiler::compiler] [icu_data.o]: Hash key: 82a2d00c05091eff179cd24c199bc2e508cc01f2490f909a5a410713c627b8ff

[1] https://treeherder.mozilla.org/jobs?repo=try&revision=f698379a90ece024782bee17067c76b6f1e593f2
[2] https://treeherder.mozilla.org/jobs?repo=try&revision=d2930b02b73b117dfc2f25fffb6d72ce75d5f9de

Comment 10

[André Bargull [:anba]]

Attachment: Bug 2058419 - Part 2: Temporarily rename ICU data file to workaround sccache issue. r=#spidermonkey-reviewers!

sccache returns the same hash key for "icu_data.o", even though the included
binary file was updated. Temporarily rename the ICU data file as a workaround.

Comment 11

[André Bargull [:anba]]

Hi Sylvestre,
do you think this issue about calculating the same hash key (bug 2058419, comment #9) could be caused by https://github.com/mozilla/sccache/pull/2545, similar to the already filed https://github.com/mozilla/sccache/issues/2700?

https://searchfox.org/firefox-main/source/config/external/icu/data/icu_data.S includes the ICU data file https://searchfox.org/firefox-main/source/config/external/icu/data/icudt78l.dat. sccache computed the same hash key for "icu_data.o", even after the ICU data file was modified. This resulted in compiling Firefox with a stale ICU data file.

Comment 12

[BugBot [:suhaib / :marco]]

There are some r+ patches which didn't land and no activity in this bug for 1 week.
:anba, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 13

[Dan Minor [:dminor]]

Presumably this is waiting a resolution to the sccache issue.

Comment 14

[Dylan Myers]

Morocco switched to UTC+0 4 days ago, and currently on Firefox Developer 157.0b5 if I enter Temporal.Now.zonedDateTimeISO('Africa/Casablanca').offset in the console I see +01:00. This is materially affecting our switch to Temporal, I would appreciate an update as Firefox is the only major browser with this issue - Chromium team fixed this earlier this month in https://issues.chromium.org/issues/522179940

Thanks