- tz - lists.iana.org

Re: Alberta DST change
by Paul Eggert June 19, 2026

June 19, 2026

On 2026-06-19 13:22, Cary Sweet wrote: > this Regulation expires on June 30, 2031. > > Does this mean that the Edmonton timezone in the patch should also revert back to MST on that date? No, even though that Alberta regulation expires then, it's merely about the legal term for the time in Alberta. The Alberta Order in Council that changes timekeeping, which is what counts for us, doesn't expire. Although the legal term's provisional nature doesn't affect TZDB's data, it's worth mentioning in a comment, to give a heads-up to downstream uses like CLDR that deal with localization. I installed the attached proposed patch to do that. The regulation also simply deletes several instances of the phrase "Mountain Standard Time" from other regulations, without replacing them with "Alberta Time". I expect they did this because they didn't want the hassle of replacing lots of "Alberta Time"s later.

1 0

[PROPOSED] tz-link updates, e.g., HP-UX gone
by Paul Eggert June 19, 2026

June 19, 2026

* Makefile, tz-link.html: The TZDIST list vanished. vzic moved. HP no longer supports HP-UX. Other minor editorial changes. --- Makefile | 3 ++- tz-link.html | 20 ++++++++------------ 2 files changed, 10 insertions(+), 13 deletions(-) diff --git a/Makefile b/Makefile index 786c5222..f5a22f18 100644 --- a/Makefile +++ b/Makefile @@ -1146,7 +1146,8 @@ SET_TIMESTAMP_N = sh -c '\ # If DEST depends on A B C ... in this Makefile, callers should use # $(SET_TIMESTAMP_DEP) DEST A B C ..., for the benefit of any # downstream 'make' that considers equal timestamps to be out of date. -# POSIX allows this 'make' behavior, and HP-UX 'make' does it. +# POSIX allows this 'make' behavior, although only HP-UX 'make' +# (which is no longer supported) did things that way. # If all that matters is that the timestamp be reproducible # and plausible, use $(SET_TIMESTAMP). SET_TIMESTAMP = $(SET_TIMESTAMP_N) 0 diff --git a/tz-link.html b/tz-link.html index ec5feaef..d20e41d0 100644 --- a/tz-link.html +++ b/tz-link.html @@ -197,8 +197,8 @@ more errors.</p> After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into -machine-readable binary files, one for each location. The binary files -are in a special format specified by +machine-readable binary files, one for each location. +The binary file format is specified by <a href="https://www.rfc-editor.org/rfc/rfc9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> (Internet <abbr title="Request For Comments">RFC</abbr> 9636). @@ -336,7 +336,7 @@ the Timing of Time Zone Changes</a>” for examples. an encyclopedic summary.</li> <li><a href="tz-how-to.html">How to Read the tz Database Source Files</a> explains the <code><abbr>tz</abbr></code> -database format.</li> +database source format.</li> <li><a href="https://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzo…">A literary appreciation of the Olson/Zoneinfo/tz database</a> comments on the @@ -386,13 +386,11 @@ calculates the current time difference between locations.</li> <h2 id="protocols">Network protocols for <code><abbr>tz</abbr></code> data</h2> <ul> <li><a href="https://www.rfc-editor.org/rfc/rfc7808">Time Zone -Data Distribution Service</a> (TZDIST, Internet <abbr>RFC</abbr> 7808) +Data Distribution Service</a> (Internet <abbr>RFC</abbr> 7808) is associated with <a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for -transferring time zone data by reference. -<a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST -implementations</a> are available.</li> +transferring time zone data by reference.</li> <li>The <a href="https://www.rfc-editor.org/rfc/rfc5545">iCalendar format</a> (Internet <abbr>RFC</abbr> 5445) covers time zone @@ -417,7 +415,8 @@ distributions you can generally work around compatibility problems by running the command <code>make rearguard_tarballs</code> and compiling from the resulting tarballs instead.</p> <ul> -<li><a href="https://github.com/libical/vzic">Vzic</a> is a <a +<li><a href="https://github.com/libical">Libical</a> +contains <code>vzic</code>, <a href="https://en.wikipedia.org/wiki/C_(programming_language)">C</a> program that compiles <code><abbr>tz</abbr></code> source into iCalendar-compatible VTIMEZONE files. @@ -596,8 +595,7 @@ license.</li> <li>The <a href="https://www.gnu.org/software/libc/"><abbr>GNU</abbr> C Library</a> -has an independent, thread-safe implementation of -a <abbr>TZif</abbr> file reader. +has a thread-safe <abbr>TZif</abbr> file reader. This library is freely available under the LGPL and is widely used in <abbr>GNU</abbr>/Linux systems.</li> <li><a href="https://www.gnome.org">GNOME</a>’s @@ -725,8 +723,6 @@ sources for much of the older <code><abbr>tz</abbr></code> data</a>, they are unreliable as Shanks appears to have guessed many <abbr>UT</abbr> offsets and transitions. The atlases cite no sources and do not indicate which entries are guesswork.</li> -<li><a href="https://en.wikipedia.org/wiki/HP-UX">HP-UX</a> has a database in -its own <code>tztab</code>(4) format.</li> <li>Microsoft Windows has proprietary data mentioned <a href="#System.TimeZoneInfo">above</a>.</li> <li><a href="https://www.worldtimeserver.com">World Time Server</a> -- 2.53.0

2 2

Alberta's change is actually official now
by Tim Parenti June 19, 2026

June 19, 2026

Yesterday, Thursday 18 June 2026, the Orders in Council we were awaiting from Alberta were published: OC 204/2026 proclaimed section 3 (and a few others) of Bill 31, the *Red Tape Reduction Statutes Amendment Act, 2026*, in force on the date of issue (18 June 2026), bringing the new *Official Time Act* into law. https://kings-printer.alberta.ca/Documents/Orders/Orders_in_Council/2026/20… OC 206/2026 then uses the regulatory authority within the Act to prescribe the official term "Alberta Time" and make several conforming amendments to regulations. https://kings-printer.alberta.ca/Documents/Orders/Orders_in_Council/2026/20… Proposed patch attached and pushed to the development repository, with the same CLDR workaround temporarily delaying the tm_isdst flag switch until November. We will of course need a new release soon, as 2026b will be wrong for Alberta in just over four months. However, as America/Edmonton has, to date, also represented most of the Northwest Territories where a similar proposed change is not yet official, we will want to take care here. For what it's worth, Northwest Territories appears to gazette all of its regulations and orders together at the end of each month, so at this point in the month it may be worth waiting to see whether their proposed change appears in the end-of-June edition. https://www.justice.gov.nt.ca/en/northwest-territories-gazette/#gn-filebrow… -- Tim Parenti

2 1

[PROPOSED] Fix outlandish year calculations in zic
by Paul Eggert June 16, 2026

June 16, 2026

Problem reported by Naveed Khan. * NEWS: Mention this. * zic.c (rpytime): Check for integer overflow when multiplying a repeat count by DAYSPERREPEAT. --- NEWS | 9 +++++++++ zic.c | 8 ++++---- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/NEWS b/NEWS index a04d6895..bb912dcb 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,15 @@ News for the tz database Unreleased, experimental changes + Briefly: + Another integer overflow bug has been fixed in zic. + + Changes to code + + zic no longer overflows an integer when processing outlandish + input like ‘Zone Ouch 0 - LMT 9223372036854775807’. The integer + overflow is undefined behavior in C. (Thanks to Naveed Khan.) + Changes to commentary The 2026-03-08 spring forward in Alberta and in Northwest diff --git a/zic.c b/zic.c index 7ecf3b91..1115e9ba 100644 --- a/zic.c +++ b/zic.c @@ -4128,11 +4128,11 @@ rpytime(const struct rule *rp, zic_t wantedy) y = EPOCH_YEAR; /* dayoff = floor((wantedy - y) / YEARSPERREPEAT) * DAYSPERREPEAT, - sans overflow. */ + checking for overflow. */ yrem = wantedy % YEARSPERREPEAT - y % YEARSPERREPEAT; - dayoff = ((wantedy / YEARSPERREPEAT - y / YEARSPERREPEAT - + yrem / YEARSPERREPEAT - (yrem % YEARSPERREPEAT < 0)) - * DAYSPERREPEAT); + dayoff = omul ((wantedy / YEARSPERREPEAT - y / YEARSPERREPEAT + + yrem / YEARSPERREPEAT - (yrem % YEARSPERREPEAT < 0)), + DAYSPERREPEAT); /* wantedy = y + ((wantedy - y) mod YEARSPERREPEAT), sans overflow. */ wantedy = y + (yrem + 2 * YEARSPERREPEAT) % YEARSPERREPEAT; -- 2.54.0

1 0

Request for consideration of a dedicated time zone identifier for Coyhaique, Aysén Region, Chile
by Victor Alfonso June 12, 2026

June 12, 2026

Dear Time Zone Database Maintainers, I am writing from Coyhaique, the capital city of the Aysén Region in Chile, regarding the recent adoption of UTC−03:00 in our region. Currently, many operating systems, applications, and online services identify our location using the existing "America/Punta_Arenas" time zone. While this provides the correct UTC offset, Coyhaique and the Aysén Region do not appear as a selectable or identifiable location in many systems. This can create confusion for local users, organizations, businesses, and visitors who are attempting to verify or configure the correct local time. I would like to respectfully inquire whether the creation of a dedicated time zone identifier, such as "America/Coyhaique", could be considered for inclusion in the IANA Time Zone Database. I understand that new identifiers are generally created when there are historical differences or the possibility of future divergence in timekeeping rules. However, the Aysén Region now operates under UTC−03:00 and has a distinct regional identity and administrative significance that may justify separate representation within systems that rely on the IANA database. In addition, Coyhaique serves as one of the principal gateways to Chilean Patagonia and is the administrative, commercial, and logistical center of the Aysén Region. Every year, the city receives a significant number of domestic and international visitors who rely on digital systems to coordinate flights, accommodations, tours, transportation, and business activities. The absence of a specific identifier for Coyhaique in many operating systems and platforms may create uncertainty regarding the local time zone, particularly for visitors who are unfamiliar with the relationship between Aysén and the "America/Punta_Arenas" identifier. A dedicated reference to Coyhaique could improve clarity and user experience for travelers, businesses, service providers, and software systems operating within the region. If a new identifier is not currently considered necessary, I would greatly appreciate any clarification regarding the criteria that would need to be met for such consideration in the future. Thank you for your time and for the important work you do in maintaining this essential global resource. Kind regards, Víctor Alfonso Coyhaique, Aysén Región. Chile

4 4

[PROPOSED 1/3] Update latest NWT commentary
by Paul Eggert June 12, 2026

June 12, 2026

From: Tim Parenti <tim(a)timtimeonline.com> (Thanks to James Bellaire.) --- northamerica | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/northamerica b/northamerica index c8d2eade..b71bbe3b 100644 --- a/northamerica +++ b/northamerica @@ -2415,7 +2415,13 @@ Zone America/Fort_Nelson -8:10:47 - LMT 1884 # time standard instead. ... Simpson has previously said the territory wouldn't # end seasonal time changes until Alberta does." # https://www.cbc.ca/news/canada/north/nwt-ends-daylight-saving-9.7170964 -# At time of writing, this proposed change has not yet been legislated. +# +# From Tim Parenti (2026-06-11), per James Bellaire (2026-06-02): +# Much of NWT is currently represented by America/Edmonton, which alias +# America/Yellowknife links to. While Bill 13 (assented to 2021-03-31) would +# enable NWT's proposed change mirroring Alberta's, at time of writing it has +# not yet been formally enacted; if it doesn't move forward as expected, +# America/Yellowknife would need to become its own zone. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule NT_YK 1918 only - Apr 14 2:00 1:00 D -- 2.54.0

1 2

Alberta to follow British Columbia?
by Roozbeh Pournader June 12, 2026

June 12, 2026

I just ran into this: https://calgaryherald.com/opinion/columnists/bell-alberta-daylight-time-yea…

6 14

[PROPOSED] Remove ‘typecheck’ rule from Makefile
by Paul Eggert June 8, 2026

June 8, 2026

It has not been used for some time. It stopped working in 2025a, and anyway was superseded in 2013d by the check_time_t_alternatives rule. * Makefile (TYPECHECK_CFLAGS, typecheck, long-long.ck, unsigned.ck): Remove. All uses removed. * zdump.c (mktime_z) [TYPECHECK]: Remove. (my_localtime_rz): Remove. All callers now use localtime_rz. --- Makefile | 19 ---------------- NEWS | 9 ++++++++ zdump.c | 66 +++++++++----------------------------------------------- 3 files changed, 19 insertions(+), 75 deletions(-) diff --git a/Makefile b/Makefile index 98c19b93..7edb657a 100644 --- a/Makefile +++ b/Makefile @@ -1406,24 +1406,6 @@ $(ALL_ASC): $(SET_TIMESTAMP) $(@:.t=) $(?:.t=) touch $@ -TYPECHECK_CFLAGS = $(CFLAGS) -DTYPECHECK -D__time_t_defined -D_TIME_T -typecheck: long-long.ck unsigned.ck -long-long.ck unsigned.ck: $(VERSION_DEPS) - rm -fr $@d - mkdir $@d - ln $(VERSION_DEPS) $@d - cd $@d && \ - case $@ in \ - long-long.*) i="long long";; \ - unsigned.* ) i="unsigned" ;; \ - esac && \ - $(MAKE) \ - CFLAGS="$(TYPECHECK_CFLAGS) \"-Dtime_t=$$i\"" \ - TOPDIR="$$PWD" \ - install - $@d/zdump -i -c 1970,1971 Europe/Rome - touch $@ - zonenames: tzdata.zi @$(AWK) '/^Z/ { print $$2 } /^L/ { print $$3 }' tzdata.zi @@ -1449,6 +1431,5 @@ zic.o: private.h tzdir.h tzfile.h version.h .PHONY: traditional_signatures traditional_signatures_version .PHONY: traditional_tarballs traditional_tarballs_version .PHONY: tailored_tarballs tailored_tarballs_version -.PHONY: typecheck .PHONY: zonenames zones .PHONY: $(ZDS) diff --git a/NEWS b/NEWS index fb1ced71..78e35a7b 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,14 @@ News for the tz database +Unreleased, experimental changes + + Changes to build procedure + + The undocumented ‘typecheck’ Makefile check rule has been removed. + It stopped working in 2025a and evidently nobody noticed. + The rule was superseded by ‘check_time_t_alternatives’ in 2013d. + + Release 2026b - 2026-04-22 23:06:43 -0700 Briefly: diff --git a/zdump.c b/zdump.c index c7812eae..54ef63c0 100644 --- a/zdump.c +++ b/zdump.c @@ -212,16 +212,6 @@ localtime_rz(ATTRIBUTE_MAYBE_UNUSED timezone_t rz, time_t *tp, struct tm *tmp) return localtime_r(tp, tmp); } -# ifdef TYPECHECK -# undef mktime_z -# define mktime_z zdump_mktime_z -static time_t -mktime_z(timezone_t tz, struct tm *tmp) -{ - return mktime(tmp); -} -# endif - # undef tzalloc # undef tzfree # define tzalloc zdump_tzalloc @@ -330,42 +320,6 @@ my_gmtime_r(time_t *tp, struct tm *tmp) return USE_LOCALTIME_RZ ? localtime_rz(gmtz, tp, tmp) : gmtime_r(tp, tmp); } -#ifndef TYPECHECK -# define my_localtime_rz localtime_rz -#else /* !defined TYPECHECK */ - -static struct tm * -my_localtime_rz(timezone_t tz, time_t *tp, struct tm *tmp) -{ - tmp = localtime_rz(tz, tp, tmp); - if (tmp) { - struct tm tm; - register time_t t; - - tm = *tmp; - t = mktime_z(tz, &tm); - if (t != *tp) { - fflush(stdout); - fprintf(stderr, "\n%s: ", progname); - fprintf(stderr, tformat(), *tp); - fprintf(stderr, " ->"); - fprintf(stderr, " year=%d", tmp->tm_year); - fprintf(stderr, " mon=%d", tmp->tm_mon); - fprintf(stderr, " mday=%d", tmp->tm_mday); - fprintf(stderr, " hour=%d", tmp->tm_hour); - fprintf(stderr, " min=%d", tmp->tm_min); - fprintf(stderr, " sec=%d", tmp->tm_sec); - fprintf(stderr, " isdst=%d", tmp->tm_isdst); - fprintf(stderr, " -> "); - fprintf(stderr, tformat(), t); - fprintf(stderr, "\n"); - errout = true; - } - } - return tmp; -} -#endif /* !defined TYPECHECK */ - static void abbrok(const char *const abbrp, const char *const zone) { @@ -600,16 +554,16 @@ main(int argc, char *argv[]) t = absolute_min_time; if (! (iflag | Vflag)) { show(tz, argv[i], t, true); - if (my_localtime_rz(tz, &t, &tm) == NULL + if (localtime_rz(tz, &t, &tm) == NULL && t < cutlotime) { time_t newt = cutlotime; - if (my_localtime_rz(tz, &newt, &newtm) != NULL) + if (localtime_rz(tz, &newt, &newtm) != NULL) showextrema(tz, argv[i], t, NULL, newt); } } if (t + 1 < cutlotime) t = cutlotime - 1; - tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; + tm_ok = localtime_rz(tz, &t, &tm) != NULL; if (tm_ok) { ab = saveabbr(&abbrev, &abbrevsize, &tm); if (iflag) { @@ -651,9 +605,9 @@ main(int argc, char *argv[]) time_t newt = absolute_max_time; t = cuthitime; if (t < newt) { - struct tm *tmp = my_localtime_rz(tz, &t, &tm); + struct tm *tmp = localtime_rz(tz, &t, &tm); if (tmp != NULL - && my_localtime_rz(tz, &newt, &newtm) == NULL) + && localtime_rz(tz, &newt, &newtm) == NULL) showextrema(tz, argv[i], t, tmp, newt); } show(tz, argv[i], absolute_max_time, true); @@ -728,7 +682,7 @@ hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) caller already did that. On platforms without TM_ZONE, tzname may have been altered since our caller broke down LOT, and tzname needs to be changed back. */ - bool lotm_ok = my_localtime_rz(tz, &lot, &lotm) != NULL; + bool lotm_ok = localtime_rz(tz, &lot, &lotm) != NULL; bool tm_ok; char const *ab = lotm_ok ? saveabbr(&loab, &loabsize, &lotm) : NULL; @@ -739,7 +693,7 @@ hunt(timezone_t tz, time_t lot, time_t hit, bool only_ok) time_t t = (rem_sum == 2) - (rem_sum < 0) + lot / 2 + hit / 2; if (t == lot) break; - tm_ok = my_localtime_rz(tz, &t, &tm) != NULL; + tm_ok = localtime_rz(tz, &t, &tm) != NULL; if (lotm_ok == tm_ok && (only_ok || (ab && tm.tm_isdst == lotm.tm_isdst @@ -847,7 +801,7 @@ show(timezone_t tz, char *zone, time_t t, bool v) } printf(" = "); } - tmp = my_localtime_rz(tz, &t, &tm); + tmp = localtime_rz(tz, &t, &tm); if (tmp == NULL) { printf(tformat(), t); printf(_(" (localtime failed)")); @@ -884,7 +838,7 @@ showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) : hi + (hi < TIME_T_MAX)); if (SECSPERDAY < boundary - lo) { lo = boundary - SECSPERDAY; - lotmp = my_localtime_rz(tz, &lo, &localtm[old]); + lotmp = localtime_rz(tz, &lo, &localtm[old]); } if (lotmp) localtm[old] = *lotmp; @@ -899,7 +853,7 @@ showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) worth the trouble. */ for (t = lo + 1; t < hi; t++) { bool new = !old; - if (! my_localtime_rz(tz, &t, &localtm[new])) + if (! localtime_rz(tz, &t, &localtm[new])) localtm[new].tm_sec = -1; if (! my_gmtime_r(&t, &gmtm[new])) gmtm[new].tm_sec = -1; -- 2.54.0

1 0

Proposal to add America/Quito as a link to America/Guayaquil in the 'southamerica' file
by Byron Valdivieso June 8, 2026

June 8, 2026

Dear TZ Coordinators and community, I would like to formally propose adding 'America/Quito' as a Link to 'America/Guayaquil' in the 'southamerica' data file. While I understand the database policy of minimizing redundancy for regions with identical UTC offset history since 1970, the exclusion of Quito causes significant friction for end-users. In almost all modern Linux distributions and open-source installers, users in Ecuador are forced to select "Guayaquil" as their geographic anchor, creating confusion since Quito is the nation's capital and the administrative center. Geopolitically and historically, Quito holds the legal custody of the national time. According to Ecuadorian legislation, the "Observatorio Astronómico de Quito" (OAO), founded in 1873 and located in the capital, is the official institution responsible for calculating and broadcasting the official time for the entire continental territory (Ecuador Time - ECT, UTC-5). Adding a link would align Ecuador's representation with neighboring South American countries where capitals are systematically used as canonical zone names or main entry points (e.g., America/Bogota, America/Lima). Therefore, I suggest adding the following line to the 'southamerica' file: Link America/Guayaquil America/Quito Thank you very much for your time, consideration, and your continuous maintenance of the global time zone database. Best regards, Byron Valdivieso AndradeQuito - Ecuador

2 1

Nunavut explores ending time changes
by bellaire＠tk.com June 2, 2026

June 2, 2026

I am watching for news related to Cambridge Bay officially changing to UTC-06 to match the new time zone in Alberta. It appears Nunavut is ready to reconsider time zones across their entire territory. Justice Minister George Hickes provided the update Tuesday in the legislative assembly in response to a question from Kugluktuk MLA Simon Kuliktana. “As recently as earlier this month, my officials from Justice have been in communication with other counterparts in Northwest Territories to discuss this matter. So yes, it is something that’s in front of me,” Hickes said. . . . Nunavut’s three time zones add “complexity” to the issue, Hickes said, adding there would be public consultation before any changes are made and new legislation would be required for implementation. https://nunatsiaq.com/stories/article/nunavut-explores-ending-time-changes/ The full discussion can be read starting on page 11 (PDF page 17) of the Nunavut Hansard for May 26th. https://www.assembly.nu.ca/sites/default/files/2026-05/20260526_Blues_Engli…

3 2