Version in base suite: 2026c-0+deb13u1 Version in overlay suite: 2026e-0+deb13u1 Base version: tzdata_2026e-0+deb13u1 Target version: tzdata_2026f-0+deb13u1 Base file: /srv/ftp-master.debian.org/ftp/pool/main/t/tzdata/tzdata_2026e-0+deb13u1.dsc Target file: /srv/ftp-master.debian.org/policy/pool/main/t/tzdata/tzdata_2026f-0+deb13u1.dsc Makefile | 20 ++++--- NEWS | 113 +++++++++++++++++++++++++++++++++------- backzone | 40 -------------- debian/changelog | 10 +++ debian/upstream/signing-key.asc | 52 +++++++++--------- leapseconds | 24 +++----- leapseconds.awk | 39 ++++--------- northamerica | 73 +++++++++++++++++-------- southamerica | 35 ++++++++---- theory.html | 38 ++++++------- version | 2 11 files changed, 262 insertions(+), 184 deletions(-) dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpnh3ce0ft/tzdata_2026e-0+deb13u1.dsc: no acceptable signature found dpkg-source: warning: cannot verify inline signature for /srv/release.debian.org/tmp/tmpnh3ce0ft/tzdata_2026f-0+deb13u1.dsc: no acceptable signature found diff -Nru tzdata-2026e/Makefile tzdata-2026f/Makefile --- tzdata-2026e/Makefile 2026-08-30 06:01:32.000000000 +0000 +++ tzdata-2026f/Makefile 2026-10-25 05:34:23.000000000 +0000 @@ -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 00:15:52.000000000 +0000 +++ tzdata-2026f/NEWS 2026-10-28 06:18:08.000000000 +0000 @@ -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 and + 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/backzone tzdata-2026f/backzone --- tzdata-2026e/backzone 2026-09-22 01:49:27.000000000 +0000 +++ tzdata-2026f/backzone 2026-10-13 21:05:24.000000000 +0000 @@ -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 20:28:09.000000000 +0000 +++ tzdata-2026f/debian/changelog 2026-10-28 20:57:59.000000000 +0000 @@ -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 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 20:28:09.000000000 +0000 +++ tzdata-2026f/debian/upstream/signing-key.asc 2026-10-28 20:57:59.000000000 +0000 @@ -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 13:08:50.000000000 +0000 +++ tzdata-2026f/leapseconds 2026-10-16 00:10:21.000000000 +0000 @@ -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 # # or via a less-secure protocol and with different comments and -# less volatile last-modified and expiration timestamps, from +# less volatile timestamp metadata, from # . # 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) # . # 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 -# . +# 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 # . @@ -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 19:25:58.000000000 +0000 +++ tzdata-2026f/leapseconds.awk 2026-10-16 00:10:20.000000000 +0000 @@ -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 "# " 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 "# ." 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 "# ." 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 "# ." + 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 "# ." @@ -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/northamerica tzdata-2026f/northamerica --- tzdata-2026e/northamerica 2026-09-29 21:12:34.000000000 +0000 +++ tzdata-2026f/northamerica 2026-10-27 17:24:00.000000000 +0000 @@ -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 18:04:12.000000000 +0000 +++ tzdata-2026f/southamerica 2026-10-27 16:34:00.000000000 +0000 @@ -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 (1931-10-01) # Decree 21,896 (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 (1933-10-10) # revoked DST. @@ -790,28 +800,32 @@ # Decree 27,998 (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 (1953-02-24) -Rule Brazil 1953 only - Mar 1 0:00 0 - +Rule Brazil 1953 only - Feb 28 24:00 0 - # Decree 34,724 (1953-11-30) # revoked DST. # Decree 52,700 (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 (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 (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 (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 (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 (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 (1968-10-15) # revoked DST. # Decree 91,698 (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 16:04:27.000000000 +0000 +++ tzdata-2026f/theory.html 2026-10-16 00:10:20.000000000 +0000 @@ -838,12 +838,12 @@ The relationship between POSIX time (that is, UTC but ignoring leap seconds) and UTC 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.
  • The tz database does not represent how @@ -1347,35 +1347,33 @@

    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 -plans -to discontinue them by 2035. -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.

    The tz 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 -Precision timekeeping, +Leap seconds, and this package by default installs a leapseconds file commonly used by NTP -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.

    -The directly supported mechanism assumes that time_t +In the rare case where this package's code is configured to support +leap seconds, it assumes that time_t counts of seconds since the POSIX epoch normally include leap seconds, as opposed to POSIX time_t counts which exclude leap seconds. This modified timescale is converted to UTC diff -Nru tzdata-2026e/version tzdata-2026f/version --- tzdata-2026e/version 2026-09-30 00:15:53.000000000 +0000 +++ tzdata-2026f/version 2026-10-28 06:18:09.000000000 +0000 @@ -1 +1 @@ -2026e +2026f