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, 2026f, has been released with a change
for Cuba, which will not fall back to -05 on 2026-11-01.
[ Impact ]
If this version is not accepted, the clock of users in Cuba will start
differing on 2026-11-01.
[ Tests ]
There are no tests for these changes.
[ Risks ]
The risks to import new upstream versions of tzdata are quite low, and
is done routinely. This version just got uploaded to unstable and is not
yet in testing. However this time the changes are relatively small,
compensating the risks of a less tested (in debian) release.
[ 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 2026f upstream version contains the following change to
future timestamps:
- Cuba will not fall back to -05 on 2026-11-01 and instead plans to
maintain -04 through 2027-11-07.
It also contains some historical changes for Brazil and Ukraine, and
updates to the comments regarding the ongoing Canadian changes. It also
changes the comments of the leapseconds file to explain the expiration
date in that file is now obsolete.
In addition the debian packaging includes an update of the upstream
signing key, given it was expired.
[ Other info ]
Given that the next point release is scheduled for Nov 14, this will
need to go through stable-updates.
I have just uploaded the package to the archive.
diff -Nru tzdata-2026e/backzone tzdata-2026f/backzone
--- tzdata-2026e/backzone 2026-09-22 03:49:27.000000000 +0200
+++ tzdata-2026f/backzone 2026-10-13 23:05:24.000000000 +0200
@@ -1577,27 +1577,6 @@
2:00 Russia EE%sT 1992 Jan 19 2:00
3:00 Russia MSK/MSD
-# Ukraine
-#
-# Although Shanks & Pottenger say Transcarpathia used CET 1990/1991,
-# this unreliable source contradicts contemporaneous government resolutions
-# (see the commentary for Ukraine in the 'europe' file)
-# so for now this dubious zone is in 'backzone'.
-# "Uzhhorod" is the transliteration of the Ukrainian spelling, but
-# "Uzhgorod" was a common English spelling when this dubious zone was
-# added to TZDB in 1999.
-Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct
- 1:00 - CET 1940
- 1:00 C-Eur CE%sT 1944 Oct
- 1:00 1:00 CEST 1944 Oct 26
- 1:00 - CET 1945 Jun 29
- 3:00 Russia MSK/MSD 1990
- 3:00 - MSK 1990 Jul 1 2:00
- 1:00 - CET 1991 Mar 31 3:00
- 2:00 - EET 1992 Mar 20
- 2:00 C-Eur EE%sT 1996 May 13
- 2:00 EU EE%sT
-
# Liechtenstein
# From Paul Eggert (2022-07-21):
@@ -1620,25 +1599,6 @@
1:00 - CET 1982 Nov 27
1:00 EU CE%sT
-# Ukraine
-
-# Although Shanks & Pottenger say Zaporizhzhia and eastern Lugansk
-# observed DST 1990/1991, this unreliable source contradicts contemporaneous
-# government resolutions (see the commentary for Ukraine in the 'europe' file)
-# so for now this dubious zone is in 'backzone'.
-# "Zaporizhzhia" is the transliteration of the Ukrainian name, but
-# "Zaporozhye" was a common English spelling when this dubious zone was
-# added to TZDB in 1999.
-Zone Europe/Zaporozhye 2:20:40 - LMT 1880
- 2:20 - +0220 1924 May 2
- 2:00 - EET 1930 Jun 21
- 3:00 - MSK 1941 Aug 25
- 1:00 C-Eur CE%sT 1943 Oct 25
- 3:00 Russia MSK/MSD 1991 Mar 31 2:00
- 2:00 E-Eur EE%sT 1992 Mar 20
- 2:00 C-Eur EE%sT 1996 May 13
- 2:00 EU EE%sT
-
# Madagascar
Zone Indian/Antananarivo 3:10:04 - LMT 1911 Jul
3:00 - EAT 1954 Feb 27 23:00s
diff -Nru tzdata-2026e/debian/changelog tzdata-2026f/debian/changelog
--- tzdata-2026e/debian/changelog 2026-10-17 22:28:09.000000000 +0200
+++ tzdata-2026f/debian/changelog 2026-10-28 21:57:59.000000000 +0100
@@ -1,3 +1,13 @@
+tzdata (2026f-0+deb13u1) trixie; urgency=medium
+
+ * New upstream version 2026f:
+ - Cuba will not fall back to -05 on 2026-11-01 and instead plans to
+ maintain -04 through 2027-11-07
+ - Mention that the "expires" in the leapseconds file is now obsolete
+ * Update debian/upstream/signing-key.asc
+
+ -- Aurelien Jarno <[email protected]> Wed, 28 Oct 2026 21:57:59 +0100
+
tzdata (2026e-0+deb13u1) trixie; urgency=medium
* New upstream version 2026d:
diff -Nru tzdata-2026e/debian/upstream/signing-key.asc
tzdata-2026f/debian/upstream/signing-key.asc
--- tzdata-2026e/debian/upstream/signing-key.asc 2026-10-17
22:28:09.000000000 +0200
+++ tzdata-2026f/debian/upstream/signing-key.asc 2026-10-28
21:57:59.000000000 +0100
@@ -13,18 +13,18 @@
nrQzvJbBn6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQAB
tCBQYXVsIEVnZ2VydCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PokCVQQTAQgAPwIbAwYL
CQgHAwIGFQgCCQoLBBYCAwECHgECF4AWIQR+N5Kp2Kz31jO8FYjtl+kOYqp+NAUC
-YTAc/AUJHhWsGAAKCRDtl+kOYqp+NBKwD/9Qise9/wZsD8Nyl+ADOCIAFZY5qlSl
-/5SyCjJIRc6cx/Z0fm4yJVH2Tf3GlSBk1uW24z8+mB2ZxFQUGjio/2iDndSqxYR4
-qvPGudo4RGvdvhw6LLqTdRsAY4947xLpNUO6gDtZsRpn4isn+ViX85XfGJrIFjBm
-zj70eMxEZZrz1IMfUB5I/2oNGDsXDZlCUU30RFMYChGA1ofpIHWdAs+lW2jVBfeE
-Lbi2su+oUpqrx83u0eJQg3RY3jmPjw8snHS4ieXpvS0e89qziBlNCqS59qJHaf4G
-XCjz+o5gap2e0NEeQYqcyCqAfqjI78KEpVJNQx5D/zSOvnNs6KuzWD7No4nb5A3p
-A6KA1JAwJW0H3F2+RhTEg+kFxpcCen0jjuFBnE3TfO3RSpSGqZN0j4AkuR6h/+I7
-uUfaQAAope4mso/9VBEElaHYTQmA/m4/AXb2Kt/qkt6QgUIyJtSKcMCVTbfL6iIj
-rzu4EzkjtZJkbAfvU8lpkUsWX2Qwo25MwyxyzsHMUq9ccIRPEiI0hVu7jeFAql6c
-ql/3KUWvSr8QCyn7KWhfxyzy6j0+2xtQ29LHAOhboawJJoZd+PtintzHSSZ6G+8T
-Xn3EbjmHHlXWWfnvWyaJCuJzf1PybRgNYqL6EXCHRHCIb4S9Av8sJpJzZiskG1v5
-WUkv79aHb1ol17kCDQRMgHJkARAApoXrvxP3DIfjCNOtXU/PdwMShKdX/RlSs5Pf
+amTy1wUJJ0qB8wAKCRDtl+kOYqp+NM8EEACBtAREofFYaCcNfFDUob0r/8baklxb
+TZ0xgktDciP02O+HxL+w4Il/e7TMbVN8AH90ttdRq5+si6j7158Y72T8vo8M9YFc
+Xtfbs4W10VgemiN+GX0Ij4BEfrS5AcPAOObn9t4yuSS8WhGaKbLHuZkQzcklxcY3
+C8/PVJdq0G8TVszGuZOnwsh8ZhKCkU13BdK/qJuAAxUDtIGOHYclh89GkE0mzbnv
+RrhDWe2Jr+8O8zrWIJvTk3m66m6Yk8elpU4yLt/OzFxXF9CFFgcIAYX4A4xe6L70
+lxee0AA/ZXLGcWnms93JLi2WKHlJNvFhvM2ONjuUicAx8B+agi03mTuFZ5wS5tbB
+FXna59czf/EGOTJO5J7n8f15MCzNp/gO4B4kT/P4Y51aoA+MQtDczq93w3WsOBpI
+hWsrP2xoG3rKLhM3P4JWe1uGcU1MaIjwXcHLftUvrrUFH0gXxF2mOPguXBBy5uCU
+/ju7ibodNW0w5RLprvpAPp+P9HuoSBedb/H8nI20366toUarkuHPH/Si3SFhvKjY
+ZZxHGqRIPpZyf86HCupfZSIAkphci6x0aSdGfueBrCytjRappmP/6y3nAwQy/wdk
+xHor6c1ywnedybMIjBHDfh5zW3xrbv9I4ggHGYb4rdIbmDeMoLhFhZWWxAW0jDfS
+OvXd690VUaQ7QbkCDQRMgHJkARAApoXrvxP3DIfjCNOtXU/PdwMShKdX/RlSs5Pf
unV1wbKP8herXHrvQdFVqECaTSxmlhzbk8X0PkY9gcVaU2O49T3qsOd1cHeF52YF
GEt0LhsBeMjgNX5uZ1V76r8gyeVlFpWWb0SIwJUBHrDXexF67upeRb2vdHBjYDNe
ySn+0B7gFEqvVmZu+LadudDp6kQLjatFvHQHUSGNshBnkkcaTbiI9Pst0GCc2aiz
@@ -35,18 +35,18 @@
+F+uDDI+uYkRxUFp92ykmdhDEFg1yjYsU8iGU69aHyvhq36z4zctvbqhRNzOWB1b
VJ/dIMDvsExGcXQVDIT7sDNXv0wE3jKSKpp7NDG1oXUXL+2+SF99Kjy753AbQSAm
H617fyBNwhJWvQYg+mUvPpiGOtses9EXUI3lS4v0MEaPG43flEs1UR+1rpFQWVHo
-1y1OO+sAEQEAAYkCPAQYAQgAJgIbDBYhBH43kqnYrPfWM7wViO2X6Q5iqn40BQJh
-MB1RBQkeFaxtAAoJEO2X6Q5iqn40d5QP/iRm1LyrCKbMdqgP9ShOcPH7UfFEr4SY
-2TDdQgE4L+QItP16RNgTxAkxaBxK95I0nletr03inRKwsb0dIw/BH2LXbG2DjI6y
-KJK6UThVhWWBXYuGjSv2i6bVIzHLRY3IOQF+8dyVJ+voeaOtxdV1lYR1ke/Dv6pF
-qUGGNBsSVu/2R03uCffTA9OsRzbuV5mJrFgxVFmBAguLN/cT5Ffh77x3LsA61Ro3
-hIX4399GFFBQ3h4RfMA1nNWiU0KjNy/GtW0amxn26zhqQvy0W0hEJRA6ts+e/4ZH
-wcX3U7NTnPTckbCyy71d7U8/AVHkoy7EB8ROcDbJHTJcKlG9f6eYlPZ2aYVqBd9n
-1Yj4NYT1zobrQjvHQRCUAx0naKscN2es9x/rWvg4BnnBcXRaT2a8Wy3pKzLGD61d
-stvUM7tnyvdBxHk7aLlbdsfZP+flP2tbHkFNZWH5myPElPMcQGFYyi9to+4YZU28
-G3rnzxmKFWkYAEMaxPZPunOZnOBHURFhgk/qs6GYSTPvg0u/kd1JV2yOKHb8+SB/
-Dpk/gx9KybTUC3TtbW1b2X94ErB8LCmpMi26a3ZvyxrE5DJx2GdUoj2QkKTSFQV7
-MOo1tJ9vwtSfHnpT/+E6yKtzCLl9CNiVjd57puN1BhWCVvLwfAzUC2UvpPYh8u3m
-aJaMAC6BgK78
-=tMLq
+1y1OO+sAEQEAAYkCPAQYAQgAJgIbDBYhBH43kqnYrPfWM7wViO2X6Q5iqn40BQJq
+ZPLjBQknSoH/AAoJEO2X6Q5iqn401toP/2MQrta0PI/cAmw9jtjX0cQtE8fCnLd0
+isgRzXPY6tM5uPpYH6szIuNb+gEqtE8v2dQ+vMczl65JpoFjLCSlHDGNtya3xBdt
+koapbFfuKU52vAi0drtXJuRUHppwZA9Fo+dubKWgGHnlNT8c14V8vgj2myIfFLWz
+W7SXbQRh2flr/ZYAK0mFSy+q/l9ToByUz5EAAK4lGZcpRpemXIDSMlW722nYiMhN
+1f5/pHpQ6mQ4GFNHdUgeMh2XGzWUh7iKnJB3ZyqoxxgMChw+/XdoVLdRRAEqnyl7
+FEA8edJtJuICY+bP3AMAPSn/AbmyoWXWjP5GVRmlhHM0443mM05Wtvhj7TgEm1bN
+/oxSIyMnq0ZUKeXAOAivzY/wHH3AfRrYBA0UgKwtOC1FrPDYxzXI1VLsaqeymGOp
+l/frRI2fFpWRmSXgH/1OrJXWYf1Iho6Iqv6HUapjh6vu7rpRQ3QnNoc9Z3INQi9x
+MPyLI+AUK0XDAToBV7B7vmvDfgdZul8O+5OrSD8Azl40DvIbJJ9EgUYCdiXFn4Ga
+uo7Q7j/4XRnqOeXrqh9j6XAxXBBu/t9A4irf+sHmGTLKkMJc4PQXT2EfHn6AnJC+
+LmeHPXtO0uwbd3HDXZaclD722FYx2HyxW3hJw+5bw27/WoNZ4ur9v+FmfednmWwO
+gB3wog+PrHIZ
+=cACl
-----END PGP PUBLIC KEY BLOCK-----
diff -Nru tzdata-2026e/leapseconds tzdata-2026f/leapseconds
--- tzdata-2026e/leapseconds 2026-07-06 15:08:50.000000000 +0200
+++ tzdata-2026f/leapseconds 2026-10-16 02:10:21.000000000 +0200
@@ -1,4 +1,4 @@
-# Allowance for leap seconds added to each time zone file.
+# Leap seconds (1972-2016) optionally added to TZif files.
# This file is in the public domain.
@@ -6,7 +6,7 @@
# NIST/IERS format leap-seconds.list file, which can be copied from
# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>
# or via a less-secure protocol and with different comments and
-# less volatile last-modified and expiration timestamps, from
+# less volatile timestamp metadata, from
# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>.
# For more about leap-seconds.list, please see
# The NTP Timescale and Leap Seconds
@@ -18,10 +18,8 @@
# (ITU-R) Recommendation TF.460-6 (02/2002)
# <https://www.itu.int/rec/R-REC-TF.460-6-200202-I/>.
# The International Earth Rotation and Reference Systems Service (IERS)
-# periodically uses leap seconds to keep UTC to within 0.9 s of UT1
-# (a proxy for Earth's angle in space as measured by astronomers)
-# and publishes leap second data in a copyrighted file
-# <https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat>.
+# periodically used leap seconds to keep UTC to within 0.9 s of UT1
+# (a proxy for Earth's angle in space as measured by astronomers).
# See: Levine J. Coordinated Universal Time and the leap second.
# URSI Radio Sci Bull. 2016;89(4):30-6. doi:10.23919/URSIRSB.2016.7909995
# <https://ieeexplore.ieee.org/document/7909995>.
@@ -33,8 +31,8 @@
# of UTC.
# All leap-seconds are Stationary (S) at the given UTC time.
-# The correction (+ or -) is made at the given time, so in the unlikely
-# event of a negative leap second, a line would look like this:
+# The correction (+ or -) is made at the given time, so if a negative
+# leap second had ever occurred, a line would have looked like this:
# Leap YEAR MON DAY 23:59:59 - S
# Typical lines look like this:
# Leap YEAR MON DAY 23:59:60 + S
@@ -67,8 +65,9 @@
Leap 2016 Dec 31 23:59:60 + S
# UTC timestamp when this leap second list expires.
-# Any additional leap seconds will come after this.
-# This Expires line is commented out for now,
+# The idea was that any additional leap seconds would come after this.
+# This timestamp is obsolete as there will be no more leap seconds.
+# This Expires line is commented out, to avoid confusion, and
# so that pre-2020a zic implementations do not reject this file.
#Expires 2027 Jun 28 00:00:00
@@ -76,10 +75,9 @@
# "#updated" gives the last time the leap seconds data changed
# or, if this file was derived from the IERS leap-seconds.list,
# the last time that file changed in any way.
-# "#expires" gives the first time this file might be wrong;
-# if this file was derived from the IERS leap-seconds.list,
-# this is typically a bit less than one year after "updated".
#updated 1783323897 (2026-07-06 07:44:57 UTC)
+# "#expires" gives the first time this file might be wrong.
+# This timestamp is obsolete as there will be no more leap seconds.
#expires 1814140800 (2027-06-28 00:00:00 UTC)
# Updated through IERS Bulletin C
(https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
diff -Nru tzdata-2026e/leapseconds.awk tzdata-2026f/leapseconds.awk
--- tzdata-2026e/leapseconds.awk 2025-04-24 21:25:58.000000000 +0200
+++ tzdata-2026f/leapseconds.awk 2026-10-16 02:10:20.000000000 +0200
@@ -5,18 +5,11 @@
# This program uses awk arithmetic. POSIX requires awk to support
# exact integer arithmetic only through 10**10, which means for NTP
# timestamps this program works only to the year 2216, which is the
-# year 1900 plus 10**10 seconds. However, in practice
-# POSIX-conforming awk implementations invariably use IEEE-754 double
-# and so support exact integers through 2**53. By the year 2216,
-# POSIX will almost surely require at least 2**53 for awk, so for NTP
-# timestamps this program should be good until the year 285,428,681
-# (the year 1900 plus 2**53 seconds). By then leap seconds will be
-# long obsolete, as the Earth will likely slow down so much that
-# there will be more than 25 hours per day and so some other scheme
-# will be needed.
+# year 1900 plus 10**10 seconds. However, this is not a practical problem
+# as the last leap second was in 2016 and there will be no more.
BEGIN {
- print "# Allowance for leap seconds added to each time zone file."
+ print "# Leap seconds (1972-2016) optionally added to TZif files."
print ""
print "# This file is in the public domain."
print ""
@@ -24,7 +17,7 @@
print "# NIST/IERS format leap-seconds.list file, which can be copied from"
print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>"
print "# or via a less-secure protocol and with different comments and"
- print "# less volatile last-modified and expiration timestamps, from"
+ print "# less volatile timestamp metadata, from"
print "# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
print "# For more about leap-seconds.list, please see"
print "# The NTP Timescale and Leap Seconds"
@@ -36,10 +29,8 @@
print "# (ITU-R) Recommendation TF.460-6 (02/2002)"
print "# <https://www.itu.int/rec/R-REC-TF.460-6-200202-I/>."
print "# The International Earth Rotation and Reference Systems Service
(IERS)"
- print "# periodically uses leap seconds to keep UTC to within 0.9 s of UT1"
- print "# (a proxy for Earth's angle in space as measured by astronomers)"
- print "# and publishes leap second data in a copyrighted file"
- print "# <https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat>."
+ print "# periodically used leap seconds to keep UTC to within 0.9 s of UT1"
+ print "# (a proxy for Earth's angle in space as measured by astronomers)."
print "# See: Levine J. Coordinated Universal Time and the leap second."
print "# URSI Radio Sci Bull. 2016;89(4):30-6.
doi:10.23919/URSIRSB.2016.7909995"
print "# <https://ieeexplore.ieee.org/document/7909995>."
@@ -51,8 +42,8 @@
print "# of UTC."
print ""
print "# All leap-seconds are Stationary (S) at the given UTC time."
- print "# The correction (+ or -) is made at the given time, so in the
unlikely"
- print "# event of a negative leap second, a line would look like this:"
+ print "# The correction (+ or -) is made at the given time, so if a negative"
+ print "# leap second had ever occurred, a line would have looked like this:"
print "# Leap YEAR MON DAY 23:59:59 - S"
print "# Typical lines look like this:"
print "# Leap YEAR MON DAY 23:59:60 + S"
@@ -108,16 +99,15 @@
sstamp_to_ymdhMs(expires, ss_NTP)
print "# UTC timestamp when this leap second list expires."
- print "# Any additional leap seconds will come after this."
+ print "# The idea was that any additional leap seconds would come after
this."
+ print "# This timestamp is obsolete as there will be no more leap
seconds."
if (! EXPIRES_LINE) {
- print "# This Expires line is commented out for now,"
+ print "# This Expires line is commented out, to avoid confusion, and"
print "# so that pre-2020a zic implementations do not reject this file."
}
printf "%sExpires %.4d\t%s\t%.2d\t%.2d:%.2d:%.2d\n", \
EXPIRES_LINE ? "" : "#", \
ss_year, monthabbr[ss_month], ss_mday, ss_hour, ss_min, ss_sec
- } else {
- print "# (No Expires line, since the expires time is unknown.)"
}
# The difference between the NTP and POSIX epochs is 70 years
@@ -130,9 +120,6 @@
print "# \"#updated\" gives the last time the leap seconds data changed"
print "# or, if this file was derived from the IERS leap-seconds.list,"
print "# the last time that file changed in any way."
- print "# \"#expires\" gives the first time this file might be wrong;"
- print "# if this file was derived from the IERS leap-seconds.list,"
- print "# this is typically a bit less than one year after \"updated\"."
if (updated) {
sstamp_to_ymdhMs(updated, ss_NTP)
printf "#updated %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \
@@ -142,12 +129,12 @@
print "#(updated time unknown)"
}
if (expires) {
+ print "# \"#expires\" gives the first time this file might be wrong."
+ print "# This timestamp is obsolete as there will be no more leap
seconds."
sstamp_to_ymdhMs(expires, ss_NTP)
printf "#expires %d (%.4d-%.2d-%.2d %.2d:%.2d:%.2d UTC)\n", \
expires - epoch_minus_NTP, \
ss_year, ss_month, ss_mday, ss_hour, ss_min, ss_sec
- } else {
- print "#(expires time unknown)"
}
printf "\n%s", last_lines
}
diff -Nru tzdata-2026e/Makefile tzdata-2026f/Makefile
--- tzdata-2026e/Makefile 2026-08-30 08:01:32.000000000 +0200
+++ tzdata-2026f/Makefile 2026-10-25 06:34:23.000000000 +0100
@@ -129,6 +129,9 @@
# What kind of TZif data files to generate. (TZif is the binary time
# zone data format that zic generates; see Internet RFC 9636.)
+# Although TZif files with leap second info are rarely used and the last
+# leap second was in 2016, they are still supported for compatibility
+# with historical timestamps generated via TZif files with leap seconds.
# If you want only POSIX time, with time values interpreted as
# seconds since the epoch (not counting leap seconds), use
# REDO= posix_only
@@ -151,14 +154,17 @@
REDO= posix_only
# Whether to put an "Expires" line in the leapseconds file.
-# Use EXPIRES_LINE=1 to put the line in, 0 to omit it.
-# The EXPIRES_LINE value matters only if REDO's value contains "right".
+# Use EXPIRES_LINE=1 to put the "Expires" line in, 0 to omit it.
+# This variable is obsolescent and should be removed in a future release.
+# It defaults to 0 because the circa 2020 effort to support it
+# became obsolete after the 2026 decision to discontinue leap seconds.
+# The EXPIRES_LINE value does not affect the contents of TZif files;
+# it affects only the leapseconds file itself, so it matters only if
+# the leapseconds file is used directly by third-party software.
# If you change EXPIRES_LINE, remove the leapseconds file before running
"make".
# zic's support for the Expires line was introduced in tzdb 2020a,
-# and was modified in tzdb 2021b to generate version 4 TZif files.
-# EXPIRES_LINE defaults to 0 for now so that the leapseconds file
-# can be given to pre-2020a zic implementations and so that TZif files
-# built by newer zic implementations can be read by pre-2021b libraries.
+# was modified in tzdb 2021b to generate version 4 TZif files,
+# and was removed after tzdb 2026e was released.
EXPIRES_LINE= 0
# To install data in text form that has all the information of the TZif data,
@@ -317,6 +323,8 @@
# It also costs CPU time and memory.
# -Dtime_tz=\"T\" to use T as the time_t type, rather than the system time_t
# This is intended for internal use only; it mangles external names.
+# -DMIN_TRANSITION_GAP=N to reject TZif files containing transitions
+# separated by fewer than N seconds. See localtime.c.
# -DTZ_CHANGE_INTERVAL=N if functions depending on TZ should check
# no more often than every N seconds for TZif file changes.
# If N is negative (the default), no such checking is done.
diff -Nru tzdata-2026e/NEWS tzdata-2026f/NEWS
--- tzdata-2026e/NEWS 2026-09-30 02:15:52.000000000 +0200
+++ tzdata-2026f/NEWS 2026-10-28 07:18:08.000000000 +0100
@@ -1,5 +1,66 @@
News for the tz database
+Release 2026f - 2026-10-27 23:16:49 -0700
+
+ Briefly:
+ Cuba will not fall back 2026-11-01; stays on -04 through 2027-11-07.
+ No more leap seconds, and leap second tables no longer expire.
+ Improve 1965/1966 data for Brazil.
+
+ Changes to future timestamps
+
+ Cuba will not fall back to -05 on 2026-11-01 and instead plans to
+ maintain -04 through 2027-11-07.
+
+ Changes to past timestamps
+
+ In 1965 Brazil ended DST on 03-31 at 24:00 not 00:00, and in 1966
+ it ended DST on 03-01 at 01:00 not 00:00. (Thanks to Daniel Dias
+ Rodrigues.)
+
+ Changes to code
+
+ zic now ignores Expires lines, as leap second tables in TZif files
+ no longer expire now that there are no more leap seconds;
+ see Internet RFC 9636 §3.2. (Thanks to Garrett Wollman for the
+ heads-up re no more leap seconds.)
+
+ localtime.c no longer supports 49 leap seconds, as 27 now suffice.
+ zic now warns if you go over the new limit.
+
+ A new compile-time flag -DMIN_TRANSITION_GAP=N specifies a minimum
+ transition gap of N seconds when reading TZif files. It currently
+ defaults to 0, but can be set to 1 if TZif files generated by zic
+ 2021b and earlier are no longer of concern.
+
+ With 32-bit time_t, localtime.c functions now check for transition
+ ordering in TZif data as carefully as they do with 64-bit time_t.
+ (Problem reported by Ana Bobillo.)
+
+ On platforms like FreeBSD that have O_RESOLVE_BENEATH but lack
+ O_REGULAR, localtime.c compiled with -DOPENAT_TZDIR now checks
+ that a TZ setting with ".." components names a regular file
+ before opening it in an unprivileged program, as it already did
+ for other settings that might name a file outside TZDIR.
+ This fixes a bug introduced in 2026c. (Thanks to Ana Bobillo.)
+
+ Changes to documentation and commentary
+
+ Documentation and commentary now reflect leap seconds’ demise.
+
+ Changes to commentary
+
+ Discussion on timekeeping in northwestern Ontario has been updated
+ to reflect that provincial regulation has been issued to allow these
+ areas to stay aligned with America/Winnipeg and follow Manitoba’s
+ adoption of year-round -05 after all. (Thanks to Aoun Khan,
+ Chris Walton, and Heitor David Pinto.)
+
+ Discussion on timekeeping in Saskatchewan has been updated to
+ document its new Time Act, 2026 which comes into force on
+ 2026-10-30. (Thanks to Heitor David Pinto.) No change is expected.
+
+
Release 2026e - 2026-09-29 17:14:38 -0700
Briefly:
@@ -12,7 +73,10 @@
its traditional abbreviation EST. Although the change to
permanent -05 legally takes place on 2026-10-31, temporarily model
the change to occur on 2026-11-01 at 02:00 for the same reason as
- other recent temporary hacks. (Caution: see “NOTE FOR 2026b
+ other recent temporary hacks. This new temporary hack works
+ around a limitation in Unicode CLDR 48.2.2 (2026-09-21)
+ and ICU 78.3 (2026-03-17), and is planned to be removed after
+ CLDR and ICU are fixed. (Caution: see “NOTE FOR 2026
TEMPORARY HACK FOR CLDR AND CANADA” below.)
As the change affects both America/Winnipeg and its backward
@@ -22,7 +86,7 @@
Another TZDB release may be needed soon if any of the portions of
northwestern Ontario historically aligned with America/Winnipeg do
- not follow. For now, given the short leadtime with Manitoba’s
+ not follow. For now, given the short lead time with Manitoba’s
announcement, assume that they will, to avoid creating new zones
that may not be needed if no divergence occurs.
@@ -52,8 +116,11 @@
Model this with its traditional abbreviation CST. Although the
change to permanent -06 legally took place on 2026-08-21,
temporarily model the change to occur on 2026-11-01 at 02:00
- for the same reason as other recent temporary hacks. (Caution:
- see “NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA” below.)
+ for the same reason as other recent temporary hacks.
+ This new temporary hack works around a limitation in Unicode CLDR
+ 48.2.1 (2026-07-08) and and ICU 78.3 (2026-03-17), and is planned
+ to be removed after CLDR and ICU are fixed. (Caution:
+ see “NOTE FOR 2026 TEMPORARY HACK FOR CLDR AND CANADA” below.)
This affects only America/Inuvik as the rest of the territory is
covered by America/Edmonton, for which the equivalent change was
released in 2026c.
@@ -135,8 +202,11 @@
CST. Although the change to permanent -06 legally took place on
2026-06-18, temporarily model the change to occur on 2026-11-01 at
02:00 instead, for the same reason we introduced a similarly
- temporary hack for British Columbia in 2026b. (Caution: see
- “NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA” below.)
+ temporary hack for British Columbia in 2026b. This new temporary
+ hack works around a limitation in Unicode CLDR 48.1 (2026-01-08)
+ and ICU 78.2 (2025-01-30), and is planned to be removed after CLDR
+ and ICU are fixed. (Caution: see “NOTE FOR 2026 TEMPORARY HACK
+ FOR CLDR AND CANADA” below.)
As the change affects both America/Edmonton and its backward
compatibility link, the obsolescent setting TZ="Canada/Mountain"
@@ -202,9 +272,10 @@
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 48.1 (2026-01-08). This temporary hack is
- planned to be removed after CLDR is fixed.
+ 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,
@@ -217,15 +288,15 @@
observing -07, and may change it to "-07" if no alphabetic
consensus emerges.
- Changes to code
+ NOTE FOR 2026 TEMPORARY HACK FOR CLDR AND CANADA:
- zic no longer mishandles a last transition to a new time type.
- NOTE FOR 2026b TEMPORARY HACK FOR CLDR AND CANADA:
- This zic fix is needed for the temporary hack (mentioned above)
- that works around the Canadian timekeeping bug in Unicode CLDR.
- Without the fix, the temporary hack causes zic versions 2023d
- through 2026a, in their default mode that generates slim output,
- to generate a TZif file that violates Internet RFC 9636 §3.3.
+ 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
@@ -234,6 +305,10 @@
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.)
@@ -5318,9 +5393,9 @@
foreseeable future, though 2012 is all we're fairly certain of.)
Armenia has abolished Summer Time.
Tokelau jumped the International Date Line back last December
- (just the same as their near neighbour, Samoa).
+ (just the same as their near neighbor, Samoa).
America/Creston is a new zone for a small area of British Columbia
- There will be a leapsecond 2012-06-30 23:59:60 UTC.
+ There will be a leap second 2012-06-30 23:59:60 UTC.
Other minor changes are:
Corrections to 1918 Canadian summer time end dates.
diff -Nru tzdata-2026e/northamerica tzdata-2026f/northamerica
--- tzdata-2026e/northamerica 2026-09-29 23:12:34.000000000 +0200
+++ tzdata-2026f/northamerica 2026-10-27 18:24:00.000000000 +0100
@@ -1752,16 +1752,11 @@
# been aligned with neighboring Manitoba and use America/Winnipeg, in
# accordance with section 2(2) of Ontario's Time Act, RSO 1990 chapter T.9:
# https://www.ontario.ca/laws/statute/90t09
-# With Manitoba now opting to stay on -05 year-round, if any of these areas do
-# not follow, it would require a new zone; however, given the short leadtime
-# ahead of a potential divergence on 2026-11-01 and in the interest of not
-# creating zones that may not be needed, assume for the time being that they
-# will.
#
# In practice, there are several exceptions to the 90°W dividing line set by
# the province, all of which technically contravene the official Ontario rules:
-# - An area around Big Trout Lake in Kenora District observes Central Time
-# (-06/-05) despite extending east of 90°W.
+# - An area around Big Trout Lake in Kenora District aligns with
+# America/Winnipeg despite extending east of 90°W.
# - An area around Upsala in the southwest of Thunder Bay District observes
# Eastern Time (-05/-04) like America/Toronto despite extending west of
# 90°W.
@@ -1773,9 +1768,27 @@
# 1998, though it is less clear how far back that arrangement goes; assume
# the area is covered in the same way as Atikokan.
# See the 'backzone' file for further commentary.
-# At time of writing, it is not yet known to what extent Manitoba's 2026-09-17
-# announcement may spur further adaptations in northwestern Ontario; see
-# Manitoba, below.
+#
+# From Tim Parenti (2026-10-13):
+# On 2026-09-17, after neighboring Manitoba announced a shift to year-round -05
+# (see Manitoba, below), local leaders throughout northwestern Ontario
+# coordinated regionally alongside their local members of provincial parliament
+# to swiftly conduct several local surveys on the matter ahead of a potential
+# divergence on 2026-11-01. All of the surveys returned more than 90% support
+# for remaining in alignment with the “Manitoba model”.
+#
https://www.nwonewswatch.com/local-journalism-initiative-lji/vast-majority-want-to-end-time-changes-mayor-12838025
+#
https://www.kenoraminerandnews.com/news/local-news/kenora-asks-province-to-end-clock-changes/article_5118b819-9f67-42ce-938a-1478b8ab541e.html
+# From Aoun Khan and Chris Walton (2026-10-13):
+# Ontario is set to move parts of the province’s northwest region to permanent
+# daylight time in order to align with Manitoba.
+#
https://www.cp24.com/news/canada/2026/10/13/ontario-to-move-northwest-regions-to-permanent-daylight-time/
+# The provincial government has issued a written news release:
+#
https://news.ontario.ca/en/release/1008130/ontario-moving-to-permanent-daylight-saving-time-in-parts-of-northwestern-ontario
+# From Heitor David Pinto (2026-10-22):
+# [On 2026-10-19] the government of Ontario issued [Regulation 333/26] setting
+# the time in the part of the province west of 90°W as UTC-5 all year. It
+# comes into force on 1 November 2026.
+# https://www.ontario.ca/laws/regulation/r26333
# Manitoba
@@ -1953,13 +1966,13 @@
# which can be prescribed by regulation "if it is in the provincial interest"
# for those areas to observe either "UTC-5, UTC-6 or UTC-7 for all or part of
# the year" on at least 30 days' notice.
-# The new Act comes into force by order of the Lieutenant Governor in Council.
-# From Tim Parenti (2026-09-21):
-# With Manitoba now adopting year-round -05, the area around Creighton will
-# likely wish to follow. As the area doesn't have a special charter like
-# Lloydminster, the existing de facto arrangement technically violates
-# provincial law already, but once the new Act takes effect it will better
-# allow for continued alignment with Manitoba, per the above.
+# From Tim Parenti (2026-10-27), per Heitor David Pinto (2026-10-27):
+# Order in Council 438/2026 brings the new Act into force from 2026-10-30.
+# https://publications.saskatchewan.ca/#/products/130175
+# This should allow the area around Creighton to more straightforwardly remain
+# aligned with Manitoba on year-round -05, since its previous de facto
+# arrangement technically violated provincial law without a special charter
+# like Lloydminster.
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Regina 1918 only - Apr 14 2:00 1:00 D
@@ -2171,7 +2184,7 @@
# 2026-08-14 meeting.
#
https://www.cbc.ca/news/canada/british-columbia/east-kootenay-stops-changing-clocks-9.7308201
#
-# From Tim Parenti (2026-09-24):
+# From Tim Parenti (2026-10-15):
# Echoing RDEK’s earlier false step, the Town of Golden initially opted for
# year-round -07 by a 4–2 Council vote on 2026-09-01. This was met with
# significant pushback from residents preferring to maintain the existing
@@ -2185,9 +2198,10 @@
# school”, the new resolution directs town staff to partner on safety supports
# and commits to reviewing the decision and its impacts in October 2027.
#
https://www.ctvnews.ca/calgary/article/golden-bc-council-reverses-course-on-time-zone-opts-for-mountain-daylight-time/
-# At time of writing, the surrounding CSRD Area A is yet to formalize its own
-# decision following a 2026-09-10 deferral “to gather and assess further
-# information”, but is expected to follow.
+# Following a 2026-09-10 deferral “to gather and assess further information” in
+# light of the ongoing petition, the surrounding CSRD Area A unanimously
+# formalized its own change on 2026-10-15 in order to maintain the alignment.
+# https://www.csrd.bc.ca/m/newsflash/home/detail/2486
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Vanc 1918 only - Apr 14 2:00 1:00 D
@@ -3534,6 +3548,17 @@
# From Paul Eggert (2012-11-03):
# For now, assume the future rule is first Sunday in November.
+# From an anonymous contributor (2026-10-24):
+# On October 24, 2026, the Cuban authorities announced that daylight saving
+# time would remain in effect until November 7, 2027, suspending the usual
+# return to standard time scheduled for November 1, 2026.
+# From Tim Parenti (2026-10-26):
+# The measure delays the start times for schools and workplaces by 30 minutes
+# during the period in which standard time would normally be in effect "to
+# avoid disrupting social activities during the early part of the day".
+#
http://www.cuba.cu/otras/2026-10-25/cuba-mantendra-horario-de-verano-hasta-noviembre-de-2027/69459
+#
https://en.cibercuba.com/noticias/2026-10-24-u1-e74-s27061-nid343708-cuba-mantendra-horario-verano-noviembre-2027-retrasara
+
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Cuba 1928 only - Jun 10 0:00 1:00 D
Rule Cuba 1928 only - Oct 10 0:00 0 S
@@ -3572,8 +3597,10 @@
Rule Cuba 2011 only - Mar Sun>=15 0:00s 1:00 D
Rule Cuba 2011 only - Nov 13 0:00s 0 S
Rule Cuba 2012 only - Apr 1 0:00s 1:00 D
-Rule Cuba 2012 max - Nov Sun>=1 0:00s 0 S
-Rule Cuba 2013 max - Mar Sun>=8 0:00s 1:00 D
+Rule Cuba 2012 2025 - Nov Sun>=1 0:00s 0 S
+Rule Cuba 2013 2026 - Mar Sun>=8 0:00s 1:00 D
+Rule Cuba 2027 max - Nov Sun>=1 0:00s 0 S
+Rule Cuba 2028 max - Mar Sun>=8 0:00s 1:00 D
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Havana -5:29:28 - LMT 1890
diff -Nru tzdata-2026e/southamerica tzdata-2026f/southamerica
--- tzdata-2026e/southamerica 2026-08-21 20:04:12.000000000 +0200
+++ tzdata-2026f/southamerica 2026-10-27 17:34:00.000000000 +0100
@@ -778,11 +778,21 @@
# From Paul Eggert (2013-10-17):
# For now, assume western Amazonas will change as well.
+# From Daniel Dias Rodrigues (2026-10-20):
+# Under Brazilian law, a period stated as "until day X" includes day X.
+# From Tim Parenti (2026-10-27):
+# With the decrees explicitly naming the hour of 01:00 for only a few fall back
+# transitions, there remains some ambiguity in whether other implied midnight
+# fall back transitions may have therefore been intended as 24:00s (i.e.,
+# 25:00 -> 24:00) rather than as 24:00 (24:00 -> 23:00), particularly prior to
+# 1966. Since contemporaneous reporting was somewhat inconsistent on this,
+# minimize changes from earlier tzdb versions where there is ambiguity.
+
# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
# Decree 20,466 <http://pcdsh01.on.br/HV20466.htm> (1931-10-01)
# Decree 21,896 <http://pcdsh01.on.br/HV21896.htm> (1932-01-10)
Rule Brazil 1931 only - Oct 3 11:00 1:00 -
-Rule Brazil 1932 1933 - Apr 1 0:00 0 -
+Rule Brazil 1932 1933 - Mar 31 24:00 0 -
Rule Brazil 1932 only - Oct 3 0:00 1:00 -
# Decree 23,195 <http://pcdsh01.on.br/HV23195.htm> (1933-10-10)
# revoked DST.
@@ -790,28 +800,32 @@
# Decree 27,998 <http://pcdsh01.on.br/HV27998.htm> (1950-04-13)
Rule Brazil 1949 1952 - Dec 1 0:00 1:00 -
Rule Brazil 1950 only - Apr 16 1:00 0 -
-Rule Brazil 1951 1952 - Apr 1 0:00 0 -
+Rule Brazil 1951 1952 - Mar 31 24:00 0 -
# Decree 32,308 <http://pcdsh01.on.br/HV32308.htm> (1953-02-24)
-Rule Brazil 1953 only - Mar 1 0:00 0 -
+Rule Brazil 1953 only - Feb 28 24:00 0 -
# Decree 34,724 <http://pcdsh01.on.br/HV34724.htm> (1953-11-30)
# revoked DST.
# Decree 52,700 <http://pcdsh01.on.br/HV52700.htm> (1963-10-18)
-# established DST from 1963-10-23 00:00 to 1964-02-29 00:00
-# in SP, RJ, GB, MG, ES, due to the prolongation of the drought.
+# established DST as an "Hora Especial" from 1963-10-23 00:00 in SP, RJ, GB,
+# MG, ES, due to the prolongation of the drought. It originally specified an
+# end date of 1964-02-29 24:00.
# Decree 53,071 <http://pcdsh01.on.br/HV53071.htm> (1963-12-03)
-# extended the above decree to all of the national territory on 12-09.
+# extended DST as a usual "hora de verão" to all of the national territory from
+# 1963-12-09 and would have extended its end date to 1964-03-31 24:00.
Rule Brazil 1963 only - Dec 9 0:00 1:00 -
# Decree 53,604 <http://pcdsh01.on.br/HV53604.htm> (1964-02-25)
-# extended summer time by one day to 1964-03-01 00:00 (start of school).
+# restored the original end date of 1964-03-01 00:00 due to the start of
+# school.
Rule Brazil 1964 only - Mar 1 0:00 0 -
# Decree 55,639 <http://pcdsh01.on.br/HV55639.htm> (1965-01-27)
Rule Brazil 1965 only - Jan 31 0:00 1:00 -
-Rule Brazil 1965 only - Mar 31 0:00 0 -
+Rule Brazil 1965 only - Mar 31 24:00 0 -
# Decree 57,303 <http://pcdsh01.on.br/HV57303.htm> (1965-11-22)
-Rule Brazil 1965 only - Dec 1 0:00 1:00 -
+Rule Brazil 1965 only - Nov 30 24:00 1:00 -
# Decree 57,843 <http://pcdsh01.on.br/HV57843.htm> (1966-02-18)
-Rule Brazil 1966 1968 - Mar 1 0:00 0 -
+Rule Brazil 1966 only - Mar 1 1:00 0 -
Rule Brazil 1966 1967 - Nov 1 0:00 1:00 -
+Rule Brazil 1967 1968 - Mar 1 0:00 0 -
# Decree 63,429 <http://pcdsh01.on.br/HV63429.htm> (1968-10-15)
# revoked DST.
# Decree 91,698 <http://pcdsh01.on.br/HV91698.htm> (1985-09-27)
@@ -1040,6 +1054,7 @@
# Goiás (GO), Distrito Federal (DF), Minas Gerais (MG),
# Espírito Santo (ES), Rio de Janeiro (RJ), São Paulo (SP), Paraná (PR),
# Santa Catarina (SC), Rio Grande do Sul (RS)
+# The 1963 date is for MG, ES, RJ, SP; others started DST on 1963-12-09.
Zone America/Sao_Paulo -3:06:28 - LMT 1914
-3:00 Brazil %z 1963 Oct 23 0:00
-3:00 1:00 %z 1964
diff -Nru tzdata-2026e/theory.html tzdata-2026f/theory.html
--- tzdata-2026e/theory.html 2026-09-12 18:04:27.000000000 +0200
+++ tzdata-2026f/theory.html 2026-10-16 02:10:20.000000000 +0200
@@ -838,12 +838,12 @@
The relationship between POSIX time (that is, <abbr>UTC</abbr> but
ignoring <a href="https://en.wikipedia.org/wiki/Leap_second";>leap
seconds</a>) and <abbr>UTC</abbr> is not agreed upon.
- This affects time stamps during the leap second era (1972–2035).
+ This affects time stamps during the leap second era (1972–2016).
Although the POSIX
- clock officially stops during an inserted leap second, at least one
- proposed standard has it jumping back a second instead; and in
- practice POSIX clocks more typically either progress glacially during
- a leap second, or are slightly slowed while near a leap second.
+ clock officially stopped during an inserted leap second,
+ at least one proposed standard had it jumping back a second instead;
+ and in practice POSIX clocks more typically either progressed glacially
+ during a leap second, or were slightly slowed while near a leap second.
</li>
<li>
The <code><abbr>tz</abbr></code> database does not represent how
@@ -1347,35 +1347,33 @@
<p>
Leap seconds were introduced in 1972 to accommodate the
difference between atomic time and the less regular rotation of the earth.
-Unfortunately they have caused so many problems with civil
-timekeeping that there are
-<a href="https://www.bipm.org/en/cgpm-2022/resolution-4";>plans
-to discontinue them by 2035</a>.
-Even if these plans come to fruition, a record of leap seconds will still be
-needed to resolve timestamps from 1972 through 2035,
-and there may also be a need to record whatever mechanism replaces them.
+Unfortunately they caused so many problems with civil
+timekeeping that the last leap second was in 2016.
+A record of leap seconds is still
+needed to resolve timestamps from 1972 through 2016,
+and there may also be a need to record whatever mechanism replaces them
+in the likely-distant future.
</p>
<p>
The <code><abbr>tz</abbr></code> code and data can account for leap seconds,
thanks to code contributed by Bradley White.
-However, the leap second support of this package is rarely used directly
+However, the leap second support of this package's code was rarely used
+even before leap seconds were discontinued,
because POSIX requires leap seconds to be excluded and many
software packages would mishandle leap seconds if they were present.
-Instead, leap seconds are more commonly handled by occasionally adjusting
+Instead, leap seconds were more commonly handled by occasionally adjusting
the operating system kernel clock as described in
-<a href="tz-link.html#precision">Precision timekeeping</a>,
+<a href="tz-link.html#leaps">Leap seconds</a>,
and this package by default installs a <samp>leapseconds</samp> file
commonly used by
<a href="https://www.ntp.org";><abbr title="Network Time
Protocol">NTP</abbr></a>
-software that adjusts the kernel clock.
-However, kernel-clock twiddling approximates UTC only roughly,
-and systems needing more precise UTC can use this package’s leap
-second support directly.
+software that adjusted the kernel clock.
</p>
<p>
-The directly supported mechanism assumes that <code>time_t</code>
+In the rare case where this package's code is configured to support
+leap seconds, it assumes that <code>time_t</code>
counts of seconds since the POSIX epoch normally include leap seconds,
as opposed to POSIX <code>time_t</code> counts which exclude leap seconds.
This modified timescale is converted to <abbr>UTC</abbr>
diff -Nru tzdata-2026e/version tzdata-2026f/version
--- tzdata-2026e/version 2026-09-30 02:15:53.000000000 +0200
+++ tzdata-2026f/version 2026-10-28 07:18:09.000000000 +0100
@@ -1 +1 @@
-2026e
+2026f
