Hello, I was wondering if the recent changes to Vancouvers timezones would be included in the next release? https://www.timeanddate.com/news/time/canada-bc-permanent-dst.html Thank you! Chrisitan Hubbell
On Mon, Mar 2, 2026 at 12:04 PM Paul Eggert via tz-announce < [email protected]> wrote: > The 2026a release of the tz code and data is available. This release > corrects the time for Moldova's upcoming clock transition on March 29, > as well as on other dates. It also has significant changes to code and > to the build procedure. > > This release contains the following changes: > > Briefly: > Moldova has used EU transition times since 2022. > 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. > Several integer overflow bugs have been fixed. > > Changes to past and future timestamps > > Since 2022 Moldova has observed EU transition times, that is, it > has sprung forward at 03:00, not 02:00, and has fallen back at > 04:00, not 03:00. (Thanks to Heitor David Pinto.) > > Changes to data > > Remove Europe/Chisinau from zonenow.tab, as it now agrees with > Europe/Athens for future timestamps. > > Changes to build procedure > > 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, > 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'. > This change does not affect the leapseconds file, which is still > installed as before. > > The Makefile's POSIXRULES option, which was declared obsolete in > release 2019b, has been removed. The Makefile's build procedure > thus no longer optionally installs the obsolete posixrules file. > > Changes to code > > Compiling with the new option -DTZ_RUNTIME_LEAPS=0 disables > runtime support for leap seconds. Although this conforms to > POSIX, shrinks tzcode's attack surface, and is more efficient, > it fails to support Internet RFC 9636's leap seconds. > > zic now can generate, and localtime.c can now use, TZif files that > hold up to 256 bytes of abbreviations, counting trailing NULs. > The previous limit was 50 bytes, and some tzdata TZif files were > already consuming 40 bytes. zic -v warns if it generates a file > that exceeds the old 50-byte limit. > > 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 > 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. > > localtime.c no longer accesses the posixrules file generated by > zic -p. Hence for obsolete and nonconforming settings like > TZ="AST4ADT" it now typically falls back on US DST rules, rather > than attempting to override this fallback with the contents of the > posixrules file. This removes library support that was declared > obsolete in release 2019b, and fixes some undefined behavior. > (Undefined behavior reported by GitHub user Naveed8951.) > > The posix2time, posix2time_z, time2posix, and time2posix_z > functions now set errno=EOVERFLOW and return ((time_t) -1) if the > result is not representable. Formerly they had undefined behavior > that could in practice result in crashing, looping indefinitely, > or returning an incorrect result. As before, these functions are > defined only when localtime.c is compiled with the -DSTD_INSPIRED > option. > > Some other undefined behavior, triggered by TZif files containing > outlandish but conforming UT offsets or leap second corrections, > has also been fixed. (Some of these bugs reported by Naveed8951.) > > localtime.c no longer rejects TZif files that exactly fit in its > internal structures, fixing off-by-one typos introduced in 2014g. > > zic no longer generates a no-op transition when > simultaneous Rule and Zone changes cancel each other out. > This occurs in tzdata only in Asia/Tbilisi on 1997-03-30. > (Thanks to Renchunhui for a test case showing the bug.) > > zic no longer assumes you can fflush a read-only stream. > (Problem reported by Christos Zoulas.) > > zic no longer generates UT offsets equal to -2**31 and localtime.c > no longer accepts them, as they can cause trouble in both > localtime.c and its callers. RFC 9636 prohibits such offsets. > > zic -p now warns that the -p option is obsolete and likely > ineffective. > > Here are links to the release files: > > https://www.iana.org/time-zones/repository/releases/tzcode2026a.tar.gz > https://www.iana.org/time-zones/repository/releases/tzdata2026a.tar.gz > https://www.iana.org/time-zones/repository/releases/tzdb-2026a.tar.lz > > The following convenience links are also available, although they may > point to the previous release until the relevant caches are refreshed: > > https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz > https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz > https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz > > Links are also available via plain HTTP, and via FTP from > ftp://ftp.iana.org/tz/releases with the same basenames as above. > > Each release file has a GPG signature, which can be retrieved by > appending ".asc" to the above URLs. Copies of these signatures are > appended to this message. > > This release corresponds to commit > dd6be6d1558163517ec55c652efac70842c3b4cc dated 2026-03-01 22:59:49 -0800 > and tagged '2026a' in the development GitHub repository at > <https://github.com/eggert/tz>. > > Here are the SHA3-512 checksums for the release files, generated by > the GNU coreutils 9.8+ command 'cksum -a sha3 -l 512'. > > SHA3-512 (tzcode2026a.tar.gz) = > > 7106762916c6d21aa71fc5b43924582b603e231c90f19fb40ecd81db96208f8a4d6ff9664508c7298c521ab8fed97d4100665f84b2ba17caed04af129e40c5c2 > SHA3-512 (tzdata2026a.tar.gz) = > > 898b090b74d927495a412f382636e4eb2f697e3e357e5a1d35e01cf95f6cdc3bd52533a269ae247b521c6ec1112cbc2df0bb5466accf376e2e7b78a3adde26bd > SHA3-512 (tzdb-2026a.tar.lz) = > > 5aefc96aa15113da1c30fbba7564636e106e3c0e33f475d48f32c5d3417e945fada548176e56c474a85bf02681e101c7b4dd727eb0053d1d39a81c9a13afe37b > > Here are the SHA-512 checksums for the release files: > > 69a2ad3334ab1491ba349fcd5d3066a26b38ccb59031fec70ca19379cb0514fe2757af7bee31e796913c0cfc322134e2ba16f93ba07fa45cd4a415b9122b2f27 > > tzcode2026a.tar.gz > 407e8e93aaa054a22a4a7d6d8cf480a20630073bf1a00956df16b10318f239a12015de38fad3072249193e314d6fddbff4e74afa40a88f7bf5c9eecc7659ea15 > > tzdata2026a.tar.gz > 1824fc2e198a449ebaa41e6c679a494c486b848f13fe8f18f948fde0533e99f5f01e7e7298e257c565838d24ec743e824f402887abdf525d1ce578a714c71414 > > tzdb-2026a.tar.lz > > Here are GPG digital signatures for the release files: > > -----BEGIN PGP SIGNATURE----- > > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq > fjS64g//TxOxFmBXtJRx4LM8QIL315hvWwVpVAmAk+oFzqjluosfb3xbszBw3fWw > PzcOyQ8PDXV42dq29jO8JjVJkCrvLiBjXWTTV6yDRqp3TEBh5uM4cUormnfcTLkT > bmgVLLmqiNZgZpEHrsQQKaf8Ia/23F2topG0USSzqguLgLBVLcdut8Djfqb5qpqV > xurq88ciC+ZvLENJsBXyfJzN2neuCOelbXgPDz+LJZrv3mJqFrm7EzxHngE8xZ+j > Ny0V6WFaZJisWEif4oGeTPtxQS+LT/2bDBKtNpcFQhvquS6dU0nHHVAvNAIZaGNf > HeQ/LgxFDQjnIisoqKA61qNmZZ1F5rDuYtL/j53nhjJpLkaDAoEU+xfKtYybJzir > mH7Dj8WwUcLwH7lT/U4KDZmiUiT49Vk/u/7+pI1Vx7OogJ4Vs9WTtCt8avNGkwFF > qez91hNIb6iZzVbnSKz+TWlfnBgltFQU02ozTZNW6K3TawLuwgyMoAGX0kaK8Lxy > 8KKEo53phmmFnZ9vQKEJkJdaaIuisK1qJH1K6cj2GX44bhpDfT/kq4AQQbR7HDWR > ZSTB5oG4TvqfGd3bKrDzpGOOLJ2AoiBaGi+rcA8n4WWvdGxodIJ6RU1cDI+RHPfv > 8caWfWcEtAPCciArx2pa10gupda67DF1pwxAYLEbr+dmg2S8jQI= > =/yto > -----END PGP SIGNATURE----- > -----BEGIN PGP SIGNATURE----- > > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq > fjR04A//YmSFvKQi/w8hfB5fAf4VSV+5HBIeuTRJPn9BuRAUvZVYl78ApYGzSqPh > sG3H/IPprHICVxMJcPBvEI7+tXVPozCOnwUx7jz2nAvl7awxj5n2z1zs+jjZ+/pU > kiQ4x4uZDJTw5wsymy9nPasoQba5kmSItjB7fDXe2wwjPOh3osOzSfC0KDnPvTxl > jPxBTd+CXDmz5fiI7RPSi1uJWJFXEtE+NpaltQpA8J1M7QSv2O+7x3eLfNoa1Eh9 > GQ5JjtvMixdQGxFzMeID/Y2Rjj3vKFpB0+blf1zu5aBchemmvW/DFpOBhdm+lRf0 > Me1TVlmlBI3oj4lrNhGIz3f7zf+IrPVfAAQ/hMMcyYc/FwYuuV9SSF0Aj2pWR0Mi > wvASEXb23bWu2t1aeu7by7XSnL033o1P5DqWDueVSilTdeVSOS0EtyyFMC6THmj4 > PcQh7/O60zbPhsUXan85rOC1CNv9lZJlEzZShy3B3tAccGr4IKrPRT/jIhVwVbu9 > rS25dLR9S/bcrYTpn4aaWMPQ9tuYJ/83i1euAgs7NjKao0lziPTOPaBvqW6fdg1v > /4dHluvwMufDLa23WVy2iPueTPD8NDH228xwrtGm/Spyu3XCX7YZJdCJVcNF0E9m > W4z5R07LGBZYKscd9T8otPJyzTLcunLmnaf/Mbsrj4FmB+dNof8= > =SR0V > -----END PGP SIGNATURE----- > -----BEGIN PGP SIGNATURE----- > > iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgQACgkQ7ZfpDmKq > fjRfhg//WKsUlkhd9treq8Q3YMju7fezVZhvinFib7mmC3kn3HM5Xo2AKakjtwYn > d0ZDuA886qFp3Llkn3pwnEh8vugE0A86qRwk3D3RoL/QfpbKkrVyAWONEWCHMKF1 > MswUEO01Lcxd+CmjFWsH+dEhJ8HHLlPgyYgWCy6X3zvTyCLK5navq93QTmIKBguy > tXAtWClft7wEv4Sg6xI0MtcAMamt5aBP9oC284XJbjfHz169QcK5VaCJPG82kuDs > ABorgc6KVJN88SzPWsajpEQQE17hsH99y+Jh4UR4Lx4s06+52zOl814t0Aru28B2 > K8u0PF5mO3druoHN8ielp9gdqIMk5JbOobhezGmnNPQT2ZIazTBa22/zVknkqoLq > 6NQnpPekc2sjuVljRYCRkDwWXaUYfl8gR7e59Ew45IfFBpRCfkpEFK4A97KGfGVM > gSCdW/N+9lCG2p1MrrRETykyGCX181rtnw8RXO+ADxmz8ddQ5WRrmGIkBYi7iocY > 2iULltrLOAzCnUGsN0x/7xk8fLf7MRX+cExUJG992foiPQ/6N/06gp6SNeJyuKgG > hI5TO9RIsR8JzjfUpI0Nbr9ZwkQuLFfkvvXSZeYwVU4rFNEHaQqz4dVvcfTAwi1T > 9AK8S/7FjRoh/aqbUe9rVsUAOUcoOAkgCd2bUkcYLQ8FXJqJPYA= > =t0qu > -----END PGP SIGNATURE----- >
