Time Zone Database Release 2026b
Released
Downloads
| File | Description |
|---|---|
 tzdb-2026b.tar.lz (548.4kb) |
Complete Distribution (Data, Code and Extras) |
| tzdata2026b.tar.gz (462.6kb) |
Data Only Distribution |
| tzcode2026b.tar.gz (316.5kb) |
Code Only Distribution |
Release Notes
Briefly:
British Columbia moved to permanent -07 on 2026-03-09.
zic no longer mishandles a last transition to a new time type.
Some more overflow bugs have been fixed in zic.
Changes to future timestamps
British Columbia’s 2026-03-08 spring forward was its last
foreseeable clock change, as it moved to permanent -07 thereafter.
(Thanks to Arthur David Olson.) Although the change to permanent
-07 legally took place on 2026-03-09, temporarily model the change
to occur on 2026-11-01 at 02:00 instead. This temporary hack
works around a limitation in Unicode CLDR 48 (2025-10-29) and
ICU 78 (2025-10-30), and is planned to be removed after CLDR and
ICU are fixed.
To match longstanding practice for -07 standard time in North
America, such as for America/Dawson, America/Dawson_Creek,
America/Fort_Nelson and America/Whitehorse, affected BC
timestamps use the abbreviation MST. As the change affects both
America/Vancouver and its backward compatibility link, the
obsolescent setting TZ="Canada/Pacific" will now use the
abbreviation MST. Future TZDB releases may change the
abbreviation if something else becomes popular across areas
observing -07, and may change it to "-07" if no alphabetic
consensus emerges.
NOTE FOR 2026 TEMPORARY HACK FOR CLDR AND CANADA:
This temporary hack works around limitations in Unicode CLDR and
ICU, and is planned to be removed after CLDR and ICU are fixed.
See <https://cldr.unicode.org/downloads/cldr-48> and
<https://www.unicode.org/releases/> for 2026 changes there.
Unfortunately the temporary hack also causes zic in tzcode
2023d through 2026a, in the default slim mode, to generate a
TZif file that does not conform to Internet RFC 9636 §3.3.
The buggy file in turn causes some TZif readers, including tzcode
itself, to ignore America/Vancouver’s 2026-11-01 02:00 transition
from PDT (tm_isdst=1) to MST (tm_isdst=0). Although the buggy
file does not cause any known TZif reader to mishandle UT offsets,
caution is advised when using zic 2023d through 2026a to compile
data from more-recent tz releases. To work around this problem
when using these older zic versions, use ‘zic -b fat’.
Changes to code
zic no longer mishandles a last transition to a new time type.
zic no longer overflows a buffer when generating a TZ string like
"PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
which can occur with adversarial input. (Thanks to Naveed Khan.)
zic no longer generates a longer TZif file than necessary when
an earlier time zone abbreviation is a suffix of a later one.
As a nice side effect, zic no longer overflows a buffer when given
a long series of abbreviations, each a suffix of the next.
(Buffer overflow reported by Arthur Chan.)
zic no longer overflows an int when processing input like ‘Zone
Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer
overflow in adversarial cases. (Thanks to Naveed Khan.)
zic now checks for signals more often.