- tz - lists.iana.org

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

June 9, 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 9, 2026

June 9, 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 29, 2026

May 29, 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

Missing record Madeira Island DST
by Stefanie Schlosser May 27, 2026

May 27, 2026

Dear IANA team, For personal reasons, I've been trying to find out about DST on Madeira Island, Portugal during the past century. Long story short. I've researched a lot and along the way I've been told that even IANA is actually missing some records for when Madeira Island was congruent in its time changes with mainland Portugal (Lisbon) and when it did its own thing. I've eventually found the original law text for Madeira Island from 1982 and am hereby submitting it to you. You don't have any mistake in your tzdb, but seemingly part of it is based on the assumption that Madeira did not apply DST under certain years, and you didn't have prove of it. Here comes the prove. :) With best regards, Stefanie Schlosser

2 1

US permanent DST to make its way into transportation funding bill
by Tim Parenti May 23, 2026

May 23, 2026

Many on this list will remember the *Sunshine Protection Act of 2021* passing the US Senate in March 2022 by unanimous consent in uncharacteristically swift fashion: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/GRBDSXXXWM4XXNERF… Following near-immediate blowback from a few senators — including Senator Tom Cotton of Arkansas, who says his staff had not properly flagged it for his opposition — the effort ultimately stalled in the House. When sponsors of functionally identical legislation in the current Congress similarly attempted to fast-track it in October 2025, Cotton blocked the effort. https://thehill.com/homenews/nexstar_media_wire/5581335-effort-to-fast-trac… *The Hill* now reports this week that the legislation is receiving a full markup by the House Energy and Commerce Committee, and will be rolled into the *Motor Vehicle Modernization Act*, a larger transportation funding package. https://thehill.com/homenews/house/5886117-daylight-saving-time-house-repub… https://thehill.com/policy/5889199-permanent-daylight-saving-time-legislati… https://thehill.com/homenews/administration/5890568-trump-praises-daylight-… President Donald Trump, who last year admitted to press that DST reform is a "50/50 issue" which "it's hard to get excited about", praised the committee's vote on Thursday, calling it "a very nice win for the Republican Party" and saying he is "going to work very hard" to see the act signed into law. https://truthsocial.com/@realDonaldTrump/posts/116615022975327653 If adopted as-is, states that do not join Arizona and Hawaii in opting for the existing "standard time" exemption prior to the new law taking effect would automatically be placed into "permanent daylight time". The text does not currently carry any delay provision, nor does it allow for states to opt in or out of DST after it is adopted. https://www.congress.gov/bill/119th-congress/house-bill/139/text https://www.congress.gov/bill/119th-congress/house-bill/7389/text -- Tim Parenti

1 0

Manitoba DST survey underway
by Tim Parenti May 23, 2026

May 23, 2026

Following on from Manitoba Premier Wab Kinew's recent statements to press that "the days of Manitoba switching the clocks twice a year are pretty much at the end"… https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/MLTAPD5WO23WH5MFB… CBC and Global report on social media posts from the premier's office this week, encouraging Manitobans to take a survey on the future of semi-annual time changes: https://www.cbc.ca/news/canada/manitoba/time-change-survey-9.7205662 https://globalnews.ca/news/11856999/manitoba-survey-daylight-savings/ "[The survey] asks specifically which option residents would like to see. Choices include permanent daylight time, permanent standard time, sticking to the status quo and keeping time changes and a final option for no preference." A government spokesperson has said the survey will run through 31 August 2026, so we will probably not see legislative action until the Assembly's fall sitting which is scheduled from 29 September to 3 December 2026. It seems, then, that clocks in Manitoba will likely fall back to UTC−6 on 1 November 2026 as scheduled and either (a) stay there, adopting a "permanent standard time"/"Prairie time zone", (b) spring forward a final time to UTC−5 on 14 March 2027, or (c) maintain the *status quo*. Whichever the outcome, scheduled offsets are not likely to be affected until sometime in 2027. The survey is available in both English and French here: https://engagemb.ca/time-change https://participationmb.ca/changement-d-heure -- Tim Parenti

1 0