The 2024a release of the tz code and data is available.
This release contains the following changes:
Briefly:
Kazakhstan unifies on UTC+5 beginning 2024-03-01.
Palestine springs forward a week later after Ramadan.
zic no longer pretends to support indefinite-past DST.
localtime no longer mishandles Ciudad Juárez in 2422.
Changes to future timestamps
Kazakhstan unifies on UTC+5. This affects Asia/Almaty and
Asia/Qostanay which together represent the eastern portion of the
country that will transition from UTC+6 on 2024-03-01 at 00:00 to
join the western portion. (Thanks to Zhanbolat Raimbekov.)
Palestine springs forward a week later than previously predicted
in 2024 and 2025. (Thanks to Heba Hamad.) Change spring-forward
predictions to the second Saturday after Ramadan, not the first;
this also affects other predictions starting in 2039.
Changes to past timestamps
Asia/Ho_Chi_Minh's 1955-07-01 transition occurred at 01:00
not 00:00. (Thanks to Đoàn Trần Công Danh.)
From 1947 through 1949, Toronto's transitions occurred at 02:00
not 00:00. (Thanks to Chris Walton.)
In 1911 Miquelon adopted standard time on June 15, not May 15.
Changes to code
The FROM and TO columns of Rule lines can no longer be "minimum"
or an abbreviation of "minimum", because TZif files do not support
DST rules that extend into the indefinite past - although these
rules were supported when TZif files had only 32-bit data, this
stopped working when 64-bit TZif files were introduced in 1995.
This should not be a problem for realistic data, since DST was
first used in the 20th century. As a transition aid, FROM columns
like "minimum" are now diagnosed and then treated as if they were
the year 1900; this should suffice for TZif files on old systems
with only 32-bit time_t, and it is more compatible with bugs in
2023c-and-earlier localtime.c. (Problem reported by Yoshito
Umaoka.)
localtime and related functions no longer mishandle some
timestamps that occur about 400 years after a switch to a time
zone with a DST schedule. In 2023d data this problem was visible
for some timestamps in November 2422, November 2822, etc. in
America/Ciudad_Juarez. (Problem reported by Gilmore Davidson.)
strftime %s now uses tm_gmtoff if available. (Problem and draft
patch reported by Dag-Erling Smørgrav.)
Changes to build procedure
The leap-seconds.list file is now copied from the IERS instead of
from its downstream counterpart at NIST, as the IERS version is
now in the public domain too and tends to be more up-to-date.
(Thanks to Martin Burnicki for liaisoning with the IERS.)
Changes to documentation
The strftime man page documents which struct tm members affect
which conversion specs, and that tzset is called. (Problems
reported by Robert Elz and Steve Summit.)
Here are links to the release files:
https://www.iana.org/time-zones/repository/releases/tzcode2024a.tar.gz
https://www.iana.org/time-zones/repository/releases/tzdata2024a.tar.gz
https://www.iana.org/time-zones/repository/releases/tzdb-2024a.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
380c07cef01c71c1f93e9709d9f8c79b91cff063 dated 2024-02-01 09:28:56 -0800
and tagged '2024a' in the development GitHub repository at
<https://github.com/eggert/tz>.