Version 2026.5

Upstream version 2026e released 2026-09-30T00:14:38+00:00.

Briefly:

Manitoba moves to permanent -05 on 2026-10-31.

Changes to future timestamps

Manitoba’s 2026-03-08 spring forward was its last foreseeable clock change, as
it moved to permanent -05 thereafter. Model this with 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
TEMPORARY HACK FOR CLDR AND CANADA” below.)

As the change affects both America/Winnipeg and its backward compatibility link,
the obsolescent setting TZ="Canada/Central" will now use the abbreviation EST
for affected timestamps, akin to TZ="Canada/Pacific" behavior introduced in
2026b.

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 announcement, assume that they will, to
avoid creating new zones that may not be needed if no divergence occurs.

Changes to past timestamps

In 1925 Ireland fell back on 09-20 not 10-04 (thanks to Stan Ulbrych).

Changes to commentary

Discussion on timekeeping practices in northwestern Ontario has been expanded in
light of Manitoba’s recent announcement. It is not yet known whether or to what
extent these areas may adapt their own timekeeping practices in response.

Version 2026.4

Upstream version 2026d released 2026-09-11T22:21:07+00:00

Briefly:

Canada’s Northwest Territories moved to permanent -06 on 2026-08-21. Obsolescent
settings like TZ="EST5EDT" now conform better to POSIX. Fix security,
performance and porting bugs in zic and localtime.

Changes to future timestamps

Canada’s Northwest Territories will not fall back on 2026-11-01 and will stay on
-06 year-round, matching Alberta’s recent change. 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.) 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.

Changes to past timestamps

Colombia’s 1992-05-02 spring forward was at 00:00, not 24:00.

Iran’s 1979-05-26 spring forward was at 00:00, not 24:00. (Thanks to N.F. Hase.)

The backward-compatibility names EST5EDT, CST6CDT, MST7MDT, and PST8PDT now
conform better to POSIX. For example, EST5EDT now always uses the abbreviation
"EST" for standard time (now always 5 hours behind UT) and "EDT" for daylight
saving time, whereas it formerly had different UT offsets before standard time
was introduced and sometimes used abbreviations like "LMT", "EWT" and "EPT", all
contrary to POSIX. Also, though not required by POSIX these names now use US
federal rules rather than rules of places like New York, reverting to 2024a
behavior. This change affects only timestamps before 1966-10-30 at 01:00
standard time.

Other data changes

The temporary hacks used for North American timekeeping changes now work around
a libstdc++ std::chrono bug in GCC 14.1-14.4, 15.1-15.2, and 16.1; see GCC bug
124851. This data change does not affect TZif files or timestamps. The change
does not work around the related but less serious GCC bugs 116110 and 124513.
These GCC bugs are all fixed in GCC 16.2.

Changes to documentation

URLs for release tarballs in tz-link.html have been updated to reflect their new
canonical URLs on data.iana.org.

Version 2026.3

Upstream version 2026c released 2026-07-08T17:23:58+00:00

Briefly:

Alberta moved to permanent -06 on 2026-06-18. Morocco moves to permanent +00 on
2026-09-20. More integer overflow bugs have been fixed in zic.

Changes to future timestamps

Alberta’s 2026-03-08 spring forward was its last foreseeable clock change, as it
moved to permanent -06 thereafter. (Thanks to Roozbeh Pournader and others.)
Model this with its traditional abbreviation 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.

Although another TZDB release will likely be needed soon because Northwest
Territories will likely follow Alberta, the legal formalities have not yet taken
place.

Morocco plans to move back to permanent UTC, without daylight saving time
transitions, on 2026-09-20 at 02:00. This also affects Western Sahara.

Changes to commentary

Northwest Territories is expected to move to permanent -06 prior to 2026-11-01
02:00, when clocks would otherwise fall back. (Thanks to Tim Parenti and James
Bellaire.) Model this with its traditional abbreviation CST. Unfortunately the
change is not yet official, so it is currently present only as comments that can
be uncommented as needed.

Version 2026.2

Upstream version 2026b released 2026-04-23T06:06:43+00:00

Briefly:

British Columbia moved to permanent -07 on 2026-03-09. Some more overflow bugs
have been fixed in zic.

Changes to future timestamps

British Columbia’s 2026-03-08 spring forward was its last foreseeable clock
change, as it moved to permanent -07 thereafter. (Thanks to Arthur David Olson.)
Although the change to permanent -07 legally took place on 2026-03-09,
temporarily model the change to occur on 2026-11-01 at 02:00 instead. This
works around a limitation in CLDR v48.2 (2026-03-17). This temporary hack is
planned to be removed after CLDR is fixed.

Version 2026.1

Upstream version 2026a released 2026-03-02T06:59:49+00:00

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.

Version 2025.3

Upstream version 2025c released 2025-12-10T22:42:37+00:00

Briefly:

Several code changes for compatibility with FreeBSD.

Changes to past timestamps

Baja California agreed with California’s DST rules in 1953 and in 1961 through
1975, instead of observing standard time all year. (Thanks to Alois Treindl.)

Changes to commentary

The leapseconds file contains commentary about the IERS and NIST last-modified
and expiration timestamps for leap second data. (Thanks to Judah Levine.)

Commentary now also uses characters from the set –‘’“”•≤ as this can be useful
and should work with current applications. This also affects data in
iso3166.tab and zone1970.tab, which now contain strings like “Côte d’Ivoire”
instead of “Côte d'Ivoire”.

Version 2025.2

Upstream version 2025b released 2025-03-22T20:40:46+00:00

Briefly:

New zone for Aysén Region in Chile which moves from -04/-03 to -03.

Changes to future timestamps

Chile's Aysén Region moves from -04/-03 to -03 year-round, joining Magallanes
Region. The region will not change its clocks on 2025-04-05 at 24:00, diverging
from America/Santiago and creating a new zone America/Coyhaique. (Thanks to
Yonathan Dossow.) Model this as a change to standard offset effective
2025-03-20.

Changes to past timestamps

Iran switched from +04 to +0330 on 1978-11-10 at 24:00, not at year end.
(Thanks to Roozbeh Pournader.)

Version 2025.1

Upstream version 2025a released 2025-01-15T18:47:24+00:00

Briefly:

Paraguay adopts permanent -03 starting spring 2024. Improve pre-1991 data for
the Philippines. Etc/Unknown is now reserved.

Changes to future timestamps

Paraguay will stop changing its clocks after the spring-forward transition on
2024-10-06, so it is now permanently at -03. (Thanks to Heitor David Pinto and
Even Scharning.) This affects timestamps starting 2025-03-22, as well as the
obsolescent tm_isdst flags starting 2024-10-15.

Changes to past timestamps

Correct timestamps for the Philippines before 1900, and from 1937 through 1990.
(Thanks to P Chan for the heads-up and citations.) This includes adjusting local
mean time before 1899; fixing transitions in September 1899, January 1937, and
June 1954; adding transitions in December 1941, November 1945, March and
September 1977, and May and July 1990; and removing incorrect transitions in
March and September 1978.

Changes to data

Add zone1970.tab lines for the Concordia and Eyre Bird Observatory research
stations. (Thanks to Derick Rethans and Jule Dabars.)

Changes to documentation

The name Etc/Unknown is now reserved: it will not be used by TZDB. This is for
compatibility with CLDR, which uses the string "Etc/Unknown" for an unknown or
invalid timezone. (Thanks to Justin Grant, Mark Davis, and Guy Harris.)

Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format.

Version 2024.2

Upstream version 2024b released 2024-09-04T19:27:47+00:00

Briefly:

Improve historical data for Mexico, Mongolia, and Portugal. System V names are
now obsolescent. The main data form now uses %z. The code now conforms to RFC
8536 for early timestamps. Support POSIX.1-2024, which removes asctime_r and
ctime_r. Assume POSIX.2-1992 or later for shell scripts. SUPPORT_C89 now
defaults to 1.

Changes to past timestamps

Asia/Choibalsan is now an alias for Asia/Ulaanbaatar rather than being a
separate Zone with differing behavior before April 2008. This seems better given
our wildly conflicting information about Mongolia's time zone history. (Thanks
to Heitor David Pinto.)

Historical transitions for Mexico have been updated based on official Mexican
decrees. The affected timestamps occur during the years 1921-1927, 1931, 1945,
1949-1970, and 1981-1997. The affected zones are America/Bahia_Banderas,
America/Cancun, America/Chihuahua, America/Ciudad_Juarez, America/Hermosillo,
America/Mazatlan, America/Merida, America/Mexico_City, America/Monterrey,
America/Ojinaga, and America/Tijuana. (Thanks to Heitor David Pinto.)

Historical transitions for Portugal, represented by Europe/Lisbon,
Atlantic/Azores, and Atlantic/Madeira, have been updated based on a close
reading of old Portuguese legislation, replacing previous data mainly
originating from Whitman and Shanks & Pottenger. These changes affect a few
transitions in 1917-1921, 1924, and 1940 throughout these regions by a few hours
or days, and various timestamps between 1977 and 1993 depending on the region.
In particular, the Azores and Madeira did not observe DST from 1977 to 1981.
Additionally, the adoption of standard zonal time in former Portuguese colonies
have been adjusted: Africa/Maputo in 1909, and Asia/Dili by 22 minutes at the
start of 1912. (Thanks to Tim Parenti.)

Changes to past tm_isdst flags

The period from 1966-04-03 through 1966-10-02 in Portugal is now modeled as DST,
to more closely reflect how contemporaneous changes in law entered into force.

Changes to data

Names present only for compatibility with UNIX System V (last released in the
1990s) have been moved to 'backward'. These names, which for post-1970
timestamps mostly just duplicate data of geographical names, were confusing
downstream uses. Names moved to 'backward' are now links to geographical names.
This affects behavior for TZ='EET' for some pre-1981 timestamps, for TZ='CET'
for some pre-1947 timestamps, and for TZ='WET' for some pre-1996 timestamps.
Also, TZ='MET' now behaves like TZ='CET' and so uses the abbreviation "CET"
rather than "MET". Those needing the previous TZDB behavior, which does not
match any real-world clocks, can find the old entries in 'backzone'. (Problem
reported by Justin Grant.)

The main source files' time zone abbreviations now use %z, supported by zic
since release 2015f and used in vanguard form since release 2022b. For example,
America/Sao_Paulo now contains the zone continuation line "-3:00 Brazil %z",
which is less error prone than the old "-3:00 Brazil -03/-02". This does not
change the represented data: the generated TZif files are unchanged. Rearguard
form still avoids %z, to support obsolescent parsers.

Asia/Almaty has been removed from zonenow.tab as it now agrees with
Asia/Tashkent for future timestamps, due to Kazakhstan's 2024-02-29 time zone
change. Similarly, America/Scoresbysund has been removed, as it now agrees with
America/Nuuk due to its 2024-03-31 time zone change.

Changes to documentation

The documentation now reflects POSIX.1-2024.

Changes to commentary

Commentary about historical transitions in Portugal and her former colonies has
been expanded with links to many relevant legislation. (Thanks to Tim Parenti.)

Version 2024.1

Upstream version 2024a released 2024-02-01T17:28:56+00:00

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 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.)