Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: [email protected]
Control: affects -1 + src:tzdata
User: [email protected]
Usertags: pu
[ Reason ]
A new upstream version of tzdata, 2026a, has been released with a change
for British Columbia which moved to permanent -07 since 2026-03-08.
[ Impact ]
This time the impact of not accepting this update is relatively low, as
the time will only starting to differ starting on 2026-11-01.
[ Tests ]
There are no tests for this change.
[ Risks ]
The risk to import new upstream versions of tzdata are quite low, and is
done routinely. This version is already in testing and sid.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
The 2026b upstream version contains the following changes to
past and future timestamps:
- British Columbia moved to permanent -07 on 2026-03-09.
[ Other info ]
Given the changes are small, I have just uploaded the package.
diff --git a/NEWS b/NEWS
index acd2228..a004270 100644
--- a/NEWS
+++ b/NEWS
@@ -1,10 +1,47 @@
News for the tz database
+Release 2026a - 2026-04-22 23:06:43 -0700
+
+ Briefly:
+ British Columbia moved to permanent -07 on 2026-03-09.
+ 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 works around a
+ limitation in CLDR v48.2 (2026-03-17). This temporary hack is
+ planned to be removed after CLDR is fixed.
+
+ 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.
+
+
Release 2026a - 2026-03-01 22:59:49 -0800
Briefly:
Moldova has used EU transition times since 2022.
- The "right" TZif files are no longer installed by default.
+ The “right” TZif files are no longer installed by default.
-DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds.
TZif files are no longer limited to 50 bytes of abbreviations.
zic is no longer limited to 50 leap seconds.
@@ -25,23 +62,23 @@ Release 2026a - 2026-03-01 22:59:49 -0800
The Makefile no longer by default installs an alternate set
of TZif files for system clocks that count leap seconds.
- Install with 'make REDO=posix_right' to get the old default,
+ Install with ‘make REDO=posix_right’ to get the old default,
which is rarely used in major downstream distributions.
If your system clock counts leap seconds (contrary to POSIX),
- it is better to install with 'make REDO=right_only'.
+ it is better to install with ‘make REDO=right_only’.
This change does not affect the leapseconds file, which is still
installed as before.
- The Makefile's POSIXRULES option, which was declared obsolete in
- release 2019b, has been removed. The Makefile's build procedure
+ The Makefile’s POSIXRULES option, which was declared obsolete in
+ release 2019b, has been removed. The Makefile’s build procedure
thus no longer optionally installs the obsolete posixrules file.
Changes to code
Compiling with the new option -DTZ_RUNTIME_LEAPS=0 disables
runtime support for leap seconds. Although this conforms to
- POSIX, shrinks tzcode's attack surface, and is more efficient,
- it fails to support Internet RFC 9636's leap seconds.
+ POSIX, shrinks tzcode’s attack surface, and is more efficient,
+ it fails to support Internet RFC 9636’s leap seconds.
zic now can generate, and localtime.c can now use, TZif files that
hold up to 256 bytes of abbreviations, counting trailing NULs.
@@ -51,7 +88,7 @@ Release 2026a - 2026-03-01 22:59:49 -0800
zic -L can now generate TZif files with more than 50 leap seconds.
This helps test TZif readers not limited to 50 leap seconds, as
- tzcode's localtime.c is; it has little immediate need for
+ tzcode’s localtime.c is; it has little immediate need for
practical timekeeping as there have been only 27 leap seconds and
possibly there will be no more, due to planned changes to UTC.
zic -v warns if its output exceeds the old 50-second limit.
diff --git a/debian/changelog b/debian/changelog
index af94486..f1285d7 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+tzdata (2026b-0+deb13u1) trixie; urgency=medium
+
+ * New upstream version 2026b:
+ - British Columbia moved to permanent -07 on 2026-03-09, so it will not
+ fall back from -07 to -08 on 2026-11-01.
+
+ -- Aurelien Jarno <[email protected]> Tue, 28 Apr 2026 20:45:23 +0200
+
tzdata (2026a-0+deb13u1) trixie; urgency=medium
* New upstream version 2026a:
diff --git a/northamerica b/northamerica
index 16b79af..3e8641e 100644
--- a/northamerica
+++ b/northamerica
@@ -1957,6 +1957,56 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep
#
https://searcharchives.vancouver.ca/daylight-saving-1918-starts-again-july-7-1941-start-d-s-sept-27-end-of-d-s-1941
# We have no further details, so omit them for now.
+# From Arthur David Olson (2026-03-02):
+# B. C. Gov News: “Adopting permanent daylight saving time: ‘Spring forward’
+# on March 8 will be the last time change, ending twice-yearly clock changes.”
+# https://news.gov.bc.ca/releases/2026AG0013-000209
+#
+# From Paul Eggert (2026-03-07):
+# The law says that 21 hours after the usual 2026-03-08 02:00 switch from
+# PST to PDT, the next day inaugurates the new standard time Pacific Time,
+# i.e., just one clock change but two name changes separated by 21 hours.
+# PT, the obvious abbreviation for Pacific Time, is one letter too short
+# to conform to TZDB’s (and POSIX’s) [-+[:alnum:]]{3,6} requirements.
+# I asked the BC government for advice, with no response. For now, do this:
+# 1. As a temporary hack, pretend that the BC law takes effect
+# not on 2026-03-09 at 00:00, but on 2026-11-01 at 02:00.
+# This pretense works around a limitation in CLDR v48.2 (2026-03-17),
+# which would otherwise say the interval uses “Pacific Standard Time”.
+# (Below, this temporary hack is marked “Temporary hack; see above.”)
+# Strictly speaking this hack is incorrect since the interval uses
+# standard time, but it does have the right UT offset and it
+# works around the CLDR limitation. We should be able to remove
+# the temporary hack after CLDR is fixed.
+# 2. After the BC law takes effect, model the time as MST sans DST.
+# We can change this later if another conforming non-numeric abbreviation
+# for Pacific Time becomes more popular. Possibilities include:
+# MST - the most compatible with existing software and practice,
+# and already used in parts of BC and in Yukon
+# PDT - almost as software-friendly, but confusing because it implies
+# it is DST and is paired with PST, whereas PT is standard time
+# PST - straightforward but even more confusing,
+# and will likely break much software that assumes PST is -08
+# -07 - accurate and clear in itself, but makes BC look odd vs neighbors
+# CPT, CPST - for Canadian Pacific (Standard) Time,
+# by analogy with AEST in Australia
+# P-T - conforming approximation to “PT”
+# PT+ - like P-T but suggesting one-hour advance over PST
+
+# From Chris Walton (2026-03-15):
+# The Regional District of East Kootenay is planning to move to year-round
+# Mountain Standard Time (MST) on November 1, 2026....
+#
https://www.rdek.bc.ca/news/entry/rdek_board_moves_to_transition_to_year_round_mountain_standard_time
+# (2026-03-17):
+# The final decision East Kootenay made a few days ago may turn out not to
+# be final after all. They are going to reopen the debate next month!
+#
https://www.cbc.ca/news/canada/british-columbia/what-time-is-it-in-the-east-kootenay-debate-9.7132624
+# From Paul Eggert (2026-03-17):
+# Mayor Steve Fairbairn of Elkford asked the question be called a second time,
+# saying, “Pardon the pun, but this is not a time-sensitive issue.”
+# For now, merely mention the potential change in these comments.
+# If it happens it would likely affect clocks starting 2027-03-14 at 02:00.
+
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Vanc 1918 only - Apr 14 2:00 1:00 D
Rule Vanc 1918 only - Oct 27 2:00 0 S
@@ -1970,7 +2020,11 @@ Rule Vanc 1962 2006 - Oct lastSun
2:00 0 S
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Vancouver -8:12:28 - LMT 1884
-8:00 Vanc P%sT 1987
- -8:00 Canada P%sT
+ -8:00 Canada P%sT 2026 Mar 9
+ # Temporary hack; see above.
+ -8:00 1:00 PDT 2026 Nov 1 02:00
+ # End of temporary hack.
+ -7:00 - MST
Zone America/Dawson_Creek -8:00:56 - LMT 1884
-8:00 Canada P%sT 1947
-8:00 Vanc P%sT 1972 Aug 30 2:00
diff --git a/version b/version
index 5d91260..75d34ee 100644
--- a/version
+++ b/version
@@ -1 +1 @@
-2026a
+2026b
diff --git a/zone.tab b/zone.tab
index 2626b05..2ae8a8c 100644
--- a/zone.tab
+++ b/zone.tab
@@ -124,12 +124,12 @@ CA +5017-10750 America/Swift_Current CST -
SK (midwest)
CA +5333-11328 America/Edmonton Mountain - AB, BC(E), NT(E),
SK(W)
CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west)
CA +682059-1334300 America/Inuvik Mountain - NT (west)
+CA +4916-12307 America/Vancouver MST - BC (most areas)
CA +4906-11631 America/Creston MST - BC (Creston)
CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John)
CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson)
CA +6043-13503 America/Whitehorse MST - Yukon (east)
CA +6404-13925 America/Dawson MST - Yukon (west)
-CA +4916-12307 America/Vancouver Pacific - BC (most areas)
CC -1210+09655 Indian/Cocos
CD -0418+01518 Africa/Kinshasa Dem. Rep. of Congo (west)
CD -1140+02728 Africa/Lubumbashi Dem. Rep. of Congo (east)
diff --git a/zone1970.tab b/zone1970.tab
index cd43e3d..a9b47bc 100644
--- a/zone1970.tab
+++ b/zone1970.tab
@@ -115,11 +115,11 @@ CA +5017-10750 America/Swift_Current CST -
SK (midwest)
CA +5333-11328 America/Edmonton Mountain - AB, BC(E), NT(E),
SK(W)
CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west)
CA +682059-1334300 America/Inuvik Mountain - NT (west)
+CA +4916-12307 America/Vancouver MST - BC (most areas)
CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John)
CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson)
CA +6043-13503 America/Whitehorse MST - Yukon (east)
CA +6404-13925 America/Dawson MST - Yukon (west)
-CA +4916-12307 America/Vancouver Pacific - BC (most areas)
CH,DE,LI +4723+00832 Europe/Zurich Büsingen
CI,BF,GH,GM,GN,IS,ML,MR,SH,SL,SN,TG +0519-00402 Africa/Abidjan
CK -2114-15946 Pacific/Rarotonga
diff --git a/zonenow.tab b/zonenow.tab
index aa3a64f..54e4485 100644
--- a/zonenow.tab
+++ b/zonenow.tab
@@ -58,6 +58,9 @@ XX -2504-13005 Pacific/Pitcairn Pitcairn
# -08/-07 - PST/PDT (North America DST)
XX +340308-1181434 America/Los_Angeles Pacific (PST/PDT) - US &
Canada; Mexico near US border
#
+# -08/-07 - PST/PDT (North America DST) until 2026-11-01 02:00; then MST
+XX +4916-12307 America/Vancouver MST - BC (most areas)
+#
# -07 - MST
XX +332654-1120424 America/Phoenix Mountain Standard (MST) - Arizona;
western Mexico; Yukon
#
