Import tzdata 2026b

FreeBSD/src

Fork 0

mirror of https://git.FreeBSD.org/src.git synced 2026-06-02 11:24:32 +00:00

Browse Source

This commit is contained in:

Philip Paeps

2026-04-23 22:59:30 +08:00

parent 18b0e604df

commit def146fe2a

6 changed files with 106 additions and 12 deletions

NEWS

+45 -8

View File

 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.
     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
+    The Makefile’s POSIXRULES option, which was declared obsolete in
-    release 2019b, has been removed.  The Makefile's build procedure
+    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,
+    POSIX, shrinks tzcode’s attack surface, and is more efficient,
-    it fails to support Internet RFC 9636's leap seconds.
+    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.
     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.

northamerica

+55 -1

View File

 # 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
 # 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

version

+1 -1

View File

`@@ -1 +1 @@`
	`2026a`	`2026b`

zone.tab

+1 -1

View File

 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)

zone1970.tab

+1 -1

View File

 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

zonenow.tab

View File

 # -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
 #