- tz - lists.iana.org

[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

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

June 11, 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

2 1

[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

New Apple time zone data for Canada?
by Paul Eggert June 1, 2026

June 1, 2026

Gary Ng reported[1] that on Tuesday he got a notification on his Apple TV that updated time zone information was available, and that this was because Apple pushed out an over-the-air time zone update for Canadian users due to recent provincial legislation in BC and Alberta. I'm skeptical at least about the "Alberta" part, since the Alberta changes are not yet official. Does anyone have definitive information about this? The only public repository I found for Apple[2] is currently based on TZDB 2025b, which is so old that it doesn't have the official changes for British Columbia, much less the not-yet-official changes for Alberta. I would guess the updates Ng reported are newer than 2025b. Another possibility is that Apple's changes for Canada are about interfacing to cell phone service providers, which are presumably having their own issues with time zones. [1]: Ng G. Apple Sends Overnight Time Zone Fix to Canadian iPhones. Here’s Why. iPhone in Canada. 2026-05-27. <https://www.iphoneincanada.ca/2026/05/27/apple-iphone-time-zone-update-cana…> [2]: https://github.com/apple-oss-distributions/TimeZoneData/commits/main/

4 6

Nunavut explores ending time changes
by James Bellaire June 1, 2026

June 1, 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/

2 1

[PROPOSED] Stop using -Wstrict-overflow
by Paul Eggert May 28, 2026

May 28, 2026

* Makefile (GCC_DEBUG_FLAGS): Remove -Wstrict-overflow, as it is deprecated and slated to be removed in GCC 17. Issue reported by Drea Pinski in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101913#c6 --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 3428e8fd..98c19b93 100644 --- a/Makefile +++ b/Makefile @@ -383,7 +383,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ -Wmissing-variable-declarations -Wnested-externs \ -Wnull-dereference \ -Wold-style-definition -Woverlength-strings -Wpointer-arith \ - -Wshadow -Wshift-overflow=2 -Wstrict-overflow \ + -Wshadow -Wshift-overflow=2 \ -Wstrict-prototypes -Wstringop-overflow=4 \ -Wsuggest-attribute=cold \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -- 2.54.0

1 0

KDS Calendar and projection-based time systems — question for TZ coordinators
by Dragan Škondrić May 27, 2026

May 27, 2026

Dear TZ Coordinators and list members, My name is Dragan Škondrić. I am an independent researcher and the author of *KDS Calendar Version 3.0*, a canon-first calendar-time specification. I am writing with a conceptual and architectural question, not with a request to change the IANA Time Zone Database. The core idea of KDS is that existing civil, legal, metrological, and software time systems — including UTC, Gregorian dates, local time zones, DST rules, ISO 8601 renderings, and TZDB-based local-time projections — may remain as projection-facing systems, while a separate canonical layer preserves invariant event identity. In short: *KDS proposes a canonical event-identity layer above projection-based time systems.* Under this framing, time zones and civil-time rules are not treated as errors or obsolete mechanisms. They remain essential projection systems for human, legal, and operational use. However, they are not treated as the primary identity of a preserved event. The event would instead carry a canonical identity, edition information, annual phase, canonical coordinates, source metadata, and projection profile information, so that different projections can be generated without collapsing the event identity into any one local-time rendering. I am aware that TZDB already solves a very different and highly practical problem: maintaining historical and current civil-time rule data for real-world locations. KDS is not proposed as a replacement for that work. My question is narrower: Does the distinction between *canonical event identity* and *civil/time-zone projection* seem technically meaningful from the perspective of people who maintain or use TZDB? A related question is whether there are existing terms, prior discussions, or known models in the time-zone / civil-time community that already address this separation between: 1. the identity of an event, 2. the instant or time scale used for ordering, 3. the local civil-time rendering, 4. and the future replay of that event under changing time-zone or calendar rules. The specification is archived on Zenodo: *KDS Calendar - Version 3.0* DOI: *10.5281/zenodo.20067725* At this stage I am not asking for endorsement, adoption, or any change to TZDB. I would simply appreciate any technical comments on whether this framing is meaningful, already covered by existing practice, or conceptually misplaced from the viewpoint of the TZDB community. Kind regards, *Dragan Škondrić*

4 5