11News for the tz database
22
3+ Release 2026d - 2026-09-11 15:21:07 -0700
4+
5+ Briefly:
6+ Canada’s Northwest Territories moved to permanent -06 on 2026-08-21.
7+ Obsolescent settings like TZ="EST5EDT" now conform better to POSIX.
8+ Fix security, performance and porting bugs in zic and localtime.
9+
10+ Changes to future timestamps
11+
12+ Canada’s Northwest Territories will not fall back on 2026-11-01
13+ and will stay on -06 year-round, matching Alberta’s recent change.
14+ Model this with its traditional abbreviation CST. Although the
15+ change to permanent -06 legally took place on 2026-08-21,
16+ temporarily model the change to occur on 2026-11-01 at 02:00
17+ for the same reason as other recent temporary hacks. (Caution:
18+ see “NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA” below.)
19+ This affects only America/Inuvik as the rest of the territory is
20+ covered by America/Edmonton, for which the equivalent change was
21+ released in 2026c.
22+
23+ Changes to past timestamps
24+
25+ Colombia’s 1992-05-02 spring forward was at 00:00, not 24:00.
26+
27+ Iran’s 1979-05-26 spring forward was at 00:00, not 24:00.
28+ (Thanks to N.F. Hase.)
29+
30+ The backward-compatibility names EST5EDT, CST6CDT, MST7MDT, and
31+ PST8PDT now conform better to POSIX. For example, EST5EDT now
32+ always uses the abbreviation "EST" for standard time (now always 5
33+ hours behind UT) and "EDT" for daylight saving time, whereas it
34+ formerly had different UT offsets before standard time was
35+ introduced and sometimes used abbreviations like "LMT", "EWT" and
36+ "EPT", all contrary to POSIX. Also, though not required by POSIX
37+ these names now use US federal rules rather than rules of places
38+ like New York, reverting to 2024a behavior. This change affects
39+ only timestamps before 1966-10-30 at 01:00 standard time.
40+
41+ Other data changes
42+
43+ The temporary hacks used for North American timekeeping changes
44+ now work around a libstdc++ std::chrono bug in GCC 14.1-14.4,
45+ 15.1-15.2, and 16.1; see GCC bug 124851. This data change does
46+ not affect TZif files or timestamps. The change does not work
47+ around the related but less serious GCC bugs 116110 and 124513.
48+ These GCC bugs are all fixed in GCC 16.2.
49+
50+ Changes to code
51+
52+ zic now rejects Link targets that would have invalid names, and
53+ more efficiently processes Expires, Leap and Rule lines with years
54+ far in the past or future. (Thanks to Darren Carreras.)
55+
56+ zic now ports to systems that report lack of link support via
57+ EINVAL, ENOSYS or EPERM errno values. (Thanks to Tom Lane.)
58+
59+ When tzset and related functions encounter a TZif file that is too
60+ large for them, they now consistently fail instead of sometimes
61+ silently ignoring excess parts of the file.
62+
63+ localtime-related functions no longer mishandle extreme timestamps
64+ when given TZif files holding some unlikely timezone histories.
65+ (Problem reported by David Sarkisyan.)
66+
67+ localtime-related functions no longer check the values of TZif
68+ files’ standard/wall and UT/local indicators, which these
69+ functions have not used since 2026a’s removal of the old
70+ posixrules feature.
71+
72+ tzcode has been ported to Haiku.
73+
74+ localtime.c now works again by default on AIX and DragonFly BSD.
75+
76+ zic now rejects ‘:’ and ‘\’ in Zone and Link names when running on
77+ Microsoft Windows. (Problem reported by David Diaz.)
78+
79+ Changes to documentation
80+
81+ URLs for release tarballs in tz-link.html have been updated to
82+ reflect their new canonical URLs on data.iana.org.
83+
84+
385Release 2026c - 2026-07-08 10:23:58 -0700
486
587 Briefly:
@@ -15,7 +97,13 @@ Release 2026c - 2026-07-08 10:23:58 -0700
1597 CST. Although the change to permanent -06 legally took place on
1698 2026-06-18, temporarily model the change to occur on 2026-11-01 at
1799 02:00 instead, for the same reason we introduced a similarly
18- temporary hack for British Columbia in 2026b.
100+ temporary hack for British Columbia in 2026b. (Caution: see
101+ “NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA” below.)
102+
103+ As the change affects both America/Edmonton and its backward
104+ compatibility link, the obsolescent setting TZ="Canada/Mountain"
105+ will now use the abbreviation CST for affected timestamps,
106+ akin to TZ="Canada/Pacific" behavior introduced in 2026b.
19107
20108 Although another TZDB release will likely be needed soon because
21109 Northwest Territories will likely follow Alberta, the legal
@@ -67,6 +155,7 @@ Release 2026b - 2026-04-22 23:06:43 -0700
67155
68156 Briefly:
69157 British Columbia moved to permanent -07 on 2026-03-09.
158+ zic no longer mishandles a last transition to a new time type.
70159 Some more overflow bugs have been fixed in zic.
71160
72161 Changes to future timestamps
@@ -79,9 +168,33 @@ Release 2026b - 2026-04-22 23:06:43 -0700
79168 limitation in CLDR 48.1 (2026-01-08). This temporary hack is
80169 planned to be removed after CLDR is fixed.
81170
171+ To match longstanding practice for -07 standard time in North
172+ America, such as for America/Dawson, America/Dawson_Creek,
173+ America/Fort_Nelson and America/Whitehorse, affected BC
174+ timestamps use the abbreviation MST. As the change affects both
175+ America/Vancouver and its backward compatibility link, the
176+ obsolescent setting TZ="Canada/Pacific" will now use the
177+ abbreviation MST. Future TZDB releases may change the
178+ abbreviation if something else becomes popular across areas
179+ observing -07, and may change it to "-07" if no alphabetic
180+ consensus emerges.
181+
82182 Changes to code
83183
84184 zic no longer mishandles a last transition to a new time type.
185+ NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA:
186+ This zic fix is needed for the temporary hack (mentioned above)
187+ that works around the Canadian timekeeping bug in Unicode CLDR.
188+ Without the fix, the temporary hack causes zic versions 2023d
189+ through 2026a, in their default mode that generates slim output,
190+ to generate a TZif file that violates Internet RFC 9636 §3.3.
191+ The buggy file in turn causes some TZif readers, including tzcode
192+ itself, to ignore America/Vancouver’s 2026-11-01 02:00 transition
193+ from PDT (tm_isdst=1) to MST (tm_isdst=0). Although the buggy
194+ file does not cause any known TZif reader to mishandle UT offsets,
195+ caution is advised when using zic 2023d through 2026a to compile
196+ data from more-recent tz releases. To work around this problem
197+ when using these older zic versions, use ‘zic -b fat’.
85198
86199 zic no longer overflows a buffer when generating a TZ string like
87200 "PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59",
0 commit comments