- tz - lists.iana.org

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

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

May 26, 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 22, 2026

May 22, 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 22, 2026

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

[PATCH] Let build environment override _, N_
by Paul Eggert May 19, 2026

May 19, 2026

This is helpful when building this code inside glibc. Problem reported by Adhemerval Zanella Netto in: https://sourceware.org/pipermail/libc-alpha/2026-May/177497.html * private.h (_, N_): Don’t define if already defined. --- private.h | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/private.h b/private.h index ee191b4e..1e6db08c 100644 --- a/private.h +++ b/private.h @@ -1071,12 +1071,16 @@ time_t timeoff(struct tm *, long); ** The default is to use gettext if available, and use MSGID otherwise. */ -#if HAVE_GETTEXT -# define _(msgid) gettext(msgid) -#else /* !HAVE_GETTEXT */ -# define _(msgid) (msgid) -#endif /* !HAVE_GETTEXT */ -#define N_(msgid) (msgid) +#ifndef _ +# if HAVE_GETTEXT +# define _(msgid) gettext(msgid) +# else +# define _(msgid) (msgid) +# endif +#endif +#ifndef N_ +# define N_(msgid) (msgid) +#endif #if !defined TZ_DOMAIN && defined HAVE_GETTEXT # define TZ_DOMAIN "tz" -- 2.53.0

1 0

Alberta to follow British Columbia?
by Roozbeh Pournader May 15, 2026

May 15, 2026

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

6 10

BC considering “PacT” to abbreviate Pacific Time
by Paul Eggert May 14, 2026

May 14, 2026

The BC government is considering recommending the abbreviation “PacT” for Pacific Time as observed in British Columbia since 2026-03-09. Two draft TZDB patches are attached that would implement this. The first simply changes “MST” to “PacT” for timestamps starting 2026-11-01, in line with 2026b’s temporary hack to delay this transition because the downstream user CLDR v48.2 (2026-03-17) cannot support BC’s current timekeeping. The second patch removes the temporary hack, adjusting TZDB to better reflect BC’s timekeeping, in the hope that the temporary hack is no longer needed once the abbreviation changes from “MST” to “PacT”. I have not installed these patches into the TZDB development repository, as “PacT” is still under consideration. Comments are welcome as usual.

2 2

Re: research on TZ list
by Michelle Bastian May 13, 2026

May 13, 2026

Dear all, I'm following up from a 2021 post where I let the list know about an academic research project I was planning which involved an analysis of the list discussion. I have now had a chance to finally start on this. I said at the time that I would get back in touch to ask permissions from anyone I would like to quote directly in my write up. Since the tz discussion list is searchable, this would mean that I could not fully anonymise those I quote as is the usual default practice in my field. This email to the full list is just to update everyone on the project, and let people know that I will contact some posters individually through the email they shared with this list. There is no pressure at all to agree, in fact you can ask me to remove any of your comments entirely. If I don't hear back after my first email I will send one follow up, but after that I will assume that you would rather not be involved. If you are happy to be included, I will share an information sheet that explains in detail what I'm asking for, and what to consider when making a decision, as well as consent form. Thanks all! Earlier post: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/OTOYYCADZ7P5BUQX… With best wishes, Michelle. --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh Level 1, Room 303B, The Maltings | Minto House, 20-22 Chambers Street, Edinburgh, EH1 1JZ | 0131 651 5779 https://www.eca.ed.ac.uk/profile/dr-michelle-bastian The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0

[PROPOSED] Adjust to GCC 16’s warnings
by Paul Eggert May 9, 2026

May 9, 2026

* Makefile (GCC_DEBUG_FLAGS): Add -Wfree-labels, -Wkeyword-macro. --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c0dde5be..3428e8fd 100644 --- a/Makefile +++ b/Makefile @@ -377,7 +377,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ -Wdeclaration-after-statement -Wdouble-promotion \ -Wduplicated-branches -Wduplicated-cond -Wflex-array-member-not-at-end \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ - -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op \ + -Wfree-labels -Wimplicit-fallthrough=5 -Winit-self \ + -Wkeyword-macro -Wlogical-op \ -Wmissing-declarations -Wmissing-prototypes \ -Wmissing-variable-declarations -Wnested-externs \ -Wnull-dereference \ -- 2.54.0

1 0

[PROPOSED] Update commentary for Winnipeg in 1916 and 1960s
by Paul Eggert May 8, 2026

May 8, 2026

* northamerica: Update commentary in the light of Christian Cassidy’s article published two days ago. Although it seems that our data for America/Winnipeg in the 1960s are incorrect, as yet we have no better sources than Shanks & Pottenger. --- northamerica | 21 ++++++++++++++++----- 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/northamerica b/northamerica index 3e8641e1..6198e72e 100644 --- a/northamerica +++ b/northamerica @@ -1742,6 +1742,22 @@ Zone America/Toronto -5:17:32 - LMT 1895 # Manitoba +# From Paul Eggert (2026-05-08): +# For 1916 timestamps America/Winnipeg covers only a small region. See: +# Cassidy C. Winnipeg's 100-year history with daylight time. +# Winnipeg Free Press. 2026-05-06. +# https://www.winnipegfreepress.com/our-communities/correspondents/2026/05/06… +# Of the 1916 experiment, Cassidy writes: "As rural areas and nearby +# urban centres such as Selkirk and Brandon did not adopt DST, the +# City of Winnipeg essentially had its own time zone." Cassidy also +# writes that province-wide DST came into effect on 1963-05-12. +# +# Shanks & Pottenger write that Winnipeg did not observe DST in 1964 and 1965. +# Although dubious in the light of Cassidy's article, we lack a better source. +# Perhaps S&P's data are for the train stations, not for the city? +# Also, S&P say Manitoba switched at 02:00 (not 02:00s) starting in 1966. +# Since 02:00s is clearly correct for 1967 on, assume 02:00s in 1966 too. + # From Rob Douglas (2006-04-06): # the old Manitoba Time Act - as amended by Bill 2, assented to # March 27, 1987 ... said ... @@ -1756,11 +1772,6 @@ Zone America/Toronto -5:17:32 - LMT 1895 # the 1987 version would apply - the changeover was at 2:00 Central # Standard Time (i.e. not until 3:00 Central Daylight Time). -# From Paul Eggert (2006-04-10): -# Shanks & Pottenger say Manitoba switched at 02:00 (not 02:00s) -# starting 1966. Since 02:00s is clearly correct for 1967 on, assume -# it was also 02:00s in 1966. - # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Winn 1916 only - Apr 23 0:00 1:00 D Rule Winn 1916 only - Sep 17 0:00 0 S -- 2.51.0

1 0

Greenland to abolish DST starting in 2028
by Paul Eggert May 6, 2026

May 6, 2026

The Copenhagen Post reported today[1] that the Naalakkersuisut Government of Greenland supports abolishing daylight saving time, effective January 1, 2028, so that most of Greenland will remain on UTC-2 indefinitely after that. The premier Jens-Frederik Nelson confirmed the intention to issue a new decree to that effect. Although I don't know the details, my impression is that this will affect America/Nuuk and America/Scoresbysund but not America/Thule (which uses US rules, not EU) and America/Danmarkshavn (which does not observe DST). The practical date for this change is 2028-03-26, which is when Greenland would otherwise spring forward, so we have plenty of time to wait for the details in the official decree and install a change to TZDB well before the practical date. [1]: Greenland to abolish daylight saving time from 2028. Copenhagen Post. 2026-05-06. <https://cphpost.dk/2026-05-06/news/round-up/greenland-to-abolish-daylight-s…>

1 0

Elsewhere in Canada
by Tim Parenti May 6, 2026

May 6, 2026

Manitoba Premier Wab Kinew says he thinks "the days of Manitoba switching the clocks twice a year are pretty much at the end," though there appears to be some internal wrangling over which way the clocks should move for the final time. "If we move to permanent standard time, you could have a Prairie time zone" shared between Manitoba, Saskatchewan, and Alberta. https://www.cbc.ca/news/canada/manitoba/time-change-kinew-9.7176389 Manitoba's Legislative Assembly is in session through 1 June before its summer recess, though a decision to adopt such a "Prairie time zone" on year-round UTC−6 likely wouldn't affect wall-clock times until 14 March 2027. So any legislation, if forthcoming, may not happen until the fall. Meanwhile, in Atlantic Canada, "Nova Scotia Premier Tim Houston said he is open to the idea but only if neighbouring provinces did too," while New Brunswick Premier Susan Holt says "we would want to do it in concert with our Atlantic peers. But this is premature." https://www.msn.com/en-ca/news/canada/as-alberta-moves-to-end-time-changes-… https://www.pressreader.com/canada/telegraph-journal/20260429/2815565924285… -- Tim Parenti

1 0

America/Cranbrook
by Chris Walton May 6, 2026

May 6, 2026

Heads up: The *Regional District of East Kootenay* is planning to move to year-round Mountain Standard Time (MST) on November 1, 2026. The district will seek approval from the province (British Columbia). I am skepitcal that they really need provincial approval, but I guess there is no harm in seeking it. In practical terms the district would move from MDT to MST on November 1 as per usual. After that, the clocks would stay fixed on MST. Currently most of East Kootenay uses the *America/Edmonton* TZ ID. There is a very small area in the southwest corner that uses *America/Creston*. If the change is approved, we would need a new TZ ID... probably something like "*America/Cranbrook"*. https://www.rdek.bc.ca/news/entry/rdek_board_moves_to_transition_to_year_ro… Columbia-Shuswap Regional District lies to the north of East Kootenay Regional District. Some areas of Columbia-Shuswap are already on year-round MST and some areas (including the town of Golden) use MST/MDT. I would not be surprised if all of Columbia-Shuswap eventually adopts year-round MST. If that happens, the entire province of BC would be aligned on year-round MST. -chris

4 13

[PROPOSED] Check for NEWS typos similar to 2026b’s
by Paul Eggert April 23, 2026

April 23, 2026

* Makefile (check_mild): Depend on new check. (news.ck): New check. * NEWS: Reword to pass check. --- Makefile | 8 +++++++- NEWS | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 1e0a5903..c0dde5be 100644 --- a/Makefile +++ b/Makefile @@ -913,7 +913,7 @@ tzselect: tzselect.ksh version check: check_mild back.ck now.ck check_mild: check_web check_zishrink \ character-set.ck white-space.ck links.ck mainguard.ck \ - name-lengths.ck slashed-abbrs.ck sorted.ck \ + name-lengths.ck news.ck slashed-abbrs.ck sorted.ck \ tables.ck ziguard.ck tzs.ck # True if UTF8_LOCALE does not work; @@ -1083,6 +1083,12 @@ zishrink-posix.ck zishrink-right.ck: \ rm -fr $@d t-$@d shrunk-$@d touch $@ +# Check that NEWS has data release versions and dates in reverse order. +news.ck: NEWS + grep '^Release [0-9][0-9][0-9][0-9]' NEWS | LC_ALL=C sort -cru + sed -n '/ -0000$$/!s/^Release [^ ]*//p' NEWS|LC_ALL=C sort -cru + touch $@ + clean_misc: rm -fr *.ckd *.dir rm -f *.ck *.core *.o *.out *.t core core.* \ diff --git a/NEWS b/NEWS index ea52e67e..fb1ced71 100644 --- a/NEWS +++ b/NEWS @@ -6666,7 +6666,7 @@ few (e.g., code2012c-data2012d) have tarballs with mixed version numbers. Recent releases also come in an experimental format consisting of a single tarball tzdb-R.tar.lz with extra data. -Release timestamps are taken from the release's commit (for newer, +A release's timestamp is taken from the release's commit (for newer, Git-based releases), from the newest file in the tarball (for older releases, where this info is available) or from the email announcing the release (if all else fails; these are marked with a time zone -- 2.51.0

1 0

[tz-announce] 2026b release of tz code and data available
by Paul Eggert via tz-announce April 23, 2026

April 23, 2026

The 2026b release of the tz code and data is available. As Tim mentioned yesterday[1], this release’s main impetus is British Columbia’s decision to stop changing its clocks and stay on permanent UTC-07, which affects BC’s UTC offsets starting 2026-11-01 at 02:00. Since this change will likely cause problems downstream as CLDR’s latest release cannot handle it, we’re pushing out this release now so that downstream has some time to test and reprogram. Quite possibly we’ll need another release soon to accommodate proposed changes in Alberta and Northwest Territories. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/LZIJFAY2K4OXXCAGF… There is an embarrassing typo in the 2026b release: its NEWS file's third line has the wrong release number. I applied the following patch to the development version on GitHub and this patch should appear in the 2026c release. diff --git a/NEWS b/NEWS index a0042701..ea52e67e 100644 --- a/NEWS +++ b/NEWS @@ -3 +3 @@ News for the tz database -Release 2026a - 2026-04-22 23:06:43 -0700 +Release 2026b - 2026-04-22 23:06:43 -0700 The 2026b release contains the following changes: 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. Changes to code zic no longer mishandles a last transition to a new time type. zic no longer overflows a buffer when generating a TZ string like "PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59", which can occur with adversarial input. (Thanks to Naveed Khan.) zic no longer generates a longer TZif file than necessary when an earlier time zone abbreviation is a suffix of a later one. As a nice side effect, zic no longer overflows a buffer when given a long series of abbreviations, each a suffix of the next. (Buffer overflow reported by Arthur Chan.) zic no longer overflows an int when processing input like ‘Zone Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer overflow in adversarial cases. (Thanks to Naveed Khan.) zic now checks for signals more often. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2026b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2026b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2026b.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 48c25a1ba86cb602990c0573aba7795417931bb4 dated 2026-04-22 23:06:43 -0700 and tagged '2026b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 55b44d52a83c9db151be32c3d78376ea7f9d4311ef15ed6fe34b855b08fc546531e51309d178d9c175a6d5d7d0b058440e45a55d200ca8925e3798dac9bc739f tzcode2026b.tar.gz a44882258c0a7fbe587e8b73d6bb3cd5be7d4788976ea742adbbf176eb3b33e5bd7d1714b2fffe2972b1a42e7335eac39ed0bd63e819bb421550f8cae1df4f2f tzdata2026b.tar.gz 5ec7f74f14cd2c70a0730e3690e82bd0ba889ac26c96397c16aa08005473c2c86feb47958b52e0301810c8eb908e6d8faf998ffae75b2337a912cc9e52c0f9e9 tzdb-2026b.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt34ACgkQ7ZfpDmKq fjSZew//brt18HiMD/tgxJ1CdjvvzDIZ4P0xWsVuxG4MjkC4821zYCfhDYLZ9Zdb /8wCi63uecmK2JsGjxzz+raX4ppHhZpg31a70KlyU9MarISVB2ldPqYDn+Xc98lR XIKj1ahtzyJoNu/67ZbCT7Ih/Wp8hwdlEFivjq00lnt+M2XCeINq9Cy3guisx3/8 dCziZEqoJFXDsdWmCvKZ93U/o7Xq8x7d9nfRjeBlX8VZMXuSnY3WkhLBRl+2Zgml ECeohhLMBuR6dFNOW6qwlsZGXfDb/Nq1NPsxIKqJ5Lv1K8Sj0h4icsGDMRrLvlZM qfNpsjWZQcH9JErR5hfB/Y6INRsKomRamul9LdlEAauMwO287eR8r5LrADMiAvPR jBVqmceAmgS+34BpRmMUfLwQJmEELbK8xzcdW8e41jrQQ8SuyqXQeYBjgjm3v7gc sA1HyWwDRn6276DQATonELOzREctHLIp2jfRGLAwngAl2CzqkhLZgBEHvdZbqW/s RbZLOk0u/y3Trd+dyFcLq/gxNSZQYQqpDmRiYNkb0vl02lu3lbZ1o3dmdF/AZ70U evj6z5iXztdKCQb9ZkecjNXncPDQNPoO1bJqm1QNYvUToMDNnJdu12qva+skNUyt HE54zxjcKv78bhm2ufXcqt4Ju/onyACTkSDQeCEzIzdBu9abVgw= =7394 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt34ACgkQ7ZfpDmKq fjTFTxAAisuje9O4OTkSUUQ4nHuZOHQW/1FNGXmIb/bGnAGAwOrGqiLuyQ0kJYxk Gdp4cTXEu5+NyQXeBPFtjBNbZO2cMC80rvl9/h3qUlbYG+ydhY0bjDglV3BEP/U/ OrP4pQsNjHeSl+p+3VSq7fAtOGcCRkBQrbEy5yXN5HzYJyCH4GAE1HZNNYKbCzAm hIxspmu6zjeN4xeLsXrB7DfiP7BJydrxk1LShU4zwmwJdmkH8dCGnDW4Kipz+tWF 2W8P4braXTAWCswLhOC8xYZLJKxf1nWS3dyo3i1IfnRciGD0O9dyLsJmlHxS4/34 Ometm9XahPHPiWvjBoqubKEfp6B+AlmmP9D1jM0BY7seuz2oxFUE7YW5+4cO4VhJ soWTDCKjyzo+wgflw3brv7j5AFP7tA7To6fbQ0W0oAmSRFQ10MA3JB0GSgn45SST 49C9jQ7U0XcroeIuoWs/1MbAz+qgCLk9QdijxNWsvk5S5h88FKLckVkEUUNgUSL/ F3z4h2Af6KpWq/n3wL97gwdis8cwxWScL3ZpfikiMJbEGuaIHabiw7C+r/dQssW0 7SbG01yZWgn3HtJBfELs1cmqWCUN4F+Y28um0Y4VYHTpSnNuVHBJ1wtfqCSatWYC wQa+n7KtBEGpY7BbSDZ/oGuqfDzpgR41F1tX7ZRa5y24zWHRQLQ= =eO2u -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmnpt38ACgkQ7ZfpDmKq fjTopg//ViAbiWmRZnu7F5owFRPySQWCSM1RJfBWOTL/UJjSArP2JbkOudcgeXZo Wj6fk1soY8w3o6CJACq12HhUAjQq6/mCupTyDSgOETMn2x/ZknuE407MOMc0t51t iYnfICJNYs1u1uRC/b7PEALYT7lt3Ab6QGe5iO2kVrFqJoB1AxRDIQlfPAHiRILY Abbt9avcL+k76idhSC782BmAFqtogPeHBVYQzBOgw/LfWGQ8ckkk66f4X8E6QMzA CkDSt/bAWIM/iVKw6ag4VBvIbzY2sR1EieN2GlHj5Dx6xMBlQdDpETgTIfNYG7si Ndai7vbMh+Gff5JfYiKq94WJ2uAP4jI3phN2NXpcYwc0OmEEMlYc/lcIlje3Bb3o Y+yop6RoVQpN6zbzLnuCMiDmy1SB2yhWpYQm/bqR1Qsb8vBfWBD3fvdscWXabDl8 m3ii38melVIdjSR18Qf3j9MOXefHo3xu0t00/ppPCwnuKKbhSItvTI9vg8BxqWL8 7iZYhNBkoJTIpgmTaHAggNUKNoa3mNYTuwJr7o/i4Bhki2ggzR5dKiKE9PAXSLaG 1tvCoWVVA3gGklkxFYnUncghC/YbEBDYWlaXbfgOC/+fhix7HnRCNcwckxlww86m gZCa2DcTBWiVQ6PP/6LzgHgNn7mhriVs0cGGVOlTL/h/zjm5CDw= =1+mL -----END PGP SIGNATURE-----

1 0

Northwest Territories joining Alberta in plans to scrap seasonal time changes
by Tim Parenti April 22, 2026

April 22, 2026

https://www.cbc.ca/news/canada/north/nwt-ends-daylight-saving-9.7170964 "[Northwest Territories] Premier R.J. Simpson announced Monday that the territory will move to end seasonal time changes and will adopt a year-round time standard instead." "Simpson has previously said the territory wouldn't end seasonal time changes until Alberta does." Meanwhile, Alberta's proposed change, mentioned yesterday <https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/KHKTGFAIURBVZBBJB…>, has yet to be introduced in its Assembly and raises questions about whether the Regional District of East Kootenay will end up continuing to follow Alberta or joining the rest of British Columbia. From the NWT government press release: https://www.gov.nt.ca/en/newsroom/premier-rj-simpson-announces-end-seasonal… "Our government will begin the necessary planning to ensure a smooth transition here in the Northwest Territories. That includes developing a clear timeline, working with partners, and giving residents, businesses, and service providers the time they need to prepare." -- Tim Parenti

2 1

Canada legislative summary as of 2026-04-22
by Tim Parenti April 22, 2026

April 22, 2026

All, Paul and I have discussed the recent news out of Alberta and the Northwest Territories in Canada and how that affects our plans for upcoming releases of tzdata. *tl;dr We are inclined to cut a release with the changes for BC shortly, while we wait for AB and NWT legislation to come through and to determine where areas such as the Regional District of East Kootenay (Cranbrook, BC) will land.* To be clear, we were already aiming to release for BC any day now, but the recent AB/NWT news did prompt another check and balancing of competing priorities. A detailed summary of our understanding of where things currently stand throughout western Canada follows: *British Columbia*'s premier, David Eby, announced a shift from UTC−8/−7 to year-round UTC−7 for the bulk of the province (America/Vancouver) on 2 March 2026, pursuant to Order in Council 63 of 2026, joining other areas of BC (America/Dawson_Creek, America/Fort_Nelson) which had already observed year-round UTC−7 and are thus unaffected. The order took effect on 9 March and affects wall clock times from 1 November 2026. *Alberta*'s premier, Danielle Smith, announced in an interview on Monday 20 April 2026 a planned shift from UTC−7/−6 to year-round UTC−6, aligning the province (America/Edmonton) with Saskatchewan's long-standing practice, with legislation to be introduced "this week" as part of an omnibus bill. Order papers for Alberta's Legislative Assembly suggest the referenced bill may be Bill 31, the *Red Tape Reduction Statutes Amendment Act, 2026*, but the Assembly rose before it could be formally introduced today (Wednesday) so no text is yet available. Following another sitting tomorrow (Thursday), Alberta's Legislative Assembly is scheduled to adjourn for a constituency week before sitting again from 4 to 14 May and then adjourning to late October. So, if the proposed change is envisioned to take effect from 1 November to imitate BC, then the bill would likely need to wind its way through the legislative process within the next few weeks. *Border areas* within BC, such as most of the Regional District of East Kootenay (Cranbrook) and eastern portions of the Regional District of Central Kootenay and the Columbia–Shuswap Regional District, currently remain with the *status quo* of UTC−7/−6. In particular, RDEK had previously said on 14 March that it would join the rest of BC on year-round UTC−7, but walked that back on 10 April while committing to a "public consultation process". Attached to the agenda for the 10 April RDEK Board meeting were 189 pages of public comment opposed to the March proposal and 66 pages in support. Given Alberta's recent announcement, it seems highly likely, then, that the region will ultimately choose one single year-round time or the other; if sticking with AB and UTC−6, no new zone would be needed, while if rejoining BC and UTC−7, a new zone would be needed. Meanwhile, any prolonged regional inaction could require our action in creating a new zone anyway, so we will need to keep a close eye on what this area decides and when. Upcoming RDEK Board meetings are scheduled for 8 May and 12 June. Similarly, Saskatchewan's *Time Act* may need legislative tweaks to better handle the area around Lloydminster, which straddles the border between AB and SK and has thus generally followed Alberta, but here it is much more reasonable to assume that the end result will ultimately be year-round UTC−6, once those two provinces are so aligned. Saskatchewan's Legislative Assembly is presently scheduled to sit until 14 May before similarly adjourning to late October. https://www.sasktoday.ca/provincial-news/implications-for-sask-of-alberta-m… *Northwest Territories*' premier, RJ Simpson, announced later on Monday 20 April 2026 that NWT (represented by America/Edmonton and America/Inuvik) would follow AB in shifting from UTC−7/−6 to year-round UTC−6, but gave no specific timeline, stating only that the NWT government will "begin the necessary planning", which includes "developing a clear timeline [and] working with partners". Again, assuming this goes forward alongside AB, no new zone will be needed, but legislative inaction could necessitate America/Yellowknife becoming its own zone rather than a link. The NWT Legislative Assembly has committee work scheduled in the next two weeks, 27 April through 8 May, and next sits from 27 May through 4 June before also adjourning to late October, so it may be some weeks before legislative details emerge there. * * * In short, because the AB and NWT changes are yet to be legislated and may take several more weeks to be finalized, it makes sense for us to wait on those and batch them, so as to also give more time to see how the various border areas react. Based on legislative calendars, it seems reasonable to think that any legislation which is to happen in these areas will happen by mid-June if it is to take effect for November 2026. In the meantime, a release now-ish with the changes for BC will allow those to start propagating and downstream vendors/projects to begin grappling with their various implementation details, including concepts such as "Pacific Time (US & Canada)" no longer meaning what they once did, before a follow-up release with AB and NWT changes hopefully by sometime in June similarly affects additional regions and concepts. Hopefully this ongoing situation is illustrative as to why we are extremely hesitant to promise any particular release timing. Any possible forward guidance we could give would always come with the asterisk "unless something else comes up". -- Tim Parenti

1 0

[PROPOSED] Output a minimal time zone designation table
by Paul Eggert April 15, 2026

April 15, 2026

When keeping the time zone designation table small, also handle the case where an existing abbreviation is a suffix of the newly arrived abbreviation, so that only the latter abbreviation needs to be stored. The only TZif file in the current data affected by this change is Asia/Ho_Chi_Minh, which shrinks by 4 bytes because the earlier abbreviation LMT is a suffix of a later one PLMT. As a nice side effect, this patch also fixes an unlikely stack buffer overflow reported privately by Arthur Chan. * NEWS: Mention this. * zic.c (writezone, addtype): Handle an abbreviation being added when an existing abbreviation is its suffix. Without this patch both abbreviations would appear in this table, but only the longer abbreviation needs to be present. (checkabbr): New function, containing the checking part of the old newabbr function. (newabbr): Remove. Change uses to checkabbr + addabbr. (addabbr): New function, which is like the old newabbr’s adding code, except it removes any existing abbreviation that is a suffix of the new one. --- NEWS | 6 ++++ zic.c | 110 +++++++++++++++++++++++++++++++++++++++------------------- 2 files changed, 81 insertions(+), 35 deletions(-) diff --git a/NEWS b/NEWS index 1a97cbfe..09a15519 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,12 @@ Unreleased, experimental changes "PST-167:59:58PDT-167:59:59,M11.5.6/-167:59:59,M12.5.6/-167:59:59", which can occur with adversarial input. (Thanks to Naveed Khan.) + zic no longer generates a longer TZif file than necessary when + an earlier time zone abbreviation is a suffix of a later one. + As a nice side effect, zic no longer overflows a buffer when given + a long series of abbreviations, each a suffix of the next. + (Buffer overflow reported by Arthur Chan.) + zic no longer overflows an int when processing input like ‘Zone Ouch 2147483648:00:00 - LMT’. The int overflow can lead to buffer overflow in adversarial cases. (Thanks to Naveed Khan.) diff --git a/zic.c b/zic.c index 6e859d09..7ecf3b91 100644 --- a/zic.c +++ b/zic.c @@ -253,12 +253,13 @@ symlink(char const *target, char const *linkname) (errno = ENOTSUP, -1) #endif -static void check_for_signal(void); +static int addabbr(char[TZ_MAX_CHARS], int *, char const *); static void addtt(zic_t starttime, int type); static int addtype(zic_t, char const *, bool, bool, bool); -static void leapadd(zic_t, int, int); static void adjleap(void); static void associate(void); +static void checkabbr(char const *); +static void check_for_signal(void); static void dolink(const char *, const char *, bool); static int getfields(char *, char **, int); static zic_t gethms(const char * string, const char * errstring); @@ -271,11 +272,11 @@ static void inrule(char ** fields, int nfields); static bool inzcont(char ** fields, int nfields); static bool inzone(char ** fields, int nfields); static bool inzsub(char **, int, bool); -static int itssymlink(char const *, int *); static bool is_alpha(char a); +static int itssymlink(char const *, int *); +static void leapadd(zic_t, int, int); static char lowerit(char); static void mkdirs(char const *, bool); -static void newabbr(const char * abbr); static zic_t oadd(zic_t t1, zic_t t2); static zic_t omul(zic_t, zic_t); static void outzone(const struct zone * zp, ptrdiff_t ntzones); @@ -2936,30 +2937,27 @@ writezone(const char *const name, const char *const string, char version, : i == thisdefaulttype ? old0 : i] = thistypecnt++; - for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i) - indmap[i] = -1; thischarcnt = stdcnt = utcnt = 0; for (i = old0; i < typecnt; i++) { - register char * thisabbr; - if (omittype[i]) continue; if (ttisstds[i]) stdcnt = thistypecnt; if (ttisuts[i]) utcnt = thistypecnt; - if (indmap[desigidx[i]] >= 0) - continue; - thisabbr = &chars[desigidx[i]]; - for (j = 0; j < thischarcnt; ++j) - if (strcmp(&thischars[j], thisabbr) == 0) - break; - if (j == thischarcnt) { - strcpy(&thischars[thischarcnt], thisabbr); - thischarcnt += strlen(thisabbr) + 1; - } - indmap[desigidx[i]] = j; + addabbr(thischars, &thischarcnt, &chars[desigidx[i]]); } + + /* Now that all abbrevs have been added to THISCHARS, + it is safe to set INDMAP without worrying about + whether the abbrevs might move later. */ + for (i = 0; i < TZ_MAX_CHARS; i++) + indmap[i] = -1; + for (i = old0; i < typecnt; i++) + if (!omittype[i] && indmap[desigidx[i]] < 0) + indmap[desigidx[i]] = addabbr(thischars, &thischarcnt, + &chars[desigidx[i]]); + if (pass == 1 && !want_bloat()) { hicut = thisleapexpiry = false; pretranstype = -1; @@ -3782,6 +3780,7 @@ static int addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut) { register int i, j; + int charcnt0; /* RFC 9636 section 3.2 specifies this range for utoff. */ if (! (-TWO_31_MINUS_1 <= utoff && utoff <= TWO_31_MINUS_1)) { @@ -3791,12 +3790,18 @@ addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut) if (!want_bloat()) ttisstd = ttisut = false; - for (j = 0; j < charcnt; ++j) - if (strcmp(&chars[j], abbr) == 0) - break; - if (j == charcnt) - newabbr(abbr); - else { + checkabbr(abbr); + + charcnt0 = charcnt; + j = addabbr(chars, &charcnt, abbr); + if (charcnt0 < charcnt) { + /* If an abbreviation was inserted, increment indexes no + earlier than the insert by the size of the insertion, + so that they continue to point to the same contents. */ + for (i = 0; i < typecnt; i++) + if (j <= desigidx[i]) + desigidx[i] += charcnt - charcnt0; + } else { /* If there's already an entry, return its index. */ for (i = 0; i < typecnt; i++) if (utoff == utoffs[i] && isdst == isdsts[i] && j == desigidx[i] @@ -4181,10 +4186,8 @@ will not work with pre-2004 versions of zic")); } static void -newabbr(const char *string) +checkabbr(char const *string) { - register int i; - if (strcmp(string, GRANDPARENTED) != 0) { register const char * cp; const char * mp; @@ -4203,13 +4206,50 @@ mp = _("time zone abbreviation differs from POSIX standard"); if (mp != NULL) warning("%s (%s)", mp, string); } - i = strnlen(string, TZ_MAX_CHARS - charcnt) + 1; - if (charcnt + i > TZ_MAX_CHARS) { - error(_("too many, or too long, time zone abbreviations")); - exit(EXIT_FAILURE); - } - strcpy(&chars[charcnt], string); - charcnt += i; +} + +/* Put into CHS, which currently contains *PNCHS bytes containing + NUL-terminated abbreviations none of which are suffixes of another, + the abbreviation ABBR including its trailing NUL. + If ABBR does not already appear in CHS, + possibly as a suffix of an existing abbreviation, + add ABBR to CHS, remove from CHS any abbreviation + that is a suffix of ABBR, and increment *PNCHS accordingly. + Return the index of ABBR after any modifications to CHS are made. + + If all abbreviations have already been added, this function + lets the caller look up the index of an existing abbreviation. */ +static int +addabbr(char chs[TZ_MAX_CHARS], int *pnchs, char const *abbr) +{ + int nchs = *pnchs; + int alen = strlen(abbr), nchs_incr = alen + 1; + int i; + for (i = 0; i < nchs; ) { + int clen = strlen(&chs[i]); + if (alen <= clen) { + /* If ABBR is a suffix of an abbreviation in CHS, + return the index of ABBR in CHS. */ + int isuff = i + (clen - alen); + if (memcmp(&chs[isuff], abbr, alen) == 0) + return isuff; + } else if (memcmp(&chs[i], &abbr[alen - clen], clen) == 0) { + /* An abbreviation in CHS is a substring of ABBR. + Replace it with ABBR, instead of the more-common + actions of appending ABBR or doing nothing. */ + nchs_incr = alen - clen; + break; + } + i += clen + 1; + } + if (TZ_MAX_CHARS < nchs + nchs_incr) { + error(_("too many, or too long, time zone abbreviations")); + exit(EXIT_FAILURE); + } + memmove(&chs[i + nchs_incr], &chs[i], nchs - i); + memcpy(&chs[i], abbr, nchs_incr); + *pnchs = nchs + nchs_incr; + return i; } /* Ensure that the directories of ARGNAME exist, by making any missing -- 2.53.0

1 0