- tz - lists.iana.org

[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

America/Cranbrook
by Chris Walton April 11, 2026

April 11, 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 12

British Columbia will adopt permanent daylight saving time starting March 8, 2026, with no further seasonal clock changes.
by Francis, Jereme April 10, 2026

April 10, 2026

British Columbia will adopt permanent daylight saving time starting March 8, 2026, with no further seasonal clock changes. Please ensure this is updated in your database. Thank you. Jereme Francis This email and its attachments are confidential. Any unauthorized use or disclosure is prohibited. If you receive this email in error, please notify me by reply email and permanently delete the original without making any copies or disclosing its contents.

2 1

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

April 8, 2026

The 2026a release of the tz code and data is available. This release corrects the time for Moldova's upcoming clock transition on March 29, as well as on other dates. It also has significant changes to code and to the build procedure. This release contains the following changes: Briefly: Moldova has used EU transition times since 2022. The "right" TZif files are no longer installed by default. -DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds. TZif files are no longer limited to 50 bytes of abbreviations. zic is no longer limited to 50 leap seconds. Several integer overflow bugs have been fixed. Changes to past and future timestamps Since 2022 Moldova has observed EU transition times, that is, it has sprung forward at 03:00, not 02:00, and has fallen back at 04:00, not 03:00. (Thanks to Heitor David Pinto.) Changes to data Remove Europe/Chisinau from zonenow.tab, as it now agrees with Europe/Athens for future timestamps. Changes to build procedure The Makefile no longer by default installs an alternate set of TZif files for system clocks that count leap seconds. Install with 'make REDO=posix_right' to get the old default, which is rarely used in major downstream distributions. If your system clock counts leap seconds (contrary to POSIX), it is better to install with 'make REDO=right_only'. This change does not affect the leapseconds file, which is still installed as before. The Makefile's POSIXRULES option, which was declared obsolete in release 2019b, has been removed. The Makefile's build procedure thus no longer optionally installs the obsolete posixrules file. Changes to code Compiling with the new option -DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds. Although this conforms to POSIX, shrinks tzcode's attack surface, and is more efficient, it fails to support Internet RFC 9636's leap seconds. zic now can generate, and localtime.c can now use, TZif files that hold up to 256 bytes of abbreviations, counting trailing NULs. The previous limit was 50 bytes, and some tzdata TZif files were already consuming 40 bytes. zic -v warns if it generates a file that exceeds the old 50-byte limit. zic -L can now generate TZif files with more than 50 leap seconds. This helps test TZif readers not limited to 50 leap seconds, as tzcode's localtime.c is; it has little immediate need for practical timekeeping as there have been only 27 leap seconds and possibly there will be no more, due to planned changes to UTC. zic -v warns if its output exceeds the old 50-second limit. localtime.c no longer accesses the posixrules file generated by zic -p. Hence for obsolete and nonconforming settings like TZ="AST4ADT" it now typically falls back on US DST rules, rather than attempting to override this fallback with the contents of the posixrules file. This removes library support that was declared obsolete in release 2019b, and fixes some undefined behavior. (Undefined behavior reported by GitHub user Naveed8951.) The posix2time, posix2time_z, time2posix, and time2posix_z functions now set errno=EOVERFLOW and return ((time_t) -1) if the result is not representable. Formerly they had undefined behavior that could in practice result in crashing, looping indefinitely, or returning an incorrect result. As before, these functions are defined only when localtime.c is compiled with the -DSTD_INSPIRED option. Some other undefined behavior, triggered by TZif files containing outlandish but conforming UT offsets or leap second corrections, has also been fixed. (Some of these bugs reported by Naveed8951.) localtime.c no longer rejects TZif files that exactly fit in its internal structures, fixing off-by-one typos introduced in 2014g. zic no longer generates a no-op transition when simultaneous Rule and Zone changes cancel each other out. This occurs in tzdata only in Asia/Tbilisi on 1997-03-30. (Thanks to Renchunhui for a test case showing the bug.) zic no longer assumes you can fflush a read-only stream. (Problem reported by Christos Zoulas.) zic no longer generates UT offsets equal to -2**31 and localtime.c no longer accepts them, as they can cause trouble in both localtime.c and its callers. RFC 9636 prohibits such offsets. zic -p now warns that the -p option is obsolete and likely ineffective. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2026a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2026a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2026a.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 dd6be6d1558163517ec55c652efac70842c3b4cc dated 2026-03-01 22:59:49 -0800 and tagged '2026a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA3-512 checksums for the release files, generated by the GNU coreutils 9.8+ command 'cksum -a sha3 -l 512'. SHA3-512 (tzcode2026a.tar.gz) = 7106762916c6d21aa71fc5b43924582b603e231c90f19fb40ecd81db96208f8a4d6ff9664508c7298c521ab8fed97d4100665f84b2ba17caed04af129e40c5c2 SHA3-512 (tzdata2026a.tar.gz) = 898b090b74d927495a412f382636e4eb2f697e3e357e5a1d35e01cf95f6cdc3bd52533a269ae247b521c6ec1112cbc2df0bb5466accf376e2e7b78a3adde26bd SHA3-512 (tzdb-2026a.tar.lz) = 5aefc96aa15113da1c30fbba7564636e106e3c0e33f475d48f32c5d3417e945fada548176e56c474a85bf02681e101c7b4dd727eb0053d1d39a81c9a13afe37b Here are the SHA-512 checksums for the release files: 69a2ad3334ab1491ba349fcd5d3066a26b38ccb59031fec70ca19379cb0514fe2757af7bee31e796913c0cfc322134e2ba16f93ba07fa45cd4a415b9122b2f27 tzcode2026a.tar.gz 407e8e93aaa054a22a4a7d6d8cf480a20630073bf1a00956df16b10318f239a12015de38fad3072249193e314d6fddbff4e74afa40a88f7bf5c9eecc7659ea15 tzdata2026a.tar.gz 1824fc2e198a449ebaa41e6c679a494c486b848f13fe8f18f948fde0533e99f5f01e7e7298e257c565838d24ec743e824f402887abdf525d1ce578a714c71414 tzdb-2026a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq fjS64g//TxOxFmBXtJRx4LM8QIL315hvWwVpVAmAk+oFzqjluosfb3xbszBw3fWw PzcOyQ8PDXV42dq29jO8JjVJkCrvLiBjXWTTV6yDRqp3TEBh5uM4cUormnfcTLkT bmgVLLmqiNZgZpEHrsQQKaf8Ia/23F2topG0USSzqguLgLBVLcdut8Djfqb5qpqV xurq88ciC+ZvLENJsBXyfJzN2neuCOelbXgPDz+LJZrv3mJqFrm7EzxHngE8xZ+j Ny0V6WFaZJisWEif4oGeTPtxQS+LT/2bDBKtNpcFQhvquS6dU0nHHVAvNAIZaGNf HeQ/LgxFDQjnIisoqKA61qNmZZ1F5rDuYtL/j53nhjJpLkaDAoEU+xfKtYybJzir mH7Dj8WwUcLwH7lT/U4KDZmiUiT49Vk/u/7+pI1Vx7OogJ4Vs9WTtCt8avNGkwFF qez91hNIb6iZzVbnSKz+TWlfnBgltFQU02ozTZNW6K3TawLuwgyMoAGX0kaK8Lxy 8KKEo53phmmFnZ9vQKEJkJdaaIuisK1qJH1K6cj2GX44bhpDfT/kq4AQQbR7HDWR ZSTB5oG4TvqfGd3bKrDzpGOOLJ2AoiBaGi+rcA8n4WWvdGxodIJ6RU1cDI+RHPfv 8caWfWcEtAPCciArx2pa10gupda67DF1pwxAYLEbr+dmg2S8jQI= =/yto -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgMACgkQ7ZfpDmKq fjR04A//YmSFvKQi/w8hfB5fAf4VSV+5HBIeuTRJPn9BuRAUvZVYl78ApYGzSqPh sG3H/IPprHICVxMJcPBvEI7+tXVPozCOnwUx7jz2nAvl7awxj5n2z1zs+jjZ+/pU kiQ4x4uZDJTw5wsymy9nPasoQba5kmSItjB7fDXe2wwjPOh3osOzSfC0KDnPvTxl jPxBTd+CXDmz5fiI7RPSi1uJWJFXEtE+NpaltQpA8J1M7QSv2O+7x3eLfNoa1Eh9 GQ5JjtvMixdQGxFzMeID/Y2Rjj3vKFpB0+blf1zu5aBchemmvW/DFpOBhdm+lRf0 Me1TVlmlBI3oj4lrNhGIz3f7zf+IrPVfAAQ/hMMcyYc/FwYuuV9SSF0Aj2pWR0Mi wvASEXb23bWu2t1aeu7by7XSnL033o1P5DqWDueVSilTdeVSOS0EtyyFMC6THmj4 PcQh7/O60zbPhsUXan85rOC1CNv9lZJlEzZShy3B3tAccGr4IKrPRT/jIhVwVbu9 rS25dLR9S/bcrYTpn4aaWMPQ9tuYJ/83i1euAgs7NjKao0lziPTOPaBvqW6fdg1v /4dHluvwMufDLa23WVy2iPueTPD8NDH228xwrtGm/Spyu3XCX7YZJdCJVcNF0E9m W4z5R07LGBZYKscd9T8otPJyzTLcunLmnaf/Mbsrj4FmB+dNof8= =SR0V -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmmlNgQACgkQ7ZfpDmKq fjRfhg//WKsUlkhd9treq8Q3YMju7fezVZhvinFib7mmC3kn3HM5Xo2AKakjtwYn d0ZDuA886qFp3Llkn3pwnEh8vugE0A86qRwk3D3RoL/QfpbKkrVyAWONEWCHMKF1 MswUEO01Lcxd+CmjFWsH+dEhJ8HHLlPgyYgWCy6X3zvTyCLK5navq93QTmIKBguy tXAtWClft7wEv4Sg6xI0MtcAMamt5aBP9oC284XJbjfHz169QcK5VaCJPG82kuDs ABorgc6KVJN88SzPWsajpEQQE17hsH99y+Jh4UR4Lx4s06+52zOl814t0Aru28B2 K8u0PF5mO3druoHN8ielp9gdqIMk5JbOobhezGmnNPQT2ZIazTBa22/zVknkqoLq 6NQnpPekc2sjuVljRYCRkDwWXaUYfl8gR7e59Ew45IfFBpRCfkpEFK4A97KGfGVM gSCdW/N+9lCG2p1MrrRETykyGCX181rtnw8RXO+ADxmz8ddQ5WRrmGIkBYi7iocY 2iULltrLOAzCnUGsN0x/7xk8fLf7MRX+cExUJG992foiPQ/6N/06gp6SNeJyuKgG hI5TO9RIsR8JzjfUpI0Nbr9ZwkQuLFfkvvXSZeYwVU4rFNEHaQqz4dVvcfTAwi1T 9AK8S/7FjRoh/aqbUe9rVsUAOUcoOAkgCd2bUkcYLQ8FXJqJPYA= =t0qu -----END PGP SIGNATURE-----

2 1

B.C. Permanent Daylight Savings
by Matthew Lee April 6, 2026

April 6, 2026

Hello, will this database be updating for B.C. switching permanently to Daylight Savings Time? Thank you.

3 3

Fwd: [PATCH] zic: avoid integer truncation in stringoffset bounds check
by Naveed Khan April 1, 2026

April 1, 2026

---------- Forwarded message --------- From: <dxbnaveed.k(a)gmail.com> Date: Wed, Mar 18, 2026 at 2:13 AM Subject: [PATCH] zic: avoid integer truncation in stringoffset bounds check To: <tz(a)iana.org> Cc: rootvector2 <dxbnaveed.k(a)gmail.com> From: rootvector2 <dxbnaveed.k(a)gmail.com> --- zic.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index c0891001..64090fce 100644 --- a/zic.c +++ b/zic.c @@ -3171,6 +3171,7 @@ stringoffset(char *result, zic_t offset) register int hours; register int minutes; register int seconds; + zic_t zhours; bool negative = offset < 0; int len = negative; @@ -3182,11 +3183,12 @@ stringoffset(char *result, zic_t offset) offset /= SECSPERMIN; minutes = offset % MINSPERHOUR; offset /= MINSPERHOUR; - hours = offset; - if (hours >= HOURSPERDAY * DAYSPERWEEK) { + zhours = offset; + if (zhours >= HOURSPERDAY * DAYSPERWEEK) { result[0] = '\0'; return 0; } + hours = zhours; len += sprintf(result + len, "%d", hours); if (minutes != 0 || seconds != 0) { len += sprintf(result + len, ":%02d", minutes); -- 2.52.0

2 1

[PROPOSED] zic now checks for signals more often
by Paul Eggert March 17, 2026

March 17, 2026

* NEWS: Mention this. * zic.c (verror, make_links, main, get_rand_u64) (random_dirent, open_outfile, dolink, inputline, infile): Be better about checking for signals, e.g., when the input or the random number generator is giving is trouble, so that it’s easier for the user to control-C out. Although the result is not perfect it should be good enough for practical use. --- NEWS | 2 ++ zic.c | 35 ++++++++++++++++++++++------------- 2 files changed, 24 insertions(+), 13 deletions(-) diff --git a/NEWS b/NEWS index d4ba011b..fa791cb9 100644 --- a/NEWS +++ b/NEWS @@ -28,6 +28,8 @@ Unreleased, experimental changes which can occur with adversarial input. (Thanks to GitHub user rootvector2.) + zic now checks for signals more often. + Release 2026a - 2026-03-01 22:59:49 -0800 diff --git a/zic.c b/zic.c index 77396228..c0891001 100644 --- a/zic.c +++ b/zic.c @@ -253,6 +253,7 @@ symlink(char const *target, char const *linkname) (errno = ENOTSUP, -1) #endif +static void check_for_signal(void); 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); @@ -704,6 +705,7 @@ eat(int fnum, lineno num) ATTRIBUTE_FORMAT((printf, 1, 0)) static void verror(const char *const string, va_list args) { + check_for_signal(); /* ** Match the format of "cc" to allow sh users to ** zic ... 2>&1 | error -t "*" -v @@ -1074,6 +1076,7 @@ make_links(void) warning(_("link %s targeting link %s"), links[i].l_linkname, links[i].l_target); } + check_for_signal(); } } @@ -1391,6 +1394,7 @@ main(int argc, char **argv) for (j = i + 1; j < nzones && zones[j].z_name == NULL; ++j) continue; outzone(&zones[i], j - i); + check_for_signal(); } make_links(); if (lcltime != NULL) { @@ -1486,9 +1490,11 @@ get_rand_u64(void) static int nwords; if (!nwords) { ssize_t s; - do + for (;; check_for_signal()) { s = getrandom(entropy_buffer, sizeof entropy_buffer, 0); - while (s < 0 && errno == EINTR); + if (! (s < 0 && errno == EINTR)) + break; + } nwords = s < 0 ? -1 : s / sizeof *entropy_buffer; } @@ -1516,7 +1522,7 @@ get_rand_u64(void) rmod = INT_MAX < UINT_FAST64_MAX ? 0 : UINT_FAST64_MAX / nrand + 1, r = 0, rmax = 0; - do { + for (;; check_for_signal()) { uint_fast64_t rmax1 = rmax; if (rmod) { /* Avoid signed integer overflow on theoretical platforms @@ -1527,7 +1533,9 @@ get_rand_u64(void) rmax1 = nrand * rmax1 + rand_max; r = nrand * r + rand(); rmax = rmax < rmax1 ? rmax1 : UINT_FAST64_MAX; - } while (rmax < UINT_FAST64_MAX); + if (UINT_FAST64_MAX <= rmax) + break; + } return r; } @@ -1574,9 +1582,11 @@ random_dirent(char const **name, char **namealloc) *name = *namealloc = dst; } - do + for (;; check_for_signal()) { r = get_rand_u64(); - while (unfair_min <= r); + if (r < unfair_min) + break; + } for (i = 0; i < suffixlen; i++) { dst[dirlen + prefixlen + i] = alphabet[r % alphabetlen]; @@ -1611,7 +1621,7 @@ open_outfile(char const **outname, char **tempname) if (!*tempname) random_dirent(outname, tempname); - while (true) { + for (;; check_for_signal()) { int oflags = O_WRONLY | O_BINARY | O_CREAT | O_EXCL; int fd = open(*outname, oflags, creat_perms); int err; @@ -1725,8 +1735,6 @@ dolink(char const *target, char const *linkname, bool staysymlink) char const *outname = linkname; int targetissym = -2, linknameissym = -2; - check_for_signal(); - if (strcmp(target, "-") == 0) { if (remove(linkname) == 0 || errno == ENOENT || errno == ENOTDIR) return; @@ -1739,7 +1747,7 @@ dolink(char const *target, char const *linkname, bool staysymlink) } } - while (true) { + for (;; check_for_signal()) { if (linkat(AT_FDCWD, target, AT_FDCWD, outname, AT_SYMLINK_FOLLOW) == 0) { link_errno = 0; @@ -1791,7 +1799,7 @@ dolink(char const *target, char const *linkname, bool staysymlink) int symlink_errno = -1; if (contents) { - while (true) { + for (;; check_for_signal()) { if (symlink(contents, outname) == 0) { symlink_errno = 0; break; @@ -1822,7 +1830,7 @@ dolink(char const *target, char const *linkname, bool staysymlink) exit(EXIT_FAILURE); } tp = open_outfile(&outname, &tempname); - while ((c = getc(fp)) != EOF) + for (; (c = getc(fp)) != EOF; check_for_signal()) putc(c, tp); close_file(tp, directory, linkname, tempname); close_file(fp, directory, target, NULL); @@ -1946,7 +1954,7 @@ static bool inputline(FILE *fp, char *buf, ptrdiff_t bufsize) { ptrdiff_t linelen = 0, ch; - while ((ch = getc(fp)) != '\n') { + for (; (ch = getc(fp)) != '\n'; check_for_signal()) { if (ch < 0) { if (ferror(fp)) { error(_("input error")); @@ -2033,6 +2041,7 @@ infile(int fnum, char const *name) default: unreachable(); } } + check_for_signal(); } close_file(fp, NULL, filename(fnum), NULL); if (wantcont) -- 2.51.0

1 0

[PROPOSED] Fix zic buffer overflow when computing TZ
by Paul Eggert March 17, 2026

March 17, 2026

Problem reported by GitHub user rootvector2. * NEWS: Mention this. * zic.c (outzone): Increase envvar len max. --- NEWS | 5 +++++ zic.c | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 905a086d..d4ba011b 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,11 @@ Unreleased, experimental changes 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 GitHub + user rootvector2.) + Release 2026a - 2026-03-01 22:59:49 -0800 diff --git a/zic.c b/zic.c index 225ad419..77396228 100644 --- a/zic.c +++ b/zic.c @@ -3416,12 +3416,16 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) int nonTZlimtype = -1; zic_t max_year0; int defaulttype = -1; + int max_stringoffset_len = sizeof "-167:59:59" - 1; + int max_comma_stringrule_len = (sizeof ",M12.5.6/" - 1 + + max_stringoffset_len); check_for_signal(); /* This cannot overflow; see FORMAT_LEN_GROWTH_BOUND. */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; - max_envvar_len = 2 * max_abbr_len + 5 * 9; + max_envvar_len = 2 * (max_abbr_len + max_stringoffset_len + + max_comma_stringrule_len); startbuf = xmalloc(max_abbr_len + 1); ab = xmalloc(max_abbr_len + 1); -- 2.51.0

1 0

Request to delay America/Vancouver tm_isdst transition until November
by Robert Bastian March 11, 2026

March 11, 2026

The change in 8b46071 <https://github.com/eggert/tz/commit/8b46071fd85a7a9434d63894bac64d30362cc16d> sets America/Vancouver's tm_isdst flag to false starting this Monday. Because CLDR keys its display names by this flag, this change will cause ICU and other downstream software (including major operating systems) to display BC’s UTC-7 as "Pacific Standard Time," while Los Angeles’ UTC-7 will display as "Pacific Daylight Time." The CLDR and ICU Technical Committees have evaluated several immediate paths forward, including new display names or a generic "UTC-7" (both of which are not sensitive to the tm_isdst value). However, due to the tight timeline (CLDR releases don't propagate as quickly as TZDB releases), and the uncertainty around the name that will actually be used in the real world, we have determined that continuing to use "Pacific Daylight Time" through this summer is the least confusing solution for users, as it maintains alignment across the Pacific Time corridor until BC actually diverges in November. To support this, we ask that the change to the tm_isdst flag be delayed until November, at least in the rearguard version of the TZDB. This will give us time to determine the name that people will be using, remodel CLDR's data, acquire translations, and ship a release to devices. Best regards, Robert *(On behalf of the CLDR/ICU Technical Committees)*

12 40

Add Asia/Novosibirsk as a separate timezone entry
by Tomon_1 March 10, 2026

March 10, 2026

Hello, I would like to propose adding *Asia/Novosibirsk* as a separate canonical entry in the tz database, currently it is grouped under *Asia/Krasnoyarsk* (UTC+7). Novosibirsk is the third largest city in Russia with a population of 1.6 million people. While both cities currently share UTC+7, Novosibirsk has a distinct historical timeline. It was on UTC+6 (MSK+3) from 1993 to 2016, while Krasnoyarsk remained on UTC+7 during that period. This means their clocks disagreed for over 20 years. Having a separate Asia/Novosibirsk entry would better represent the Novosibirsk region's identity and its distinct timezone history, and would benefit millions of users in the region who currently see "Krasnoyarsk" displayed as their timezone. Thank you for considering this proposal.

2 1

British Columbia
by Arthur Olson March 9, 2026

March 9, 2026

B. C. Gov News: "Adopting permanent daylight saving time: ‘Spring forward’ on March 8 will be the last time change, ending twice-yearly clock changes." https://news.gov.bc.ca/releases/2026AG0013-000209 @dashdashado

15 32

Summer time transitions in Moldova
by Heitor David Pinto March 9, 2026

March 9, 2026

Soviet Moldovan resolution 132 of 1990 defined the summer time period from the last Sunday in March at 2:00 to the last Sunday in September at 3:00, matching the dates used in most of Europe at the time: https://web.archive.org/web/20211107050832/http://lex.justice.md/viewdoc.ph… It seems that in 1996 Moldova changed the end date to October like most of Europe, but kept the transitions at 2:00 and 3:00 rather than 1:00 UTC, which would have been locally 3:00 and 4:00. The TZ database currently shows Moldova with the transitions at 2:00 and 3:00 since 1997. The notices in the Moldovan government website and broadcaster showed the transitions at 2:00 and 3:00 until 2021: 2015 https://old.gov.md/en/node/7304 2016 https://old.gov.md/en/node/12587 2017 https://old.gov.md/en/node/20654 2017 https://old.gov.md/en/content/moldova-upholds-winter-time-night-28-29-octob… 2018 https://old.gov.md/en/content/moldova-switch-summer-time 2018 https://old.gov.md/en/content/cabinet-ministers-informs-about-switch-winter… 2019 https://old.gov.md/en/content/moldova-switch-summer-time-31-march 2019 https://old.gov.md/en/node/31122 2020 https://old.gov.md/en/node/32771 2020 https://old.gov.md/en/node/34497 2021 https://trm.md/ro/social/moldova-trece-in-aceasta-noapte-la-ora-de-vara 2021 https://trm.md/en/social/republica-moldova-trece-la-ora-de-iarna1 However, since 2022, the notices showed the transitions at 3:00 and 4:00, matching the EU rule at 1:00 UTC: 2022 https://trm.md/en/social/in-acest-weekend-republica-moldova-trece-la-ora-de… 2022 https://old.gov.md/en/content/moldova-switch-winter-time 2023 https://moldova1.md/p/6587/ora-de-vara-2023-cum-schimbam-acele-ceasornicelo… 2023 https://old.gov.md/en/node/46662 2024 https://moldova1.md/p/26535/republica-moldova-trece-la-ora-de-vara-in-acest… 2024 https://moldova1.md/p/37768/republica-moldova-trece-in-aceasta-noapte-la-or… 2025 https://moldova1.md/p/46349/republica-moldova-trece-la-ora-de-vara-pe-30-ma… 2025 https://moldova1.md/p/60469/republica-moldova-trece-la-ora-de-iarna-ceasuri… It seems that the changes to the end date and transition times were just done in practice without formally changing the resolution. In late 2025, the government said that the Soviet resolution was still in force, and proposed a new resolution to replace it and formally establish the EU rule: https://particip.gov.md/ro/document/stages/anunt-de-initiere-a-proiectului-… https://gov.md/sites/default/files/media/documents/sedinte-de-guvern/2026-0… It plans to approve the proposed resolution on 25 February 2026: https://gov.md/en/node/9683 However, based on the notices, it seems that in practice Moldova already uses the EU rule since 2022. This was also the year when Moldova applied to join the EU. Regards, David

7 8

An appearance in the New York Times
by Arthur Olson March 9, 2026

March 9, 2026

(Spoiler ahead) The (pay-walled) New York Times "Strands" puzzle for 2026-03-08 includes what folks on this list will recognize as a singular error. https://www.nytimes.com/games/strands @dashdashado

1 0

[PROPOSED] zic: keep needed last transition to new type
by Paul Eggert March 7, 2026

March 7, 2026

* NEWS: Mention this. * zic.c (outzone): Omit an incorrect use of ‘useuntil’. This fixes a bug in 2023-10-15’s “Fix zic bug with Palestine after 2075” (commit 35c116b7536a36c43eb7cd36bff71ad0c5ecf071), which caused zic to mess up if the last transition is to a new time type. This patch does not affect any TZif files generated by current tzdata. This artificial input illustrates the bug: Rule Canada 2007 max - Mar Sun>=8 2:00 1:00 D Rule Canada 2007 max - Nov Sun>=1 2:00 0 S Zone America/Vancouver -8:00 - PST 2026 Mar 9 -8:00 Canada P%sT 2026 Nov 1 02:00 -7:00 - MST Without the fix, zic generates a nonconforming TZif file that omits the last transition even though the trailing TZ string is "MST7". --- NEWS | 7 +++++++ zic.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 267e62da..d7bf5a3c 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,9 @@ News for the tz database Unreleased, experimental changes + Briefly: + British Columbia moves to permanent -07 on 2026-03-09. + Changes to future timestamps British Columbia's 2026-03-08 spring forward will be its last @@ -12,6 +15,10 @@ Unreleased, experimental changes a limitation in CLDR v48.1 (2026-01-08). 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. + Release 2026a - 2026-03-01 22:59:49 -0800 diff --git a/zic.c b/zic.c index c10be426..225ad419 100644 --- a/zic.c +++ b/zic.c @@ -3522,7 +3522,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) startttisut); if (usestart) { addtt(starttime, type); - if (useuntil && nonTZlimtime < starttime) { + if (nonTZlimtime < starttime) { nonTZlimtime = starttime; nonTZlimtype = type; } -- 2.51.0

1 0

[PATCH] Cite recent review of DST and sleep
by Paul Eggert March 6, 2026

March 6, 2026

* tz-link.html (Costs and benefits of time shifts): Also cite Romigi, Franco, Scoditti et al 2025. Clean up some other HTML and wording. --- tz-link.html | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/tz-link.html b/tz-link.html index f19f9aab..5f1989f0 100644 --- a/tz-link.html +++ b/tz-link.html @@ -289,7 +289,7 @@ community, and data distributors downstream. <p> If your government plans to change its time zone boundaries or daylight saving rules, please send email as described in -"<a href="#changes">Changes to the <code><abbr>tz</abbr></code> database</a>". +“<a href="#changes">Changes to the <code><abbr>tz</abbr></code> database</a>”. Do this well in advance, as this will lessen confusion and will coordinate updates to many cell phones, computers, and other devices around the world. @@ -966,11 +966,17 @@ subtropical regions consume more electricity because of <abbr>DST</abbr>.”</li <li>Neumann P, von Blanckenburg K. <a href="https://journals.sagepub.com/doi/full/10.1177/0961463X241310562">What time will it be? A comprehensive literature review on daylight saving time</a>. -<em>Time Soc</em>. 2025-01-21. +<em>Time Soc</em>. 2025;34(4):684–745. doi:<a href="https://doi.org/10.1177/0961463X241310562">10.1177/0961463X241310562</a>. -This reviews DST’s effects on electricity, health, crime, road safety, -and the economy, focusing on research since 2010, and concludes that -year-round standard time is preferable overall. +This reviews <abbr>DST</abbr>’s effects on electricity, health, crime, road +safety, and the economy, focusing on research since 2010, and concludes that +year-round standard time is preferable overall.</li> +<li>Romigi A, Franco V, Scoditti E <em>et al</em>. +The effects of daylight saving time and clock time transitions on sleep and +sleepiness: a systematic review. <em>Sleep Med Rev.</em> 2025;84:102161. doi:<a +href="https://doi.org/10.1016/j.smrv.2025.102161">10.1016/j.smrv.2025.102161</a>. +This reviews <abbr>DST</abbr> and <abbr>DST</abbr> transitions, +and concludes that they both harm sleep, health and behavior.</li> </ul> <p>The following medical societies have taken positions on the @@ -985,7 +991,7 @@ supporting permanent standard time</a> on health grounds.</li> British Sleep Society position statement on Daylight Saving Time in the UK</a>. <em>J Sleep Res.</em> 2025;34(3):e14352. doi:<a href="https://doi.org/10.1111/jsr.14352">10.1111/jsr.14352</a>. -This recommends that the UK abolish DST for health reasons.</li> +This recommends that the UK abolish <abbr>DST</abbr> for health reasons.</li> <li>Malow BA. <a href="https://academic.oup.com/sleep/article/45/12/zsac236/6717940">It is time to abolish the clock change and adopt permanent @@ -993,7 +999,7 @@ standard time in the United States: a Sleep Research Society position statement</a>. <em>Sleep.</em> 2022;45(12):zsac236. doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. -After reviewing the scientific literature, the Sleep Research Society +The Sleep Research Society advocates permanent standard time due to its health benefits.</li> <li>Rishi MA, Cheng JY, Strang AR <em>et al</em>. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time -- 2.51.0

9 16

Re: British Columbia
by Davis Carlson March 5, 2026

March 5, 2026

For those interested in the 2019 report that led to the tabling of this legislation, it can be found here: https://web.archive.org/web/20191103234633/https://engage.gov.bc.ca/app/upl… . Interesting that one of the primary tools used to guage public support for permanent DST was a survey run during the *summer *months (June - July 2019). I wonder how the responses might have changed had the survey been run a second time in the winter months. - Davis

4 4

British Columbia is moving permanently to DST on Sunday, March 8, 2026
by WorldTimeZone March 4, 2026

March 4, 2026

British Columbia, Canada is moving permanently to DST on Sunday, March 8, 2026Canadian province is permanently adopting the new clock, officials announced on Monday, ending the twice-a-year ritual of changing every device and clock you own.https://news.gov.bc.ca/releases/2026AG0013-000209https://www.facebook.c… Province of British Columbia is adopting permanent year-round daylight saving time (DST) to improve people’s overall health, reduce disruptions for families, simplify scheduling and provide an extra hour of evening light during the winter months.Alexander Krivenyshev WorldTimeZone.com https://www.worldtimezone.com/index24.php

1 0

British Columbia DST change
by Matt Johnson-Pint March 3, 2026

March 3, 2026

In the news this morning. I haven't yet searched for an official legal notice. https://www.bbc.com/news/articles/c4gq3k4590vo

1 2

Gravitational wave detectors affected by DST
by Paul Eggert March 2, 2026

March 2, 2026

An astronomy paper published in January ties daylight saving time to LIGO, the Laser Interferometer Gravitational-Wave Observatory, which detects cosmic gravitational waves. Here's a citation: Essick R. Can LIGO Detect Daylight Saving Time? ApJ. 2026;997:76. <https://doi.org/10.3847/1538-4357/ae2255>. The answer to the paper's title is "yes". Gravitational wave detectors, though designed to detect black holes merging billions of light years from here, can also distinguish Earth day from Earth night, weekends from weekdays, and even daylight saving from standard time. This is because their human operators and neighbors generate noise that significantly affects the detectors' sensitivity, and the noise itself can be analyzed to detect human-caused patterns like DST. This has consequences for the conclusions that can be drawn from LIGO surveys. For a readable summary of Essick's results, see: Tomaswick A. Gravitational wave detectors affected by daylight savings time. Universe Today. 2025-09-25. <https://phys.org/news/2025-09-gravitational-detectors-affected-daylight.html>.

2 1

[PROPOSED] The CIA World Factbook is no more
by Paul Eggert March 1, 2026

March 1, 2026

* tz-link.html: The CIA World Factbook sunsetted on 2026-02-04. Downgrade its citation accordingly. --- tz-link.html | 29 +++++++++++------------------ 1 file changed, 11 insertions(+), 18 deletions(-) diff --git a/tz-link.html b/tz-link.html index acc2df58..f19f9aab 100644 --- a/tz-link.html +++ b/tz-link.html @@ -742,31 +742,24 @@ gives current time zone rules for airports served by commercial aviation.</li> <section> <h2 id="maps">Maps</h2> <ul> -<li>The <a -href="https://www.cia.gov/the-world-factbook/maps/world-regional/">World -and Regional Maps section</a> of <em>The World Factbook</em>, published by the -<a href="https://www.cia.gov">US Central Intelligence -Agency (<abbr -title="Central Intelligence Agency">CIA</abbr>)</a>, contains a time -zone map; the -<a -href="https://maps.lib.utexas.edu/maps/world.html">Perry–Castañeda -Library Map Collection</a> -of the University of Texas at Austin has copies of -recent editions. -The pictorial quality is good, -but the maps do not indicate daylight saving time, -and parts of the data are a few years out of date.</li> <li><a href="https://www.worldtimezone.com">World Time Zone Map with current time</a> -has several fancy time zone maps; it covers Russia particularly well. -The maps’ pictorial quality is not quite as good as the <abbr>CIA</abbr>’s -but the maps are more up to date.</li> +has several fancy time zone maps; it covers Russia particularly well.</li> <li><a href="https://blog.poormansmath.net/how-much-is-time-wrong-around-the-world/">How much is time wrong around the world?</a> maps the difference between mean solar and standard time, highlighting areas such as western China where the two differ greatly. It’s a bit out of date, unfortunately.</li> +<li>The +<a +href="https://maps.lib.utexas.edu/maps/world.html">Perry–Castañeda +Library Map Collection</a> of the University of Texas at Austin has +copies of old maps taken from <a +href="https://en.wikipedia.org/wiki/The_World_Factbook"><em>The +World Factbook</em></a>, formerly published by the +<a href="https://www.cia.gov">US Central Intelligence Agency</a>. +Although the maps’ pictorial quality is good, +the maps do not indicate daylight saving time.</li> </ul> </section> -- 2.51.0

1 0

[PROPOSED] Pacify clang -Wunterminated-string-initialization
by Paul Eggert March 1, 2026

March 1, 2026

* private.h (ATTRIBUTE_NONSTRING): Also define for Clang 21+. --- private.h | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/private.h b/private.h index 6a58b073..ee191b4e 100644 --- a/private.h +++ b/private.h @@ -539,9 +539,12 @@ typedef unsigned long uintmax_t; # define HAVE___HAS_C_ATTRIBUTE false #endif -#if 8 <= __GNUC__ -# define ATTRIBUTE_NONSTRING __attribute__((__nonstring__)) -#else +#ifdef __has_attribute +# if __has_attribute (nonstring) +# define ATTRIBUTE_NONSTRING __attribute__((__nonstring__)) +# endif +#endif +#ifndef ATTRIBUTE_NONSTRING # define ATTRIBUTE_NONSTRING #endif -- 2.53.0

1 0

Request to Add Bukavu or Goma to the IANA Africa/ Time Zone Database
by Marcel Shabani Feb. 28, 2026

Feb. 28, 2026

Dear IANA Time Zone Database Team, My name is Marcel Shabani, a software developer from the Democratic Republic of the Congo (DRC). I am writing to kindly request consideration for the inclusion of Bukavu or Goma as distinct representative locations under the Africa/ region in the IANA Time Zone Database. Currently, many systems default to Africa/Lubumbashi for regions in the eastern DRC. But, cities like Bukavu<https://en.wikipedia.org/wiki/Bukavu> and Goma<https://en.wikipedia.org/wiki/Goma> are geographically distant from Lubumbashi and represent significantly different parts of the country. Having a more locally relevant TZ identifier (e.g., Africa/Bukavu or Africa/Goma) would greatly improve accuracy for residents, developers, and organizations operating in these regions. I understand that the TZ Database prioritizes representation rather than exhaustive listings, but adding one of these major cities would help ensure better alignment with real-world usage across eastern DRC. Thank you for your time, and I appreciate your continued work in maintaining this globally important resource. I am happy to provide any additional information if needed. Kind regards, Marcel Shabani -- Marcel Baguma Shabani Managing Director Tuunganes marcel.shabani(a)tuunganes.com | <https://teams.microsoft.com/l/chat/0/0?users=mshabani@ctrl-qs.com> Contact in Teams<https://teams.microsoft.com/l/chat/0/0?users=marcel.shabani@tuunganes.com> 006K, Avenue Pere Georges Defour Bukavu DRCongo https://tuunganes.com [cid:05ebfea4-d90b-40bb-b78f-ee12a0668f21]<https://outlook.office.com/bookwithme/user/c8100903c3844ae28a49622612817121…> Book time to <https://outlook.office.com/bookwithme/user/c8100903c3844ae28a49622612817121…> discuss | Prendre rendez-vous

6 6

Bill for "half-daylight time" proposed in US House
by Tim Parenti Feb. 26, 2026

Feb. 26, 2026

With the annual clock changes soon approaching, we are well-accustomed by now to discussion picking back up around the typical proposals for "permanent daylight time" and "permanent standard time". But an alternative proposal of "permanent half-daylight time" has now been put forth in the US House of Representatives. For example, "Eastern time would then be 4.5 hours behind UTC, instead of five." Republican representative Greg Steube, who represents the Sarasota area in southwest Florida's 17th district, introduced HR 7378 (the "Daylight Act of 2026") on 4 February 2026. The bill was referred to the House Committee on Energy and Commerce but, like most such proposals, has not yet moved forward. As presently drafted, the bill provides that the changes would take effect only 90 days after enactment. https://www.usatoday.com/story/news/nation/2026/02/19/daylight-act-of-2026-… https://www.congress.gov/bill/119th-congress/house-bill/7378/text https://www.congress.gov/119/bills/hr7378/BILLS-119hr7378ih.pdf -- Tim Parenti

9 12

daylight savings changes in Nunavimmiut?
by Antoine Beaupré Feb. 26, 2026

Feb. 26, 2026

Hi, I'm writing to enquire about this news article you wrote back in November: https://www.cbc.ca/news/canada/north/nunavik-daylight-savings-9.6969650 From what I gathered while reading the article, Nunavik would not change their clocks back to normal time in the fall, after this summer's daylight savings, staying permanently on "normal" time. This has significant implication in the software world: changes like this must be coordinated across different engineers. Specifically, the "Time Zone Database" (tzdb) needs to be updated to reflect those changes. Right now, the only information regarding this change is your news article, and it doesn't make it solidly clear that this is actually happening. I have actually tried calling Makivvik and, while people were busy with a meeting there, the secretary that answered didn't seem aware of the change. This makes me doubt the change will actually happen. Do you have more information about the upcoming change? Anyone we could contact to confirm this information first hand? See also: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/6HN5SWD2BJA7OVTPF… Thanks, a. -- Antoine Beaupré Debian Developer

5 6

[PROPOSED 1/2] Pacify GCC 15.2 -Wzero-as-null-pointer-constant
by Paul Eggert Feb. 24, 2026

Feb. 24, 2026

* localtime.c (time): Use NULL, not 0, for null pointer. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 32835d08..0091b81e 100644 --- a/localtime.c +++ b/localtime.c @@ -3135,7 +3135,7 @@ posix2time(time_t t) time_t time(time_t *p) { - time_t r = sys_time(0); + time_t r = sys_time(NULL); if (r != (time_t) -1) { iinntt offset = EPOCH_LOCAL ? timezone : 0; if (offset < IINNTT_MIN + EPOCH_OFFSET -- 2.51.0

1 1

Re: Bill for "half-daylight time" proposed in US House
by Doug Ewell Feb. 20, 2026

Feb. 20, 2026

World Time Zone wrote: > Maybe we should leave clocks and time zones alone and just shift work, > school, and service times by 30 minutes? If every business, school, and service entity shifted its times uniformly, then this would work, and would be effectively equivalent to having the government set the time as we do now. Anything short of complete uniformity would blow the plan. From the mid-1950s to the mid-1980s, there was a tourist attraction in Buena Park called California Alligator Farm. One of their business cards showed that their hours of operation were 11 am to 5 pm during standard time, and noon to 6 pm during DST. Alligators don’t change their circadian rhythms when humans change their clocks. A tourist attraction can get away with this, in a way that schools and workplaces and businesses and daycare centers and everyone else whose schedules depend on each other cannot. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

1 0

Re: Downloads from data.iana.org now seem to be sensitive to the User-Agent value supplied in HTTP request headers
by James Mitchell Feb. 4, 2026

Feb. 4, 2026

Hi Johny, I’m sorry you are having issues downloading the tz data. There should have been no changes to access restrictions via user agent or other attributes. I’ll investigate this and get back to you. Thanks, James Mitchell IANA From: Johny Jose via tz <tz(a)iana.org> Reply-To: Johny Jose <johny.jose(a)oracle.com> Date: Tuesday, February 3, 2026 at 4:20 PM To: "tz(a)iana.org" <tz(a)iana.org> Subject: [tz] Downloads from data.iana.org now seem to be sensitive to the User-Agent value supplied in HTTP request headers Hi, I am reaching out regarding an issue encountered while attempting to download the latest tzdata release (tzdata2025c.tar.gz) from https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz using Java JDK 8’s HTTP request API. We use the tzupdater tool (https://www.oracle.com/java/technologies/javase/tzupdater-readme.html [oracle.com]<https://urldefense.com/v3/__https:/www.oracle.com/java/technologies/javase/…>) to update the jdk to latest tzdata. Since Monday, January 26, 2026, we have been facing issues while downloading tzdata2025c.tar.gz. We are receiving an HTTP 403 error response from the server. This appears to be due to a validation failure related to the HTTP header User-Agent (specifically, User-Agent: Java/1.8.0_471). User-Agent values from JDK 11 and later (e.g. User-Agent: Java/11.0.16) do not trigger this issue. Could you kindly advise on the following: Has there been a specific format restriction enabled for the User-Agent value string to grant access? If so, is it possible to whitelist widely used Java-based User-Agent strings? Error Logs: sun.net.www.protocol.http.HttpURLConnection sendCONNECTRequest FINE: sun.net.www.MessageHeader@2f1129655<mailto:sun.net.www.MessageHeader@2f1129655> pairs: {CONNECT data.iana.org:443 HTTP/1.1: null}{User-Agent: Java/1.8.0_471}{Host: data.iana.org}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Proxy-Connection: keep-alive} Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection doTunneling FINE: sun.net.www.MessageHeader@d4342c21<mailto:sun.net.www.MessageHeader@d4342c21> pairs: {null: HTTP/1.0 200 Connection Established} Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection writeRequests FINE: sun.net.www.MessageHeader@770d33265<mailto:sun.net.www.MessageHeader@770d33265> pairs: {GET /time-zones/releases/tzdata2025c.tar.gz HTTP/1.1: null}{User-Agent: Java/1.8.0_471}{Host: data.iana.org}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive} Jan 30, 2026 8:07:24 AM sun.net.www.http.HttpClient logFinest FINEST: KeepAlive stream used: https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection getInputStream0 FINE: sun.net.www.MessageHeader@d4342c211<mailto:sun.net.www.MessageHeader@d4342c211> pairs: {null: HTTP/1.1 403 Forbidden}{Date: Fri, 30 Jan 2026 08:07:24 GMT}{Content-Type: text/plain; charset=UTF-8}{Content-Length: 16}{Connection: keep-alive}{Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0}{Expires: Thu, 01 Jan 1970 00:00:01 GMT}{Referrer-Policy: same-origin}{X-Frame-Options: SAMEORIGIN}{Server: cloudflare} java.io.IOException: Server returned HTTP response code: 403 for URL: https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz I tried to create a new thread in tz - lists.iana.org<https://lists.iana.org/hyperkitty/list/tz@iana.org/> but could not succeed in it. Thank you for your assistance. Let me know if you would like any further information. Thanks, Johny Confidential- Oracle Internal

2 2

Downloads from data.iana.org now seem to be sensitive to the User-Agent value supplied in HTTP request headers
by Johny Jose Feb. 3, 2026

Feb. 3, 2026

Hi, I am reaching out regarding an issue encountered while attempting to download the latest tzdata release (tzdata2025c.tar.gz) from https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz using Java JDK 8's HTTP request API. We use the tzupdater tool (https://www.oracle.com/java/technologies/javase/tzupdater-readme.html) to update the jdk to latest tzdata. Since Monday, January 26, 2026, we have been facing issues while downloading tzdata2025c.tar.gz. We are receiving an HTTP 403 error response from the server. This appears to be due to a validation failure related to the HTTP header User-Agent (specifically, User-Agent: Java/1.8.0_471). User-Agent values from JDK 11 and later (e.g. User-Agent: Java/11.0.16) do not trigger this issue. Could you kindly advise on the following: Has there been a specific format restriction enabled for the User-Agent value string to grant access? If so, is it possible to whitelist widely used Java-based User-Agent strings? Error Logs: sun.net.www.protocol.http.HttpURLConnection sendCONNECTRequest FINE: sun.net.www.MessageHeader@2f1129655<mailto:sun.net.www.MessageHeader@2f1129655> pairs: {CONNECT data.iana.org:443 HTTP/1.1: null}{User-Agent: Java/1.8.0_471}{Host: data.iana.org}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Proxy-Connection: keep-alive} Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection doTunneling FINE: sun.net.www.MessageHeader@d4342c21<mailto:sun.net.www.MessageHeader@d4342c21> pairs: {null: HTTP/1.0 200 Connection Established} Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection writeRequests FINE: sun.net.www.MessageHeader@770d33265<mailto:sun.net.www.MessageHeader@770d33265> pairs: {GET /time-zones/releases/tzdata2025c.tar.gz HTTP/1.1: null}{User-Agent: Java/1.8.0_471}{Host: data.iana.org}{Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2}{Connection: keep-alive} Jan 30, 2026 8:07:24 AM sun.net.www.http.HttpClient logFinest FINEST: KeepAlive stream used: https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz Jan 30, 2026 8:07:24 AM sun.net.www.protocol.http.HttpURLConnection getInputStream0 FINE: sun.net.www.MessageHeader@d4342c211<mailto:sun.net.www.MessageHeader@d4342c211> pairs: {null: HTTP/1.1 403 Forbidden}{Date: Fri, 30 Jan 2026 08:07:24 GMT}{Content-Type: text/plain; charset=UTF-8}{Content-Length: 16}{Connection: keep-alive}{Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0}{Expires: Thu, 01 Jan 1970 00:00:01 GMT}{Referrer-Policy: same-origin}{X-Frame-Options: SAMEORIGIN}{Server: cloudflare} java.io.IOException: Server returned HTTP response code: 403 for URL: https://data.iana.org/time-zones/releases/tzdata2025c.tar.gz I tried to create a new thread in tz - lists.iana.org<https://lists.iana.org/hyperkitty/list/tz@iana.org/> but could not succeed in it. Thank you for your assistance. Let me know if you would like any further information. Thanks, Johny Confidential- Oracle Internal

1 0

[PROPOSED 1/2] zic now a bit safer for overflows near 2**63
by Paul Eggert Feb. 2, 2026

Feb. 2, 2026

Simplify some overflow-checking code dating back to when zic used 32-bit arithmetic internally. Back then, the code had special cases to handle timestamps near the year 2038 that worked for tzdata but did not work in general. Nowadays zic uses 64-bit arithmetic internally, so those special cases are no longer needed and complicate maintenance. Instead, simply report overflow and exit when outlandish input causes computation to go outside the 64-bit range, even if merely temporarily. * zic.c (gethms, getleapdatetime, rpytime): Use omul instead of checking by hand for overflow in multiplication. (inzsub, outzone, rpytime): Do not use z_untiltime == min_time to represent "minus infinity", or z_untiltime == max_time to represent "positive infinity", as this didn’t work in general. min_time and max_time now just represent themselves. (getleapdatetime): If timestamp calculations overflow, exit immediately rather than plowing ahead with -1. (omul): New function. (tadd): Remove halfhearted attempt at saturated addition. Instead, simply use oadd and check that the result is in range. --- NEWS | 2 +- zic.c | 64 +++++++++++++++++++++++++---------------------------------- 2 files changed, 28 insertions(+), 38 deletions(-) diff --git a/NEWS b/NEWS index e801faf1..b9df804a 100644 --- a/NEWS +++ b/NEWS @@ -62,7 +62,7 @@ Unreleased, experimental changes Some other undefined behavior, triggered by TZif files containing outlandish but conforming UT offsets or leap second corrections, - has also been fixed. (Also reported by Naveed8951.) + has also been fixed. (Some of these bugs reported by Naveed8951.) localtime.c no longer rejects TZif files that exactly fit in its internal structures, fixing off-by-one typos introduced in 2014g. diff --git a/zic.c b/zic.c index 87450745..cf449a55 100644 --- a/zic.c +++ b/zic.c @@ -276,6 +276,7 @@ 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); static zic_t rpytime(const struct rule * rp, zic_t wantedy); static bool rulesub(struct rule * rp, @@ -2088,15 +2089,11 @@ gethms(char const *string, char const *errstring) error("%s", errstring); return 0; } - if (ZIC_MAX / SECSPERHOUR < hh) { - error(_("time overflow")); - return 0; - } ss += 5 + ((ss ^ 1) & (xr == '0')) <= tenths; /* Round to even. */ if (noise && (hh > HOURSPERDAY || (hh == HOURSPERDAY && (mm != 0 || ss != 0)))) warning(_("values over 24 hours not handled by pre-2007 versions of zic")); - return oadd(sign * hh * SECSPERHOUR, + return oadd(omul(hh, sign * SECSPERHOUR), sign * (mm * SECSPERMIN + ss)); } @@ -2256,10 +2253,6 @@ inzsub(char **fields, int nfields, bool iscont) z.z_untiltime = rpytime(&z.z_untilrule, z.z_untilrule.r_loyear); if (iscont && nzones > 0 && - z.z_untiltime > min_time && - z.z_untiltime < max_time && - zones[nzones - 1].z_untiltime > min_time && - zones[nzones - 1].z_untiltime < max_time && zones[nzones - 1].z_untiltime >= z.z_untiltime) { error(_("Zone continuation line end time is" " not after end time of previous line")); @@ -2341,15 +2334,7 @@ getleapdatetime(char **fields, bool expire_line) return -1; } dayoff = oadd(dayoff, day - 1); - if (dayoff < min_time / SECSPERDAY) { - error(_("time too small")); - return -1; - } - if (dayoff > max_time / SECSPERDAY) { - error(_("time too large")); - return -1; - } - t = dayoff * SECSPERDAY; + t = omul(dayoff, SECSPERDAY); tod = gethms(fields[LP_TIME], _("invalid time of day")); t = tadd(t, tod); if (t < 0) @@ -3599,9 +3584,6 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (!r->r_todisstd) offset = oadd(offset, save); jtime = r->r_temp; - if (jtime == min_time || - jtime == max_time) - continue; jtime = tadd(jtime, -offset); if (k < 0 || jtime < ktime) { k = j; @@ -4056,6 +4038,7 @@ time_overflow(void) exit(EXIT_FAILURE); } +/* Return T1 + T2, but diagnose any overflow and exit. */ ATTRIBUTE_PURE_114833_HACK static zic_t oadd(zic_t t1, zic_t t2) @@ -4071,26 +4054,41 @@ oadd(zic_t t1, zic_t t2) time_overflow(); } +/* Return T1 + T2, but diagnose any overflow and exit. + This is like oadd, except the result must fit in min_time..max_time range, + which on oddball machines can be a smaller range than ZIC_MIN..ZIC_MAX. */ ATTRIBUTE_PURE_114833_HACK static zic_t tadd(zic_t t1, zic_t t2) { -#ifdef ckd_add - zic_t sum; - if (!ckd_add(&sum, t1, t2) && min_time <= sum && sum <= max_time) + zic_t sum = oadd(t1, t2); + if (min_time <= sum && sum <= max_time) return sum; + time_overflow(); +} + +/* Return T1 * T2, but diagnose any overflow and exit. */ +ATTRIBUTE_PURE_114833_HACK +static zic_t +omul(zic_t t1, zic_t t2) +{ +#ifdef ckd_mul + zic_t product; + if (!ckd_mul(&product, t1, t2)) + return product; #else - if (t1 < 0 ? min_time - t1 <= t2 : t2 <= max_time - t1) - return t1 + t2; + if (t2 < 0 + ? ZIC_MAX / t2 <= t1 && (t2 == -1 || t1 <= ZIC_MIN / t2) + : t2 == 0 || (ZIC_MIN / t2 <= t1 && t1 <= ZIC_MAX / t2)) + return t1 * t2; #endif - if (t1 == min_time || t1 == max_time) - return t1; time_overflow(); } /* ** Given a rule, and a year, compute the date (in seconds since January 1, ** 1970, 00:00 LOCAL time) in that year that the rule refers to. +** Do not count leap seconds. On error, diagnose and exit. */ static zic_t @@ -4101,10 +4099,6 @@ rpytime(const struct rule *rp, zic_t wantedy) register zic_t t, y; int yrem; - if (wantedy == ZIC_MIN) - return min_time; - if (wantedy == ZIC_MAX) - return max_time; m = TM_JANUARY; y = EPOCH_YEAR; @@ -4162,11 +4156,7 @@ rpytime(const struct rule *rp, zic_t wantedy) will not work with pre-2004 versions of zic")); } } - if (dayoff < min_time / SECSPERDAY) - return min_time; - if (dayoff > max_time / SECSPERDAY) - return max_time; - t = (zic_t) dayoff * SECSPERDAY; + t = omul(dayoff, SECSPERDAY); return tadd(t, rp->r_tod); } -- 2.51.0

1 1

[PROPOSED] zic now allows more than 50 leap seconds
by Paul Eggert Jan. 25, 2026

Jan. 25, 2026

Although there have been only 27 leap seconds so far and possibly there will be no more, some TZif readers (e.g., glibc) do not have the limit of 50 leap seconds hardwired into tzcode localtime.c. Improve zic so that it can generate TZif files with more than 50 leap seconds to test these readers, just in case. * NEWS, tzfile.h: Mention this. * zic.c (leapcnt, strict timerange.leapbase) (struct timerange.leapcount): Now ptrdiff_t, not int. All uses changed. (leap_alloc): New static var. (trans, corr, roll): Remove these static vars, which have an arbitrary limit on the number of leap seconds, and replace them with ... (leap): ... this new static var. All uses changed. (writezone): If -v, warn if the leap second count exceeds the tzcode runtime limit. (leapadd): Grow leap second table dynamically if needed, instead of failing and exiting when a fixed-size table is too small. --- NEWS | 8 ++++++ tzfile.h | 6 ++-- zic.c | 85 +++++++++++++++++++++++++++++--------------------------- 3 files changed, 56 insertions(+), 43 deletions(-) diff --git a/NEWS b/NEWS index dd592871..e801faf1 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,7 @@ Unreleased, experimental changes The "right" TZif files are no longer installed by default. -DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds. TZif files are no longer limited to 50 bytes of abbreviations. + zic is no longer limited to 50 leap seconds. Several integer overflow bugs have been fixed. Changes to build procedure @@ -36,6 +37,13 @@ Unreleased, experimental changes already consuming 40 bytes. zic -v warns if it generates a file that exceeds the old 50-byte limit. + zic -L can now generate TZif files with more than 50 leap seconds. + This helps test TZif readers not limited to 50 leap seconds, as + tzcode's localtime.c is; it has little immediate need for + practical timekeeping as there have been only 27 leap seconds and + possibly there will be no more, due to planned changes to UTC. + zic -v warns if its output exceeds the old 50-second limit. + localtime.c no longer accesses the posixrules file generated by zic -p. Hence for obsolete and nonconforming settings like TZ="AST4ADT" it now typically falls back on US DST rules, rather diff --git a/tzfile.h b/tzfile.h index 1b1bac4a..1941bc3b 100644 --- a/tzfile.h +++ b/tzfile.h @@ -89,7 +89,8 @@ struct tzhead { */ #ifndef TZ_MAX_TIMES -/* This must be at least 310 for Asia/Hebron with 'zic -b fat'. */ +/* The following limit applies to localtime.c; zic has no such limit. + The limit must be at least 310 for Asia/Hebron with 'zic -b fat'. */ # define TZ_MAX_TIMES 2000 #endif /* !defined TZ_MAX_TIMES */ @@ -105,7 +106,8 @@ struct tzhead { #endif /* !defined TZ_MAX_CHARS */ #ifndef TZ_MAX_LEAPS -/* This must be at least 27 for leap seconds from 1972 through mid-2023. +/* The following limit applies to localtime.c; zic has no such limit. + The limit must be at least 27 for leap seconds from 1972 through mid-2023. There's a plan to discontinue leap seconds by 2035. */ # define TZ_MAX_LEAPS 50 /* Maximum number of leap second corrections */ #endif /* !defined TZ_MAX_LEAPS */ diff --git a/zic.c b/zic.c index 1a2f4741..87450745 100644 --- a/zic.c +++ b/zic.c @@ -298,7 +298,8 @@ static int charcnt; static bool errors; static bool warnings; static int filenum; -static int leapcnt; +static ptrdiff_t leapcnt; +static ptrdiff_t leap_alloc; static bool leapseen; static zic_t leapminyear; static zic_t leapmaxyear; @@ -539,9 +540,11 @@ static unsigned char desigidx[TZ_MAX_TYPES]; static bool ttisstds[TZ_MAX_TYPES]; static bool ttisuts[TZ_MAX_TYPES]; static char chars[TZ_MAX_CHARS]; -static zic_t trans[TZ_MAX_LEAPS]; -static zic_t corr[TZ_MAX_LEAPS]; -static char roll[TZ_MAX_LEAPS]; +static struct { + zic_t trans; + zic_t corr; + char roll; +} *leap; /* ** Memory allocation. @@ -2606,7 +2609,7 @@ atcomp(const void *avp, const void *bvp) struct timerange { int defaulttype; ptrdiff_t base, count; - int leapbase, leapcount; + ptrdiff_t leapbase, leapcount; bool leapexpiry; }; @@ -2626,13 +2629,13 @@ limitrange(struct timerange r, zic_t lo, zic_t hi, positive leap second if and only if it has a positive correction. This supports common TZif readers that assume that the first leap second is positive if and only if its correction is positive. */ - while (1 < r.leapcount && trans[r.leapbase + 1] <= lo) { + while (1 < r.leapcount && leap[r.leapbase + 1].trans <= lo) { r.leapcount--; r.leapbase++; } while (0 < r.leapbase - && ((corr[r.leapbase - 1] < corr[r.leapbase]) - != (0 < corr[r.leapbase]))) { + && ((leap[r.leapbase - 1].corr < leap[r.leapbase].corr) + != (0 < leap[r.leapbase].corr))) { r.leapcount++; r.leapbase--; } @@ -2642,7 +2645,7 @@ limitrange(struct timerange r, zic_t lo, zic_t hi, if (hi < max_time) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; - while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) + while (0 < r.leapcount && hi + 1 < leap[r.leapbase + r.leapcount - 1].trans) r.leapcount--; } @@ -2713,14 +2716,19 @@ writezone(const char *const name, const char *const string, char version, timecnt = toi; } - if (noise && timecnt > 1200) { - if (timecnt > TZ_MAX_TIMES) + if (noise) { + if (1200 < timecnt) { + if (TZ_MAX_TIMES < timecnt) warning(_("reference clients mishandle" " more than %d transition times"), TZ_MAX_TIMES); - else + else warning(_("pre-2014 clients may mishandle" " more than 1200 transition times")); + } + if (TZ_MAX_LEAPS < leapcnt) + warning(_("reference clients mishandle more than %d leap seconds"), + TZ_MAX_LEAPS); } /* ** Transfer. @@ -2736,8 +2744,8 @@ writezone(const char *const name, const char *const string, char version, for (i = 0; i < timecnt; ++i) { j = leapcnt; while (--j >= 0) - if (ats[i] > trans[j] - corr[j]) { - ats[i] = tadd(ats[i], corr[j]); + if (leap[j].trans - leap[j].corr < ats[i]) { + ats[i] = tadd(ats[i], leap[j].corr); break; } } @@ -2766,7 +2774,7 @@ writezone(const char *const name, const char *const string, char version, version = '4'; } if (0 < r->leapcount - && corr[r->leapbase] != 1 && corr[r->leapbase] != -1) { + && leap[r->leapbase].corr != 1 && leap[r->leapbase].corr != -1) { if (noise) warning(_("%s: pre-2021b clients may mishandle" " leap second table truncation"), @@ -2781,7 +2789,7 @@ writezone(const char *const name, const char *const string, char version, for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; - register int thisleapi, thisleapcnt, thisleaplim; + register ptrdiff_t thisleapi, thisleapcnt, thisleaplim; struct tzhead tzh; int pretranstype = -1, thisdefaulttype; bool locut, hicut, thisleapexpiry; @@ -3026,8 +3034,8 @@ writezone(const char *const name, const char *const string, char version, for (i = thisleapi; i < thisleaplim; ++i) { register zic_t todo; - if (roll[i]) { - if (timecnt == 0 || trans[i] < ats[0]) { + if (leap[i].roll) { + if (timecnt == 0 || leap[i].trans < ats[0]) { j = 0; while (isdsts[j]) if (++j >= typecnt) { @@ -3037,14 +3045,14 @@ writezone(const char *const name, const char *const string, char version, } else { j = 1; while (j < timecnt && - trans[i] >= ats[j]) + ats[j] <= leap[i].trans) ++j; j = types[j - 1]; } - todo = tadd(trans[i], -utoffs[j]); - } else todo = trans[i]; + todo = tadd(leap[i].trans, -utoffs[j]); + } else todo = leap[i].trans; puttzcodepass(todo, fp, pass); - puttzcode(corr[i], fp); + puttzcode(leap[i].corr, fp); } if (thisleapexpiry) { /* Append a no-op leap correction indicating when the leap @@ -3053,7 +3061,7 @@ writezone(const char *const name, const char *const string, char version, the plan is to amend the RFC to allow this in version 4 TZif files. */ puttzcodepass(leapexpires, fp, pass); - puttzcode(thisleaplim ? corr[thisleaplim - 1] : 0, fp); + puttzcode(thisleaplim ? leap[thisleaplim - 1].corr : 0, fp); } if (stdcnt != 0) for (i = old0; i < typecnt; i++) @@ -3813,32 +3821,27 @@ addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut) static void leapadd(zic_t t, int correction, int rolling) { - register int i; + register ptrdiff_t i; - if (TZ_MAX_LEAPS <= leapcnt) { - error(_("too many leap seconds")); - exit(EXIT_FAILURE); - } if (rolling && (lo_time != min_time || hi_time != max_time)) { error(_("Rolling leap seconds not supported with -r")); exit(EXIT_FAILURE); } + leap = growalloc(leap, sizeof *leap, leapcnt, &leap_alloc); for (i = 0; i < leapcnt; ++i) - if (t <= trans[i]) + if (t <= leap[i].trans) break; - memmove(&trans[i + 1], &trans[i], (leapcnt - i) * sizeof *trans); - memmove(&corr[i + 1], &corr[i], (leapcnt - i) * sizeof *corr); - memmove(&roll[i + 1], &roll[i], (leapcnt - i) * sizeof *roll); - trans[i] = t; - corr[i] = correction; - roll[i] = rolling; + memmove(&leap[i + 1], &leap[i], (leapcnt - i) * sizeof *leap); + leap[i].trans = t; + leap[i].corr = correction; + leap[i].roll = rolling; ++leapcnt; } static void adjleap(void) { - register int i; + register ptrdiff_t i; register zic_t last = 0; register zic_t prevtrans = 0; @@ -3846,18 +3849,18 @@ adjleap(void) ** propagate leap seconds forward */ for (i = 0; i < leapcnt; ++i) { - if (trans[i] - prevtrans < 28 * SECSPERDAY) { + if (leap[i].trans - prevtrans < 28 * SECSPERDAY) { error(_("Leap seconds too close together")); exit(EXIT_FAILURE); } - prevtrans = trans[i]; - trans[i] = tadd(trans[i], last); - last = corr[i] += last; + prevtrans = leap[i].trans; + leap[i].trans = tadd(prevtrans, last); + last = leap[i].corr += last; } if (0 <= leapexpires) { leapexpires = oadd(leapexpires, last); - if (! (leapcnt == 0 || (trans[leapcnt - 1] < leapexpires))) { + if (! (leapcnt == 0 || (leap[leapcnt - 1].trans < leapexpires))) { error(_("last Leap time does not precede Expires time")); exit(EXIT_FAILURE); } -- 2.51.0

1 0

[PROPOSED] Increase TZ_MAX_CHARS from 50 to 256
by Paul Eggert Jan. 24, 2026

Jan. 24, 2026

With the current localtime.c implementation, increasing TZ_MAX_CHARS from 50 to its maximum value 256 does not allocate more memory, so there is little point to the limit of 50. * NEWS, localtime.c: Mention this. * tzfile.h (TZ_MAX_CHARS): Increase from 50 to 256. * zic.c (writezone): If -v, warn about going over the old limit. --- NEWS | 7 +++++++ localtime.c | 4 ++-- tzfile.h | 6 +++--- zic.c | 5 +++++ 4 files changed, 17 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 95b1851c..dd592871 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: The "right" TZif files are no longer installed by default. -DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds. + TZif files are no longer limited to 50 bytes of abbreviations. Several integer overflow bugs have been fixed. Changes to build procedure @@ -29,6 +30,12 @@ Unreleased, experimental changes POSIX, shrinks tzcode's attack surface, and is more efficient, it fails to support Internet RFC 9636's leap seconds. + zic now can generate, and localtime.c can now use, TZif files that + hold up to 256 bytes of abbreviations, counting trailing NULs. + The previous limit was 50 bytes, and some tzdata TZif files were + already consuming 40 bytes. zic -v warns if it generates a file + that exceeds the old 50-byte limit. + localtime.c no longer accesses the posixrules file generated by zic -p. Hence for obsolete and nonconforming settings like TZ="AST4ADT" it now typically falls back on US DST rules, rather diff --git a/localtime.c b/localtime.c index ed7a32f2..32835d08 100644 --- a/localtime.c +++ b/localtime.c @@ -1227,8 +1227,8 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, if (tzparse(&up->buf[1], ts, sp)) { /* Attempt to reuse existing abbreviations. - Without this, America/Anchorage would be right on - the edge after 2037 when TZ_MAX_CHARS is 50, as + Without this, America/Anchorage would + consume 50 bytes for abbreviations, as sp->charcnt equals 40 (for LMT AST AWT APT AHST AHDT YST AKDT AKST) and ts->charcnt equals 10 (for AKST AKDT). Reusing means sp->charcnt can diff --git a/tzfile.h b/tzfile.h index 71b60f37..1b1bac4a 100644 --- a/tzfile.h +++ b/tzfile.h @@ -95,13 +95,13 @@ struct tzhead { #ifndef TZ_MAX_TYPES /* This must be at least 18 for Europe/Vilnius with 'zic -b fat'. */ -# define TZ_MAX_TYPES 256 /* Limited by what (unsigned char)'s can hold */ +# define TZ_MAX_TYPES 256 /* Limited to 256 by Internet RFC 9636. */ #endif /* !defined TZ_MAX_TYPES */ #ifndef TZ_MAX_CHARS /* This must be at least 40 for America/Anchorage. */ -# define TZ_MAX_CHARS 50 /* Maximum number of abbreviation characters */ - /* (limited by what unsigned chars can hold) */ +# define TZ_MAX_CHARS 256 /* Maximum number of abbreviation characters */ + /* (limited to 256 by Internet RFC 9636) */ #endif /* !defined TZ_MAX_CHARS */ #ifndef TZ_MAX_LEAPS diff --git a/zic.c b/zic.c index 73155138..1a2f4741 100644 --- a/zic.c +++ b/zic.c @@ -2986,6 +2986,11 @@ writezone(const char *const name, const char *const string, char version, continue; } + if (pass == 2 && noise && 50 < thischarcnt) + warning(_("%s: pre-2026 reference clients mishandle" + " more than 50 bytes of abbreviations"), + name); + /* Output a LO_TIME transition if needed; see limitrange. But do not go below the minimum representable value for this pass. */ -- 2.51.0

1 0

[PROPOSED] New -DTZ_RUNTIME_LEAPS=0 build-time option
by Paul Eggert Jan. 22, 2026

Jan. 22, 2026

This implements my suggestion in: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/Y4WLBYNBTFFG2XEQH… to add a compile-time option to disable localtime.c's support for leap seconds, and thereby shrink the attack surface on tzcode. * Makefile, NEWS, date.1, etcetera, zic.8: Mention this. * localtime.c (struct state): Define leapcnt and lsis members only if TZ_RUNTIME_LEAPS. All uses removed and replaced with the following: (leapcount, set_leapcount, lsinfo, set_lsinfo): New static getter and setter functions for leap second data. (tzloadbody) [!TZ_RUNTIME_LEAPS]: Reject TZif files with leap seconds. (gmtload) [!TZ_RUNTIME_LEAPS]: Do not load from TZLOAD_TZSTRING since we are not doing leap seconds. * private.h (TZ_RUNTIME_LEAPS, ATTRIBUTE_POSIX2TIME): New macros. (posix2time_z, time2posix_z): Declare with ATTRIBUTE_POSIX2TIME not ATTRIBUTE_PURE, because these functions are const (not merely pure) when leap seconds are disabled. --- Makefile | 4 ++ NEWS | 6 +++ date.1 | 2 +- etcetera | 3 +- localtime.c | 125 ++++++++++++++++++++++++++++++++++------------------ private.h | 13 +++++- zic.8 | 3 +- 7 files changed, 108 insertions(+), 48 deletions(-) diff --git a/Makefile b/Makefile index 021186fc..1e0a5903 100644 --- a/Makefile +++ b/Makefile @@ -328,6 +328,10 @@ LDLIBS= # -DTZ_DOMAIN=\"foo\" to use "foo" for gettext domain name; default is "tz" # -DTZ_DOMAINDIR=\"/path\" to use "/path" for gettext directory; # the default is system-supplied, typically "/usr/lib/locale" +# -DTZ_RUNTIME_LEAPS=0 to disable runtime support for leap seconds. +# This conforms to POSIX, shrinks tzcode's attack surface, +# and is more efficient. However, it fails to support Internet +# RFC 9636's leap seconds. # -DTZDEFRULESTRING=\",date/time,date/time\" to default to the specified # DST transitions for proleptic format TZ strings lacking them. # If not specified, it defaults to US rules for future DST transitions. diff --git a/NEWS b/NEWS index 995507f0..95b1851c 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: The "right" TZif files are no longer installed by default. + -DTZ_RUNTIME_LEAPS=0 disables runtime support for leap seconds. Several integer overflow bugs have been fixed. Changes to build procedure @@ -23,6 +24,11 @@ Unreleased, experimental changes Changes to code + Compiling with the new option -DTZ_RUNTIME_LEAPS=0 disables + runtime support for leap seconds. Although this conforms to + POSIX, shrinks tzcode's attack surface, and is more efficient, + it fails to support Internet RFC 9636's leap seconds. + localtime.c no longer accesses the posixrules file generated by zic -p. Hence for obsolete and nonconforming settings like TZ="AST4ADT" it now typically falls back on US DST rules, rather diff --git a/date.1 b/date.1 index 5f334358..8f2c212b 100644 --- a/date.1 +++ b/date.1 @@ -77,6 +77,6 @@ hexadecimal (leading 0x), preceded by an optional sign. .br /usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/Etc/UTC for UTC leap seconds +/usr/share/zoneinfo/Etc/UTC for UTC leap seconds, if supported .SH SEE ALSO .BR strftime (3). diff --git a/etcetera b/etcetera index 948531c8..d78f0413 100644 --- a/etcetera +++ b/etcetera @@ -20,7 +20,8 @@ # which load the "UTC" file to handle seconds properly. Zone Etc/UTC 0 - UTC -# Functions like gmtime load the "GMT" file to handle leap seconds properly. +# If leap second support is enabled, functions like gmtime +# load the "GMT" file to handle leap seconds properly. # Vanguard section, which works with most .zi parsers. #Zone GMT 0 - GMT # Rearguard section, for TZUpdater 2.3.2 and earlier. diff --git a/localtime.c b/localtime.c index 40a4d7ee..ed7a32f2 100644 --- a/localtime.c +++ b/localtime.c @@ -498,7 +498,9 @@ enum { CHARS_EXTRA = max(sizeof UNSPEC, 2) - 1 }; are put on the stack and stacks are relatively small on some platforms. See tzfile.h for more about the sizes. */ struct state { +#if TZ_RUNTIME_LEAPS int leapcnt; +#endif int timecnt; int typecnt; int charcnt; @@ -509,9 +511,48 @@ struct state { struct ttinfo ttis[TZ_MAX_TYPES]; char chars[max(max(TZ_MAX_CHARS + CHARS_EXTRA, sizeof "UTC"), 2 * (TZNAME_MAXIMUM + 1))]; +#if TZ_RUNTIME_LEAPS struct lsinfo lsis[TZ_MAX_LEAPS]; +#endif }; +static int +leapcount(ATTRIBUTE_MAYBE_UNUSED struct state const *sp) +{ +#if TZ_RUNTIME_LEAPS + return sp->leapcnt; +#else + return 0; +#endif +} +static void +set_leapcount(ATTRIBUTE_MAYBE_UNUSED struct state *sp, + ATTRIBUTE_MAYBE_UNUSED int leapcnt) +{ +#if TZ_RUNTIME_LEAPS + sp->leapcnt = leapcnt; +#endif +} +static struct lsinfo +lsinfo(ATTRIBUTE_MAYBE_UNUSED struct state const *sp, + ATTRIBUTE_MAYBE_UNUSED int i) +{ +#if TZ_RUNTIME_LEAPS + return sp->lsis[i]; +#else + unreachable(); +#endif +} +static void +set_lsinfo(ATTRIBUTE_MAYBE_UNUSED struct state *sp, + ATTRIBUTE_MAYBE_UNUSED int i, + ATTRIBUTE_MAYBE_UNUSED struct lsinfo lsinfo) +{ +#if TZ_RUNTIME_LEAPS + sp->lsis[i] = lsinfo; +#endif +} + enum r_type { JULIAN_DAY, /* Jn = Julian day */ DAY_OF_YEAR, /* n = day of year */ @@ -1005,8 +1046,6 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, char version = up->tzhead.tzh_version[0]; bool skip_datablock = stored == 4 && version; int_fast32_t datablock_size; - int_fast64_t prevtr = -1; - int_fast32_2s prevcorr; int_fast32_2s ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt), ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt), @@ -1018,7 +1057,8 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Although tzfile(5) currently requires typecnt to be nonzero, support future formats that may allow zero typecnt in files that have a TZ string and no transitions. */ - if (! (0 <= leapcnt && leapcnt <= TZ_MAX_LEAPS + if (! (0 <= leapcnt + && leapcnt <= (TZ_RUNTIME_LEAPS ? TZ_MAX_LEAPS : 0) && 0 <= typecnt && typecnt <= TZ_MAX_TYPES && 0 <= timecnt && timecnt <= TZ_MAX_TIMES && 0 <= charcnt && charcnt <= TZ_MAX_CHARS @@ -1037,12 +1077,13 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, return EINVAL; if (skip_datablock) p += datablock_size; + else if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) + && (ttisutcnt == typecnt || ttisutcnt == 0))) + return EINVAL; else { - if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) - && (ttisutcnt == typecnt || ttisutcnt == 0))) - return EINVAL; - - sp->leapcnt = leapcnt; + int_fast64_t prevtr = -1; + int_fast32_2s prevcorr; + set_leapcount(sp, leapcnt); sp->timecnt = timecnt; sp->typecnt = typecnt; sp->charcnt = charcnt; @@ -1110,7 +1151,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Read leap seconds, discarding those out of time_t range. */ leapcnt = 0; - for (i = 0; i < sp->leapcnt; ++i) { + for (i = 0; i < leapcount(sp); i++) { int_fast64_t tr = stored == 4 ? detzcode(p) : detzcode64(p); int_fast32_2s corr = detzcode(p + stored); p += stored + 4; @@ -1135,12 +1176,14 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, prevcorr = corr; if (tr <= TIME_T_MAX) { - sp->lsis[leapcnt].ls_trans = tr; - sp->lsis[leapcnt].ls_corr = corr; + struct lsinfo ls; + ls.ls_trans = tr; + ls.ls_corr = corr; + set_lsinfo(sp, leapcnt, ls); leapcnt++; } } - sp->leapcnt = leapcnt; + set_leapcount(sp, leapcnt); for (i = 0; i < sp->typecnt; ++i) { register struct ttinfo * ttisp; @@ -1605,13 +1648,15 @@ tzparse(const char *name, struct state *sp, struct state const *basep) if (basep) { if (0 < basep->timecnt) atlo = basep->ats[basep->timecnt - 1]; - sp->leapcnt = basep->leapcnt; - if (0 < sp->leapcnt) { - memcpy(sp->lsis, basep->lsis, sp->leapcnt * sizeof *sp->lsis); - leaplo = sp->lsis[sp->leapcnt - 1].ls_trans; + set_leapcount(sp, leapcount(basep)); + if (0 < leapcount(sp)) { + int i; + for (i = 0; i < leapcount(sp); i++) + set_lsinfo(sp, i, lsinfo(basep, i)); + leaplo = lsinfo(sp, leapcount(sp) - 1).ls_trans; } } else - sp->leapcnt = 0; /* So, we're off a little. */ + set_leapcount(sp, 0); /* So, we're off a little. */ sp->goback = sp->goahead = false; if (*name != '\0') { struct rule start, end; @@ -1755,7 +1800,7 @@ tzparse(const char *name, struct state *sp, struct state const *basep) static void gmtload(struct state *const sp) { - if (tzload(etc_utc, sp, TZLOAD_TZSTRING) != 0) + if (!TZ_RUNTIME_LEAPS || tzload(etc_utc, sp, TZLOAD_TZSTRING) != 0) tzparse("UTC0", sp, NULL); } @@ -1787,7 +1832,7 @@ zoneinit(struct state *sp, char const *name, char tzloadflags) /* ** User wants it fast rather than right. */ - sp->leapcnt = 0; /* so, we're off a little */ + set_leapcount(sp, 0); /* so, we're off a little */ sp->timecnt = 0; sp->typecnt = 0; sp->charcnt = 0; @@ -2274,7 +2319,6 @@ static struct tm * timesub(const time_t *timep, int_fast32_t offset, const struct state *sp, struct tm *tmp) { - register const struct lsinfo * lp; register time_t tdays; register const int * ip; int_fast32_2s corr; @@ -2288,13 +2332,13 @@ timesub(const time_t *timep, int_fast32_t offset, time_t secs_since_posleap = SECSPERMIN; corr = 0; - i = (sp == NULL) ? 0 : sp->leapcnt; + i = sp ? leapcount(sp) : 0; while (--i >= 0) { - lp = &sp->lsis[i]; - if (*timep >= lp->ls_trans) { - corr = lp->ls_corr; - if ((i == 0 ? 0 : lp[-1].ls_corr) < corr) - secs_since_posleap = *timep - lp->ls_trans; + struct lsinfo ls = lsinfo(sp, i); + if (ls.ls_trans <= *timep) { + corr = ls.ls_corr; + if ((i == 0 ? 0 : lsinfo(sp, i - 1).ls_corr) < corr) + secs_since_posleap = *timep - ls.ls_trans; break; } } @@ -2948,14 +2992,13 @@ timegm(struct tm *tmp) static int_fast32_2s leapcorr(struct state const *sp, time_t t) { - register struct lsinfo const * lp; register int i; - i = sp->leapcnt; + i = leapcount(sp); while (--i >= 0) { - lp = &sp->lsis[i]; - if (t >= lp->ls_trans) - return lp->ls_corr; + struct lsinfo ls = lsinfo(sp, i); + if (ls.ls_trans <= t) + return ls.ls_corr; } return 0; } @@ -3031,13 +3074,12 @@ NETBSD_INSPIRED_EXTERN time_t posix2time_z(struct state *sp, time_t t) { int i; - for (i = sp->leapcnt; 0 <= --i; ) { - struct lsinfo *lp = &sp->lsis[i]; - int_fast32_2s corr = lp->ls_corr; + for (i = leapcount(sp); 0 <= --i; ) { + struct lsinfo ls = lsinfo(sp, i); time_t t_corr = t; - if (increment_overflow_time(&t_corr, corr)) { - if (0 <= corr) { + if (increment_overflow_time(&t_corr, ls.ls_corr)) { + if (0 <= ls.ls_corr) { /* Overflow near maximum time_t value with positive correction. This can happen with ordinary TZif files with leap seconds. */ errno = EOVERFLOW; @@ -3046,13 +3088,10 @@ posix2time_z(struct state *sp, time_t t) /* A negative correction overflowed, so keep going. This can happen with unrealistic-but-valid TZif files. */ } - } else { - time_t trans = lp->ls_trans; - if (trans <= t_corr) - return (t_corr - - (trans == t_corr - && (i == 0 ? 0 : sp->lsis[i - 1].ls_corr) < corr)); - } + } else if (ls.ls_trans <= t_corr) + return (t_corr + - (ls.ls_trans == t_corr + && (i == 0 ? 0 : lsinfo(sp, i - 1).ls_corr) < ls.ls_corr)); } return t; } diff --git a/private.h b/private.h index e8cf9c22..6a58b073 100644 --- a/private.h +++ b/private.h @@ -193,6 +193,10 @@ # define ctime_r _incompatible_ctime_r #endif /* HAVE_INCOMPATIBLE_CTIME_R */ +#ifndef TZ_RUNTIME_LEAPS +# define TZ_RUNTIME_LEAPS 1 +#endif + /* ** Nested includes */ @@ -922,11 +926,16 @@ time_t mktime_z(timezone_t restrict, struct tm *restrict); timezone_t tzalloc(char const *); void tzfree(timezone_t); # if STD_INSPIRED +# if TZ_RUNTIME_LEAPS +# define ATTRIBUTE_POSIX2TIME ATTRIBUTE_PURE +# else +# define ATTRIBUTE_POSIX2TIME ATTRIBUTE_CONST +# endif # if TZ_TIME_T || !defined posix2time_z -ATTRIBUTE_PURE time_t posix2time_z(timezone_t, time_t); +ATTRIBUTE_POSIX2TIME time_t posix2time_z(timezone_t, time_t); # endif # if TZ_TIME_T || !defined time2posix_z -ATTRIBUTE_PURE time_t time2posix_z(timezone_t, time_t); +ATTRIBUTE_POSIX2TIME time_t time2posix_z(timezone_t, time_t); # endif # endif #endif diff --git a/zic.8 b/zic.8 index 73b19ca9..05eea105 100644 --- a/zic.8 +++ b/zic.8 @@ -107,7 +107,8 @@ any already-existing link is removed. .BI "\-L " leapsecondfilename Read leap second information from the file with the given name. If this option is not used, -no leap second information appears in output files. +no leap second information appears in output files; +this is required by some TZif readers. .TP .BI "\-p " timezone Act as if the input contained a link line of the form -- 2.52.0

1 0

Greenland daylight saving during World War II
by Paul Eggert Jan. 22, 2026

Jan. 22, 2026

Greenland's been in the political news lately, and while reading about its history I found an unsourced statement in Wikipedia[1] that Greenland observed daylight saving time during World War II. I found a few published sources confirming this, but none with enough details for me to figure out what changes should go into tzdata. For now I installed the attached proposed patch which merely adds commentary. If someone could find the details we could fix the data accordingly. [1]: https://en.wikipedia.org/wiki/Greenland_in_World_War_II

1 0

[PROPOSED] TZ_MAX_TIMES must be at least 310 now
by Paul Eggert Jan. 22, 2026

Jan. 22, 2026

* tzfile.h: Asia/Hebron is the new champion. --- tzfile.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.h b/tzfile.h index d1f0fbe6..71b60f37 100644 --- a/tzfile.h +++ b/tzfile.h @@ -89,7 +89,7 @@ struct tzhead { */ #ifndef TZ_MAX_TIMES -/* This must be at least 242 for Europe/London with 'zic -b fat'. */ +/* This must be at least 310 for Asia/Hebron with 'zic -b fat'. */ # define TZ_MAX_TIMES 2000 #endif /* !defined TZ_MAX_TIMES */ -- 2.52.0

1 0

[PROPOSED] Fix pre-C23 typos in recent overflow fixes
by Paul Eggert Jan. 21, 2026

Jan. 21, 2026

* localtime.c (time2sub) [!defined ckd_sub]: Fix typos in Friday’s “Fix remaining Naveed8951-reported overflows” changes. This is needed for GCC 13 and earlier, and for other pre-C23 compilers that lack <stdckdint.h>. --- localtime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index 698f61bf..40a4d7ee 100644 --- a/localtime.c +++ b/localtime.c @@ -2697,8 +2697,8 @@ time2sub(struct tm *const tmp, v = ckd_sub(&offdiff, mytm.TM_GMTOFF, yourtm.TM_GMTOFF); # else /* A ckd_sub approximation that is good enough here. */ - v = !(-TWO_31_MINUS_1 <= yourm.TM_GMTOFF - && your.TM_GMTOFF <= TWO_31_MINUS_1); + v = !(-TWO_31_MINUS_1 <= yourtm.TM_GMTOFF + && yourtm.TM_GMTOFF <= TWO_31_MINUS_1); if (!v) offdiff = utoff_diff(mytm.TM_GMTOFF, yourtm.TM_GMTOFF); # endif -- 2.52.0

1 0

[PROPOSED] Support slightly-larger TZif files
by Paul Eggert Jan. 21, 2026

Jan. 21, 2026

* NEWS: Mention this. * localtime.c (tzloadbody): Fix off-by-one errors in tests that mistakenly caused the code to reject TZif files that actually fit. Problem introduced in release 2014g, by my commit 13a277175c603cfb62ae5bdcf26e23faf5619ef1 dated 2014-08-19. --- NEWS | 3 +++ localtime.c | 12 ++++++------ 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 71bd91e4..995507f0 100644 --- a/NEWS +++ b/NEWS @@ -43,6 +43,9 @@ Unreleased, experimental changes outlandish but conforming UT offsets or leap second corrections, has also been fixed. (Also reported by Naveed8951.) + localtime.c no longer rejects TZif files that exactly fit in its + internal structures, fixing off-by-one typos introduced in 2014g. + zic no longer generates a no-op transition when simultaneous Rule and Zone changes cancel each other out. This occurs in tzdata only in Asia/Tbilisi on 1997-03-30. diff --git a/localtime.c b/localtime.c index aa9b48ca..698f61bf 100644 --- a/localtime.c +++ b/localtime.c @@ -1018,12 +1018,12 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Although tzfile(5) currently requires typecnt to be nonzero, support future formats that may allow zero typecnt in files that have a TZ string and no transitions. */ - if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS - && 0 <= typecnt && typecnt < TZ_MAX_TYPES - && 0 <= timecnt && timecnt < TZ_MAX_TIMES - && 0 <= charcnt && charcnt < TZ_MAX_CHARS - && 0 <= ttisstdcnt && ttisstdcnt < TZ_MAX_TYPES - && 0 <= ttisutcnt && ttisutcnt < TZ_MAX_TYPES)) + if (! (0 <= leapcnt && leapcnt <= TZ_MAX_LEAPS + && 0 <= typecnt && typecnt <= TZ_MAX_TYPES + && 0 <= timecnt && timecnt <= TZ_MAX_TIMES + && 0 <= charcnt && charcnt <= TZ_MAX_CHARS + && 0 <= ttisstdcnt && ttisstdcnt <= TZ_MAX_TYPES + && 0 <= ttisutcnt && ttisutcnt <= TZ_MAX_TYPES)) return EINVAL; datablock_size = (timecnt * stored /* ats */ -- 2.51.0

1 0

[PROPOSED 0/3] Leap second overflow bugs
by Paul Eggert Jan. 20, 2026

Jan. 20, 2026

This patch series fixes some bugs involving integer overflow in leap second calculations at runtime. The main problem is with the optional time2posix and posix2time functions; without the patches the functions can crash or loop indefinitely or return completely-wrong answers. With these patches the functions have new, documented behavior: they return (time_t) -1 and set errno to EOVERFLOW when the result is not representable, instead of behaving badly in tricky situations. Given the problems I've been seeing with the leap second runtime code, and given the worry that similar problems remain, and given that the leap second runtime code is rarely used in practice, I'm thinking it may be a good idea to add a compile-time option to disable localtime.c's support for leap seconds. Using the option would shrink the attack surface on tzcode. Paul Eggert (3): Fix theoretical -2**31 leapcorr bug Improve time2posix man page Fix overflow bugs in time2posix and posix2time NEWS | 13 ++++- localtime.c | 90 +++++++++++++++++++++------------- time2posix.3 | 134 ++++++++++++++++++++++++++++++++++----------------- 3 files changed, 156 insertions(+), 81 deletions(-) -- 2.51.0

1 3

[PROPOSED] Check with -Wzero-as-null-pointer-constant
by Paul Eggert Jan. 19, 2026

Jan. 19, 2026

* Makefile (GCC_DEBUG_FLAGS): Omit -Wstringop-truncation, as it’s the default. Add -Wzero-as-null-pointer-constant. --- Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 570518c4..021186fc 100644 --- a/Makefile +++ b/Makefile @@ -380,12 +380,13 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ -Wold-style-definition -Woverlength-strings -Wpointer-arith \ -Wshadow -Wshift-overflow=2 -Wstrict-overflow \ -Wstrict-prototypes -Wstringop-overflow=4 \ - -Wstringop-truncation -Wsuggest-attribute=cold \ + -Wsuggest-attribute=cold \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ -Wtrampolines -Wundef -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ + -Wzero-as-null-pointer-constant \ -Wno-format-nonliteral -Wno-sign-compare -Wno-type-limits # # If your system has a "GMT offset" field in its "struct tm"s -- 2.51.0

1 0

[PROPOSED] Simplify int_fast32_t definition on C89 platforms
by Paul Eggert Jan. 17, 2026

Jan. 17, 2026

* private.h (int_fast32_t, INT_FAST32_MAX, INT_FAST32_MIN): When PORT_TO_C89 is defined, simplify these fallback definitions by using long rather than attempting to use int on platforms where int suffices. The attempt’s test was too strict: its ‘INT_MAX >> 31 == 0’ should have been ‘INT_MAX >> 30 == 0’. This led to a possible performance bug on C89 platforms where int is 32 bits, as int_fast32_t was defined to be long when int would suffice. C89 platforms are now museum pieces and this code is currently scheduled to be removed in 2029 or so anyway, so it is not worth trying to measure and debug any performance issues. Simplify the definitions instead. That mirrors what is already being done for uint_fast32_t. --- private.h | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/private.h b/private.h index 42a1c892..e8cf9c22 100644 --- a/private.h +++ b/private.h @@ -410,15 +410,9 @@ typedef long long int_fast64_t; # endif # ifndef INT_FAST32_MAX -# if INT_MAX >> 31 == 0 typedef long int_fast32_t; -# define INT_FAST32_MAX LONG_MAX -# define INT_FAST32_MIN LONG_MIN -# else -typedef int int_fast32_t; -# define INT_FAST32_MAX INT_MAX -# define INT_FAST32_MIN INT_MIN -# endif +# define INT_FAST32_MAX LONG_MAX +# define INT_FAST32_MIN LONG_MIN # endif # ifndef INT_LEAST32_MAX -- 2.51.0

1 0

Re: tzload: validate tt_utoff to avoid signed overflow
by Paul Eggert Jan. 17, 2026

Jan. 17, 2026

In <https://github.com/eggert/tz/pull/37> (2026-01-10) the GitHub user Naveed8951 writes: > The TZif specification guarantees that tt_utoff is never INT32_MIN > so that 32-bit clients can safely negate it. However, tzloadbody() > previously accepted unvalidated values from untrusted TZif input. > A malformed or malicious file could therefore trigger signed integer > overflow during later offset arithmetic (e.g., negation for timezone / > altzone or offset-difference calculations), which is undefined behavior > in C. Naveed8951 submitted a patch that would cause localtime.c to reject TZif files containing UT offsets outside the POSIX range -89999..93599 (-24:59:50 .. 25:59:59), the idea being that small offsets like that would not cause overflow. Unfortunately, I think such a change would still allow undefined behavior in some cases, as overflow could still happen when adding a small offset to a large tm_sec or time_t value. Also, Internet RFC 9636 section 3.2 allows (though it discourages) UT offsets outside the POSIX range. So instead, I fixed localtime.c to handle the outlandish offsets correctly. As a special case, localtime.c (and zic.c) now reject a UT offset exactly equal to -2**31, as RFC 9636 does not allow that and it can easily cause trouble in callers that negate a UT offset stored in a 32-bit integer.

1 0

[PROPOSED] Pacify gcc -Wunused-function with 32-bit time_t
by Paul Eggert Jan. 17, 2026

Jan. 17, 2026

* localtime.c (USE_TIMEX_T): Move definition up. (is_threaded, locallock, dolock, dounlock, lock, unlock): Do not define if (defined TM_GMTOFF && USE_TIMEX_T). (rd2wrlock, tm_multi): Move definition down to be closer to use, so that it is nested inside #if and thus defined only when used. --- localtime.c | 117 ++++++++++++++++++++++++++++------------------------ 1 file changed, 62 insertions(+), 55 deletions(-) diff --git a/localtime.c b/localtime.c index a2f92b2a..9b7bbaa9 100644 --- a/localtime.c +++ b/localtime.c @@ -52,6 +52,10 @@ struct stat { char st_ctime, st_dev, st_ino; }; # define THREAD_TM_MULTI 0 #endif +#ifndef USE_TIMEX_T +# define USE_TIMEX_T false +#endif + #if THREAD_SAFE # include <pthread.h> @@ -88,6 +92,10 @@ extern int __isthreaded; # endif # endif # endif +#endif + +#if !defined TM_GMTOFF || !USE_TIMEX_T +# if THREAD_SAFE /* True if the current process might be multi-threaded, false if it is definitely single-threaded. @@ -98,24 +106,25 @@ extern int __isthreaded; static bool is_threaded(void) { -# if THREAD_PREFER_SINGLE && HAVE___ISTHREADED +# if THREAD_PREFER_SINGLE && HAVE___ISTHREADED return !!__isthreaded; -# elif THREAD_PREFER_SINGLE && HAVE_SYS_SINGLE_THREADED_H +# elif THREAD_PREFER_SINGLE && HAVE_SYS_SINGLE_THREADED_H return !__libc_single_threaded; -# else +# else return true; -# endif +# endif } -# if THREAD_RWLOCK +# if THREAD_RWLOCK static pthread_rwlock_t locallock = PTHREAD_RWLOCK_INITIALIZER; static int dolock(void) { return pthread_rwlock_rdlock(&locallock); } static void dounlock(void) { pthread_rwlock_unlock(&locallock); } -# else +# else static pthread_mutex_t locallock = PTHREAD_MUTEX_INITIALIZER; static int dolock(void) { return pthread_mutex_lock(&locallock); } static void dounlock(void) { pthread_mutex_unlock(&locallock); } -# endif +# endif + /* Get a lock. Return 0 on success, a positive errno value on failure, negative if known to be single-threaded so no lock is needed. */ static int @@ -131,25 +140,12 @@ unlock(bool threaded) if (threaded) dounlock(); } -#else +# else static int lock(void) { return -1; } static void unlock(ATTRIBUTE_MAYBE_UNUSED bool threaded) { } +# endif #endif -/* If THREADED, upgrade a read lock to a write lock. - Return 0 on success, a positive errno value otherwise. */ -static int -rd2wrlock(ATTRIBUTE_MAYBE_UNUSED bool threaded) -{ -#if THREAD_RWLOCK - if (threaded) { - dounlock(); - return pthread_rwlock_wrlock(&locallock); - } -#endif - return 0; -} - #if THREAD_SAFE typedef pthread_once_t once_t; # define ONCE_INIT PTHREAD_ONCE_INIT @@ -187,36 +183,6 @@ tm_multi_key_init(void) #endif -/* Return TMP, or a thread-specific struct tm * selected by WHICH. */ -static struct tm * -tm_multi(struct tm *tmp, ATTRIBUTE_MAYBE_UNUSED enum tm_multi which) -{ -#if THREAD_SAFE && THREAD_TM_MULTI - /* It is OK to check is_threaded() separately here; even if it - returns a different value in other places in the caller, - this function's behavior is still valid. */ - if (is_threaded()) { - /* Try to get a thread-specific struct tm *. - Fall back on TMP if this fails. */ - static pthread_once_t tm_multi_once = PTHREAD_ONCE_INIT; - pthread_once(&tm_multi_once, tm_multi_key_init); - if (!tm_multi_key_err) { - struct tm *p = pthread_getspecific(tm_multi_key); - if (!p) { - p = malloc(N_TM_MULTI * sizeof *p); - if (p && pthread_setspecific(tm_multi_key, p) != 0) { - free(p); - p = NULL; - } - } - if (p) - return &p[which]; - } - } -#endif - return tmp; -} - /* Unless intptr_t is missing, pacify gcc -Wcast-qual on char const * exprs. Use this carefully, as the casts disable type checking. This is a macro so that it can be used in static initializers. */ @@ -293,9 +259,6 @@ typedef time_t monotime_t; to a static function that returns the redefined time_t. It also tells us to define only data and code needed to support the offtime or mktime variant. */ -#ifndef USE_TIMEX_T -# define USE_TIMEX_T false -#endif #if USE_TIMEX_T # undef TIME_T_MIN # undef TIME_T_MAX @@ -1843,6 +1806,20 @@ zoneinit(struct state *sp, char const *name, char tzloadflags) } } +/* If THREADED, upgrade a read lock to a write lock. + Return 0 on success, a positive errno value otherwise. */ +static int +rd2wrlock(ATTRIBUTE_MAYBE_UNUSED bool threaded) +{ +# if THREAD_RWLOCK + if (threaded) { + dounlock(); + return pthread_rwlock_wrlock(&locallock); + } +# endif + return 0; +} + /* Like tzset(), but in a critical section. If THREADED && THREAD_RWLOCK the caller has a read lock, and this function might upgrade it to a write lock. @@ -2134,6 +2111,36 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, #if !USE_TIMEX_T +/* Return TMP, or a thread-specific struct tm * selected by WHICH. */ +static struct tm * +tm_multi(struct tm *tmp, ATTRIBUTE_MAYBE_UNUSED enum tm_multi which) +{ +# if THREAD_SAFE && THREAD_TM_MULTI + /* It is OK to check is_threaded() separately here; even if it + returns a different value in other places in the caller, + this function's behavior is still valid. */ + if (is_threaded()) { + /* Try to get a thread-specific struct tm *. + Fall back on TMP if this fails. */ + static pthread_once_t tm_multi_once = PTHREAD_ONCE_INIT; + pthread_once(&tm_multi_once, tm_multi_key_init); + if (!tm_multi_key_err) { + struct tm *p = pthread_getspecific(tm_multi_key); + if (!p) { + p = malloc(N_TM_MULTI * sizeof *p); + if (p && pthread_setspecific(tm_multi_key, p) != 0) { + free(p); + p = NULL; + } + } + if (p) + return &p[which]; + } + } +# endif + return tmp; +} + # if NETBSD_INSPIRED struct tm * localtime_rz(struct state *restrict sp, time_t const *restrict timep, -- 2.52.0

1 0

[PROPOSED 0/6] Fix integer overflows and drop posixrules
by Paul Eggert Jan. 17, 2026

Jan. 17, 2026

GitHub user Naveed8951 reported a potential (but unlikely) security flaw due to undefined behavior in localtime.c after integer overflow. The patches in this series should fix the reported problems. Some of the problem occurred in a part of the localtime.c code that was implementing a feature declared obsolete in TZDB release 2019b. This feature let the sysadmin specify default DST rules for DST-but-ruleless old-style POSIX settings like TZ="AST4ADT". Rather than try to fix the feature this patch series removes it; the feature is hardly ever used and would stop working in 2038 anyway. As a result, tzcode by default uses current US DST for these settings, with no opportunity for sysadmin override (though the default can be overriden when tzcode is compiled). This behavior is already common elsewhere. Paul Eggert (6): Add comment re UT offsets equal to -2**31 Document zic -p better zic now warns about -p Remove POSIXRULES installation option Remove TZDEFRULES ("posixrules") from localtime.c Fix remaining Naveed8951-reported overflows Makefile | 28 +--- NEWS | 19 +++ localtime.c | 388 ++++++++++++++++++++++++---------------------------- newctime.3 | 4 +- newtzset.3 | 29 +--- tzfile.5 | 7 +- tzfile.h | 12 +- zic.8 | 17 ++- zic.c | 8 ++ 9 files changed, 228 insertions(+), 284 deletions(-) -- 2.52.0

1 6

Unable to find Doha in the database
by Paul Menzel Jan. 15, 2026

Jan. 15, 2026

Dear Time Zone Database folks, Visiting Doha, I wanted to change to its time zone, and knowing `Europe/Berlin`, I looked for *Doha*, but didn’t find it in GNOME [1]. Looking through the Time Zone Database archive, there is in `asia` [3]: # Bahrain # Qatar # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Qatar 3:26:08 - LMT 1920 # Al Dawhah / Doha 4:00 - %z 1972 Jun 3:00 - %z The comment is not in my file on Debian though in `/usr/share/zoneinfo/tzdata.zi` from *tzdata* 2025c-3. Z Asia/Qatar 3:26:8 - LMT 1920 4 - %z 1972 Jun 3 - %z Of course, I do not know, if the comment would change anything. Would it be possible to also add Qatar’s capital to the database. Or is there another way to make it easier for people to find the right time zone entry? Kind regards, Paul [1]: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/3656 [2]: https://github.com/eggert/tz/blob/d5f71488fd1ec4a2f7166ceeac2024a677daaaef/…

3 2

[PROPOSED 0/5] Fix some unlikely undefined behaviors
by Paul Eggert Jan. 12, 2026

Jan. 12, 2026

This patchest fixes some bugs in localtime.c when TZif files specify a UT offset equal to -2**31. Such an offset overflows when negated on a 32-bit platform, and this leads to undefined behavior – typically wraparound arithmetic, but the C standard says anything can happen. The patchset also changes zic.c to reject attempts to create such an offset, adjusts some nearby code to be a bit cleaner and more portable. Paul Eggert (5): Omit unnecessary L suffixes zic no longer generates utoff == -2**31 Make sure 2**31 - 1 is signed Port TWOS_COMPLEMENT to signed-magnitude hosts Disallow UT offsets equal to -2**31 NEWS | 4 ++++ localtime.c | 48 ++++++++++++++++++++++++++++++++---------------- private.h | 7 +++++-- strftime.c | 5 +++-- zic.c | 7 ++++--- 5 files changed, 48 insertions(+), 23 deletions(-) -- 2.51.0

1 5

[PROPOSED] Improve .gitignore patterns
by Paul Eggert Jan. 10, 2026

Jan. 10, 2026

* .gitignore: Ignore all subdirectories. Also ignore *.bak, *.core, *.out, *.t, core, and core.*. Also ignore .*, except for .gitignore itself. --- .gitignore | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index e7bb0416..5a140b46 100644 --- a/.gitignore +++ b/.gitignore @@ -1,26 +1,38 @@ # Files intentionally not tracked by Git. # This file is in the public domain. +# +# Ignore all subdirectories. +*/ +# +# Ignore non-directories that are the output of builds, +# or are backups or nonces unlikely to be added to the repository. *.a *.asc +*.bak *.ck -*.ckd/ +*.core *.diff -*.dir/ *.i *.o *.orig +*.out *.patch *.pdf *.ps *.rej *.s +*.t *.tar *.tar.* *.txt *.tzs *.zi *~ +.* +!.gitignore ChangeLog +core +core.* date leapseconds tzdir.h -- 2.51.0

1 0

Whither /usr/share/zoneinfo/right?
by Paul Gilmartin Jan. 8, 2026

Jan. 8, 2026

ISTR on Linux long ago, a subdirectory, /usr/share/zoneinfo/right, which used arguments not POSIX time but TAI. Was that a local hack, or was it removed, possibly because of uncertainty of future leap seconds? -- Thanks, gil

4 5

Fwd: Bulletin C number 71
by Tim Parenti Jan. 7, 2026

Jan. 7, 2026

No leap second 2026-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Tue, 6 Jan 2026 at 06:50 Subject: Bulletin C number 71 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 06 January 2026 Bulletin C 71 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2026. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

2 1

static_assert macro
by Christos Zoulas Jan. 7, 2026

Jan. 7, 2026

Hello, The new tzcode uses static_assert() with no message which is a c2x extension. clang does not like that by default (without specifying -std=gnu2x). /home/source/ab/HEAD-llvm/src/lib/libc/time/private.h:1017:52: error: '_Static_assert' with no message is a C2x extension [-Werror,-Wc2x-extensions] || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); ^ , "" Best, christos

3 4

tzcode and tzdata tar base make checks fail
by Brian Inglis Dec. 31, 2025

Dec. 31, 2025

Cygwin uses separate packages of tzcode programs and tzdata files verbatim to support standard local time zones in preference to limited native data. Running make check on the separate tar file fails in both cases. When I took over the packages, I provided basic checks, but reviewed and changed the builds this release, and would like to reenable the built in checks you provide and mentioned recently. The attached logs show the results of having the package build scripts run `make check` from the package build directory which is set up with symlinks to each of the tar sources. Is there anything obviously missing or incorrect with `make check` invocations which could cause the observed failures, or things that may need changed? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry

2 6

Time zones on Antarctica expedition
by Brooks Harris Dec. 30, 2025

Dec. 30, 2025

Those who have a New York Times subscription may find this entertaining: Does Anybody Really Know What Time It Is? The clocks aboard our icebreaker will be changed several times en route to Antarctica. It’s one of many things that make the expedition feel otherworldly. https://www.nytimes.com/2025/12/29/climate/antarctica-time-zone.html

1 0

[PROPOSED] Fix some unsequenced/reproducible commentary
by Paul Eggert Dec. 21, 2025

Dec. 21, 2025

* private.h (ATTRIBUTE_CONST, ATTRIBUTE_PURE): In commentary do not say that __attribute__((const)) is stricter than [[unsequenced]], as Jens Gustedt, an originator of [[unsequenced]], wrote in <https://lists.gnu.org/r/bug-gnulib/2025-01/msg00190.html> that some const functions are not unsequenced. To be safe, make a similar change for __attribute__((pure)) and [[reproducible]], though I don’t have confirmation from Jens. --- private.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/private.h b/private.h index 074da284..50d6a52a 100644 --- a/private.h +++ b/private.h @@ -619,11 +619,11 @@ typedef unsigned long uintmax_t; # define ATTRIBUTE_UNSEQUENCED /* empty */ #endif -/* GCC attributes that are useful in tzcode. - __attribute__((const)) is stricter than [[unsequenced]], - so the latter is an adequate substitute in non-GCC C23 platforms. - __attribute__((pure)) is stricter than [[reproducible]], - so the latter is an adequate substitute in non-GCC C23 platforms. */ +/* GNU C attributes that are useful in tzcode. + Although neither __attribute__((const)) nor __attribute__((pure)) are + stricter than their C23 counterparts [[unsequenced]] and [[reproducible]], + the C23 attributes happen to work in each tzcode use of ATTRIBUTE_CONST + and ATTRIBUTE_PURE. (This might not work outside of tzcode!) */ #if __GNUC__ < 3 # define ATTRIBUTE_CONST ATTRIBUTE_UNSEQUENCED # define ATTRIBUTE_FORMAT(spec) /* empty */ -- 2.51.0

2 5

TYPE_SIGNED(t) warnings..
by Christos Zoulas Dec. 19, 2025

Dec. 19, 2025

Hi, Gcc with -Wall -Wextra -Wtype-limits produces warnings with: #define TYPE_SIGNED(T) ((T)-1) < 0) error: comparison of unsigned expression in '< 0' is always false [-Werror=type-limits] Perhaps use something that checks the sign bit directly? #define TYPE_SIGNED(T) \ (((T)~(T)0 >> (sizeof(T) * CHAR_BIT - 1)) == (T)-1) Or something from NetBSD's <sys/cdefs.h>? christos

2 2

2025c zic.c calls fflush(3) on read only file pointer.
by Christos Zoulas Dec. 18, 2025

Dec. 18, 2025

Hello, This is undefined behavior. NetBSD returns EOF and sets errno to EBADFD. I am not sure why fflush(3) is called explicitly now, since fclose(3) does it anyway. Best, christos

6 7

[Feature Request] Add validation in zic for invalid DST intervals
by 任春辉 Dec. 17, 2025

Dec. 17, 2025

Hello tzdata maintainers, I would like to propose a feature enhancement for the zic compiler. Currently, the NOS time zone rules are defined as: Rule NOS 1970 2037 - Jan 27 23:43:01 2:0 SDST Rule NOS 1970 2037 - Jan 28 0:51:01 0 S Zone OS/NOS +7:0:0 NOS NO%s Issue: - The first rule enters DST at 23:43:01 with a +2 hour offset, moving local time to 01:43:01. - The second rule is intended to revert to standard time at 00:51:01. - Due to the offset, 00:51:01 local time never occurs, so the second rule will never trigger. - This creates unreachable local times and may cause incorrect results in time calculations. Proposal: - Add validation in the zic command to detect DST rules where the offset causes the subsequent rule's local time to be unreachable. - The validation could issue a warning or error to alert the author of potentially invalid rules. - This would improve the robustness of time zone definitions and prevent subtle bugs in downstream applications. Thank you for your consideration. Best regards

3 5

[PROPOSED] Make HTML view better on cell phones
by Paul Eggert Dec. 16, 2025

Dec. 16, 2025

Unfortunately without the meta viewport element described below, most mobile browers default to unreadably tiny text for backward compatibility with how the iPhone misbehaved in 2007. While we’re giving up on vanilla style, improve readability in minor ways for bigger screens too. Here are the changes made: * Add to HTML files the element <meta name="viewport" content="width=device-width, initial-scale=1">. This is the most common setting mentioned in <https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/n…>. * Style pre elements with "overflow: auto", not "white-space: prewrap". * Decrease pre elements’ margins from 2em to 1.3rem, and change margins/padding for dd and ul to 1.3rem. * In tz-how-to.html, stop trying to package a wideish pre element inside a table, as that’s too painful to do portably and nicely on both narrow and wide screens. Just do a pre followed by a table. --- theory.html | 5 +++- tz-art.html | 4 +++ tz-how-to.html | 72 +++++++++----------------------------------------- tz-link.html | 5 +++- 4 files changed, 25 insertions(+), 61 deletions(-) diff --git a/theory.html b/theory.html index e6e64177..8c802858 100644 --- a/theory.html +++ b/theory.html @@ -3,8 +3,11 @@ <head> <title>Theory and pragmatics of the tz code and data</title> <meta charset="UTF-8"> + <meta name="viewport" content="width=device-width, initial-scale=1"> <style> - pre {margin-left: 2em; white-space: pre-wrap;} + dd {margin-left: 1.3rem;} + pre {margin-left: 1.3rem; overflow: auto;} + ul {padding-left: 1.3rem;} </style> </head> diff --git a/tz-art.html b/tz-art.html index 3039a86f..5f92fa1b 100644 --- a/tz-art.html +++ b/tz-art.html @@ -2,6 +2,10 @@ <html lang="en"> <head> <meta charset="UTF-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<style> +ul {padding-left: 1.3rem;} +</style> <title>Time and the Arts</title> </head> <body> diff --git a/tz-how-to.html b/tz-how-to.html index ccfdc9eb..ddafb2aa 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -3,14 +3,15 @@ <head> <title>How to Read the tz Database</title> <meta charset="UTF-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> <style> -pre {margin-left: 2em; white-space: pre-wrap;} -pre.td {margin-left: 0;} +pre {margin-left: 1.3rem; overflow: auto;} td {text-align: center;} table {border: 1px outset;} th, td {border: 1px inset;} table.rule {border: none; margin: auto;} td.footnote {text-align: left;} +ul {padding-left: 1.3rem;} </style> </head> <body> @@ -38,16 +39,7 @@ about the zones.</p> for Chicago (from the <code>northamerica</code> file in the <code>data</code> subdirectory):</p> -<table> -<tr> - <th colspan="6">From the Source File</th> -</tr> -<tr> - <td colspan="6"> - <table class="rule"> - <tr><td style="border:none;text-align:left"> -<pre class="td"> -#Rule NAME FROM TO - IN ON AT SAVE LETTER +<pre>#Rule NAME FROM TO - IN ON AT SAVE LETTER Rule Chicago 1920 only - Jun 13 2:00 1:00 D Rule Chicago 1920 1921 - Oct lastSun 2:00 0 S Rule Chicago 1921 only - Mar lastSun 2:00 1:00 D @@ -55,8 +47,7 @@ Rule Chicago 1922 1966 - Apr lastSun 2:00 1:00 D Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S </pre> - </td></tr></table></td> -</tr> +<table> <tr> <th colspan="6">Reformatted a Bit</th> </tr> @@ -160,16 +151,7 @@ time changed in 1955. Got it?</p> <p>OK, now for the somewhat more interesting “US” rules:</p> -<table> -<tr> - <th colspan="6">From the Source File</th> -</tr> -<tr> - <td colspan="6"> - <table class="rule"> - <tr><td style="border:none;text-align:left"> -<pre class="td"> -#Rule NAME FROM TO - IN ON AT SAVE LETTER/S +<pre>#Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War @@ -184,8 +166,7 @@ Rule US 1987 2006 - Apr Sun>=1 2:00 1:00 D Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S </pre> - </td></tr></table></td> -</tr> +<table> <tr> <th colspan="6">Reformatted a Bit</th> </tr> @@ -328,15 +309,7 @@ rule, so there should be no change.</li> <p>OK, now let’s look at a Zone record:</p> -<table> -<tr> - <th colspan="5">From the Source File</th> -</tr> -<tr> - <td colspan="5"> - <table class="rule"> - <tr><td style="border:none;text-align:left"> -<pre class="td"> +<pre> #Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24 -6:00 US C%sT 1920 @@ -347,8 +320,7 @@ Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24 -6:00 Chicago C%sT 1967 -6:00 US C%sT </pre> - </td></tr></table></td> -</tr> +<table> <tr> <th colspan="5">Columns Renamed</th> </tr> @@ -576,31 +548,14 @@ the true offset is undefined. <p>As a final example, here’s the complete history for Hawaii:</p> -<table> -<tr> - <th colspan="6">Relevant Excerpts from the US Rules</th> -</tr> -<tr> - <td colspan="6"> - <table class="rule"> - <tr><td style="border:none;text-align:left"> -<pre class="td"> +<pre># Relevant Excerpts from the US Rules</th> #Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace Rule US 1945 only - Sep lastSun 2:00 0 S -</pre> - </td></tr></table></td> -</tr> -<tr> - <th colspan="6">The Zone Record</th> -</tr> -<tr> - <td colspan="6"> - <table class="rule"> - <tr><td style="border:none;text-align:left"> -<pre class="td"> + +# The Zone Record #Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 @@ -608,8 +563,7 @@ Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST </pre> - </td></tr></table></td> -</tr> +<table> <tr> <th colspan="6">What We Infer</th> </tr> diff --git a/tz-link.html b/tz-link.html index ba10a68b..5e941a8d 100644 --- a/tz-link.html +++ b/tz-link.html @@ -3,8 +3,11 @@ <head> <title>Time zone and daylight saving time data</title> <meta charset="UTF-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> <style> -pre {margin-left: 2em; white-space: pre-wrap;} +dd {margin-left: 1.3rem;} +pre {margin-left: 1.3rem; overflow: auto;} +ul {padding-left: 1.3rem;} </style> </head> <body> -- 2.51.0

1 0

Re: [PROPOSED] Mention -Dst_ctim=M in CFLAGS
by Paul Eggert Dec. 12, 2025

Dec. 12, 2025

On 2025-12-11 22:08, Robert Elz wrote: > Prior to this (since inception) we (everything BSD derived) had > st_ctimespec ... you might want to give an example of an actual use > of -Dst_ctim=M and that might be a useful one to use, as it was so > common Thanks, good suggestion. Come to think of it, it's probably clearer to give only the st_ctimespec example and let any (probably zero) builders for obscure OS versions deduce the more-general case. I installed the attached further proposed patch.

1 0

[PROPOSED] Mention -Dst_ctim=M in CFLAGS
by Paul Eggert Dec. 11, 2025

Dec. 11, 2025

* Makefile: Add comment about using -Dst_ctim=M in CFLAGS. As far as I know this matters only on POSIXish platforms so old that they’re no longer supported by their suppliers, e.g., FreeBSD 8.4 (2013), old NetBSD, old UnixWare. --- Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index eda8d53d..09f20100 100644 --- a/Makefile +++ b/Makefile @@ -284,8 +284,10 @@ LDLIBS= # -DHAVE_STRDUP=0 if your system lacks the strdup function # -DHAVE_STRNLEN=0 if your system lacks the strnlen function+ # -DHAVE_STRTOLL=0 if your system lacks the strtoll function+ -# -DHAVE_STRUCT_STAT_ST_CTIM=0 if struct stat lacks a member st_ctim -# and code should use st_ctime instead+ +# -DHAVE_STRUCT_STAT_ST_CTIM=0 if struct stat lacks a status-change member +# of type struct timespec, so code should use st_ctime instead; +# but if the status-change member is called M rather than st_ctim, +# use -Dst_ctim=M instead (default is guessed)+ # -DHAVE_STRUCT_TIMESPEC=0 if your system lacks struct timespec+ # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if <sys/stat.h> does not work* -- 2.51.0

1 0

[tz-announce] 2025c release of tz code and data available
by Paul Eggert via tz-announce Dec. 11, 2025

Dec. 11, 2025

The 2025c release of the tz code and data is available. This release mostly changes code and commentary. The only changed data are leap second table expiration and pre-1976 time in Baja California. This release contains the following changes: Briefly: Several code changes for compatibility with FreeBSD. Changes to past timestamps Baja California agreed with California’s DST rules in 1953 and in 1961 through 1975, instead of observing standard time all year. (Thanks to Alois Treindl.) Changes to build procedure Files in distributed tarballs now have correct commit times. Formerly, the committer’s time zone was incorrectly ignored. Distribution products (*.asc, *.gz, and *.lz) now have reproducible timestamps. Formerly, only the contents of the compressed tarballs had reproducible timestamps. By default, distributed formatted man pages (*.txt) now use UTF-8 and are left-adjusted more consistently. A new Makefile macro MANFLAGS can override these defaults. (Thanks to G. Branden Robinson for inspiring these changes.) Changes to code An unset TZ is no longer invalid when /etc/localtime is missing, and is abbreviated "UTC" not "-00". This reverts to 2024b behavior. (Problem and patch reported by Dag-Erling Smørgrav.) New function offtime_r, short for fixed-offset localtime_rz. It is defined if STD_INSPIRED is defined. (Patch from Dag-Erling Smørgrav.) tzset etc. are now more cautious about questionable TZ settings. Privileged programs now reject TZ settings that start with '/', unless they are TZDEFAULT (default "/etc/localtime") or start with TZDIR then '/' (default "/usr/share/zoneinfo/"). Unprivileged programs now require files to be regular files and reject relative names containing ".." directory components; formerly, only privileged programs did those two things. These changes were inspired by similar behavior in FreeBSD. On NetBSD, unprivileged programs now use O_REGULAR to check whether a TZ setting starting with '/' names a regular file, avoiding a minor security race still present elsewhere. TZ strings taken from tzalloc arguments are now treated with no less caution than TZ strings taken from the environment, as the old undocumented behavior would have been hard to explain. tzset etc. no longer use the ‘access’ system call to check access; instead they now use the system calls issetugid, getauxval, getresuid/getresgid, and geteuid/getegid/getuid/getgid (whichever first works) to test whether a program is privileged. Compile with -DHAVE_SYS_AUXV_H=[01] to enable or disable <sys/auxv.h> which (if it defines AT_SECURE) enables getauxval, and compile with -DHAVE_ISSETUGID=[01], -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or disable the other calls’ use. The new CFLAGS option -DTZ_CHANGE_INTERVAL=N makes tzset etc. check for TZif file changes if the in-memory data are N seconds old or more, and are derived from the TZ environment variable. This is intended for platforms that want tzset etc. to reflect changes to whatever file TZ selects (including changes to /etc/localtime if TZ is unset). If N is negative (the default) these checks are omitted; this is the traditional behavior. The new CFLAGS options -DHAVE_STRUCT_STAT_ST_CTIM=0 and -DHAVE_STRUCT_TIMESPEC=0 port to non-POSIX.1-2008 platforms that lack st_ctim and struct timespec, respectively. tzset etc. now treat ' ' like '_' in time zone abbreviations, just as they treat other invalid bytes. This continues the transition begun in release 96k, which removed spaces in tzdata because the spaces break time string parsers. The new CFLAGS option -DTHREAD_PREFER_SINGLE causes tzcode in single-threaded processes to avoid locks, as FreeBSD does. This can save time in single-threaded apps. The threadedness testing costs CPU time and energy in multi-threaded apps. New options -DHAVE___ISTHREADED and -DHAVE_SYS_SINGLE_THREADED_H can help configure how to test for single-threadedness. The new CFLAGS option -DTHREAD_RWLOCK uses read-write locks, as macOS does, instead of mutexes. This saves real time when TZ is rarely changing and many threads call tzcode simultaneously. It costs more CPU time and energy. The new CFLAGS option -TTHREAD_TM_MULTI causes localtime to return a pointer to thread-specific memory, as FreeBSD does, instead of to the same memory in all threads. This supports unportable programs that incorrectly use localtime instead of localtime_r. This option affects gmtime and offtime similarly to localtime. Because the corresponding storage is freed on thread exit, this option is incompatible with POSIX.1-2024 and earlier. It also costs CPU time and memory. tzfree now preserves errno, consistently with POSIX.1-2024 ‘free’. tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. tzcode now uses strnlen to improve asymptotic performance a bit. Compile with -DHAVE_STRNLEN=0 if your platform lacks it. tzcode now hand-declares unistd.h-provided symbols like getopt if HAVE_UNISTD_H=0, not if HAVE_POSIX_DECLS=0. tzset etc. now have an experimental OPENAT_TZDIR option; see Makefile and localtime.c for details. On platforms like GNU/Hurd that do not define PATH_MAX, exceedingly long TZ strings no longer fail merely because they exceed an arbitrary file name length limit imposed by tzcode. zic has new options inspired by FreeBSD. ‘-D’ skips creation of output ancestor directories, ‘-m MODE’ sets output files’ mode, and ‘-u OWNER[:GROUP]’ sets output files’ owner and group. zic now uses the fdopen function, which was standardized by POSIX.1-1988 and is now safe to use in portable code. This replaces its use of the older umask function, which complicated maintenance. Changes to commentary The leapseconds file contains commentary about the IERS and NIST last-modified and expiration timestamps for leap second data. (Thanks to Judah Levine.) Commentary now also uses characters from the set –‘’“”•≤ as this can be useful and should work with current applications. This also affects data in iso3166.tab and zone1970.tab, which now contain strings like “Côte d’Ivoire” instead of “Côte d'Ivoire”. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025c.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 7e1145bfdb9630c127841dc8ce808a937a300938 dated 2025-03-22 13:40:46 -0700 and tagged '2025c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: d14bc0680b9cb33d6526a2c0e483f2abafc2593cfe5fbfe7dcab940aafdc1baaec065dbaa1bb58b03586a8631ffdf43ebb22ff5a70503298b6ea2cf061d82c16 tzcode2025c.tar.gz 1e33f7212fd0ae2ad3c16e68f0c1fc7a6ad26a126b8406c379a5768d79604c6a816054bd0fe3a63228d70cd6a1fc2b1bae2a9f8014e102d3727eb9d21affa1f1 tzdata2025c.tar.gz 6fa233d6a884acd24b52c44b2eecf683f9403f44b39dcbe85b1ec92fc11f4daf6ee5143f05332faf9258b8bd8f7ca7d4882e19b1e3d892b4761be43fd4f39d51 tzdb-2025c.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmk5+AQACgkQ7ZfpDmKq fjS7FQ/+OcQWOkAheWXB17w3dzqEaBTzzOFPoVWJkYDYYqRBFYcZHt6SL8NsJ6Vr 4PRv8UXvGZZhyamQY6CA3Te6/SRBTn4vKAPPYrwRxRENBHJtwf00H4khIqzL4iuu Lni7d3MyEurnQ99YKdCdsDM7V2GqGov8SFOIQWohAazL29n/396Me68Excr7WYh2 FY1qmbqQhBuh9WrQ9+YznWkKd5FcPj0a8+XBReABUR3yV58qZ4rvDhDpx+476U09 5PlOHgC3FdEII+I8ihKI+Y0FW20dDfyTc7Eechef2z3izlzaxSFbAXXQX1gs1Vj+ yhjp+MiJC9UiFP0VmafGdpuhNWafrRSF8uyhHEAPC2WRRSlz3hUBFchOWRBpgAkT yIhN7dUWPPT80Pu2vWn3Y647I8397b6mS5o8tLpgcU9S82phwY3zVtsXG4WjVVC/ RcNCyG0J2ybP+IA8r/jPdINLNm+lsdJKoU6Y19R+BJyAV1uycltUEx4yzxs8Mg/8 lxvg+JcKe94UhUHIQXo3j9lXg7KcFXCVjGBBBpfBn4FfcRmdA+IkgONF3MxWz86J 8jBJdSVi2/CjlteWVQ2pBKEEesjXjT0tX8dbVA2x4KAcWYT5jMMQxDEP+Q2uuKfj NhE4D99CiZwdYgi4JP4+86cTDArj9l17tWR9bmVXgyviFU4o3Go= =R12Y -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmk5+AUACgkQ7ZfpDmKq fjTtEg//VloILc1FvXSuFccnpY8G7rmCkL48q5628VbogfqLc3MSQ8FqlfBw3OkI LqiDAF22/nFcMhtQ9j61cFJ5GrAUF28MIKDl1ol5YEswQgiLxDxFbK2c5uWdYJed 4I5bqU8rs6RTA/5ZZ/MMDe7JIGEYClZhHzT9Hs9vLrg2aOW7vSzXjjuAy7FqUwpX k1m6KQtL6UPl4tkbDY9wLSifDtg6GqfZT9bYtPxxLKc89Mm0tFJP7aXuooELb0/k 1YsCFZDU7OK8ttgAlPbtAebfrFJbk1jKuBQqoqyH59QtA4OegHFjRVPFcHYevJsl FMhA10XEXS1C3T2KC9De9Xypt1aJIVIhtEHz7GjlubZRfgLGb+xAvTsJj2h20TIm mTAaJ9tBdr7TiVRlLdUgWdsLRwrVSOLbFCjL5Fa2+XpTNoowPmDp7YHmFsk+itDH 40fRFvBc842huCIsFbQ1EInjVpuUQqaMb1CmZlNMhJz6DoXEicOoo9iwqjRxZyVt 7NB4AQaqBwAKgvTw7iV4Iw0naWaKhwN9pP2AbnC5cMd3SRMneJ6Sxt4MtA9dqpFB mKIMF9Tlb+twuyOZXezaD/RqJs19gusdFmVlpJbNzez//pYMJ/9LcjB+xz61c5Zf mIPWE0mkzSRvhqca4L3inlC73aTRDp2OEt9+n+AJPnk27BRe5Xs= =1kyi -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmk5+AYACgkQ7ZfpDmKq fjRXzA/9GHRwVUZRXXmlwgpPZDVU5BtB2xrcJVQk3pFLs0J6cz+nUVRtsm3Gz400 qaksn6T+azBX5Lv6pSPYmDtj+cSbCA7vcaLxHh414gKu6SKkNTm566xGM3RIKome odhacZtLvPYpfONIGt0YRgwl6oO+Q1dXuu4aoi2H4jdYrHEjpTFY1Pg1TfRrpM/p JxarI/VUOvuXZHAsJRBJshEc5GcOnaUAzYKr/yAelbdowjW2DLetRhWU0YZ9zgZk w6xaVNvcU0i9fX2Ri0MMiTpo92xzRdZd1WZ8wfU3hqUMfolVSMJuk8Qs/NyYm8v9 DMtiQb0Ewi10Y0YyGUnQi3r6wpKQ2K1D2JVZj5eGLsbTfBpi+3bilJHtxBc05NaK HQyZhhgXSTwLkR4LUcsyTtWdiS9uUB2D18EtfxODWoeJsIcoU2fRPX3zVIn0EjTq YLSrGvbk69xAiyhDQlcYFEUoL6GQb0WbDOz1b1IwRJ6de7YcNkkCAlWTt4qIat65 6OfZURSGURRWd9BBNqF2m1OgaGfv4fn/HJL4TYYaEXATpTUxVoPujxl73In5Mu3O A8zVP2QouGD25RYmoQLdAYMyap9XJIS1HWRNBPAyRC8z5YZE1ptm+L0KzBD9+vwe rTejW79L/QMsu9Orz6Mnptraz6C83q7C1hi7STqwNPd4rE8grV8= =MFmx -----END PGP SIGNATURE-----

1 1

Question about leap-seconds.list expiry
by Marcus van Dam Dec. 11, 2025

Dec. 11, 2025

Hi, I hope this is the appropriate list for questions about the leap-seconds file. It seems the `leap-seconds.list` file hosted on the IANA server [1] is about to expire on 28 December 2025, and its latest update NTP timestamp (01 July 2025) appears to be older than the timestamp on the upstream bulletin [2] (07 July 2025). The obspm.fr servers also appear to host a leap-seconds.list file [3] with an expiry date of 28 June 2026. With the current expiry date approaching, I was wondering if the IANA-hosted file will be updated to have an expiry date in the future. As a side note, the leap-seconds.list file shipped in tzdata on Debian [4] already seems to use the 2026 expiry date. [1] https://data.iana.org/time-zones/tzdb/leap-seconds.list [2] https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat [3] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list [4] https://sources.debian.org/src/tzdata/2025b-0%2Bdeb12u2/leap-seconds.list -- Kind regards Marcus van Dam

3 2

[PROPOSED] Say more clearly that the tz mailing list is public
by Paul Eggert Dec. 10, 2025

Dec. 10, 2025

* CONTRIBUTING, africa, asia, australasia, backzone, europe, * northamerica, southamerica, theory.html, tz-art.html * tz-link.html: Say that the tz mailing list and its archive are public, and that people should not contribute confidential information. --- CONTRIBUTING | 6 +++++- africa | 6 +++--- asia | 6 +++--- australasia | 6 +++--- backzone | 8 ++++---- europe | 8 ++++---- northamerica | 6 +++--- southamerica | 6 +++--- theory.html | 11 ++++++++--- tz-art.html | 7 +++++-- tz-link.html | 12 +++++++++--- 11 files changed, 50 insertions(+), 32 deletions(-) diff --git a/CONTRIBUTING b/CONTRIBUTING index 1f064fa0..c5fa803f 100644 --- a/CONTRIBUTING +++ b/CONTRIBUTING @@ -10,7 +10,8 @@ warning, the data entries do not cover all of civil time before 1970, and undoubtedly errors remain in the code and data. Feel free to fill gaps or fix mistakes, and please email improvements to <tz(a)iana.org> for use in the future. In your email, please give -reliable sources that reviewers can check. +reliable sources that reviewers can check. The mailing list and its +archives are public, so please do not send confidential information. ## Contributing technical changes @@ -84,6 +85,9 @@ If you use Git the following workflow may be helpful: git format-patch main + * Check that the patch files and your email setup contain only + information that you want to make public. + * After reviewing the patch files, send the patches to <tz(a)iana.org> for others to review. diff --git a/africa b/africa index 11738a1e..ec067bee 100644 --- a/africa +++ b/africa @@ -4,9 +4,9 @@ # 2009-05-17 by Arthur David Olson. # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (2018-05-27): # diff --git a/asia b/asia index d3d1059a..dd76bdfc 100644 --- a/asia +++ b/asia @@ -4,9 +4,9 @@ # 2009-05-17 by Arthur David Olson. # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (2019-07-11): # diff --git a/australasia b/australasia index 5cf8f117..e52aab10 100644 --- a/australasia +++ b/australasia @@ -937,9 +937,9 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # NOTES # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (2018-11-18): # diff --git a/backzone b/backzone index dd7a8675..3c7e720a 100644 --- a/backzone +++ b/backzone @@ -2,10 +2,10 @@ # This file is in the public domain. -# This file is by no means authoritative; if you think you know -# better, go ahead and edit it (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# This file is by no means authoritative; if you think you know better, +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # When proposing changes to this file, please use 'git format-patch' # format, either by attaching the resulting .patch file to your email, diff --git a/europe b/europe index 4d7e1f3b..af521710 100644 --- a/europe +++ b/europe @@ -4,9 +4,9 @@ # 2009-05-17 by Arthur David Olson. # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (2017-02-10): # @@ -42,7 +42,7 @@ # <https://www.jstor.org/stable/1774359>. He writes: # "It is requested that corrections and additions to these tables # may be sent to Mr. John Milne, Royal Geographical Society, -# Savile Row, London." Nowadays please email them to tz(a)iana.org. +# Savile Row, London." Nowadays please see the file CONTRIBUTING. # # Byalokoz EL. New Counting of Time in Russia since July 1, 1919. # This Russian-language source was consulted by Vladimir Karpinsky; see diff --git a/northamerica b/northamerica index bb3d1b43..16b79af2 100644 --- a/northamerica +++ b/northamerica @@ -6,9 +6,9 @@ # also includes Central America and the Caribbean # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (1999-03-22): # A reliable and entertaining source about time zones is diff --git a/southamerica b/southamerica index 06fee598..bcd4abdf 100644 --- a/southamerica +++ b/southamerica @@ -4,9 +4,9 @@ # 2009-05-17 by Arthur David Olson. # This file is by no means authoritative; if you think you know better, -# go ahead and edit the file (and please send any changes to -# tz(a)iana.org for general use in the future). For more, please see -# the file CONTRIBUTING in the tz distribution. +# go ahead and edit the file, and please send any changes to +# the public mailing list tz(a)iana.org for general use in the future. +# For more, please see the file CONTRIBUTING in the tz distribution. # From Paul Eggert (2016-12-05): # diff --git a/theory.html b/theory.html index cdc6093a..6e52a929 100644 --- a/theory.html +++ b/theory.html @@ -1584,9 +1584,14 @@ Sources for time on other planets: </section> <footer> - <hr> - This file is in the public domain, so clarified as of 2009-05-17 by - Arthur David Olson. +<hr> +This web page is in the public domain, so clarified as of +2009-05-17 by Arthur David Olson. +<br> +Please send corrections to this web page to the +<a href="mailto:tz@iana.org">time zone mailing list</a>. +The mailing list and its archives are public, +so please do not send confidential information. </footer> </body> </html> diff --git a/tz-art.html b/tz-art.html index 01a00297..3039a86f 100644 --- a/tz-art.html +++ b/tz-art.html @@ -611,13 +611,16 @@ but maybe in your time zone I haven’t finished yet. So stay tuned!” <li><a href="tz-link.html">Time Zone and Daylight Saving Time Data</a></li> </ul> + +<footer> <hr> -<address> This web page is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. <br> Please send corrections to this web page to the <a href="mailto:tz@iana.org">time zone mailing list</a>. -</address> +The mailing list and its archives are public, +so please do not send confidential information. +</footer> </body> </html> diff --git a/tz-link.html b/tz-link.html index 669a3cb8..9267fb6f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -211,7 +211,10 @@ location.</p> The <code><abbr>tz</abbr></code> code and data are by no means authoritative. If you find errors, please email changes to <a href="mailto:tz@iana.org"><code>tz(a)iana.org</code></a>, -the time zone mailing list. See +the time zone mailing list. +The mailing list and its archives are public, +so please do not send confidential information. +See <a href="https://lists.iana.org/postorius/lists/tz.iana.org/">the mailing list’s main page</a> to subscribe or to browse its archive of old messages. <a href="https://tzdata-meta.timtimeonline.com">Metadata for mailing list @@ -283,8 +286,9 @@ collaboration among governments, the time zone database volunteer community, and data distributors downstream. <p> If your government plans to change its time zone boundaries or -daylight saving rules, please send email to <a -href="mailto:tz@iana.org"><code>tz(a)iana.org</code></a> well in advance, +daylight saving rules, please send email as described in +"<a href="#changes">Changes to the <code><abbr>tz</abbr></code> database</a>". +Do this well in advance, as this will lessen confusion and will coordinate updates to many cell phones, computers, and other devices around the world. In your email, please cite the legislation or regulation that specifies @@ -1250,6 +1254,8 @@ This web page is in the public domain, so clarified as of <br> Please send corrections to this web page to the <a href="mailto:tz@iana.org">time zone mailing list</a>. +The mailing list and its archives are public, +so please do not send confidential information. </footer> </body> </html> -- 2.51.0

1 0

An odd juxtaposition...
by Arthur Olson Dec. 10, 2025

Dec. 10, 2025

...of sex appeal and time zones at the Hyattsville, Maryland Mall at Prince George's: a watch kiosk called "Time Zone 2" by a Victoria's Secret store. An image is part of the social media posting linked to below. @dashdashado https://bsky.app/profile/dashdashado.bsky.social/post/3m7ld53qtj22s

3 2

Greenland parliament to vote February on time zone change
by Paul Eggert Dec. 8, 2025

Dec. 8, 2025

Hanna Hviid reported in Sermitsiaq last month[1] (in Danish) that Inatsisartut, Greenland's parliament, plans to debate in February whether to revert the 2023 change to Greenland's clocks. It seems like there's a good chance something will pass. Although the details are unclear, presumably this would affect clocks starting in fall 2026. I found out about this by running across last month's "Iceland’s Old Timezone Controversy Echoes in Greenland"[2], by the Iceland Review's Michael Chapman. [1]: https://www.sermitsiaq.ag/samfund/pele-beskylder-udvalg-for-at-forhale-over… [2]: https://www.icelandreview.com/news/icelands-old-timezone-controversy-echoes…

2 3

Request for Clarification or Alternative Label for “Indian/Mauritius” Time Zone
by James Lai Dec. 4, 2025

Dec. 4, 2025

Hello, I hope you are well. I am writing regarding the naming of the IANA time zone “Indian/Mauritius.” Many users in Mauritius have reported confusion because the word “Indian” is often interpreted as referring to India rather than the Indian Ocean region. This creates misunderstandings when scheduling international meetings, especially on platforms like Zoom, Google Calendar, and others that rely directly on IANA time zone identifiers. I understand that renaming time zones is avoided due to compatibility concerns. However, I would like to kindly ask whether: 1. An alternative label such as “IndianOcean/Mauritius” could be considered, or 2. A documented alias or clarification could be added to help reduce confusion for end users. Even a non-breaking solution (e.g., an alias) would greatly help clarify the intended meaning without disrupting existing systems. Thank you for your time and for maintaining this important global standard. Kind regards, Kind regards, [cid:asset3_0cde460c-bb22-4017-a4dd-b19716304dc9.png] James Lai IT | Head of Operations Intercontinental Trust Limited Level 3, Alexander House, 35 Cybercity, Ebene 72201, Mauritius E: jlai(a)intercontinentaltrust.com<mailto:jlai@intercontinentaltrust.com> W: www.intercontinentaltrust.com<http://www.intercontinentaltrust.com/> T: (230) 403 0800 DID: (230) 403 0869 M: (230) 5258 5889 F: (230) 403 0801 BRN: C07023546 [cid:itl_emailbanner_03.10.25v2_d5878fa8-0af2-4ccb-b63e-55a10f1a1c87.jpg] Intercontinental Trust Ltd is regulated by the Financial Services Commission in Mauritius. If you are not the intended recipient, please advise the sender immediately and delete this message. [cid:facebooklogo_9db4cba5-e3da-4106-9849-2d5d2e6d37db.gif]<https://www.facebook.com/IntercontinentalTrust?fref=ts> [cid:LinkedInlogo_86f1ad59-c943-4f8d-a70a-699b2322ca7e.gif] <http://www.linkedin.com/company/2502998?trk=pro_other_cmpy> [cid:Twitterlogo_3b4b7685-ec4d-4906-8971-931729a1de68.gif] <https://twitter.com/ITLMauritius> Disclaimer<http://intercontinentaltrust.com/disclaimer> Please consider the environment before you print

8 10

backward file for zonenow.tab?
by kirill.gagarski＠gmail.com Nov. 17, 2025

Nov. 17, 2025

Hi. Our software tries to expose a list of supported timezones to an end user for setting up some periodic scheduled task in the UI. Till now we've tried to populate the list of Java supported timezones, filtering out aliases (from backward file). I noticed that zonedata now ships with zonenow.tab file which is exactly what we need for our UI and meets our needs more precisely. Unfortunately it seems quite impossible to migrate old data to this new notation automatically. For example, hte fact that 'Europe/Berlin' is covered by 'Europe/Paris' in zonenow.tab is not mentioned anywhere. Is there a way to determine this fact from tzdata without deep analysis of the rules done by myself? Other simple question: is there a way to know what is "now" in zonenow? Is it defined by the release date of a new version?

4 6

Calendrical Issues Russia section
by Kirill Gagarski Nov. 14, 2025

Nov. 14, 2025

I fully understand that I am trying to engage into a 30 y.o discussion now, but the Russia section in calendars file repeats quite widespread myths about Eternal Calendar with 30th February. I used to believe in that myself, given quite a little information on the internet about the issue. Even Wikipedia spread this myth back in the day. Even the Russian version of Wikipedia spreaded the myth: https://ru.wikipedia.org/w/index.php?title=%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D… Nowadays, Wikipedia is more clean about the issue, providing some source links: https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0… https://en.wikipedia.org/wiki/Soviet_calendar The truth is: - Gregorian calendar was continuously used during the mentioned time - 30th February in USSR is an absolute myth (to be more clear, this is a declined proposal of a new calendar) - Mentioned 5-day weeks and 6-day weeks were in fact an attempt to relabel weekdays (Monday-Sunday) - Relabeling was done in a way, not conflicting with traditional weekdays (they used words like "third day of six-week day" or colors). Traditional names were used in parallel I could not say, the calendar file does not say the truth (after all, it raises doubts in a second quoted message), and all this information is indeed very interesting from a historical point of view, but does not seem relevant to Calendrical Issues. In fact 100 years later no one (unless someone is specifically interested in these weird weekdays) cares if 12th of December of 1937 was "sixth day of six-day week", because it was Sunday at the same time. I'd suggest removing the whole Russia section from this file (you can keep the small note about switching from Julia to Gregorian calendar in 1918), since for the purpose of it it raises nothing but confusion.

2 2

[PROPOSED] Fix unlikely backslash bug in scripts
by Paul Eggert Nov. 12, 2025

Nov. 12, 2025

* tzselect.ksh, workman.sh: Use printf, not echo, if the argument might in theory contain a backslash. --- tzselect.ksh | 9 +++++---- workman.sh | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 7cd8679d..85a8c670 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -145,9 +145,11 @@ do t*) # Undocumented option, used for developer testing. zonetabtype=$OPTARG;; -help) - exec echo "$usage";; + say "$usage" + exit;; -version) - exec echo "tzselect $PKGVERSION$TZVERSION";; + say "tzselect $PKGVERSION$TZVERSION" + exit;; -*) say >&2 "$0: -$opt$OPTARG: unknown option; try '$0 --help'"; exit 1;; *) @@ -516,8 +518,7 @@ while ' ="$distance_table" ) echo >&2 'Please select one of the following timezones,' - echo >&2 'listed roughly in increasing order' \ - "of distance from $coord". + say >&2 "listed roughly in increasing order of distance from $coord." doselect $regions region=$select_result tz=$( diff --git a/workman.sh b/workman.sh index 91621b10..5da55654 100644 --- a/workman.sh +++ b/workman.sh @@ -51,6 +51,6 @@ elif (type nroff && type perl) >/dev/null 2>&1; then } ' else - echo >&2 "$0: please install groff, or mandoc and col" + printf >&2 '%s\n' "$0: please install groff, or mandoc and col" exit 1 fi -- 2.51.0

1 0

Melbourne's Shrine of Remembrance
by Tim Parenti Nov. 11, 2025

Nov. 11, 2025

Earlier this year, Julian O'Shea released a short video detailing a peculiarity about the Shrine of Remembrance in Melbourne, "How Daylight Savings Broke this $24 Million Building": https://www.youtube.com/watch?v=mfzsBMUiGGQ The shrine, originally dedicated in 1934 to honor those who served in World War I, was designed with a small aperture in the roof. Each Remembrance Day (11 November) at 11:00am local time, the position of the sun would be perfectly aligned to shine through the aperture, allowing the light of its rays to fall upon an inscribed stone inside, thus commemorating the hour of the Armistice. The problem? Several decades later, in 1971, Victoria adopted DST, but of course the aperture had been tuned to the position of the sun at 11:00am AEST. So what do you do to preserve this meaningful element of an annual ceremony with important dignitaries, when it's effectively been moved an hour earlier to 11:00am AEDT instead? The answer involves a clever system of mirrors. (And the general public still gets to witness the light following its true path an hour later!) Since this is quite a grand physical representation of how we interact with our timekeeping, I've added this to tz-art.html, as well as a few fixups to unclosed HTML tags nearby. -- Tim Parenti

4 3

Cape Town
by Justin Singh Nov. 11, 2025

Nov. 11, 2025

Hello The Timezone for Cape Town is UTC+01:00 The western Northern Cape and Western Cape differ, however. Everywhere on land west of 22°30′ E effectively experiences year-round daylight saving time because of its location in true UTC+01:00 but still being in South African Standard Time. Sunrise and sunset are thus relatively late in Cape Town, compared to the rest of the country.

6 7

Nunavik to stop changing its clocks after March 2026?
by Paul Eggert Nov. 8, 2025

Nov. 8, 2025

Yesterday’s CBC News report “Nunavimmiut have wound back their clocks for the last time”[1] is so light on details that for now I am merely attaching a draft patch to this email for review, rather than installing the patch into the development repository. I found no announcement of the change at www.makivvik.ca. Although I asked for more details by using the form at <https://www.makivvik.ca/contact/>, these sorts of contact forms often do not work, so if anyone has access to more-authoritative info than the CBC report, please let us know. Among other things, details in the news report make me wonder how likely Makivvik would reconsider its decision before the change would take effect about a year from now. [1]: https://www.cbc.ca/news/canada/north/nunavik-daylight-savings-9.6969650

1 0

Phoenix AZ timezone issue
by akbar＠marketing-qa.com Nov. 5, 2025

Nov. 5, 2025

🧭 Problem Summary Arizona remains one of the few U.S. states that does not observe Daylight Saving Time (DST) since 1968. However, it identifies its time zone as Mountain Standard Time (MST) — which does change to MDT when DST applies elsewhere. Because of this, every spring and fall, Arizona’s effective time alignment shifts: In summer, Arizona matches Pacific Daylight Time (PDT). In winter, it matches Mountain Standard Time (MST). This causes systemic issues in digital calendars, automated scheduling, flight bookings, and cross-state business coordination, requiring frequent manual adjustments. 💡 Recommended Solution Create and declare a dedicated time zone: “Phoenix Standard Time.” This would be a fixed, non-DST time zone officially recognized by IANA (the Internet Assigned Numbers Authority) and major platforms (Microsoft, Apple, Google). All digital devices could use it as a unique time zone identifier that never shifts with DST — eliminating confusion and rescheduling errors. It would function similarly to “UTC+7” year-round but would display as “Phoenix Standard Time (PST)” in software systems. Thank you Akbar Jaffer Akbar Jaffer Office: (415) 335-6950 Mobile: (650) 430-0232 Web: Marketing-QA.com <http://www.marketing-qa.com/> Meeting: Book time W/Akbar <https://calendly.com/ajaffer/> LinkedIn <https://www.linkedin.com/in/akbarjaffer/> | POI Blog <https://pointofintersection.org/>

8 9

How to select zones for a TimeZone picker
by Guillermo Rodriguez Garcia Nov. 3, 2025

Nov. 3, 2025

Hi all, I'm building a TimeZone picker with the following constraints: 1. At least one distinct timezone per country (so that e.g. there is an entry for Atlantic/Reykjavik instead of mapping IS to Africa/Abidjan) 2. Within a country, do not show timezones that currently have identical rules to another timezone in the same country (i.e. historical differences don't matter). Because of (1) I started from zone.tab rather than zone1970.tab. However, I'm not sure how to handle (2). For example, Spain has three zones in zone.tab: Europe/Madrid, Africa/Ceuta, and Atlantic/Canary. But as far as most users are concerned, as of today there are only two timezones in Spain: Madrid and Canary Islands. Ceuta follows Madrid rules, so there should be no need to show this as an option to the user. Another example: the U.S. lists 29 zones, but only 8 are distinct today (ignoring historical changes). So, the question: Any suggestions on how to filter timezones within each country to drop those that as of today are not relevant except for historical differences? Thank you, Guillermo Rodriguez Garcia guille.rodriguez(a)gmail.com

8 17

[PROPOSED] tzfree now preserves errno
by Paul Eggert Nov. 3, 2025

Nov. 3, 2025

* Makefile, NEWS, newtzset.3: Mention this. * localtime.c (FREE_PRESERVES_ERRNO): Default to 1 if 'free' is known to preserve errno, 0 otherwise. (tzfree): Preserve errno if 'free' does not. --- Makefile | 2 ++ NEWS | 2 ++ localtime.c | 15 +++++++++++++++ newtzset.3 | 4 ++++ 4 files changed, 23 insertions(+) diff --git a/Makefile b/Makefile index 0fe8a9f8..0d33fa17 100644 --- a/Makefile +++ b/Makefile @@ -239,6 +239,8 @@ LDLIBS= # -DEPOCH_OFFSET=N if the 'time' function returns a value N greater # than what POSIX specifies, assuming local time is UT. # For example, N is 252460800 on AmigaOS. +# -DFREE_PRESERVES_ERRNO=[01] if the 'free' function munges or preserves errno +# (default is guessed) # -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r # on POSIX platforms predating POSIX.1-2024 # -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' diff --git a/NEWS b/NEWS index 1ed9b2eb..a9b2d321 100644 --- a/NEWS +++ b/NEWS @@ -93,6 +93,8 @@ Unreleased, experimental changes option is incompatible with POSIX.1-2024 and earlier. It also costs CPU time and memory. + tzfree now preserves errno, consistently with POSIX.1-2024 'free'. + tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. diff --git a/localtime.c b/localtime.c index b85941f2..46acf3bd 100644 --- a/localtime.c +++ b/localtime.c @@ -2061,10 +2061,25 @@ tzalloc(char const *name) return sp; } +#ifndef FREE_PRESERVES_ERRNO +# if ((defined _POSIX_VERSION && 202405 <= _POSIX_VERSION) \ + || (defined __GLIBC__ && 2 < __GLIBC__ + (33 <= __GLIBC_MINOR__)) \ + || defined __OpenBSD__ || defined __sun) +# define FREE_PRESERVES_ERRNO 1 +# else +# define FREE_PRESERVES_ERRNO 0 +# endif +#endif + void tzfree(timezone_t sp) { + int err; + if (!FREE_PRESERVES_ERRNO) + err = errno; free(sp); + if (!FREE_PRESERVES_ERRNO) + errno = err; } /* diff --git a/newtzset.3 b/newtzset.3 index 3801ab1b..028cfd25 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -379,6 +379,10 @@ If successful, the function returns a nonnull pointer to the newly allocated object. Otherwise, it returns a null pointer and sets .IR errno . +The +.B tzfree +function does not modify +.IR errno . .SH ERRORS .TP .B EOVERFLOW -- 2.51.0

1 0

[PROPOSED] Improve TZ="/..." security and speed (NetBSD only)
by Paul Eggert Oct. 28, 2025

Oct. 28, 2025

* NEWS: Mention security. * localtime.c (O_REGULAR): Default to 0. (tzloadbody): Open TZif files with O_REGULAR. Suppress unnecessary call to 'stat' if O_REGULAR is present. --- NEWS | 3 +++ localtime.c | 7 +++++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 64d32bf3..1ed9b2eb 100644 --- a/NEWS +++ b/NEWS @@ -40,6 +40,9 @@ Unreleased, experimental changes and reject relative names containing ".." directory components; formerly, only privileged programs did those two things. These changes were inspired by similar behavior in FreeBSD. + On NetBSD, unprivileged programs now use O_REGULAR to check + whether a TZ setting starting with '/' names a regular file, + avoiding a minor security race still present elsewhere. TZ strings taken from tzalloc arguments are now treated with no less caution than TZ strings taken from the environment, as the old undocumented behavior would have been hard to explain. diff --git a/localtime.c b/localtime.c index 0d2d2a93..b85941f2 100644 --- a/localtime.c +++ b/localtime.c @@ -355,6 +355,9 @@ static int openat(int dd, char const *path, int oflag) { unreachable (); } #ifndef O_PATH # define O_PATH 0 #endif +#ifndef O_REGULAR +# define O_REGULAR 0 +#endif #ifndef O_RESOLVE_BENEATH # define O_RESOLVE_BENEATH 0 #endif @@ -900,7 +903,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, register int tzheadsize = sizeof(struct tzhead); int dd = AT_FDCWD; int oflags = (O_RDONLY | O_BINARY | O_CLOEXEC | O_CLOFORK - | O_IGNORE_CTTY | O_NOCTTY); + | O_IGNORE_CTTY | O_NOCTTY | O_REGULAR); int err; struct stat st; st.st_ctime = 0; @@ -927,7 +930,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, continue; else if (issetugid()) return ENOTCAPABLE; - else { + else if (!O_REGULAR) { /* Check for devices, as their mere opening could have unwanted side effects. Though racy, there is no portable way to fix the races. This check is needed -- 2.48.1

1 0

Iana build failures on Windows
by Manuela Friedrich Oct. 28, 2025

Oct. 28, 2025

Hello Paul, I have hit a compile error for zic.c on Windows. Git commit 9e0bf0b42d68b3d9ad0bc7ff70fc92d87f8b40d2 zic.c zic.c(152): error C2081: 'mode_t': name in formal parameter list illegal zic.c(2437): warning C4116: unnamed type definition in parentheses NMAKE : U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\cl.EXE"' : return code '0x2' Stop. Can you please advise? Please do not release a new version with this issue present. Thank you! Regards Manuela Friedrich

4 17

[PROPOSED] Be more like OpenBSD wrt ".."
by Paul Eggert Oct. 25, 2025

Oct. 25, 2025

* localtime.c (tzloadbody): Do not worry about settings like TZ=".." (i.e., trailing ".." component) as the later read will fail anyway. This simplifies the code slightly, and agrees with the security-conscious OpenBSD libc. --- localtime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/localtime.c b/localtime.c index f1a82370..0d2d2a93 100644 --- a/localtime.c +++ b/localtime.c @@ -941,13 +941,13 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, if (relname[0] != '/') { if (!OPENAT_TZDIR || !O_RESOLVE_BENEATH) { - /* Fail if a relative name contains a ".." component, - as such a name could read a file outside TZDIR + /* Fail if a relative name contains a non-terminal ".." component, + as such a name could read a non-directory outside TZDIR when AT_FDCWD and O_RESOLVE_BENEATH are not available. */ char const *component; for (component = relname; component[0]; component++) if (component[0] == '.' && component[1] == '.' - && ((component[2] == '/') | !component[2]) + && component[2] == '/' && (component == relname || component[-1] == '/')) return ENOTCAPABLE; } -- 2.48.1

1 0

[PATCH 1/5] Clarify <sys/auxv.h> vs getauxval
by Paul Eggert Oct. 25, 2025

Oct. 25, 2025

FreeBSD has <sys/auxv.h> but not getauxval, so clarify ifdeffery to reflect this. This doesn’t fix any bugs (since FreeBSD also has issetugid) but makes things clearer. * Makefile, NEWS: Update to match new behavior and fix a few old typos. * localtime.c: Move the <sys/auv.h> code to be closer together. (HAVE_SYS_AUXV_H) [!HAVE_ISSETUGID]: New macro. * private.h (HAVE_GETAUXVAL): Remove. All uses replaced by HAVE_SYS_AUXV_H. --- Makefile | 12 ++++++------ NEWS | 9 +++++---- localtime.c | 25 +++++++++++++++++++------ private.h | 13 ------------- 4 files changed, 30 insertions(+), 29 deletions(-) diff --git a/Makefile b/Makefile index 3b259c80..0fe8a9f8 100644 --- a/Makefile +++ b/Makefile @@ -246,7 +246,6 @@ LDLIBS= # -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) # -DHAVE_FCHMOD=0 if your system lacks the fchmod function # -DHAVE__GENERIC=0 if _Generic does not work* -# -DHAVE_GETAUXVAL=1 if getauxval works, 0 otherwise (default is guessed) # -DHAVE_GETEUID=0 if gete?[ug]id do not work # -DHAVE_GETRANDOM if getrandom works (e.g., GNU/Linux), # -DHAVE_GETRANDOM=0 to avoid using getrandom @@ -258,7 +257,9 @@ LDLIBS= # ctime_r and asctime_r incompatibly with POSIX.1-2017 and earlier # (Solaris when _POSIX_PTHREAD_SEMANTICS is not defined). # -DHAVE_INTTYPES_H=0 if <inttypes.h> does not work*+ -# -DHAVE_ISSETUID=1 if issetugid works, 0 otherwise (default is guessed) +# -DHAVE_ISSETUGID=1 if issetugid works, 0 otherwise (default is guessed) +# If 0, you may also use -DHAVE_SYS_AUXV_H=1 if <sys/auxv.h> works, +# 0 otherwise (default is guessed). # -DHAVE_LINK=0 if your system lacks a link function # -DHAVE_LOCALTIME_R=0 if your system lacks a localtime_r function # -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz @@ -268,8 +269,8 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # variables like 'tzname' required by POSIX # -DHAVE_PWD_H=0 if your system lacks pwd.h, grp.h and corresponding functions -# The following additional options may be needed: -# -Dgid_t=T, -Duid_t=T to define gid_t, uid_t to be type T +# If 0, you may also need -Dgid_t=G -Duid_t=U +# to define gid_t and uid_t to be types G and U. # -DHAVE_SETENV=0 if your system lacks the setenv function # -DHAVE_SETMODE=[01] if your system lacks or has the setmode and getmode # functions (default is guessed) @@ -285,8 +286,7 @@ LDLIBS= # -DHAVE_STRUCT_TIMESPEC=0 if your system lacks struct timespec+ # -DHAVE_SYMLINK=0 if your system lacks the symlink function # -DHAVE_SYS_STAT_H=0 if <sys/stat.h> does not work* -# The following additional option may be needed: -# -Dmode_t=T to define mode_t to be type T +# If 0, you may also need -Dmode_t=M to define mode_t to be type M. # -DHAVE_TZSET=0 if your system lacks a tzset function # -DHAVE_UNISTD_H=0 if <unistd.h> does not work* # -DHAVE_UTMPX_H=0 if <utmpx.h> does not work* diff --git a/NEWS b/NEWS index 37ac9fba..64d32bf3 100644 --- a/NEWS +++ b/NEWS @@ -44,12 +44,13 @@ Unreleased, experimental changes no less caution than TZ strings taken from the environment, as the old undocumented behavior would have been hard to explain. tzset etc. no longer use the 'access' system call to check access; - instead they now use the system calls issetuid, getauxval, + instead they now use the system calls issetugid, getauxval, getresuid/getresgid, and geteuid/getegid/getuid/getgid (whichever first works) to test whether a program is privileged. - Compile with -DHAVE_ISSETUID=[01], -DHAVE_GETAUXVAL=[01], - -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or - disable these system calls' use. + Compile with -DHAVE_SYS_AUXV_H=[01] to enable or disable + <sys/auxv.h> which (if it defines AT_SECURE) enables getauxval, + and compile with -DHAVE_ISSETUGID=[01], -DHAVE_GETRESUID=[01], and + -DHAVE_GETEUID=[01] to enable or disable the other calls' use. The new CFLAGS option -DTZ_CHANGE_INTERVAL=N makes tzset etc. check for TZif file changes if the in-memory data are N seconds diff --git a/localtime.c b/localtime.c index a8c442dd..f2d35813 100644 --- a/localtime.c +++ b/localtime.c @@ -19,10 +19,6 @@ #include "tzfile.h" #include <fcntl.h> -#if HAVE_GETAUXVAL && !HAVE_ISSETUGID -# include <sys/auxv.h> -#endif - #if HAVE_SYS_STAT_H # include <sys/stat.h> # ifndef S_ISREG @@ -366,12 +362,29 @@ static int openat(int dd, char const *path, int oflag) { unreachable (); } # define O_SEARCH 0 #endif -/* Return 1 if the process is privileged, 0 otherwise. */ #if !HAVE_ISSETUGID + +# if !defined HAVE_SYS_AUXV_H && defined __has_include +# if __has_include(<sys/auxv.h>) +# define HAVE_SYS_AUXV_H 1 +# endif +# endif +# ifndef HAVE_SYS_AUXV_H +# if defined __GLIBC__ && 2 < __GLIBC__ + (19 <= __GLIBC_MINOR__) +# define HAVE_SYS_AUXV_H 1 +# else +# define HAVE_SYS_AUXV_H 0 +# endif +# endif +# if HAVE_SYS_AUXV_H +# include <sys/auxv.h> +# endif + +/* Return 1 if the process is privileged, 0 otherwise. */ static int issetugid(void) { -# if HAVE_GETAUXVAL && defined AT_SECURE +# if HAVE_SYS_AUXV_H && defined AT_SECURE unsigned long val; errno = 0; val = getauxval(AT_SECURE); diff --git a/private.h b/private.h index 8d3d6404..4daa4864 100644 --- a/private.h +++ b/private.h @@ -294,19 +294,6 @@ extern int optind; # endif #endif -#if !defined HAVE_GETAUXVAL && defined __has_include -# if __has_include(<sys/auxv.h>) -# define HAVE_GETAUXVAL 1 -# endif -#endif -#ifndef HAVE_GETAUXVAL -# if defined __GLIBC__ && 2 < __GLIBC__ + (19 <= __GLIBC_MINOR__) -# define HAVE_GETAUXVAL 1 -# else -# define HAVE_GETAUXVAL 0 -# endif -#endif - #ifndef HAVE_ISSETUGID # if (defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ || (defined __linux__ && !defined __GLIBC__) /* Android, musl, etc. */ \ -- 2.51.0

1 4

[PROPOSED] Shorten GCC_INSTRUMENT à la GCC 14
by Paul Eggert Oct. 25, 2025

Oct. 25, 2025

* Makefile (GCC_INSTRUMENT): Switch from -fsanitize-undefined-trap-on-error to its shorter alias -fsanitize-trap=all, introduced in GCC 14. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index f57042df..3b259c80 100644 --- a/Makefile +++ b/Makefile @@ -380,7 +380,7 @@ LDLIBS= # Select instrumentation via "make GCC_INSTRUMENT='whatever'". GCC_INSTRUMENT = \ -fsanitize=undefined -fsanitize-address-use-after-scope \ - -fsanitize-undefined-trap-on-error -fstack-protector + -fsanitize-trap=all -fstack-protector # Omit -fanalyzer from GCC_DEBUG_FLAGS, as it makes GCC too slow. GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ $(GCC_INSTRUMENT) \ -- 2.51.0

1 0

[PROPOSED 0/3] zic options -D, -m, and -u from FreeBSD
by Paul Eggert Oct. 24, 2025

Oct. 24, 2025

This thread contains proposed patches to add support for the zic options -D, -m, and -u, which have been in FreeBSD zic for many years. The implementation differs from that of FreeBSD, to fix some unlikely security races. I installed these patches in the development repository on GitHub. Paul Eggert (3): New zic option -D, inspired by FreeBSD New zic option -m, inspired by FreeBSD New zic option -u, inspired by FreeBSD Makefile | 8 ++ NEWS | 2 + zic.8 | 32 +++++++ zic.c | 259 +++++++++++++++++++++++++++++++++++++++++++++++++++++-- 4 files changed, 293 insertions(+), 8 deletions(-) -- 2.48.1

2 5

Possible timezone change in Argentina (starting in April?)
by Mariano Absatz - el Baby Oct. 24, 2025

Oct. 24, 2025

Hi, back here after 12+ years for a heads up... There is a Law proposal approved by the Cámara de Diputados (equivalent of the House) but yet to be approved in the Senate regarding Argentina's timezone. Argentina is currently in UTC-3 with no DST. The proposal establishes the Official Time for the whole country as UTC-4 (which is geographically more accurate), with a DST of UTC-3. The DST would start at 00:00 on the first April Sunday and would end at 00:00 on the first September Sunday. The Executive is authorized to modify these dates and to coordinate with other countries of MERCOSUR to apply changes on the same moment. This is just a heads up, since the Senate did not approve or modify the proposal. If this is approved and enacted before April 2026, we can assume the current status is DST and at 00:00 Sunday April 5th 2026 we would be moving the clock back to 23:00 Saturday April 4th. I'll keep you posted as this evolves, but don't hold your breath since on October 26th there are Legislative Elections (midterm), and half of the House and one third of the Senate will change. The new legislators will take office on December 10th. By the end of December the ordinary session of Congress ends; it may be extended by the Executive Branch, but there is no certainty about which bills can be discussed. References (all in Spanish): * Law proposal (official Cámara de Diputados site): https://www.hcdn.gob.ar/diputados/jcobos/proyecto.html?exp=1110-D-2024 (click on the "Ver documento original" button) * Status in the Senate: https://www.senado.gob.ar/parlamentario/comisiones/verExp/14.25/CD/PL (click on the "Texto Original" button for the signed proposal sent from the Cámara de Diputados; click on the "Trámite Legislativo" button for the process status in the Senate) * Brief article about the proposal on a reputed fact checking site: https://chequeado.com/el-explicador/cambio-de-huso-horario-en-la-argentina-… -- Mariano Absatz - el Baby www.clueless.ar

3 3

[PROPOSED 1/2] Refactor duplicate duplicate-option code
by Paul Eggert Oct. 24, 2025

Oct. 24, 2025

* zic.c (duplicate_options): New function. (main): Use it. --- zic.c | 73 +++++++++++++++++++---------------------------------------- 1 file changed, 23 insertions(+), 50 deletions(-) diff --git a/zic.c b/zic.c index 67bcaa43..34e7d91c 100644 --- a/zic.c +++ b/zic.c @@ -708,6 +708,13 @@ close_file(FILE *stream, char const *dir, char const *name, } } +ATTRIBUTE_NORETURN static void +duplicate_options(char const *opt) +{ + fprintf(stderr, _("%s: More than one %s option specified\n"), progname, opt); + exit(EXIT_FAILURE); +} + ATTRIBUTE_NORETURN static void usage(FILE *stream, int status) { @@ -1063,73 +1070,39 @@ main(int argc, char **argv) error(_("invalid option: -b '%s'"), optarg); break; case 'd': - if (directory == NULL) - directory = optarg; - else { - fprintf(stderr, - _("%s: More than one -d option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (directory) + duplicate_options("-d"); + directory = optarg; break; case 'l': - if (lcltime == NULL) - lcltime = optarg; - else { - fprintf(stderr, - _("%s: More than one -l option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (lcltime) + duplicate_options("-l"); + lcltime = optarg; break; case 'p': - if (psxrules == NULL) - psxrules = optarg; - else { - fprintf(stderr, - _("%s: More than one -p option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (psxrules) + duplicate_options("-p"); + psxrules = optarg; break; case 't': - if (tzdefault != NULL) { - fprintf(stderr, - _("%s: More than one -t option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (tzdefault) + duplicate_options("-t"); tzdefault = optarg; break; case 'y': warning(_("-y ignored")); break; case 'L': - if (leapsec == NULL) - leapsec = optarg; - else { - fprintf(stderr, - _("%s: More than one -L option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (leapsec) + duplicate_options("-L"); + leapsec = optarg; break; case 'v': noise = true; break; case 'r': - if (timerange_given) { - fprintf(stderr, - _("%s: More than one -r option" - " specified\n"), - progname); - return EXIT_FAILURE; - } + if (timerange_given) + duplicate_options("-r"); if (! timerange_option(optarg)) { fprintf(stderr, _("%s: invalid time range: %s\n"), -- 2.48.1

1 1

South Africa Daylight Saving Time
by Saras Sing Oct. 21, 2025

Oct. 21, 2025

https://www.timeanddate.com/time/change/south-africa?year=1942 https://www.timeanddate.com/time/change/south-africa?year=1944 https://www.timeanddate.com/time/change/south-africa Hello South Africa has Daylight Saving Time every year from September to March South African Daylight Saving Time starts at every first Sunday of September from GMT/UTC+02:00 00:00 to 01:00 to GMT/UTC+03:00 South African Daylight Saving Time ends at every last Sunday of March from GMT/UTC+03:00 01:00 to 00:00 back to South Africa Standard Time GMT/UTC+02:00 Thank you

5 4

[PROPOSED 1/3] zic now uses is_digit
by Paul Eggert Oct. 18, 2025

Oct. 18, 2025

Refactor zic.c to use is_digit like others use. * zic.c (is_digit): New static function, copied from localtime.c and from zdump.c. It’s too bad we can’t avoid duplication by putting this into private.h, because gcc -Wunused-function would then complain about it. Perhaps ‘inline’ would pacify gcc but then we’d have to port ‘inline’ to ancient compilers and anyway ‘inline’ is supposed to be just a performance hint which is not needed here. --- zic.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 39e1e2bc..30426621 100644 --- a/zic.c +++ b/zic.c @@ -229,6 +229,13 @@ static bool rulesub(struct rule * rp, const char * dayp, const char * timep); static zic_t tadd(zic_t t1, zic_t t2); +/* Is C an ASCII digit? */ +static bool +is_digit(char c) +{ + return '0' <= c && c <= '9'; +} + /* Bound on length of what %z can expand to. */ enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; @@ -1852,7 +1859,7 @@ gethms(char const *string, char const *errstring) &hh, &hhx, &mm, &mmx, &ss, &ssx, &tenths, &xr, &xs)) { default: ok = false; break; case 8: - ok = '0' <= xr && xr <= '9'; + ok = is_digit(xr); ATTRIBUTE_FALLTHROUGH; case 7: ok &= ssx == '.'; @@ -3952,7 +3959,7 @@ newabbr(const char *string) cp = string; mp = NULL; - while (is_alpha(*cp) || ('0' <= *cp && *cp <= '9') + while (is_alpha(*cp) || is_digit(*cp) || *cp == '-' || *cp == '+') ++cp; if (noise && cp - string < 3) -- 2.51.0

1 2

[PROPOSED] New compile-time option THREAD_TM_MULTI
by Paul Eggert Oct. 14, 2025

Oct. 14, 2025

* Makefile, NEWS: Mention it. * localtime.c (THREAD_TM_MULTI): Default to 0. The remaining changes affect only the THREAD_TM_MULTI case. (enum tm_multi): New enum. (N_TM_MULTI): New constant. (tm_multi_key, tm_multi_key_err): New static vars. (tm_multi): New static function. (localtime, gmtime, offtime): Use it. --- Makefile | 8 ++++++++ NEWS | 9 +++++++++ localtime.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 70 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 8939869a..b172542a 100644 --- a/Makefile +++ b/Makefile @@ -316,6 +316,14 @@ LDLIBS= # This can improve paralellism and thus save real time # if many threads call tzcode functions simultaneously. # It also costs CPU time and thus energy. +# -DTHREAD_TM_MULTI to have gmtime, localtime, and offtime +# return different struct tm * addresses in different threads. +# This supports unportable programs that call +# gmtime/localtime/offtime when they should call +# gmtime_r/localtime_r/offtime_r to avoid races. +# Because the corresponding storage is freed on thread exit, +# this option is incompatible with POSIX.1-2024 and earlier. +# It also costs CPU time and memory. # -Dtime_tz=\"T\" to use T as the time_t type, rather than the system time_t # This is intended for internal use only; it mangles external names. # -DTZ_CHANGE_INTERVAL=N if functions depending on TZ should check diff --git a/NEWS b/NEWS index 5bfb7bb4..46bf48ed 100644 --- a/NEWS +++ b/NEWS @@ -80,6 +80,15 @@ Unreleased, experimental changes rarely changing and many threads call tzcode simultaneously. It costs more CPU time and energy. + The new CFLAGS option -TTHREAD_TM_MULTI causes localtime to return + a pointer to thread-specific memory, as FreeBSD does, instead of + to the same memory in all threads. This supports unportable + programs that incorrectly use localtime instead of localtime_r. + This option affects gmtime and offtime similarly to localtime. + Because the corresponding storage is freed on thread exit, this + option is incompatible with POSIX.1-2024 and earlier. It also + costs CPU time and memory. + tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. diff --git a/localtime.c b/localtime.c index 1191f810..709b954c 100644 --- a/localtime.c +++ b/localtime.c @@ -52,6 +52,10 @@ struct stat { char st_ctime, st_dev, st_ino; } # define THREAD_RWLOCK 0 #endif +#ifndef THREAD_TM_MULTI +# define THREAD_TM_MULTI 0 +#endif + #if THREAD_SAFE # include <pthread.h> @@ -171,6 +175,52 @@ once(once_t *once_control, void (*init_routine)(void)) #endif } +enum tm_multi { LOCALTIME_TM_MULTI, GMTIME_TM_MULTI, OFFTIME_TM_MULTI }; + +#if THREAD_SAFE && THREAD_TM_MULTI + +enum { N_TM_MULTI = OFFTIME_TM_MULTI + 1 }; +static pthread_key_t tm_multi_key; +static int tm_multi_key_err; + +static void +tm_multi_key_init(void) +{ + tm_multi_key_err = pthread_key_create(&tm_multi_key, free); +} + +#endif + +/* Return TMP, or a thread-specific struct tm * selected by WHICH. */ +static struct tm * +tm_multi(struct tm *tmp, ATTRIBUTE_MAYBE_UNUSED enum tm_multi which) +{ +#if THREAD_SAFE && THREAD_TM_MULTI + /* It is OK to check is_threaded() separately here; even if it + returns a different value in other places in the caller, + this function's behavior is still valid. */ + if (is_threaded()) { + /* Try to get a thread-specific struct tm *. + Fall back on TMP if this fails. */ + static pthread_once_t tm_multi_once = PTHREAD_ONCE_INIT; + pthread_once(&tm_multi_once, tm_multi_key_init); + if (!tm_multi_key_err) { + struct tm *p = pthread_getspecific(tm_multi_key); + if (!p) { + p = malloc(N_TM_MULTI * sizeof *p); + if (p && pthread_setspecific(tm_multi_key, p) != 0) { + free(p); + p = NULL; + } + } + if (p) + return &p[which]; + } + } +#endif + return tmp; +} + /* Unless intptr_t is missing, pacify gcc -Wcast-qual on char const * exprs. Use this carefully, as the casts disable type checking. This is a macro so that it can be used in static initializers. */ @@ -2156,7 +2206,7 @@ localtime(const time_t *timep) # if !SUPPORT_C89 static struct tm tm; # endif - return localtime_tzset(timep, &tm, true); + return localtime_tzset(timep, tm_multi(&tm, LOCALTIME_TM_MULTI), true); } struct tm * @@ -2208,7 +2258,7 @@ gmtime(const time_t *timep) # if !SUPPORT_C89 static struct tm tm; # endif - return gmtime_r(timep, &tm); + return gmtime_r(timep, tm_multi(&tm, GMTIME_TM_MULTI)); } # if STD_INSPIRED @@ -2229,7 +2279,7 @@ offtime(time_t const *timep, long offset) # if !SUPPORT_C89 static struct tm tm; # endif - return offtime_r(timep, offset, &tm); + return offtime_r(timep, offset, tm_multi(&tm, OFFTIME_TM_MULTI)); } # endif -- 2.48.1

1 0

[PROPOSED 1/3] Define fullname only if needed
by Paul Eggert Oct. 14, 2025

Oct. 14, 2025

* localtime.c (union local_storage): Define fullname member only if needed. This saves space on unlikely platforms where sizeof (struct file_analysis) < PATH_MAX, and is closer to FreeBSD. (tzloadbody): Mention fullname only if declared. --- localtime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index a78962a6..c9836b2d 100644 --- a/localtime.c +++ b/localtime.c @@ -771,7 +771,7 @@ union local_storage { struct state st; } u; -#ifdef PATH_MAX +#if defined PATH_MAX && !OPENAT_TZDIR && !SUPPRESS_TZDIR /* The name of the file to be opened. */ char fullname[PATH_MAX]; #endif @@ -890,7 +890,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, cp = mempcpy(lsp, tzdirslash, tzdirslashlen); cp = mempcpy(cp, name, namelen); *cp = '\0'; -#ifdef PATH_MAX +#if defined PATH_MAX && !OPENAT_TZDIR && !SUPPRESS_TZDIR name = lsp->fullname; #else name = (char *) lsp; -- 2.48.1

1 2

[PROPOSED 1/2] Simplify function parameter decl style
by Paul Eggert Oct. 14, 2025

Oct. 14, 2025

* localtime.c (time2sub, time2, time1): Use simpler style for declaring function parameters. Although this style has worked since C89, I didn’t know about it until reading Jens Gustedt’s book Modern C. Switching to this style now can simplify future future changes that also use a functional programming style. --- localtime.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/localtime.c b/localtime.c index 63b8ea0a..24972b20 100644 --- a/localtime.c +++ b/localtime.c @@ -2442,8 +2442,8 @@ mktmcpy(struct tm *dest, struct tm const *src) static time_t time2sub(struct tm *const tmp, - struct tm *(*funcp)(struct state const *, time_t const *, - int_fast32_t, struct tm *), + struct tm *funcp(struct state const *, time_t const *, + int_fast32_t, struct tm *), struct state const *sp, const int_fast32_t offset, bool *okayp, @@ -2661,8 +2661,8 @@ label: static time_t time2(struct tm * const tmp, - struct tm *(*funcp)(struct state const *, time_t const *, - int_fast32_t, struct tm *), + struct tm *funcp(struct state const *, time_t const *, + int_fast32_t, struct tm *), struct state const *sp, const int_fast32_t offset, bool *okayp) @@ -2680,8 +2680,8 @@ time2(struct tm * const tmp, static time_t time1(struct tm *const tmp, - struct tm *(*funcp)(struct state const *, time_t const *, - int_fast32_t, struct tm *), + struct tm *funcp(struct state const *, time_t const *, + int_fast32_t, struct tm *), struct state const *sp, const int_fast32_t offset) { -- 2.48.1

1 1

[PROPOSED] Port recent PATH_MAX change to strict C23
by Paul Eggert Oct. 14, 2025

Oct. 14, 2025

* localtime.c (tzdirslashlen): Now an enum, not a const size_t, as strict C23 requires this for the static_assert that uses tzdirslashlen when PATH_MAX is defined. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 3f3bdce5..ec13ed71 100644 --- a/localtime.c +++ b/localtime.c @@ -676,7 +676,7 @@ union input_buffer { ATTRIBUTE_NONSTRING #endif static char const tzdirslash[sizeof TZDIR + OPENAT_TZDIR] = TZDIR "/"; -static size_t const tzdirslashlen = sizeof TZDIR; +enum { tzdirslashlen = sizeof TZDIR }; /* Local storage needed for 'tzloadbody'. */ union local_storage { -- 2.48.1

3 5

[PROPOSED 1/2] Optionally use read-write locks instead of mutexes
by Paul Eggert Oct. 13, 2025

Oct. 13, 2025

This avoids bottlenecks when many threads access local time but no thread is changing TZ. It costs CPU time and energy. * Makefile, NEWS: Mention this. * localtime.c (THREAD_RWLOCK): New macro, defaulting to 0. (locallock) [THREAD_RWLOCK]: Now of type pthread_rwlock_t, not pthread_mutex_t. All uses changed. (rd2wrlock): New function. (tzset_unlocked): If THREAD_RWLOCK, upgrade the read lock to a write lock if needed. (tzset_unlocked, gmtcheck): Upgrade the read to a write lock in the unlikely case where writing is needed. --- Makefile | 5 +++ NEWS | 5 +++ localtime.c | 100 +++++++++++++++++++++++++++++++++++++--------------- 3 files changed, 82 insertions(+), 28 deletions(-) diff --git a/Makefile b/Makefile index 85c2c50b..c2c82c3a 100644 --- a/Makefile +++ b/Makefile @@ -304,6 +304,11 @@ LDLIBS= # -DTHREAD_SAFE to make localtime.c thread-safe, as POSIX requires; # not needed by the main-program tz code, which is single-threaded. # Append other compiler flags as needed, e.g., -pthread on GNU/Linux. +# The following option can also be used: +# -DTHREAD_RWLOCK to use read-write locks intead of mutexes. +# This can improve paralellism and thus save real time +# if many threads call tzcode functions simultaneously. +# It also costs CPU time and thus energy. # -Dtime_tz=\"T\" to use T as the time_t type, rather than the system time_t # This is intended for internal use only; it mangles external names. # -DTZ_CHANGE_INTERVAL=N if functions depending on TZ should check diff --git a/NEWS b/NEWS index 64d9336d..8ba97ab4 100644 --- a/NEWS +++ b/NEWS @@ -68,6 +68,11 @@ Unreleased, experimental changes transition begun in release 96k, which removed spaces in tzdata because the spaces break time string parsers. + The new CFLAGS option -DTHREAD_RWLOCK uses read-write locks, as + macOS does, instead of mutexes. This saves real time when TZ is + rarely changing and many threads call tzcode simultaneously. + It costs more CPU time and energy. + tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. diff --git a/localtime.c b/localtime.c index ec13ed71..3a38ef04 100644 --- a/localtime.c +++ b/localtime.c @@ -44,16 +44,39 @@ struct stat { char st_ctime, st_dev, st_ino; } # define st_ctim st_ctimespec #endif +#ifndef THREAD_RWLOCK +# define THREAD_RWLOCK 0 +#endif + #if defined THREAD_SAFE && THREAD_SAFE # include <pthread.h> +# if THREAD_RWLOCK +static pthread_rwlock_t locallock = PTHREAD_RWLOCK_INITIALIZER; +static int lock(void) { return pthread_rwlock_rdlock(&locallock); } +static void unlock(void) { pthread_rwlock_unlock(&locallock); } +# else static pthread_mutex_t locallock = PTHREAD_MUTEX_INITIALIZER; static int lock(void) { return pthread_mutex_lock(&locallock); } static void unlock(void) { pthread_mutex_unlock(&locallock); } +# endif #else static int lock(void) { return 0; } static void unlock(void) { } #endif +/* Upgrade a read lock to a write lock. + Return 0 on success, an errno value otherwise. */ +static int +rd2wrlock(void) +{ +# if THREAD_RWLOCK + unlock(); + return pthread_rwlock_wrlock(&locallock); +# else + return 0; +# endif +} + /* Unless intptr_t is missing, pacify gcc -Wcast-qual on char const * exprs. Use this carefully, as the casts disable type checking. This is a macro so that it can be used in static initializers. */ @@ -1733,38 +1756,55 @@ zoneinit(struct state *sp, char const *name, char tzloadflags) } /* Like tzset(), but in a critical section. + If THREAD_RWLOCK the caller has a read lock, + and this function might ugrade it to a write lock. If tz_change_interval is positive the time is NOW; otherwise ignore NOW. */ static void tzset_unlocked(monotime_t now) { - char const *name = getenv("TZ"); - struct state *sp = lclptr; - char tzloadflags = TZLOAD_FROMENV | TZLOAD_TZSTRING; - size_t namelen = sizeof lcl_TZname + 1; /* placeholder for no name */ - - if (name) { - namelen = strnlen(name, sizeof lcl_TZname); - - /* Abbreviate a string like "/usr/share/zoneinfo/America/Los_Angeles" - to its shorter equivalent "America/Los_Angeles". */ - if (!SUPPRESS_TZDIR && tzdirslashlen < namelen - && memcmp(name, tzdirslash, tzdirslashlen) == 0) { - char const *p = name + tzdirslashlen; - while (*p == '/') - p++; - if (*p && *p != ':') { - name = p; - namelen = strnlen(name, sizeof lcl_TZname); - tzloadflags |= TZLOAD_TZDIR_SUB; + char const *name; + struct state *sp; + char tzloadflags; + size_t namelen; + bool writing = false; + + for (;;) { + name = getenv("TZ"); + sp = lclptr; + tzloadflags = TZLOAD_FROMENV | TZLOAD_TZSTRING; + namelen = sizeof lcl_TZname + 1; /* placeholder for no name */ + + if (name) { + namelen = strnlen(name, sizeof lcl_TZname); + + /* Abbreviate a string like "/usr/share/zoneinfo/America/Los_Angeles" + to its shorter equivalent "America/Los_Angeles". */ + if (!SUPPRESS_TZDIR && tzdirslashlen < namelen + && memcmp(name, tzdirslash, tzdirslashlen) == 0) { + char const *p = name + tzdirslashlen; + while (*p == '/') + p++; + if (*p && *p != ':') { + name = p; + namelen = strnlen(name, sizeof lcl_TZname); + tzloadflags |= TZLOAD_TZDIR_SUB; + } } } + + if ((tz_change_interval <= 0 ? tz_change_interval < 0 : fresh_tzdata(now)) + && (name + ? 0 < lcl_is_set && strcmp(lcl_TZname, name) == 0 + : lcl_is_set < 0)) + return; + + if (!THREAD_RWLOCK || writing) + break; + if (rd2wrlock() != 0) + return; + writing = true; } - if ((tz_change_interval <= 0 ? tz_change_interval < 0 : fresh_tzdata(now)) - && (name - ? 0 < lcl_is_set && strcmp(lcl_TZname, name) == 0 - : lcl_is_set < 0)) - return; # if ALL_STATE if (! sp) lclptr = sp = malloc(sizeof *lclptr); @@ -1829,12 +1869,16 @@ gmtcheck(void) if (lock() != 0) return; if (! gmt_is_set) { + if (rd2wrlock() != 0) + return; + if (!THREAD_RWLOCK || !gmt_is_set) { #if ALL_STATE - gmtptr = malloc(sizeof *gmtptr); + gmtptr = malloc(sizeof *gmtptr); #endif - if (gmtptr) - gmtload(gmtptr); - gmt_is_set = true; + if (gmtptr) + gmtload(gmtptr); + gmt_is_set = true; + } } unlock(); } -- 2.51.0

1 1

[PROPOSED] Port better to platforms lacking mempcpy
by Paul Eggert Oct. 13, 2025

Oct. 13, 2025

* private.h (mempcpy) [!HAVE_MEMPCPY]: Args are pointer to void, not pointer to char, for compatibility with glibc. --- private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/private.h b/private.h index f6f12aa2..befa6db1 100644 --- a/private.h +++ b/private.h @@ -844,7 +844,7 @@ extern char **environ; #endif #if !HAVE_MEMPCPY static void * -mempcpy(char *restrict s1, char const *restrict s2, size_t n) +mempcpy(void *restrict s1, void const *restrict s2, size_t n) { char *p = memcpy(s1, s2, n); return p + n; -- 2.51.0

1 0

[PROPOSED 1/3] tzset sets errno if lock fails
by Paul Eggert Oct. 10, 2025

Oct. 10, 2025

* localtime.c (tzset): Set errno if the lock fails. This should never happen, but if it does the least we can do is set errno, as other functions do. --- localtime.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 54db0ab7..ef094560 100644 --- a/localtime.c +++ b/localtime.c @@ -1788,8 +1788,11 @@ void tzset(void) { monotime_t now = get_monotonic_time(); - if (lock() != 0) + int err = lock(); + if (err != 0) { + errno = err; return; + } tzset_unlocked(now); unlock(); } -- 2.51.0

1 3

[PROPOSED 1/2] Simplify port to NetBSD struct __state
by Paul Eggert Oct. 8, 2025

Oct. 8, 2025

NetBSD uses ‘struct __state’ where tzcode uses ‘struct state’. tzcode 2014g worked around this by a tricky #define and #undef of the relevant names. However, as I recall, this was motivated by an old compatibility issue as to whether the functions would take pointer-to-const or plain pointer. That issue has been resolved in favor of the latter (which is what NetBSD did all along, despite its attempt to do the former), so use a less-tricky workaround similar to what NetBSD libc is already using. * private.h (localtime_rz, mktime_z, posix2time_z, time2posix_z) (timezone_t, tzalloc, tzfree): Do not #define and #undef. (state) [NETBSD_INSPIRED && _NETBSD_SOURCE]: New macro. --- private.h | 28 +++++++--------------------- 1 file changed, 7 insertions(+), 21 deletions(-) diff --git a/private.h b/private.h index 23f1d9fb..4599d0b9 100644 --- a/private.h +++ b/private.h @@ -194,30 +194,15 @@ ** Nested includes */ -/* Avoid clashes with NetBSD by renaming NetBSD's declarations. - If defining the 'timezone' variable, avoid a clash with FreeBSD's +/* If defining the 'timezone' variable, avoid a clash with FreeBSD's 'timezone' function by renaming its declaration. */ -#define localtime_rz sys_localtime_rz -#define mktime_z sys_mktime_z -#define posix2time_z sys_posix2time_z -#define time2posix_z sys_time2posix_z #if defined USG_COMPAT && USG_COMPAT == 2 # define timezone sys_timezone #endif -#define timezone_t sys_timezone_t -#define tzalloc sys_tzalloc -#define tzfree sys_tzfree #include <time.h> -#undef localtime_rz -#undef mktime_z -#undef posix2time_z -#undef time2posix_z #if defined USG_COMPAT && USG_COMPAT == 2 # undef timezone #endif -#undef timezone_t -#undef tzalloc -#undef tzfree #include <stddef.h> @@ -920,15 +905,16 @@ time_t posix2time(time_t); #endif /* -** Define functions that are ABI compatible with NetBSD but have -** better prototypes. NetBSD 6.1.4 defines a pointer type timezone_t -** and labors under the misconception that 'const timezone_t' is a -** pointer to a constant. This use of 'const' is ineffective, so it -** is not done here. What we call 'struct state' NetBSD calls +** Define functions that are ABI compatible with NetBSD. +** What we call 'struct state' NetBSD calls ** 'struct __state', but this is a private name so it doesn't matter. */ #if NETBSD_INSPIRED +# ifdef _NETBSD_SOURCE +# define state __state +# else typedef struct state *timezone_t; +# endif struct tm *localtime_rz(timezone_t restrict, time_t const *restrict, struct tm *restrict); time_t mktime_z(timezone_t restrict, struct tm *restrict); -- 2.51.0

1 1

[PROPOSED] Support FreeBSD-style TZif polling
by Paul Eggert Oct. 7, 2025

Oct. 7, 2025

I installed the attached proposed patch, which adds a tzcode option to periodically poll the TZif file to see whether it changed. You can enable this option by compiling with -DTZ_CHANGE_INTERVAL=61 (or choose your own favorite polling interval instead of 61 seconds). The option affects localtime and other functions whose behavior depends on the TZ environment variable (or its absence); it does not affect tzalloc-related functions. This patch affects tzcode's behavior only if you compile with the new option. The remaining major difference between the functionalities of tzcode and FreeBSD is FreeBSD's support for calling localtime (not localtime_r) from multiple threads. I plan to take a look at that some time soon, with the idea of adding that as another tzcode option. While preparing this patch I noticed some issues in FreeBSD localtime.c, noted below. The attached patch addresses these issues. * A bug can occur in the first minute after reboot, where FreeBSD’s tzdata_is_fresh assumes that since the monotonic clock is less than 61, the cache must be fresh. * Prefer CLOCK_MONOTONIC_COARSE aka CLOCK_MONOTONIC_FAST if available, as its precision suffices here and it should be more efficient than CLOCK_MONOTONIC. * When checking the file timestamp, the code should not fail merely because fstat fails due to EOVERFLOW. Instead, it should assume the file has changed, as this results in better behavior for the user. * When checking the file timestamp the code should not use strlcpy to copy its name. The strlcpy could silently truncate the name in the unlikely case where a relative file name is shorter than PATH_MAX but the absolute file name is not. More importantly, the file contents are what matter here, and since the file name does not matter there is no need to copy it. * It’s a bit better to check st_ctim, not just st_ctime, as st_ctim has subsecond resolution and is more likely to avoid false matches on platforms with dicey st_dev or st_ino. * For efficiency do not bother checking st_mtim/st_mtime, as st_ctim is updated whenever st_mtim is. * For efficiency do not call fstat twice in the unlikely case where TZ is an absolute pathname. * tzdata_is_fresh is poorly named, as it returns 0 if the cache is fresh, 1 if not. And as a nit, in traditional English, “data” is a plural word. The attached patch uses a function fresh_tzdata instead, with the more common interpretation of true and false. * The attached patch ports to platforms with 32-bit time_t and without tm_gmtoff. On these platforms, strftime.c includes localtime.c and localtime.h uses ‘#define time_t timex_t’. For this reason, fresh_tzdata cannot use time_t (which might be timex_t); it needs to use the underlying system time_t. * The attached patch ports to platforms lacking <sys/stat.h>, struct timespec, clock_gettime, or CLOCK_MONOTONIC/CLOCK_MONOTONIC_COARSE.

4 13

[PROPOSED] Port to -DHAVE_SYS_STAT_H=0 -DHAVE_POSIX_DECLS=0
by Paul Eggert Oct. 3, 2025

Oct. 3, 2025

This is mostly for testing that the code still might work on platforms lacking <sys/stat.h>. * zic.c [!HAVE_POSIX_DECLS && !mkdir]: Declare mkdir. [!HAVE_POSIX_DECLS && S_IWGRP]: Declare umask. --- zic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/zic.c b/zic.c index e78dfd47..109dbef8 100644 --- a/zic.c +++ b/zic.c @@ -148,6 +148,12 @@ struct zone { extern int getopt(int argc, char * const argv[], const char * options); extern int link(const char * target, const char * linkname); +# ifndef mkdir +extern int mkdir(char const *, mode_t); +# endif +# ifdef S_IWGRP +extern mode_t umask(mode_t); +# endif extern char * optarg; extern int optind; #endif -- 2.48.1

1 0

[PROPOSED 1/3] Pacify GCC 15 -Wunterminated-string-initialization
by Paul Eggert Oct. 3, 2025

Oct. 3, 2025

* private.h (ATTRIBUTE_NONSTRING): New macro. * localtime.c (tzdirslash) [!OPENAT_TZDIR]: Use it. --- localtime.c | 3 +++ private.h | 6 ++++++ 2 files changed, 9 insertions(+) diff --git a/localtime.c b/localtime.c index 186c7bf3..8ef529d5 100644 --- a/localtime.c +++ b/localtime.c @@ -571,6 +571,9 @@ union input_buffer { }; /* TZDIR with a trailing '/'. It is null-terminated if OPENAT_TZDIR. */ +#if !OPENAT_TZDIR +ATTRIBUTE_NONSTRING +#endif static char const tzdirslash[sizeof TZDIR + OPENAT_TZDIR] = TZDIR "/"; static size_t const tzdirslashlen = sizeof TZDIR; diff --git a/private.h b/private.h index 867340fa..23f1d9fb 100644 --- a/private.h +++ b/private.h @@ -555,6 +555,12 @@ typedef unsigned long uintmax_t; # define HAVE___HAS_C_ATTRIBUTE false #endif +#if 8 <= __GNUC__ +# define ATTRIBUTE_NONSTRING __attribute__((__nonstring__)) +#else +# define ATTRIBUTE_NONSTRING +#endif + #if HAVE___HAS_C_ATTRIBUTE # if __has_c_attribute(deprecated) # define ATTRIBUTE_DEPRECATED [[deprecated]] -- 2.51.0

1 2

South African Daylight Saving Time for UTC+1 and UTC+2
by Saras Sing Oct. 2, 2025

Oct. 2, 2025

Here is a map for South Africa having UTC+1 and UTC+2 timezones so the timezone having UTC+1 have Daylight Saving Time to UTC+2 and the timezone having UTC+2 have Daylight Saving Time to UTC+3

5 4

South African Daylight Saving Time
by Saras Sing Oct. 1, 2025

Oct. 1, 2025

https://www.timeanddate.com/time/change/south-africa?year=1942 https://www.timeanddate.com/time/change/south-africa?year=1944 https://www.timeanddate.com/time/change/south-africa Hello South Africa has Daylight Saving Time every year from September to April at every first Sunday of September at UTC/GMT+2 South Africa Standard Time from 00:00 to 01:00 South African Summer Time UTC/GMT+3 and it ends at every last Sunday of April at 01:00 to 0:00 back to South Africa Standard Time UTC/GMT+2

6 10

British Summer Time end error
by Saras Sing Oct. 1, 2025

Oct. 1, 2025

Hello The United Kingdom British Summer Time ends at every last Sunday of November Thank you

7 6

[PROPOSED] Restore SUPPRESS_TZDIR support if OPENAT_TZDIR
by Paul Eggert Sept. 30, 2025

Sept. 30, 2025

The 09-28 changes inadvertently removed some support for the rarely-used SUPPRESS_TZDIR option. * localtime.c (tzloadbody) [OPENAT_TZDIR && SUPPRESS_TZDIR]: Do not open TZDIR, as when SUPPRESS_TZDIR we want relative pathnames to be relative to the working directory, not to TZDIR. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 3937e5dd..186c7bf3 100644 --- a/localtime.c +++ b/localtime.c @@ -667,7 +667,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, return ENOTCAPABLE; } - if (OPENAT_TZDIR) { + if (OPENAT_TZDIR && !SUPPRESS_TZDIR) { /* Prefer O_SEARCH or O_PATH if available; O_RDONLY should be OK too, as TZDIR is invariably readable. O_DIRECTORY should be redundant but might help -- 2.48.1

1 0

Use -00 only for invalid time zones
by Dag-Erling Smørgrav Sept. 30, 2025

Sept. 30, 2025

Hi, I've had complaints from FreeBSD users and downstream vendors about the change in 2025a which replaced "UTC" with "-00" when we fail to load a time zone. It turns out quite a few people relied on the old default as a faster way of setting the time zone to UTC, and I can't say I blame them. The attached patch changes tzset_unlocked() slightly so that UNSPEC is only used if TZ was set or zoneinit() returned an error other than ENOENT, so the behavior TZ is unset and TZDEFAULT does not exist is unchanged but we still get an error indication if TZ is set to something we don't understand, or TZDEFAULT exists but can't be read, or TZDEFAULT is readable but not a valid TZif file. DES -- Dag-Erling Smørgrav - des(a)des.no

8 20

Improving tzcode localtime.c security a la FreeBSD
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

The first difference between FreeBSD and tzcode localtime.c that I'd like to address is that FreeBSD is more cautious about handling outlandish TZ settings like "../foo". It seems to me that tzcode should largely mimic FreeBSD's extra caution. In the long run I'd like tzcode localtime.c to be byte-for-byte identical to FreeBSD localtime.c but it's better to do this one step at a time and this security caution is a good first step. I noticed some minor issues with the FreeBSD implementation of this extra checking, so I propose implementing it in a somewhat different way in tzcode. I'm attaching proposed patches to do that, and have installed them in the tzcode development repository on GitHub. Here are issues I noticed: * With an environment variable setting like TZ="/usr/share/zoneinfo/America/Los_Angeles", in a privileged program FreeBSD first opens the directory /usr/share/zoneinfo to get a directory file descriptor, and then uses fstatat and openat, both with AT_RESOLVE_BENEATH. However, it passes the full name to fstatat which must be a typo; I can't see how that would work reliably for a setuid program, even though the neighboring code suggests it was intended to work. I assume it was intended to pass a relative name to fstatat. * As near as I can make out, in privileged programs FreeBSD rejects adjacent slashes in settings like TZ="/usr/share/zoneinfo//America/Los_Angeles", where there are two slashes after "zoneinfo". It would be nicer to treat those two slashes as if they were one, as the kernel does. * tzcode is intended to be portable to platforms lacking openat and AT_RESOLVE_BENEATH, so for now the attached patches mimic FreeBSD's extra checking without using these two features. There are efficiency motivations for using the two features if available, but I'd like to defer that to a later patchset. * Although FreeBSD takes some steps to treat TZ settings the same regardless of whether they come from the TZ environment variable, it doesn't take this idea to its logical conclusion. It seems to me that it's better to not care where the TZ setting came from, as that's easier to document, understand, and maintain, so the attached patches do that. * FreeBSD uses issetugid, which is not universally available. The attached patches work around this by supplying an issetugid substitute for platforms like GNU/Linux that lack it. The first attached patch is a minor indenting fixup. The second one is a minor efficiency improvement, to use strnlen instead of strlen when that improves asymptotic efficiency. The third patch adopts FreeBSD's idea of treating a TZ setting starting with "/usr/share/zoneinfo/" as if it lacked that prefix. And the fourth and main patch changes the tzcode security checks as described above. These tzcode patches do not address other differences between tzcode and FreeBSD, such as the multithreading differences or the check-for-changes differences. These can wait for later patchsets. Comments and suggestions are welcome as usual.

3 12

[PROPOSED] Also treat space as bogus in abbreviations
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

* NEWS: Mention this. * localtime.c (scrub_abbrs): Treat ' ' as bogus. --- NEWS | 5 +++++ localtime.c | 1 - 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 0436c615..2c354038 100644 --- a/NEWS +++ b/NEWS @@ -51,6 +51,11 @@ Unreleased, experimental changes -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or disable these system calls' use. + tzset etc. now treat ' ' like '_' in time zone abbreviations, + just as they treat other invalid bytes. This continues the + transition begun in release 96k, which removed spaces in tzdata + because the spaces break time string parsers. + tzcode now uses mempcpy if available, guessing its availability. Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. diff --git a/localtime.c b/localtime.c index c5bc4e93..aa9ad7bd 100644 --- a/localtime.c +++ b/localtime.c @@ -504,7 +504,6 @@ scrub_abbrs(struct state *sp) for (i = 0; i < sp->charcnt; ++i) switch (sp->chars[i]) { case '\0': - case ' ': case '+': case '-': case '.': case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': -- 2.48.1

1 0

[PATCH 1/3] Prefer mempcpy to doing it by hand
by Paul Eggert Sept. 29, 2025

Sept. 29, 2025

This is less error-prone. Supply a mempcpy if the system lacks it. * Makefile, NEWS: Mention this. * localtime.c (tzloadbody, tzparse): * zic.c (random_dirent, relname, doabbr): * zdump.c (my_snprintf) [!HAVE_SNPRINTF]: (istrftime): Prefer mempcpy to doing it by hand. * private.h (HAVE_MEMPCPY): New macro. (mempcpy) [!HAVE_MEMPCPY]: New function. --- Makefile | 1 + NEWS | 3 +++ localtime.c | 13 +++++++------ private.h | 17 +++++++++++++++++ zdump.c | 11 +++++++---- zic.c | 36 ++++++++++++++++++++---------------- 6 files changed, 55 insertions(+), 26 deletions(-) diff --git a/Makefile b/Makefile index 83122ecc..5b577781 100644 --- a/Makefile +++ b/Makefile @@ -262,6 +262,7 @@ LDLIBS= # -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz # localtime_rz can make zdump significantly faster, but is nonstandard. # -DHAVE_MALLOC_ERRNO=0 if malloc etc. do not set errno on failure. +# -DHAVE_MEMPCPY=1 if your system has mempcpy, 0 if not (default is guessed) # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SETENV=0 if your system lacks the setenv function diff --git a/NEWS b/NEWS index 5c4786cb..0436c615 100644 --- a/NEWS +++ b/NEWS @@ -51,6 +51,9 @@ Unreleased, experimental changes -DHAVE_GETRESUID=[01], and -DHAVE_GETEUID=[01] to enable or disable these system calls' use. + tzcode now uses mempcpy if available, guessing its availability. + Compile with -DHAVE_MEMPCPY=1 or 0 to override the guess. + tzcode now uses strnlen to improve asymptotic performance a bit. Compile with -DHAVE_STRNLEN=0 if your platform lacks it. diff --git a/localtime.c b/localtime.c index 67500312..316c7504 100644 --- a/localtime.c +++ b/localtime.c @@ -624,6 +624,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, } if (!SUPPRESS_TZDIR && name[0] != '/') { + char *cp; if (sizeof lsp->fullname - sizeof tzdirslash <= strnlen(name, sizeof lsp->fullname - sizeof tzdirslash)) return ENAMETOOLONG; @@ -631,8 +632,9 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Create a string "TZDIR/NAME". Using sprintf here would pull in stdio (and would fail if the resulting string length exceeded INT_MAX!). */ - memcpy(lsp->fullname, tzdirslash, sizeof tzdirslash); - strcpy(lsp->fullname + sizeof tzdirslash, name); + cp = lsp->fullname; + cp = mempcpy(cp, tzdirslash, sizeof tzdirslash); + strcpy(cp, name); name = lsp->fullname; } @@ -1471,12 +1473,11 @@ tzparse(const char *name, struct state *sp, struct state const *basep) } sp->charcnt = charcnt; cp = sp->chars; - memcpy(cp, stdname, stdlen); - cp += stdlen; + cp = mempcpy(cp, stdname, stdlen); *cp++ = '\0'; if (dstlen != 0) { - memcpy(cp, dstname, dstlen); - *(cp + dstlen) = '\0'; + cp = mempcpy(cp, dstname, dstlen); + *cp = '\0'; } return true; } diff --git a/private.h b/private.h index 6ae0c2fd..867340fa 100644 --- a/private.h +++ b/private.h @@ -837,6 +837,23 @@ extern char *asctime_r(struct tm const *restrict, char *restrict); extern char **environ; #endif +#ifndef HAVE_MEMPCPY +# if (defined mempcpy \ + || defined __FreeBSD__ || defined __NetBSD__ || defined __linux__) +# define HAVE_MEMPCPY 1 +# else +# define HAVE_MEMPCPY 0 +# endif +#endif +#if !HAVE_MEMPCPY +static void * +mempcpy(char *restrict s1, char const *restrict s2, size_t n) +{ + char *p = memcpy(s1, s2, n); + return p + n; +} +#endif + #if 2 <= HAVE_TZNAME + (TZ_TIME_T || !HAVE_POSIX_DECLS) extern char *tzname[]; #endif diff --git a/zdump.c b/zdump.c index 8e836e60..93fe05cb 100644 --- a/zdump.c +++ b/zdump.c @@ -927,6 +927,7 @@ my_snprintf(char *s, size_t size, char const *format, ...) int n; va_list args; char const *arg; + char *cp; size_t arglen, slen; char buf[1024]; va_start(args, format); @@ -943,8 +944,9 @@ my_snprintf(char *s, size_t size, char const *format, ...) arglen = n; } slen = arglen < size ? arglen : size - 1; - memcpy(s, arg, slen); - s[slen] = '\0'; + cp = s; + cp = mempcpy(cp, arg, slen); + *cp = '\0'; n = arglen <= INT_MAX ? arglen : -1; va_end(args); return n; @@ -1073,8 +1075,9 @@ istrftime(char *buf, ptrdiff_t size, char const *time_fmt, char fbuf[100]; bool oversized = sizeof fbuf <= f_prefix_copy_size; char *f_prefix_copy = oversized ? xmalloc(f_prefix_copy_size) : fbuf; - memcpy(f_prefix_copy, f, f_prefix_len); - strcpy(f_prefix_copy + f_prefix_len, "X"); + char *cp = f_prefix_copy; + cp = mempcpy(cp, f, f_prefix_len); + strcpy(cp, "X"); formatted_len = strftime(b, s, f_prefix_copy, tm); if (oversized) free(f_prefix_copy); diff --git a/zic.c b/zic.c index 6bdb039d..e78dfd47 100644 --- a/zic.c +++ b/zic.c @@ -1327,10 +1327,10 @@ random_dirent(char const **name, char **namealloc) uint_fast64_t unfair_min = - ((UINTMAX_MAX % base__6 + 1) % base__6); if (!dst) { - dst = xmalloc(size_sum(dirlen, prefixlen + suffixlen + 1)); - memcpy(dst, src, dirlen); - memcpy(dst + dirlen, prefix, prefixlen); - dst[dirlen + prefixlen + suffixlen] = '\0'; + char *cp = dst = xmalloc(size_sum(dirlen, prefixlen + suffixlen + 1)); + cp = mempcpy(cp, src, dirlen); + cp = mempcpy(cp, prefix, prefixlen); + cp[suffixlen] = '\0'; *name = *namealloc = dst; } @@ -1430,15 +1430,17 @@ relname(char const *target, char const *linkname) if (*linkname == '/') { /* Make F absolute too. */ size_t len = strlen(directory); - size_t lenslash = len + (len && directory[len - 1] != '/'); + bool needs_slash = len && directory[len - 1] != '/'; + size_t lenslash = len + needs_slash; size_t targetsize = strlen(target) + 1; + char *cp; if (*directory != '/') return NULL; linksize = size_sum(lenslash, targetsize); - f = result = xmalloc(linksize); - memcpy(result, directory, len); - result[len] = '/'; - memcpy(result + lenslash, target, targetsize); + f = cp = result = xmalloc(linksize); + cp = mempcpy(cp, directory, len); + *cp = '/'; + memcpy(cp + needs_slash, target, targetsize); } for (i = 0; f[i] && f[i] == linkname[i]; i++) if (f[i] == '/') @@ -1448,11 +1450,13 @@ relname(char const *target, char const *linkname) taillen = strlen(f + dir_len); dotdotetcsize = size_sum(size_product(dotdots, 3), taillen + 1); if (dotdotetcsize <= linksize) { + char *cp; if (!result) result = xmalloc(dotdotetcsize); + cp = result; for (i = 0; i < dotdots; i++) - memcpy(result + 3 * i, "../", 3); - memmove(result + 3 * dotdots, f + dir_len, taillen + 1); + cp = mempcpy(cp, "../", 3); + memmove(cp, f + dir_len, taillen + 1); } return result; } @@ -2875,11 +2879,11 @@ doabbr(char *abbr, struct zone const *zp, char const *letters, else if (letters == disable_percent_s) return 0; sprintf(abbr, format, letters); - } else if (isdst) { - strcpy(abbr, slashp + 1); - } else { - memcpy(abbr, format, slashp - format); - abbr[slashp - format] = '\0'; + } else if (isdst) + strcpy(abbr, slashp + 1); + else { + char *abbrend = mempcpy(abbr, format, slashp - format); + *abbrend = '\0'; } len = strlen(abbr); if (!doquotes) -- 2.48.1

1 2

Changes to moderation procedures
by James Mitchell Sept. 29, 2025

Sept. 29, 2025

Hi all, We've made a small update to moderation settings in response to recent spam: * First posts from new members will be held for review. Once approved, the moderation flag will be removed. * All posts from non-members will continue to be held for moderation. A few existing members currently have moderation enabled. You may experience brief delays while these changes take effect—thank you for your patience. If you believe your messages are being held in error, please contact the list owners at tz-owner(a)iana.org<mailto:tz-owner@iana.org>. Kind regards, James Mitchell IANA

1 0

List moderation
by Kim Davies Sept. 24, 2025

Sept. 24, 2025

Hi folks, Our team have removed the list subscriber that flooded the list with emails in the last few minutes, and have put some emergency moderation in place until we can confirm it has died down. Apologies for the noise. kim

1 0

Prevent spam
by stan＠ulbrych.org Sept. 24, 2025

Sept. 24, 2025

Hello, I just received a barrage of emails (over 50) due to spam messages, I suggest the list owners look into first posts requiring approval before they are published. This is done for example in the Python docs list, and allows for such spam to be prevented. Best Regards, Stan Ulbrych

1 0

List moderation
by Kim Davies Sept. 24, 2025

Sept. 24, 2025

Hi folks, Our team have removed the list subscriber that flooded the list with emails in the last few minutes, and have put some emergency moderation in place until we can confirm it has died down. Apologies for the noise. kim

1 0

CRA auditor in BC checked commute route and distance in Toronto at rush hour BC time
by Brian Inglis Sept. 7, 2025

Sept. 7, 2025

How Google Maps helped one Toronto commuter beat traffic - and the tax collector: https://www.cbc.ca/news/canada/british-columbia/traffic-relocation-tax-cour… CRA auditor in BC checked commute route distance in Toronto at rush hour BC time! -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

TZLOAD_FROMENV flag used incorrectly
by Dag-Erling Smørgrav Aug. 31, 2025

Aug. 31, 2025

tzset_unlocked() calls zoneinit() with TZLOAD_STRINGS | TZLOAD_FROMENV regardless of whether name actually came from the environment. If name is null, zoneinit() will use TZDEFAULT instead, but will incorrectly consider that to be tainted, and unnecessarily perform an access check before trying to open it. That is luckily harmless in unmodified tzcode, but I would still prefer if TZLOAD_FROMENV were only set when actually true; see attached patch. DES -- Dag-Erling Smørgrav - des(a)des.no

2 3

[PROPOSED] Update tz-link for FTP, Go, Levine proposal
by Paul Eggert Aug. 31, 2025

Aug. 31, 2025

* tz-link.html: Remove links to projects that seem to be dead: MINIX, tziCal, tzdist-bis, Australian Parliamentary Library pub. Remove ftp: links as modern browsers don’t support them; instead, just mention FTP (and rsync, while we’re at it). Go seems to have fixed its 32-bit time_t bug. Cite British Sleep Society position paper on DST, and move the medical citations to a new list. Update citation to Judah Levine’s proposal to use 13-second leap smears every decade, as a substitute for leap seconds. --- tz-link.html | 115 +++++++++++++++++++++++++++------------------------ 1 file changed, 60 insertions(+), 55 deletions(-) diff --git a/tz-link.html b/tz-link.html index 76566224..669a3cb8 100644 --- a/tz-link.html +++ b/tz-link.html @@ -84,7 +84,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://www.chromium.org/chromium-os/">ChromiumOS</a>, <a href="https://cygwin.com">Cygwin</a>, <a href="https://mariadb.org">MariaDB</a>, -<a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, <a href="https://musl.libc.org">musl libc</a>, <a href="https://www.mysql.com">MySQL</a>, <a href="https://en.wikipedia.org/wiki/WebOS"><abbr @@ -175,12 +174,15 @@ ustar interchange format</a>, compressed as described above; older releases use a nearly compatible format. Since version 2016h, each release has contained a text file named “<code>version</code>” whose first (and currently only) line is the version. -Older releases are <a href="https://ftp.iana.org/tz/releases/">archived</a>, -and are also available in an -<a href="ftp://ftp.iana.org/tz/releases/"><abbr -title="File Transfer Protocol">FTP</abbr> directory</a> via a -less secure protocol.</p> -<p>Alternatively, a development repository of code and data can be +<a href="https://ftp.iana.org/tz/releases/">Older archived releases are +available</a> via +<a href="https://en.wikipedia.org/wiki/HTTPS"><abbr +title="Hypertext Transfer Protocol Secure">HTTPS</abbr></a>, +<a href="https://en.wikipedia.org/wiki/Rsync"><abbr +title="remote sync">rsync</abbr></a>, and +<a href="https://en.wikipedia.org/wiki/FTP"><abbr +title="File Transfer Protocol">FTP</abbr></a>. +<p>Alternatively, a development repository of code and data can bem retrieved from <a href="https://github.com">GitHub</a> via the shell command:</p> <pre><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> @@ -195,7 +197,7 @@ After obtaining the code and data files, see the The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files are in a special format specified by -<a href="https://www.rfc-editor.org/rfc/9636">The +<a href="https://www.rfc-editor.org/rfc/rfc9636">The Time Zone Information Format (<abbr>TZif</abbr>)</a> (Internet <abbr title="Request For Comments">RFC</abbr> 9636). The code also lets @@ -249,7 +251,7 @@ with lines terminated by <a href="https://en.wikipedia.org/wiki/Newline"><abbr title="linefeed">LF</abbr></a>, which can be modified by common text editors such as <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>, -<a href="https://gedit-technology.github.io/apps/gedit/">gedit</a>, and +<a href="https://gedit-text-editor.org">gedit</a>, and <a href="https://www.vim.org">vim</a>. Specialized source-file editing can be done via the <a href="https://packagecontrol.io/packages/zoneinfo">Sublime @@ -377,21 +379,16 @@ calculates the current time difference between locations.</li> <section> <h2 id="protocols">Network protocols for <code><abbr>tz</abbr></code> data</h2> <ul> -<li>The <a href="https://www.ietf.org">Internet Engineering Task Force</a>’s -<a href="https://datatracker.ietf.org/wg/tzdist/charter/">Time Zone Data -Distribution Service (tzdist) working group</a> defined <a -href="https://www.rfc-editor.org/rfc/rfc7808">TZDIST</a> -(Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, -along with <a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> +<li><a href="https://www.rfc-editor.org/rfc/rfc7808">Time Zone +Data Distribution Service</a> (TZDIST, Internet <abbr>RFC</abbr> 7808) +is associated with +<a href="https://www.rfc-editor.org/rfc/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. <a href="https://devguide.calconnect.org/Time-Zones/TZDS/">TZDIST -implementations</a> are available. -The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses possible extensions.</li> -<li>The <a href="https://www.rfc-editor.org/rfc/rfc5545"> -Internet Calendaring and Scheduling Core Object Specification -(iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) +implementations</a> are available.</li> +<li>The <a href="https://www.rfc-editor.org/rfc/rfc5545">iCalendar format</a> +(Internet <abbr>RFC</abbr> 5445) covers time zone data; see its VTIMEZONE calendar component. The iCalendar format requires specialized parsers and generators; a @@ -423,10 +420,6 @@ available under the <a href="https://www.gnu.org/copyleft/gpl.html"><abbr>GNU</abbr> General Public License (<abbr title="General Public License">GPL</abbr>)</a>.</li> -<li><a href="https://sourceforge.net/projects/tzical/">tziCal – tz -database conversion utility</a> is like Vzic, except for the <a -href="https://dotnet.microsoft.com">.NET framework</a> -and with a <abbr>BSD</abbr>-style license.</li> <li><a href="https://metacpan.org/release/DateTime-TimeZone">DateTime::TimeZone</a> contains a script <code>parse_olson</code> that compiles @@ -616,6 +609,9 @@ the Apache License.</li> library that translates between <abbr>UT</abbr> and civil time and can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> +<li>The <a href="https://golang.org">Go programming language</a> +has a <abbr>TZif</abbr> file reader <a +href="https://pkg.go.dev/time#LoadLocationFromTZData"><code>LoadLocationFromTZData</code></a>.</li> <li>The <a href="https://github.com/nayarsystems/posix_tz_db"><code>posix_tz_db</code> package</a> contains Python code @@ -678,10 +674,6 @@ href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. It displays multiple clocks in the application window, and has a mapping interface to <a href="https://www.google.com/earth/">Google Earth</a>. It is freely available under the <abbr>GPL</abbr>.</li> -<li><a href="https://golang.org">Go programming language</a> -implementations contain a copy of a 32-bit subset of a recent -<code><abbr>tz</abbr></code> database in a -Go-specific format.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> data (mentioned <a href="#CLDR">below</a>) used by the @@ -836,7 +828,8 @@ Saving Time – History, rationale, laws & dates</a> and summarized in History of Daylight Saving Time</a>.</li> <li><a href="https://www.laphamsquarterly.org/roundtable/time-lords">Time Lords</a> discusses how authoritarians manipulate civil time.</li> -<li><a href="https://www.w3.org/TR/timezone/">Working with Time Zones</a> +<li><a href="https://www.w3.org/TR/timezone/">Working with Time +and Time Zones</a> contains guidelines and best practices for software applications that deal with civil time.</li> <li><a href="https://webspace.science.uu.nl/~gent0113/idl/idl.htm">A History of @@ -851,10 +844,7 @@ Zone Concepts</a> discusses terminological issues behind time zones.</li> <h2 id="national">National histories of legal time</h2> <dl> <dt>Australia</dt> -<dd>The Parliamentary Library commissioned a <a -href="https://parlinfo.aph.gov.au/parlInfo/download/library/prspub/359V6/upload_b…">research -paper on daylight saving time in Australia</a>. -The Bureau of Meteorology publishes a list of <a +<dd>The Bureau of Meteorology publishes a list of <a href="http://www.bom.gov.au/climate/averages/tables/dst_times.shtml">Implementation Dates of Daylight Savings Time within Australia</a>.</dd> <dt>Belgium</dt> @@ -915,8 +905,8 @@ covers the history of local time in the Netherlands from ancient times.</dd> href="https://www.dia.govt.nz/Daylight-Saving-History">History of Daylight Saving</a>.</dd> <dt>Palestine</dt> -<dd>The Ministry of Telecom and IT publishes a <a -href="https://mtit.pna.ps/home/TimeZone" +<dd>The Ministry of Telecom and Digital Economy publishes a <a +href="https://mtde.gov.ps/home/TimeZone" hreflang="ar">history of clock changes (in Arabic)</a>.</dd> <dt>Portugal</dt> <dd>The Lisbon Astronomical Observatory publishes a @@ -957,9 +947,6 @@ zone shifts, and many scientific studies have been conducted. This section summarizes reviews and position statements based on scientific literature in the area.</p> <ul> -<li>In 2022 the American Medical Association issued a -<a href="https://www.ama-assn.org/press-center/press-releases/ama-calls-permanent-st…">statement -supporting permanent standard time</a> on health grounds.</li> <li>Carey RN, Sarma KM. <a href="https://bmjopen.bmj.com/content/7/6/e014319.long">Impact of daylight saving time on road traffic collision risk: a systematic @@ -969,22 +956,12 @@ This reviews research literature and concludes that the evidence neither supports nor refutes road safety benefits from shifts in time zones.</li> <li>Havranek T, Herman D, Irsova D. -<a href="https://www.iaee.org/en/publications/ejarticle.aspx?id=3051">Does -daylight saving save electricity? A meta-analysis</a>. +Does daylight saving save electricity? A meta-analysis. <em>Energy J.</em> 2018;39(2):35–61. doi:<a href="https://doi.org/10.5547/01956574.39.2.thav">10.5547/01956574.39.2.thav</a>. This analyzes research literature and concludes, “Electricity savings are larger for countries farther away from the equator, while subtropical regions consume more electricity because of <abbr>DST</abbr>.”</li> -<li>Malow BA. <a -href="https://academic.oup.com/sleep/article/45/12/zsac236/6717940">It is time -to abolish the clock change and adopt permanent -standard time in the United States: -a Sleep Research Society position statement</a>. -<em>Sleep.</em> 2022;45(12):zsac236. -doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. -After reviewing the scientific literature, the Sleep Research Society -advocates permanent standard time due to its health benefits. <li>Neumann P, von Blanckenburg K. <a href="https://journals.sagepub.com/doi/full/10.1177/0961463X241310562">What time will it be? A comprehensive literature review on daylight saving time</a>. @@ -993,6 +970,30 @@ doi:<a href="https://doi.org/10.1177/0961463X241310562">10.1177/0961463X24131056 This reviews DST’s effects on electricity, health, crime, road safety, and the economy, focusing on research since 2010, and concludes that year-round standard time is preferable overall. +</ul> + +<p>The following medical societies have taken positions on the +advisability of clock shifts:</p> + +<ul> +<li>In 2022 the American Medical Association issued a +<a href="https://www.ama-assn.org/press-center/press-releases/ama-calls-permanent-st…">statement +supporting permanent standard time</a> on health grounds.</li> +<li>Crawford MR, Winnebeck EC, von Schantz M <em>et al</em>. +<a href="https://onlinelibrary.wiley.com/doi/10.1111/jsr.14352">The +British Sleep Society position statement on Daylight Saving Time in the UK</a>. +<em>J Sleep Res.</em> 2025;34(3):e14352. +doi:<a href="https://doi.org/10.1111/jsr.14352">10.1111/jsr.14352</a>. +This recommends that the UK abolish DST for health reasons.</li> +<li>Malow BA. <a +href="https://academic.oup.com/sleep/article/45/12/zsac236/6717940">It is time +to abolish the clock change and adopt permanent +standard time in the United States: +a Sleep Research Society position statement</a>. +<em>Sleep.</em> 2022;45(12):zsac236. +doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. +After reviewing the scientific literature, the Sleep Research Society +advocates permanent standard time due to its health benefits.</li> <li>Rishi MA, Cheng JY, Strang AR <em>et al</em>. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time is the optimal choice for health and safety: @@ -1144,12 +1145,16 @@ to discontinue the use of leap seconds by 2035, and requested that no discontinuous adjustments be made to UTC for at least a century. The World Radiocommunication Conference <a href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved -in 2023</a> to cooperate with this process. -<a href="https://www.preprints.org/manuscript/202406.0043/v1">A proposal -to change the leap-second adjustments to Coordinated Universal Time</a> -(doi:<a href="https://doi.org/10.1088/1681-7575/ad6266">10.1088/1681-7575/ad6266</a>) -would replace leap seconds with 13-second leap smears occurring once per +in 2023</a> to cooperate with this process. One proposal to implement this +would replace leap seconds with seven 13-second leap smears occurring once per decade until 2100, with leap smears after that gradually increasing in size. +See: +<ul> +<li>Levine J. <a href="https://www.preprints.org/manuscript/202406.0043/v1">A +proposal to change the leap-second adjustments to +coordinated universal time</a>. <em>Metrologia.</em> 2024;61(5):055002. doi:<a +href="https://doi.org/10.1088/1681-7575/ad6266">10.1088/1681-7575/ad6266</a>.</li> +</ul> However, there is still no consensus on whether this is the best way to replace leap seconds. </li> -- 2.48.1

1 0

Using curved quotes etc. in TZDB HTML
by Paul Eggert Aug. 30, 2025

Aug. 30, 2025

After looking at today’s little change[1] to one of TZDB’s HTML files, I noticed that it cited Morrison et al’s 2020 paper but changed the paper’s title to use straight quotes 'like this' instead of curved quotes ‘like this’. Although TZDB’s HTML files mostly use straight quotes, they’re not methodical about it, and anyway straight quotes are to some extent a relic of the 20th century and in HTML files we can now reliably use curved quotes. So I composed a patch (attached) to be more consistent about quoting, and to use curved quotes except in places where the quotes are part of computer code and need to be straight. I haven’t installed this patch, though, because it’s annoying to edit HTML that looks like this: strings like “Prague”, “Praha”, “Прага”, and “布拉格”. I’d rather edit HTML that looks like this: strings like “Prague”, “Praha”, “Прага”, and “布拉格”. Since the HTML files are already UTF-8 encoded (otherwise they wouldn’t contain those non-ASCII letters) this shouldn’t be a problem with today’s editors. In 2014[2] I held off on making such a change because Garrett Wollman wrote that XEmacs 21.4 does not support quotes ‘like this’ or “like this”. However, XEmacs 21.4 has not been updated since 2009 and by now I would think XEmacs users would be using either XEmacs 21.5 (even though it’s still “beta”) or GNU Emacs, and both of these do support curved quotes. So instead of installing this patch, I’m inclined to install a different one in which HTML files use UTF-8 quotes “like this” rather than harder-to-read HTML entities “like this”. If this is OK we can also do something similar with other special characters such as “–” instead of “–”. Comments welcome. I am ccing this email to Garrett to see whether XEmacs 21.4 is still an issue with him. [1]: https://lists.iana.org/hyperkitty/list/tz@iana.org/message/BH63ZL5DHEBJPT2C… [2]: https://mm.icann.org/pipermail/tz/2014-June/046053.html

9 16

Re: Disabling adjustment, hyphenation, SGR, and page headers and footers in man pages
by Paul Eggert Aug. 28, 2025

Aug. 28, 2025

On 2025-08-27 16:42, G. Branden Robinson wrote: > I sent this to tz(a)iana.org a few days ago, but it appears to have gotten > discarded, maybe because I am not subscribed to the list. Yes, it's August and I suspect mailing list reviewers are on vacation. For tz list readers: Branden's original email is archived here: https://lists.gnu.org/r/groff/2025-08/msg00041.html > I have a suggestion for accomplishing all of the tasks named in the > Subject with command-line options to (recent) nroff. If I understand > the "workman.sh" script correctly, all that would be left for your > pipeline is to strip a trailing blank line. Thanks for the suggestion. As TZDB has been shipping *.txt files with single header and trailer lines for some time, I think we can simply prefer that style now for groff; this removes the need to strip a trailing blank line. For traditional nroff the best we can easily do is omit all headers and trailers, to avoid irritating headers elsewhere. > You might find it more convenient to use command-line options than to > append to macro definitions and otherwise inject *roff into nroff's > input stream (which is interpreted only after the macro package is > loaded, a fact that will have important consequences in groff 1.24). Thanks for the suggestion. Although this assumes groff we can do it just for groff (and for mandoc) and continue to do things the traditional way on old-fashioned (by now, very old-fashioned) hosts. I installed the attached proposed patches to implement your suggestion and a bit more.

1 0

Re: question regarding Mongolian timezone /Hovd GMT+/
by Munkh-Erdene Erdenebat Aug. 28, 2025

Aug. 28, 2025

Dear IANA Colleagues, I hope this message finds you well. My name is Munkh-Erdene from Mobicom Corporation, a mobile phone operator in Mongolia. I have a question regarding the Mongolian timezone, specifically for the Hovd region. According to various online sources, Mongolia currently has two time zones: Hovd (UTC+7) and Ulaanbaatar (UTC+8). The Hovd timezone is observed in three provinces: Hovd, Bayan-Ulgii, and Uvs. However, when I checked the tzdata files (zone.tab and zone1970.tab), it lists five provinces under the Hovd timezone. My understanding is that it should be only the three provinces mentioned above. Could you please advise on the process for requesting a correction in tzdata? Are there any specific requirements we need to meet? Also, please let me know if my understanding of the timezone coverage is incorrect. Thank you for your time and support. MUNKH-ERDENE Erdenebat Manager Core Network Department /CND/ CN&BSD/TS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> From: Munkh-Erdene Erdenebat Sent: Wednesday, March 13, 2024 5:28 PM To: tz-owner(a)iana.org<mailto:tz-owner@iana.org> Subject: question regarding Mongolian timezone /Hovd GMT+/ Dear IANA Colleagues, How are you, doing well. I am Munkh-Erdene from Mobicom Corporation, which is Mongolian mobile phone operator. I've question regarding Mongolian timezone. We have some misunderstanding regarding Mongolian timezone, specially for Hovd region. As we checked from internet, it says there is 2 timezone in Mongolia now. Hovd+7 and Ulaanbaatar +8. Behind of Hovd region, there is 3 provinces which is Hovd, Bayan-Ulgii & Uvs. [cid:image004.png@01DC1810.84CC7F10][cid:image007.jpg@01DC1810.84CC7F10] World Time Zone Map (24timezones.com)<https://24timezones.com/timezone-map> Mongolia Time Zone - WhichTimezone<https://whichtimezone.com/asia/mongolia/> But when I checked from tzdata file. Zone.tab & zone1970.tab files. There is 5 aimags behind of Hovd region, it should be 3 provinces which is Hovd, Bayan-Ulgii & Uvs. We want to correct it on tzdata, how can we send request to you and is there any requirements from you? please correct me if I was checked wrongly. [cid:image008.jpg@01DC1810.84CC7F10] [cid:image009.jpg@01DC1810.84CC7F10] MUNKH-ERDENE Erdenebat Department Manager Network Operation & Maintenance Department /NOMD/ TOMD/TOMS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> ???????? ?????? ????? ?????? ?? (????????????? ????) ?????? ?????? ?????????? ?????????, ?????? ???? ??? ????? ???????? ???????????? ?????. ?? ????? ??????? ??????????? ???????? ?? ??????? ?????????????, ????????? ???????? ?????? ?????? ??????????? ???????????? ???? ?????????? ? ??????? ????????????? ??? ?? ????????????? ??. ????? ?? ?? ????? ??????? ??????? ???????? ?????? ????? ??? ??? ?????? ????? ??????? ????????? ????? ????? ?????? ?????? ?????? ????????, ?????????? ????? ????? ????? ??????? ?????? ????????? ??? ????? ?????? ???? ??????? ???? ??. ???????? ?????? ???????? ??????????? ?????????? ?????? ????????? ?????????, ??????????, ?????? ?????? ????? ?? ??????????? ????????? ??????? ????? ?????? ????, ?? ?????? ????? ????? ??? ?????? ???????? ??. Disclaimer This email (including any attachments) is intended only to be read and used by the addressee. It may contain confidential or legally privileged information, which is not waived if it is mistakenly delivered to you. If you are not the intended recipient, please immediately notify the sender by return email and delete both messages from your system; any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

3 3

Asia/Riyadh TZ abbreviation "+03"?
by Peter Chamberlin Aug. 25, 2025

Aug. 25, 2025

Wouldn’t this be better defined as "AST" for Arabia Standard Time per https://24timezones.com/Riyadh/time?

5 9

[PROPOSED 1/3] Fix adjustment and hyphenation in *.txt files
by Paul Eggert Aug. 24, 2025

Aug. 24, 2025

* date.1: Remove no-longer-needed .nh and .na. * workman.sh: Modernize the code that disables adjustment and hyphenation, to work in groff 1.23 too. Add comments. --- date.1 | 2 -- workman.sh | 18 +++++++++++++++--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/date.1 b/date.1 index 3a02e7c2..5f334358 100644 --- a/date.1 +++ b/date.1 @@ -4,8 +4,6 @@ .SH NAME date \- show and set date and time .SH SYNOPSIS -.if n .nh -.if n .na .B date [ .B \-u diff --git a/workman.sh b/workman.sh index 29f317cb..ad1a9532 100644 --- a/workman.sh +++ b/workman.sh @@ -9,12 +9,24 @@ if (type nroff && type perl) >/dev/null 2>&1; then # Tell groff not to emit SGR escape sequences (ANSI color escapes). export GROFF_NO_SGR=1 - echo ".am TH -.hy 0 + printf '%s\n' '. +.\" -- Tailor groff -man -- +. +.\" Left-adjust and do not hyphenate. +.ds AD l +.nr HY 0 +. +.\" -- Tailor traditional troff -man -- +. +.\" Left-adjust and do not hyphenate. +.am TH .na +.hy 0 .. +.\" Omit page headers and footers. .rm }H -.rm }F" | nroff -man - ${1+"$@"} | perl -ne ' +.rm }F +.' | nroff -man - ${1+"$@"} | perl -ne ' binmode STDIN, '\'':encoding(utf8)'\''; binmode STDOUT, '\'':encoding(utf8)'\''; chomp; -- 2.50.1

1 2

Possible upcoming change to America/Argentina/*, from -03 to -04
by Salvador Pardiñas Aug. 23, 2025

Aug. 23, 2025

Hi all! I wanted to warn you about a potential change to all the Argentinean timezones, as a law proposal looking to move the entire country to GMT-4 has now passed the Lower Chamber of Parliament, and is now waiting for approval by the Upper Chamber of Parliament: https://www.lanacion.com.ar/politica/la-camara-de-diputados-le-dio-media-sa… https://www.infobae.com/sociedad/2025/08/21/cambio-de-huso-horario-en-argen…

1 0

[PATCH] Mention Qinling Station opened in Antarctica on 2024-02-07.
by Collin Funk Aug. 16, 2025

Aug. 16, 2025

Hi Paul, Regarding this comment at the top of the antartica file: # From Paul Eggert (1999-11-15): # To keep things manageable, we list only locations occupied year-round; see # COMNAP - Stations and Bases # http://www.comnap.aq/comnap/comnap.nsf/P/Stations/ [...] You may want to update it to link to page which is not dead [1]. It contains a link to "COMNAP Antarctic Facilities List", which is a file that is updated periodically as things change in Antarctica (not often, I assume?). Currently it is this [2]. Anyways, China opened a new year-round base in 2024 that it is probably worth mentioning [3]. It has a higher population than their other ones, if Wikipedia is to be trusted [4]. Patch attached. Collin [1] https://www.comnap.aq/antarctic-facilities-information [2] https://www.comnap.aq/s/Facilities_Nov2024.csv [3] https://www.reuters.com/world/china/china-opens-antarctic-station-south-aus… [4] https://en.wikipedia.org/wiki/Qinling_Station

2 1

DST in Baja California 1973
by Alois Treindl Aug. 6, 2025

Aug. 6, 2025

TZ maintains for zone America/Tijuana that there was not DST observed between 1961 and 1975. > # Baja California > Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 7:00u > -7:00 - MST 1924 > -8:00 - PST 1927 Jun 10 > -7:00 - MST 1930 Nov 15 > -8:00 - PST 1931 Apr 1 > -8:00 1:00 PDT 1931 Sep 30 > -8:00 - PST 1942 Apr 24 > -8:00 1:00 PWT 1945 Aug 14 23:00u > -8:00 1:00 PPT 1945 Nov 15 # Peace > -8:00 - PST 1948 Apr 5 > -8:00 1:00 PDT 1949 Jan 14 > -8:00 - PST 1950 May 1 > -8:00 1:00 PDT 1950 Sep 24 > -8:00 - PST 1951 Apr 29 2:00 > -8:00 1:00 PDT 1951 Sep 30 2:00 > -8:00 - PST 1952 Apr 27 2:00 > -8:00 1:00 PDT 1952 Sep 28 2:00 > -8:00 - PST 1954 > -8:00 CA P%sT 1961 > -8:00 - PST 1976 > -8:00 US P%sT 1996 > -8:00 Mexico P%sT 2001 > -8:00 US P%sT 2002 Feb 20 > -8:00 Mexico P%sT 2010 > -8:00 US P%sT A user of our astrology service, born in 1973 in he border town Mexicali claimed that they observed DST in his town, just like on the other side of the border in California, when he was born on 30 May 1973. I did a quick newspaper archive research on https://hndm.iib.unam.mx/ and found that Título: Periódico Oficial del Estado de Baja California Norte Fecha: 1973-04-20 states clearly that DST was observed from last Sunday in April to last Sunday in October. This means the the TZ table above is false, at least for 1973. I assume that the same is the case for several other years. I attach the screenshot for 1973 The page https://hndm.iib.unam.mx/consulta/publicacion/visualizar/558075be7d1e63c9fe… should allow to search for other years as well. I used the keywords *hora legal* for my search, though do not see that now in the URL.

4 7

Fwd: Bulletin C number 70
by Tim Parenti Aug. 4, 2025

Aug. 4, 2025

No leap second 2025-12-31, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jul 2025 at 05:43 Subject: Bulletin C number 70 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 07 July 2025 Bulletin C 70 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of December 2025. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

4 11

Error in the Annuaire du Bureau des Longitudes for 1923
by Santoni Francis July 23, 2025

July 23, 2025

Hello, The most surprising thing, when I checked, in the 1980s, the consistency of this date of 1923 in the newspapers of the time, is that even in the daily newspapers there was, the day before, only a very short article, in the inside pages of the newspaper, whereas, in the same newspaper, for the previous years, the article indicating summer hours was always clearly visible. If I remember correctly, during the preceding months, the questioning about summer hours was reduced to procrastination. Le plus étonnant, lorsque j'ai vérifié, dans les années 80, la cohérence de cette date de 1923 dans les journaux de l'époque, c'est que même dans les quotidiens il n'y avait, la veille qu'un très court article, dans les pages intérieures du journal, alors que, dans le même journal, pour les années précédentes, l'article signalant les heures d'été était toujours bien visible. Si je me souviens bien, durant les mois précédents, le questionnement sur les heures d'été se résumait à des atermoiements. Francis Santoni

1 0

Yucatán thinks of moving from -06 to -05
by Paul Eggert July 23, 2025

July 23, 2025

Yucatán, which corresponds to TZDB’s America/Merida, is considering switching from -06 (CST) all year to -05 (EST) all year.[1] This would be akin to observing permanent daylight saving time. (Yucatán last observed DST in 2022, after which Mexico abolished DST except in regions near the US.) There does not seem to be any rush to decide whether to make the change. If Yucatán does switch presumably Campeche will not, so we would therefore need to split America/Merida into two zones, and as Mérida is in Yucatán we would need a new name for Campeche. The largest city in the Mexican state of Campeche is its capital San Francisco de Campeche, commonly called just “Campeche” like the state, so presumably America/Campeche would be the name of the new TZDB zone. One possible date and time for Yucatán’s hypothetical switch would be March 8, 2026 at 02:00, which is when US CST is planned to switch to CDT. Any such transition is purely speculative at this point, though, so I am not now proposing a patch to TZDB. [1]: David Domínguez Massa. Posturas desde el Congreso de Yucatán sobre homologar el horario con Quintana Roo. Diario de Yucatán. 2025-07-05. https://www.yucatan.com.mx/merida/2025/07/05/posturas-desde-el-congreso-de-…

1 0

Should all IDs from backzone be available in backward?
by robertbastian＠unicode.org July 2, 2025

July 2, 2025

The set of IDs (zones and links) in backzone is _almost_ a subset of the IDs in backward; the only ID that is in backzone but not in backward is Asia/Hanoi. Can Asia/Hanoi be added as a link in backward to ensure compatibility with systems that use IDs from backzone? Is this a desirable invariant that can be upheld in the future? This was reported to CLDR (https://unicode-org.atlassian.net/browse/CLDR-11977) so it looks like there are systems that are using these IDs.

6 8

Issue with America/Nuuk tz
by Dan Juskevicius June 20, 2025

June 20, 2025

Dear sir or madam, I'm currently working on an issue that one of our customers has reported with the tz database. Using the latest release (2025b), I have been able to reproduce an issue with America/Nuuk time where it reports at -02 instead of -01; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look. Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this? Cheers, Daniel Juskevicius Systems Software Developer djuskevicius(a)qnx.com QNX - It all starts here ---------------------------------------------------------------------- This email and any attachments are intended solely for the use of the individual or entity to whom they are addressed. This email may contain information that is confidential, privileged, or otherwise protected from disclosure. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this email in error, please immediately contact the sender and delete all copies of this email and any attachments from your systems. Any unauthorized review, use, dissemination, distribution, or reproduction of this email by unintended recipients is not authorized and may be unlawful. Thank you for your cooperation.

5 9

TZif Version Selection Issue in tzcode2025b
by PATAN JEELAN BASHA June 11, 2025

June 11, 2025

Hi All, We have encountered an issue after upgrading to tzcode2025b, where zoneinfo files that were previously generated in TZif3 format are now being generated in TZif2 format. This change appears to be due to the removal of the forced version in the writezone() call in zic.c file. Upon investigation, we found that: ->The logic in stringrule() that sets compat = 2013 based on wdayoff is not meaningful in practice. ->For rules like Sun>=8, wdayoff = 0, so compat = 0, and the compiler now generates TZif2. ->This behavior change appears to result from the removal of the forced version and the introduction of dynamic version selection logic. For example, in the northamerica file, we have: Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S These rules are used by zones such as America/Chicago and others. Since Sun>=8 results in wdayoff = 0, the compat value remains 0, and the compiler now generates TZif2 instead of TZif3. This change affects all zones relying on similar rules, even though the rule definitions themselves have not changed. Specifically, the change from: writezone(zpfirst->z_name, envvar, ZIC_VERSION); // older code to: writezone(zpfirst->z_name, envvar, version, defaulttype); // new code has caused the compiler to emit TZif2 for rules that previously resulted in TZif3. We believe this logic does not reliably reflect the need for TZif3 and may lead to inconsistent or unexpected output formats. We would appreciate your thoughts on this and whether a patch or enhancement is planned to address it. Best Regards, Jeelan

3 3

Cape Breton Island "time zone"
by Arthur Olson June 10, 2025

June 10, 2025

"Google and Meta search both report that Cape Breton Island has its own time zone 12 minutes ahead of mainland Nova Scotia time because they are both drawing that information from a Beaverton article I wrote in 2024." --Janel Comeau (The Beaverton is a Canadian satire publication. Folks on this mailing list: be alert for Cape Breton Island come 2026-04-01.) --@dashdashado https://www.threads.com/@janelcomeau/post/DKs2YqBJgqK/google-and-meta-searc… https://thebeaverton.com/2024/07/cape-breton-to-create-new-more-annoying-ti…

1 0

Fix example for zic transition coalescence
by Tim Parenti May 30, 2025

May 30, 2025

I noticed a typo in zic.8 within the "correct" example given for how zic handles/coalesces certain transitions. While I was there, it also made sense to expand a bit more on where the incorrect interpretation could come from, as a further nod to why we choose instead to have zic coalesce transitions as it does. Documentation patch attached and pushed to the development repository. -- Tim Parenti

1 0

Proposal to Add Asia/Penampang to IANA Time Zone Database
by Denis Martin May 30, 2025

May 30, 2025

Dear tz maintainers, I am submitting a formal proposal to add a new time zone entry: Asia/Penampang. The proposal seeks to represent the distinct historical, geographic, and cultural identity of Penampang and greater Kota Kinabalu (Sabah, East Malaysia) in the IANA Time Zone Database. The full proposal is hosted publicly here: https://github.com/dmmartin/Asia-Penampang-Proposal This submission builds on precedent (e.g., Asia/Kuching for Sarawak) and is fully aligned with the IANA project's criteria for regionally distinct zones, even where UTC offsets are identical. Thank you for your time and consideration. Best regards, Denis Martin Sabah Time Zone Advocacy penampang.tzproposal(a)fakemail.org Denis Martin

3 2

PyCon US Time
by Ee Durbin May 20, 2025

May 20, 2025

PyCon US is an annual gathering for the community using and developing the open-source Python programming language. PyCon US has been held in-person and on-location from 2003 to present with exception for 2020 and 2021 in response to the global COVID-19 pandemic. After an initial three year stint in Washington, D.C. USA PyCon US has been hosted in cities across North America in two-year "cycles". PyCon US makes extensive use of software across an annoying number of online and offline systems. These include GNU/Linux servers, PostgreSQL databases, all web browsers, a mobile application, Raspberry Pis, iPads, Zebra printers, printed materials, and human brain matter. These systems persist year-over-year while our timezone does not. This timezone is proposed to provide a durable solution for ensuring agreement between these systems. After over a decade dealing with these concerns, establishment of this timezone will benefit me directly, as well as those who proceed me by reducing churn in our codebases, and entirely obliviate the need to think during stressful periods of conference planning. It will also benefit my co-workers and those who follow them by dissolving an unnecessary cognitive burden when editing records in our systems, communicating deadlines and schedules, and working with one another remotely. It will also benefit attendees in reasoning about these matters. PyCon US Time is defined to be the local time of the city currently hosting the conference. PyCon US Time transitions at the time that last attendee (Larry Hastings, most often) departs the Development Sprints. We are actively working to improve the historic times for this departure, but estimate 8pm local time for years which have not yet been fully verified. Transitions =========== 2003-02-13 First Annual PyCon announced - Reference: https://www.python.org/psf/press-release/pr20030213/ - Location: Washington DC, USA, -5:00 2005-03-25 PyCon US Washington concludes - New Location: Dallas, TX, USA, -6:00 - Last Attendee Departure: Unconfirmed 2007-03-01 PyCon US Dallas concludes - New Location: Chicago, IL, USA, -6:00 - Last Attendee Departure: Unconfirmed 2009-04-02 PyCon US Chicago concludes - New Location: Atlanta, GA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2011-03-17 PyCon US Atlanta concludes - New Location: Santa Clara, CA, USA, -8:00 - Last Attendee Departure: Unconfirmed 2013-03-21 PyCon US Santa Clara concludes - New Location: Montréal, Québec, Canada, -5:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Montréal concludes - New Location: Portland OR, USA, -8:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Portland concludes - New Location: Cleveland, OH, USA, -5:00 - Last Attendee Departure: 7:59pm local time 2015-04-16 PyCon US Cleveland concludes - New Location: Worldwide, 0:00 - Last Attendee Departure: Unconfirmed - Reference: https://x.com/pycon/status/1126637785455185920 - Note: After PyCon US 2019, the planned conference cycle in Pittsburgh, PA, USA was undertaken on-line for 2020/2021. 2021-10-12 PyCon US Salt Lake City Launched - New Location: Salt Lake City, UT, USA, -7:00 - Reference: https://pycon.blogspot.com/2021/10/pycon-us-2022-website-and-sponsorship.ht… 2023-04-27 PyCon US Salt Lake City concludes - New Location: Pittsburgh, PA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2025-05-22 PyCon US Pittsburgh concludes (Estimated) - New Location: Long Beach, CA, USA, -8:00 While I appreciate and understand that this submission may appear to be a gag/joke, I am sincere in this request and humbly request that it be considered with sincerity in kind. -Ee Durbin Director of Infrastructure Python Software Foundation

2 2

Request for Update: Iran's Official Time Zone – No Daylight Saving Time Since 2023
by Khalil Kharazi May 19, 2025

May 19, 2025

Dear Time Zone Database Maintainers, I hope this message finds you well. I am writing to bring your attention to an important legal update regarding the official timekeeping policy of the Islamic Republic of Iran. In March 2022, the Iranian Parliament passed legislation to permanently abolish Daylight Saving Time (DST), effective from March 2023. As a result, Iran now observes a fixed time zone of UTC+3:30 throughout the entire year, with no forward or backward clock shifts. This change is now fully implemented across all provinces and official systems within the country. However, it has come to our attention that some international platforms, time services, and applications may still reflect outdated DST rules for Iran, which can lead to errors in scheduling, communication, and automation. Given the widespread reliance on the IANA Time Zone Database (tzdata) by global operating systems and applications, we kindly request that you verify and reflect this official update in the relevant database records (Asia/Tehran) to ensure accurate representation of Iran’s current time zone policy. Should you require further documentation or references to the legislation, I would be glad to provide official sources or translations as needed. Thank you for your attention to this matter and for your continued efforts in maintaining a reliable and globally synchronized time zone system. Sincerely, [Khalil Kharazi]

2 1

Proposed correction for zone.tab and Link: Europe/Uzhgorod to Europe/Uzhhorod
by Sorel Si May 17, 2025

May 17, 2025

Dear tz database maintainers, I would like to propose a correction to the spelling of the Ukrainian city Uzhhorod in the tz database. Currently, the city is referenced as "Uzhgorod" in `zone.tab` and as a Link target: In `zone.tab`: UA +4837+02218 Europe/Uzhgorod Zakarpattya west Link definition (in the `europe` data file): Link Europe/Kyiv Europe/Uzhgorod The spelling "Uzhgorod" (with a 'g') appears to be a transliteration from the Russian language form of the city's name ("Ужгород"). However, Uzhhorod is a city in Ukraine. The official Ukrainian name is "Ужгород". According to the current official Ukrainian national system for romanization of Ukrainian Cyrillic (approved by Resolution No. 55 of the Cabinet of Ministers of Ukraine, January 27, 2010), the Ukrainian letter "г" (which is present in "Ужгород") is transliterated as "h". Therefore, the correct romanized form from Ukrainian is "Uzhhorod". This spelling ("Uzhhorod") is consistently used by official Ukrainian sources, including the Uzhhorod City Council (e.g., uzhhorod-rada.gov.ua) and in national legislative documents. Given this, I propose the following changes for accuracy and consistency with Ukrainian national standards: 1. Update the entry in `zone.tab` to: `UA +4837+02218 Europe/Uzhhorod Zakarpattya west` 2. Update the Link target name to `Europe/Uzhhorod`: `Link Europe/Kyiv Europe/Uzhhorod` This would align the tz database with the official and correct transliteration of the city's name from its native language. Thank you for your time and consideration. Sincerely, Arsenii

5 4

[PROPOSED] Don’t mention iso3166.tab in zone1970.tab comment
by Paul Eggert May 16, 2025

May 16, 2025

* zone1970.tab: Remove mention of iso3166.tab in comment. In FreeBSD iso3166.tab is not installed, which makes the comment confusing in an installed file. Although FreeBSD gets around this problem by editing zone1970.tab, it’d be better if FreeBSD could use zone1970.tab unmodified. --- zone1970.tab | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zone1970.tab b/zone1970.tab index 36535bdf..f3227405 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -2,14 +2,14 @@ # # This file is in the public domain. # -# From Paul Eggert (2018-06-27): +# From Paul Eggert (2025-05-15): # This file contains a table where each row stands for a timezone where # civil timestamps have agreed since 1970. Columns are separated by # a single tab. Lines beginning with '#' are comments. All text uses # UTF-8 encoding. The columns of the table are as follows: # # 1. The countries that overlap the timezone, as a comma-separated list -# of ISO 3166 2-character country codes. See the file 'iso3166.tab'. +# of ISO 3166 2-character country codes. # 2. Latitude and longitude of the timezone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, -- 2.49.0

2 1

opposition to recent time zone change in Paraguay
by Paul Eggert May 6, 2025

May 6, 2025

An article last week in El Nacional reports ongoing public opposition to Paraguay's decision to not fall back on March 22, which means sunrise might not occur until after 07:45 in western Paraguay in June. Sen. Blanca Ovelar will promote going back to the old -04/-03-with-DST regime. Other possibilities include changing government schedules for schools, banks, etc. to in effect revert the change for some people. Although I do not expect this to affect TZDB in the short run, we should keep an eye on the situation. Nuevo horario divide al Paraguay. El Nacional. 2025-04-29. https://elnacional.com.py/politica/nuevo-horario-divide-paraguay-n84973

1 0

Re: wrong last-modified timestamp in NIST leap-seconds.list
by Paul Eggert April 24, 2025

April 24, 2025

On 2025-04-24 07:04, Judah Levine wrote: > Your comments have adequately addressed the #$ timetamp definition, which is described in the comments to the file. It has been defined this way for as long as I have prepared the file. There has been no leap second for a long time, and that time stamp reflects that fact. The name of the file is chosen in the same way - it changes only when a new leap event is announced, and now points to a time years ago. > I choose the expiration date of the file so that the list of leap seconds in the file will be correct at least until that date. I use IERS Bulletin C, IERS Bulletin A, and other IERS data to derive that date. It includes a prediction of the evolution of UT1-UTC by the IERS, and is more comprehensive than the simple announcement of a leap second in Bulletin C. > Apart from the recent and continuing drama in the environment here, the file has always been updated long before the expiration date arrives - usually when a new Bulletin C is published. The expiration date is intended to be a safety valve if (and only if) there are more serious problems. I regret that I cannot assure you that the current high level of drama is decreasing. > The leap second file is distributed by FTP. The method has very significant difficulties - it is a long and tedious process to update the file, and there are various reports that it is difficult to access. I don't have a choice about this, at least for now. The other alternatives, such as a web page, would be even more difficult to maintain. Thanks for the heads-up. This makes it clear that the NIST vs IERS leap-seconds.list metadata differences are intentional. I installed the attached proposed patch to TZDB to try to document this in a way that TZDB users can easily understand. If it weren't for the problems with FTP and with NIST's lagging expiration timestamps, I'd prefer the NIST metadata as they're less volatile. For now, though, the proposed patch merely changes commentary, rather than changing the default leap-second data source from the IERS back to the NIST (which was the source for many years, until TZDB release 2024a). Perhaps after things have settled down we can help coordinate the IERS and NIST leap-seconds.list files so that they agree not just about data, but also about the last-modified and expiration timestamps. This would help reduce confusion in the future.

2 1

[PATCH] Don't mention boulder.nist.gov
by Collin Funk April 24, 2025

April 24, 2025

The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves. From the Internet Archive for boulder.nist.gov it seems like it was a redirect for nist.gov until it was later deleted. The attached patch removes reference to it. Collin [1] https://web.archive.org/web/20180901000000*/boulder.nist.gov

6 13

[PROPOSED 1/6] * Makefile: Modernize comment.
by Paul Eggert April 21, 2025

April 21, 2025

--- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2130582c..502fe2fa 100644 --- a/Makefile +++ b/Makefile @@ -10,10 +10,11 @@ # To affect how this Makefile works, you can run a shell script like this: # # #!/bin/sh -# make CC='gcc -std=gnu23' "$@" +# make CFLAGS='-O2 -DHAVE_GETTEXT=0' "$@" # -# This example script is appropriate for a circa 2024 GNU/Linux system -# where a non-default setting enables this package's optional use of C23. +# This example script is appropriate for a GNU/Linux system +# which needs more optimization than default, and which does not want +# gettext's internationalion of diagnostics. # # Alternatively, you can simply edit this Makefile to tailor the following # macro definitions. -- 2.48.1

2 7

SBOM required for tzdata2025b and tzcode2025b
by Sahil Sharma D April 21, 2025

April 21, 2025

Hi team, Could you please share the SBOM for tzdata2025b and tzcode2025b? Regards, Sahil

4 6

Iran considering reintroducing daylight saving
by Roozbeh Pournader April 11, 2025

April 11, 2025

There's been news today about Iran potentially reintroducing daylight saving. The CEO of Tavanir, the governmental electric power agency, has said that the government is requesting that the parliament let it set daylight saving at its own pleasure, as opposed to the parliament controlling the rules. He estimates that daylight saving would reduce electricity consumption by about 1%, which could be critical since the country is facing energy shortages.

2 1

POSIX.1-2024 link in theory.html
by Max Nikulin April 1, 2025

April 1, 2025

Hi, I have noticed that <https://data.iana.org/time-zones/theory.html> states > As of this writing, the current edition of POSIX is POSIX.1-2024, which > has been published but not yet in HTML form. It seems, it is time to update this paragraph. For precise location in the repository see the attached file. I am unsure if a more precise link https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#ta… should be used. Perhaps some other links should be updated to point to the newer standard revision.

2 3

GNU/Linux distros lagging on yesterday's Paraguay change
by Paul Eggert March 27, 2025

March 27, 2025

Most GNU/Linux distributions, Android, iOS, macOS and Microsoft Windows all have at least version 2025a of TZDB, so properly-updated installations should be working correctly after Paraguay's rule change yesterday. However, Repology reports[1] that the latest stable versions of the following GNU/Linux distributions are still based on TZDB 2024b and thus presumably are misbehaving in Paraguay: Apertis, nixpkgs, OpenWrt, Pardus, Rosa, Trisquel, Ubuntu Of these Ubuntu is best known, and it has several downstream distros that I assume are also affected. So Ubuntu may be the most important laggard for Paraguay. In the list above, I omitted distros like Adélie that use TZDB versions that predate 2024b. I assume these distros are not intended to be up-to-date, are no longer maintained, have distro-specific patches, or aren't tracked accurately by repology. Many other systems also may be out of date for Paraguay; see the first paragraph of the section "The tz database"[2] for a partial list. I haven't tried to track them all. [1]: https://repology.org/project/tzdata/versions [2]: https://data.iana.org/time-zones/tz-link.html#tzdb

3 2

DST end time on Lord Howe Island
by Heitor David Pinto March 27, 2025

March 27, 2025

Hello, In 2001, the database was changed to show the DST start and end times in Lord Howe Island as "2:00" instead of "2:00s". This change only affects the DST end time: if "2:00", it's 2:00 local time, but if "2:00s", it's 2:30 local time. This change was based on a response from the secretary of the island board, who wrote that the DST "changeover" occurred at 2:00 local time. However, reading that comment again, my impression is that he was only referring to the start time, not also the end time. The Standard Time Act of New South Wales says that the summer time period starts and ends at 2:00, but at least in the mainland of New South Wales this is interpreted as 2:00 standard time, so I believe that it should be so for Lord Howe Island as well. All other Australian locations in the database show "2:00s". https://legislation.nsw.gov.au/view/whole/html/inforce/current/act-1987-149 Whether the DST end time is 2:00 or 2:30 local time probably has no practical consequence, as at that time everything is closed on the island and people are asleep. But for precision, I think that it would be useful to confirm this with someone on the island again. Regards, David

2 1

Paraguay Timezone change
by Martin Vuyk March 27, 2025

March 27, 2025

Hi, sorry but I don't have much time to get into the code and submit a patch following your guidelines. The timezone in Paraguay has changed to not have daylight saving time anymore. It is officially GMT-3. This is the official government website: https://www.paraguaytv.gov.py/2024/10/15/paraguay-ya-no-cambiara-su-hora-se… A lot of systems went crazy because some changed the timezone and some didn't. I have some headaches at work already on a Sunday (yay). AFAIK this database is the source of truth for most systems. But I don't know how fast you could change this and it getting pushed to all devices. Please let me know if there is any way I can help fix this ASAP. Kind Regards, Martin Vuyk L.

10 20

Paraguayan Time Zone Error
by Hugo Ortiz March 24, 2025

March 24, 2025

The local goberment of Paraguay stabloshed the GMT-3 time zone for paraguay without no more changes on timezone. Since the 00:00 of 23/03 time zone shifted to GMT-4 on many devices. The paraguayan time zone must stay on GMT-3

2 1

Solicitud de actualización de la zona horaria de Paraguay en la base de datos de IANA
by milciades meza March 24, 2025

March 24, 2025

Estimado equipo de mantenimiento de la base de datos de zonas horarias, Mi nombre es Milciades Meza y me gustaría solicitar una actualización en la base de datos de zonas horarias de IANA en relación con Paraguay. El Gobierno de Paraguay ha decretado oficialmente que el país permanecerá en GMT-3 durante todo el año, eliminando el cambio a GMT-4. Sin embargo, muchos dispositivos electrónicos continúan cambiando automáticamente a GMT-4 debido a que la base de datos de IANA aún mantiene la configuración anterior. Agradeceríamos mucho que puedan actualizar la base de datos para reflejar esta decisión gubernamental y evitar confusiones en los sistemas operativos y dispositivos que dependen de esta información. Para referencia, aquí está el decreto oficial emitido por el Gobierno de Paraguay: [Incluir enlace al decreto o documento oficial si está disponible] Agradezco su tiempo y atención a esta solicitud. Por favor, avísenme si requieren información adicional. Atentamente, Ciudadano de Paraguay Obtener Outlook para Android<https://aka.ms/AAb9ysg>

2 1

[PATCH] No need for America/Coyhaique in zonenow.tab
by Paul Eggert March 23, 2025

March 23, 2025

* zonenow.tab (America/Coyhaique): Remove, since it’s the same as America/Sao_Paolo from now on, given today’s change. --- zonenow.tab | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/zonenow.tab b/zonenow.tab index 6aa41678..093f0a0c 100644 --- a/zonenow.tab +++ b/zonenow.tab @@ -96,8 +96,6 @@ XX +1828-06954 America/Santo_Domingo Atlantic Standard ("AST") - eastern Caribbe # # -04/-03 (Chile DST) XX -3327-07040 America/Santiago most of Chile -# -04/-03 (Chile DST) until 2025-04-06; then -03 -XX -4534-07204 America/Coyhaique Aysén Region # # -04/-03 - AST/ADT (North America DST) XX +4439-06336 America/Halifax Atlantic ("AST/ADT") - Canada; Bermuda @@ -106,7 +104,7 @@ XX +4439-06336 America/Halifax Atlantic ("AST/ADT") - Canada; Bermuda XX +4734-05243 America/St_Johns Newfoundland ("NST/NDT") # # -03 -XX -2332-04637 America/Sao_Paulo eastern South America +XX -2332-04637 America/Sao_Paulo eastern and southern South America # # -03/-02 (North America DST) XX +4703-05620 America/Miquelon St Pierre & Miquelon -- 2.45.2

5 5

[tz-announce] 2025b release of tz code and data available
by Paul Eggert via tz-announce March 22, 2025

March 22, 2025

The 2025b release of the tz code and data is available. This release contains the following changes: Briefly: New zone for Aysén Region in Chile which moves from -04/-03 to -03. Changes to future timestamps Chile's Aysén Region moves from -04/-03 to -03 year-round, joining Magallanes Region. The region will not change its clocks on 2025-04-05 at 24:00, diverging from America/Santiago and creating a new zone America/Coyhaique. (Thanks to Yonathan Dossow.) Model this as a change to standard offset effective 2025-03-20. Changes to past timestamps Iran switched from +04 to +0330 on 1978-11-10 at 24:00, not at year end. (Thanks to Roozbeh Pournader.) Changes to code 'zic -l TIMEZONE -d . -l /some/other/file/system' no longer attempts to create an incorrect symlink, and no longer has a read buffer underflow. (Problem reported by Evgeniy Gorbanev.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025b.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 7e1145bfdb9630c127841dc8ce808a937a300938 dated 2025-03-22 13:40:46 -0700 and tagged '2025b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 19826b12968c10fc4db7e4b07ba782bfb8590eeebaec6f719d74b92a2e642ab817bd72bceff0015ce52a838edfdb00753b3cd87dd84b35abf2606e5bee445f76 tzcode2025b.tar.gz 7d83741f3cae81fac8131994b43c55b6da7328df18b706e5ee40e9b3212bc506e6f8fc90988b18da424ed59eff69bce593f2783b7b5f18eb483a17aeb94258d6 tzdata2025b.tar.gz 4f4afca86645ca5564a9d7d3ddc36e6b07c15c1b87cd4edbbcae72c6be4e6154e4ad1966407a7081237550301f1093af53dd8a486effb95f7cf3e5721db47c8f tzdb-2025b.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRcACgkQ7ZfpDmKq fjRqwhAAjdPreNSN3pJoZiSwQNVk6oUneEHRlNVDFw1d+DflHG2QW4Cw7wWSRaYi B+yxIV1C61ZwhkAQ1AlscFbpzvHcOtNLEgK5VTwOpgBJ0FsmsEzVUCkGYFtWDpPw qf6ZgdtSrmaPX/V+ceWrRE0oQUjFnlQEO3cwGITlcYlck9YUiQZ+y1gOzPypN+v1 YHuVzoMk4ESTTI/glEJljOQfNcl+GvgnMZRNdZWafpjJ2y68JLofEgemKgJqTu9J IKE6Age2fn2P1lyXlFg1ZTzm11XDIWa8cz37rabNqaybKICeMppSEiIp+BcrMl4p ntQwJyytmm8g2AyGUdHEa9rN97pTag8zzBNmQX/5clcYWIvlp964ul9ptXrBkexN iv+Xi2U1zFg+Wo+ytMyj1q5fhBPTe1rNsnngbrgbGFx0t5h+OOVIPxMCAQiKgGg3 w6V59jgKThJ4EbFaCKV1tN3eThxeSrmCEb6zQEGlS5QKOyTnpQNCEAlJlJ+JyeDo tMbPfCzR9EJjrrMB50qMNK9bXJK3NjsOVicJkv4aruVPfPZ1RrAD6ZDTUk7Yxo9x WHT68C2XIde67N7UIcV4gWgbuZKKagkqPnt+dtn8C/5EML1ANEhtF2is0PqqTXpI ol9XLYC5mnlEQB/F1Bu7EppPCMu7qCaFWQCbvvXaaYjUhiupFPU= =EgQ1 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRcACgkQ7ZfpDmKq fjS6yw//Wdqj0sipbfTMHAJh3y5065wUkwJhi4cbMbpG1MfJ7HQOeF/ISXBnQo2L RIzpRPswIUweKziBQx5+f+VgViWJTJRTbb2Vk0i1SfnQ6BfeEmqIXwxa87rSeCEk vBeur6mnv3Nc/f9HVvKBqx9ux6FIPWMoQbuDZyNh/GfAvrCp69YkC4miZlo8D1M5 QKoNqLB2B/JTeFVdchVYu9Jxyc2LGsSM9SDTuDDHKQyMyZN/93vJiSzfUMkzW6AF dJif5zWaj2YfrcMFP87IMKH9rAA6XrKNbf+0Xu7AWKpMW6vu30NyMoLQvuo1Gf0g uFxqFTu7fVt6ZzO2cVFuzS/MPj8pufPng88gOHpU34ASID5DB5hf98r7fxmn3jwc aBiecrqpq4F4GEqrBQHGVugFM95iBElvl5kEupO0C/8wqvV7gWoo8Qiaix7b/DE4 zpc4z8wNHntqjeP3Qrv+zX9wfZThYoX/j8UuIVZEhm1o/vHeNn5zBZz55jCQ4KOc Sffl68lWjdLkcS4edsaM1GyPsFnqaFP6FZ95zrhyl/mpsDNJggIaL3RuajMIMCBt othXosBAuBKlv3gqXBIEDaifp2aqBo0YgUUJhcVtyv+advzcUgeppnMUPh0US66R inVSt7pMQ8ubYcDQzDchoVPEay/69SPaRRd3W9unQGCBepjaXGo= =W7AG -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmffIRkACgkQ7ZfpDmKq fjRvqQ//cupgXsGqL6buntdGU8QnbY79jmNbXkuzSbjiAx+uh+sCoS34Rr9eO4Kg mFdVaPqZ704ZvI7yzh6amjpkwdYalmhjVogJ3AIHSlAV69UgedztED18AjQ53/Hj gRqqppZacgUmVO4GqybEb/f4toWfnVi8HuCY++q1WkMgQsAqOE9DIJlJOTK5BAEo Iy6+vAigXc7LyveyBP/2yOOoPTkWTRTURfXHXgQxgKuGtDJHnp12j2MPhzag5s64 KrInD6ZB1ZcpDw9BpDd+LmB1gZizwShadXbiMOi8ROC6JwR8oafZJq3rwonSkJLH kMg6VUQr3cQmu8Zd5s9yYpZmx4rMBR+9Hsz5bn0cBLSe478LtmoKI6vI37mZ048S PRTwlHnXi1/RuxovhusPiaoAf3VUN8IxhL2V4NV9D2Pn+iu3Fhj35BlM3XOn1RpH 3K3qi/Wr4XRX6jlPLQ42opBnkKorL21+Tz21+yHDOXxbF+9fYmZOaMaZwl3AjX66 QbWEN8FG+2UEOHVSyxjLKru97TV+RXSo/A1IBwTHALeaiLSc+V1zSTMMrAQVSDPm Rn1VXPc9Jff00LEM0CElS4X719d/0a0Knbs9OjIbp2bmZEun8zTGHOPEtJ8PWrc6 ficDmgynqV89laKtZ7VsUoMgHEKv7dCs1HdFBYQ5qvWW/JiKZhU= =qJJK -----END PGP SIGNATURE-----

1 0

Adjust to coverage of TZ America/Punta_Arenas
by Eduardo Romero Urra March 22, 2025

March 22, 2025

Dear Paul, The government of Chile announce adjust of coverage of Time Zone "Región de Magallanes y la Antártica Chilena" , now extend their coverage to Region "Región de Aysén del General Carlos Ibáñez del Campo," . This region coverages the following Cities: Coyhaique , Puerto Aysen and Cochrane . This area keeps all the year on UTC -03 Timezone . I've attach the link https://www.diariooficial.interior.gob.cl/publicaciones/2025/03/20/44104/01… Best regards ━━━━━━━━ Eduardo Romero Urra Asesor de Sistemas División de Redes y Seguridad Informática +56224863218 Ministerio del Interior y Seguridad Pública Gobierno de Chile CONFIDENCIALIDAD Y USO EXCLUSIVO: La información contenida en este mensaje y/o en los archivos adjuntos son de carácter confidencial y está destinada al uso exclusivo del emisor y/o de la persona o entidad a quien va dirigida, y por lo mismo pueden ser consultados y revisados por la entidad emisora o propietaria de los sistemas desde donde fueron enviados.- Si usted no es el destinatario, cualquier almacenamiento, divulgación, distribución o copia de esta información está estrictamente prohibida y sancionada por la ley. Si recibió este mensaje por error, por favor infórmenos inmediatamente respondiendo este mismo mensaje y borre éste y todos los archivos adjuntos. Considerando que no existe certidumbre de que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico, el emisor original no será responsable si el contenido del mismo ha sido modificado. Ministerio del Interior y Seguridad Publica<https://www.interior.gob.cl>

2 1

[PROPOSED] northamerica: mention Daylight Bill
by Paul Eggert March 20, 2025

March 20, 2025

--- northamerica | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/northamerica b/northamerica index 8d356aa0..20b47b48 100644 --- a/northamerica +++ b/northamerica @@ -1611,6 +1611,15 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # For more on Orillia, see: Daubs K. Bold attempt at daylight saving # time became a comic failure in Orillia. Toronto Star 2017-07-08. # https://www.thestar.com/news/insight/2017/07/08/bold-attempt-at-daylight-sa… +# From Paul Eggert (2025-03-20): +# Also see the 1912-06-17 front page of The Evening Sunbeam, +# reproduced in: Richardson M. "Daylight saving was a confusing +# time in Orillia" in the 2025-03-15 Orillia Matters. Richardson writes, +# "The first Sunday after the switch was made, [DST proponent and +# Orillia mayor William Sword] Frost walked into church an hour late. +# This became a symbol of the downfall of daylight saving in Orillia." +# The mayor became known as "Daylight Bill". +# https://www.orilliamatters.com/local-news/column-daylight-saving-was-a-conf… # From Mark Brader (2010-03-06): # -- 2.45.2

1 0

Chile's Aysén Region polled about switching from -04/-03 to -03 all year
by Paul Eggert March 20, 2025

March 20, 2025

Beginning this week and continuing through the end of the month, the citizens of Chile's Aysén Region are being polled virtually for a non-binding resolution[1] to switch from the their current timekeeping regime TZ="America/Santiago" (-04 in winter, -03 in summer) to permanent -03 (like TZ="America/Punta_Arenas"). If this happens, we'll need to create a new Zone America/Coyhaique to record the change, which would likely have practical effect on 2025-04-05 at the earliest. Unfortunately, the SurveyMonkey form used for the poll requires no authentication, which raised plausible worries this week about ballot-stuffing[2]. [1]: https://www.diarioregionalaysen.cl/noticia/actualidad/2024/11/lanzan-consul… [2]: https://www.diarioregionalaysen.cl/noticia/actualidad/2024/11/encuesta-sobr…

3 4

Iran's transition from +04:00 to +03:30 in 1978
by Roozbeh Pournader March 18, 2025

March 18, 2025

I hunted down the exact time of Iran's transition from +0400 to +0330. It was Friday 1357/8/19 AP=1978-11-10. Here's a newspaper clip from the Ettela'at newspaper, dated 1357/8/14 AP=1978-11-05, translated from Persian (at https://w.wiki/DUEY) "Following the government's decision about returning the official time to the previous status, the spokesperson for the Ministry of Energy announced today: At the hour 24 of Friday 19th of Aban (=1978-11-10), the country's time will be pulled back half an hour. In this way, the country's official time which in the last thirty months had been moved forward by about an hour and a half will return to its previous status." I will double-check the various other transition times for 1977 to 1980, but at the first glance they are either correct or may only be off by at most a day or two. Thanks a lot, Roozbeh

2 2

Leave
by Javier Esquivel Téllez March 18, 2025

March 18, 2025

leave *La información contenida en este correo electrónico y sus documentos adjuntos es confidencial y privilegiada y para el uso único y exclusivo del destinatario, por lo que queda estrictamente prohibido el uso, reproducción, retransmisión o divulgación no autorizada de su contenido. Si recibió este mensaje por error, por favor notifíquelo al remitente y bórrelo junto con sus documentos adjuntos de inmediato.* *SAFTU TECNOLOGIAS, S.A.P.I. de C.V. (SAFTU) es el responsable del uso y protección de sus datos personales. Cualquier dato personal o sensible recibido o enviado libre y voluntariamente por su titular en el presente correo se protegerá de acuerdo al aviso y políticas de privacidad de SAFTU, y será tratado para los fines descritos en el mismo, incluyendo para organizar bases de datos, prestarle los servicios o información solicitada, y mantener la comunicación. Si usted es titular de datos personales en posesión de SAFTU, y desea obtener más información sobre los términos y condiciones en que serán tratados y la forma en que podrá ejercer sus derechos ARCO, puede consultar nuestro aviso de privacidad integral en www.saftu.com <http://www.saftu.com/>*

1 0

Dump of Asia/Tehran changes?
by Roozbeh Pournader March 18, 2025

March 18, 2025

Can someone please kindly give me a dump of Asia/Tehran changes according to the latest tzdata for the years 1977-1981? I'm trying to piece together the newspaper bits and pieces and compare with the tz database, and it seems that there is clearly some transitions missing. Specifically, I find the following lines confusing: 4:00 Iran %z 1979 3:30 Iran %z Does that mean we think Iran switched from UTC+4:00 to UTC+3:30 on Jan 1, 1979? Thanks a lot, Roozbeh

3 3

[PROPOSED] Cite Neumann & von Blanckenburg’s 2025 DST review
by Paul Eggert March 15, 2025

March 15, 2025

* tz-link.html (Costs and benefits of time shifts): Add citation and brief summary. --- tz-link.html | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/tz-link.html b/tz-link.html index f4f76fdd..ad2cc972 100644 --- a/tz-link.html +++ b/tz-link.html @@ -985,6 +985,14 @@ a Sleep Research Society position statement</a>. doi:<a href="https://doi.org/10.1093/sleep/zsac236">10.1093/sleep/zsac236</a>. After reviewing the scientific literature, the Sleep Research Society advocates permanent standard time due to its health benefits. +<li>Neumann P, von Blanckenburg K. <a +href="https://journals.sagepub.com/doi/full/10.1177/0961463X241310562">What +time will it be? A comprehensive literature review on daylight saving time</a>. +<em>Time Soc</em>. 2025-01-21. +doi:<a href="https://doi.org/10.1177/0961463X241310562">10.1177/0961463X241310562</a>. +This reviews DST's effects on electricity, health, crime, road safety, +and the economy, focusing on research since 2010, and concludes that +year-round standard time is preferable overall. <li>Rishi MA, Cheng JY, Strang AR <em>et al</em>. <a href="https://jcsm.aasm.org/doi/10.5664/jcsm.10898">Permanent standard time is the optimal choice for health and safety: -- 2.45.2

1 0

false story re canceling DST in Canaries and Spain
by Paul Eggert March 15, 2025

March 15, 2025

Last week saw a widely spread false story that daylight saving time will be canceled in Spain and in the Canary Islands, starting in the year 2026. The story was reported as fact in the Daily Mirror[1], which evidently got it from the Canarian Weekly[2]. Both stories said that the last clock change would be this month (implying permanent daylight saving time), that the change would officially take place in 2026 (contradicting the last-clock-change assertion), and that this had been confirmed by the Official State Gazette (BOE), i.e., Spain's Boletín Oficial del Estado. As Gazette Life noted Thursday[3], the story is false. There is no change to Spain's timekeeping plans. I guess the bogus story is based on a misreading of Order PCM/186/2022 dated 2022-03-11[4], which listed DST transitions for 2022 through 2026. A copy of this old order was recently marked as updated by BOE (I don't know why), and my guess is that the "new" order popped up on some reporter's AI, which generated the hallucination that Spain was discontinuing DST. This reminds me of the 2023 false story about Greenland abolishing DST that was first published, as far as I can determine[5], by Bloomberg's Lebawit Lily Girma. Although I had an email correspondence about that bogus story with two Bloomberg editors, the bogus story was never corrected or retracted. I expect the same thing would happen with the Daily Mail and the Canarian Weekly, so I am not bothering to write them. We can expect more of these falsehoods in the era of generative AI, which makes it easier to write bogus stories that superficially look authentic. I am seeing considerably more use of generative AI even in scholarly papers on the subject. [1]: Bautista A. Huge EU country loved by Brits will stop changing clocks in 2026. The Mirror. 2025-03-11. https://www.mirror.co.uk/travel/huge-eu-country-loved-brits-34832825 [2]: The Canary Islands are set to abandon clock changes from 2026. Canarian Weekly. 2025-03-09. https://www.canarianweekly.com/posts/The-Canary-Islands-are-set-to-abandon-… [3]: No change on clocks for Spain and Canaries. Gazette Life. 2025-03-13. https://gazettelife.com/news/no-change-on-clocks-for-spain-and-canaries/ [4]: Orden PCM/186/2022, de 11 de marzo, por la que se publica el calendario del período de la hora de verano correspondiente a los años 2022 a 2026. https://www.boe.es/eli/es/o/2022/03/11/pcm186 [5]: Eggert P. Did Greenland abolish daylight saving from 2024 on? https://mm.icann.org/pipermail/tz/2023-April/032870.html

1 0

Ireland Time Zone
by Chris Brown March 11, 2025

March 11, 2025

Hello, We received a notification from a customer that the Ireland Time Zones sprung forward too early. According to what I found the following is true: Last Sunday of March 01:00 GMT - Last Sunday of October 01:00 GMT = GMT+1 Last Sunday of October 01:00 GMT - Last Sunday of March 01:00 GMT = GMT+0 As of the time this issue was reported the Eire (GMT+1) and Europe/Dublin (GMT+1) time zones need to be GMT+0, however, they are GMT+1. Are there any standard troubleshooting tips I can pass along to our developers? I’m looking through the documentation I can find and the threads and have seen a couple regarding Irelands time zones, but nothing conclusive on how to solve our issue moving forward. I’d like to understand if this is an error, or if there is a configuration we need to make on our end to ensure the time zones are correct in our system. [cid:image001.jpg@01DB927E.D1C45080] [Meazure Learning]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.meazurelearning.com…> meazurelearning.com [Facebook]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.facebook.com%2FMeaz…> [X]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fx.com%2Fmeazurelearning…> [LinkedIn]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.linkedin.com%2Fcomp…> Christopher Brown Product Manager [cid:image006.png@01DB927E.D1C45080] cbrown(a)meazurelearning.com<mailto:cbrown@meazurelearning.com> [cid:image007.png@01DB927E.D1C45080] 205-807-0349<tel:205-807-0349> [cid:image008.png@01DB927E.D1C45080] 205-807-0349<tel:205-807-0349> [cid:image009.png@01DB927E.D1C45080] Alabama, US (35244) [cid:image010.png@01DB927E.D1C45080]

2 1

Paraguay DST is no longer in use
by Nicolas Elisardo Garcia March 7, 2025

March 7, 2025

Paraguay currently observes Paraguay Time (PYT) all year. DST is no longer in use. Clocks do not change in Paraguay. The previous DST change in Paraguay was on October 15, 2024. Is there a new software release available for this update? Thanks in advance, Regards. Este mensaje y todos los archivos adjuntos a él son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Claro o alguna de las empresas accionistas. La publicación, uso, copia e impresión total o parcial de este mensaje o documentos adjuntos queda prohibida. Cualquier situación y/o comportamiento que pudiera resultar contrario a lo establecido en el Código de Ética disponible en https://www.americamovil.com/Spanish/gobierno-corporativo/Programa-de-Integ… - comunicarlo, incluso anónimamente, a través de la página web https://denuncias.americamovil.com/. This message and any attachments are for exclusive usage of an addressee and may contain confidential or privileged information whose disclosure is subject to penalty by law. If you are not the addressee, please notify the sender by return e-mail, delete the original message and destroy any existing copy no matter if printed or recorded. Any opinions contained in this e-mail are those of the author of the message and do not necessarily coincide with those of Claro or its shareholders. No part of this message or attachments may be used or reproduced in any manner whatsoever. Any situation and/or behavior that could be contrary to the provisions of the Code of Ethics available at https://www.americamovil.com/English/corporate-governance/integrity-and-com… - report it, even anonymously, through the website https://denuncias.americamovil.com/. Este mensaje y todos los archivos adjuntos a él son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Claro o alguna de las empresas accionistas. La publicación, uso, copia e impresión total o parcial de este mensaje o documentos adjuntos queda prohibida. Cualquier situación y/o comportamiento que pudiera resultar contrario a lo establecido en el Código de Ética disponible en https://www.americamovil.com/Spanish/gobierno-corporativo/Programa-de-Integ… - comunicarlo, incluso anónimamente, a través de la página web https://denuncias.americamovil.com/. This message and any attachments are for exclusive usage of an addressee and may contain confidential or privileged information whose disclosure is subject to penalty by law. If you are not the addressee, please notify the sender by return e-mail, delete the original message and destroy any existing copy no matter if printed or recorded. Any opinions contained in this e-mail are those of the author of the message and do not necessarily coincide with those of Claro or its shareholders. No part of this message or attachments may be used or reproduced in any manner whatsoever. Any situation and/or behavior that could be contrary to the provisions of the Code of Ethics available at https://www.americamovil.com/English/corporate-governance/integrity-and-com… - report it, even anonymously, through the website https://denuncias.americamovil.com/.

7 6

Re: buffer overflow in zic
by Paul Eggert March 6, 2025

March 6, 2025

On 2025-03-05 21:56, Евгений Горбанев wrote: > I found this scenario while researching the postgresql code using Svace > static analyzer. > Well, try this scenario: > > $ cd /tmp > $ wget https://data.iana.org/time-zones/releases/tzdb-2025a.tar.lz > $ tar xf tzdb-2025a.tar.lz > $ cd tzdb-2025a > $ make CFLAGS='-fsanitize=address -g' > $ touch test > $ ./zic -l test -d . Thanks for the explanation and recipe. I can reproduce the problem. Please try the attached proposed patch. I installed it into the development repository <https://github.com/eggert/tz>. Thanks.

1 0

buffer overflow in zic
by Evgeniy Gorbanev March 5, 2025

March 5, 2025

Hello! IfoundthatifI runzictocreatea linkonanotherdevice, the bufferoverflowinzip.c:1422inversion2025awill occur. Inthislinei==0. The commandtoreplay: ./zic -l test -d . -t /path/to/link_on_another_device Best regards, Evgeniy Gorbanyov

4 4

DST offsets other than +1
by Doug Ewell March 4, 2025

March 4, 2025

1. Are there any time zones that currently observe DST with an offset other than adding one hour? (For this question, I am treating “negative DST” zones like Europe/Dublin and Africa/Windhoek as if they observed “standard” time in winter and adjusted time in summer. Also, for this question I am only interested in current practice, not historical.) 2. Is there an easy way I could have looked up this information in the tz files? (“Easy” means without exhaustively parsing all the Rule and Zone lines, as a processor would have to do.) Thanks, -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

6 8

North Dakota HB 1259 requiring year-round standard time
by asinglet＠epic.com March 1, 2025

March 1, 2025

https://legiscan.com/ND/text/HB1259/2025 HB 1259 passed the North Dakota House last week. No idea on whether it will pass the ND Senate or be signed into law. The tricky thing about this bill is that it does not have an implementation time frame. Theoretically if it moves through in the next week or two, we could be looking at a repeat of the Lebanon 2023 fiasco. I hope if they are going to pass it, they take their time.

4 4

Maryland HB1290
by Arthur Olson Feb. 21, 2025

Feb. 21, 2025

The hearing on Maryland House Bill 1290, "Full-Year Daylight Saving Time," has been cancelled: https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb1290 In past years such bills died in committee, but only having had a hearing; this is the earliest death yet for such a bill. Perhaps the state legislators have more important matters on their minds this year. @dashdashado

2 1

EST5EDT should not resolve to America/New_York because they have different offsets
by Austin Hill Feb. 21, 2025

Feb. 21, 2025

Hello - I recently filed a GitHub issue against the perl DateTime::TimeZone library, which uses your database: https://github.com/houseabsolute/DateTime-TimeZone/issues/58#issue-28644459… I noticed that EST5EDT now resolves to America/New_York. This is problematic because the two do not have the same offset - EST5EDT is -5:00 and America/New_York is -04:56:02. My ticket was closed because the behavior appears to be caused by changes in your database in commit a0b09c0 ( https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03 ). Is this something that you would consider changing? Thanks! - Austin Hill

9 16

localized date without time
by Alejandro Colomar Feb. 12, 2025

Feb. 12, 2025

Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

5 17

ELIZA Reanimated
by Brooks Harris Jan. 23, 2025

Jan. 23, 2025

ELIZA Reanimated: The world’s first chatbot restored on the world’s first time sharing system https://arxiv.org/pdf/2501.06707 Has anyone asked ELIZA what time it is?

3 3

Re: Notice of a problem with the Asia/Tokyo time zone
by Paul Eggert Jan. 22, 2025

Jan. 22, 2025

> From: Patrick BENNY <patrick.benny(a)mixi.co.jp> > Date: Mon, Jan 20, 2025 at 6:41 PM > The Asia/Tokyo time zone seems to have been linked with Australia, probably > by mistake. > Please see this related difference from the zone1970.tab file, observed > when comparing 2024b and 2025a. > > 186c186 > < JP +353916+1394441 Asia/Tokyo > --- >> JP,AU +353916+1394441 Asia/Tokyo Eyre Bird Observatory > > The Eyre Bird Observatory should probably be linked with an Australian time > zone instead of Asia/Tokyo. Actually that line should be OK, as the Eyre Bird Observatory region (unlike the rest of Australia) has observed Tokyo time since 1970. The comments at the start of zone1970.tab say this about the "Eyre Bird Observatory" in column 4: # Comments; present if and only if countries have multiple timezones, # and useful only for those countries. For example, the comments # for the row with countries CH,DE,LI and name Europe/Zurich # are useful only for DE, since CH and LI have no other timezones. "Eyre Bird Observatory" is useful only for AU, since JP has no other timezones; so this is another example of that column-4 idea.

4 4

Medovukha factory in Kazakhstan advances its clocks by 1/20 of a day
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

Last year's move to unify Kazakhstan into a single UTC+05 time zone is seeing some pushback. In "Anger over Kazakh Time Zones" (2024-12-24)[1] RFE/RL's Chris Rickleton and Tasqyn Bolatuly reported that one lawmaker asserted that a majority his party in parliament would support a law to reverse the decision. Although government executive officials still strongly support the move, we'll need to keep an eye on the situation. Rickleton and Bolatuly also reported how one private firm is addressing the problem: > Almas Tangytuli, the owner of a company that produces medovukha, a honey-based alcoholic drink similar to mead, says he is already doing something similar. > > After struggling with the new time, he set the clocks at his factory just east of Oskemen forward by a 1 1/5 hour for the sake of his workers, who keep livestock in villages nearby. > > "After work, there was no time for them to sort out their barns in the steppe, where there is no lighting. In the morning, their cattle make a rush for the fields. You can't tell cattle that the clocks have changed," Tangytuli told RFE/RL. 1 1/5 hour is 72 minutes, or 1/20 of a day. I wonder where Tangytuli got that number? Oskemen is about 5.5 hours ahead of UTC, so he has overcorrected and is about 0.7 hours ahead of local mean time; surely this is not entirely for the sake of the cows. The fractional hour vaguely reminds me of William Willett's 1907 proposal to implement daylight saving time by advancing clocks by 20 minutes each in four successive Sundays.[2] But although Willett wanted his construction workers to get to his worksites earlier during the day, he wrote nothing about his workers' cows. [1]: https://www.rferl.org/a/33249639.html [2]: https://www.webexhibits.org/daylightsaving/willett.html

1 0

Re: [tz-announce] 2025a release of tz code and data available
by Paul Eggert Jan. 21, 2025

Jan. 21, 2025

On 2025-01-16 11:21, Geert Hendrickx wrote: > On Thu, Jan 16, 2025 at 09:37:50 -0800, Paul Eggert via tz-announce via tz wrote: >> ... Paraguay adopts permanent -03 starting spring 2024. > > starting spring *2025* ? Actually, "spring 2024" is correct. Release 2025a says the legal change occurred in Paraguay on 2024-10-15 at 00:00, which is spring in the southern hemisphere. The clocks didn't change then: only tm_isdst changed, and since tm_isdst is obsolescent that wasn't enough to prompt a new TZDB release right away. The first change to predicted timestamps is this year on March 22 at 00:00, when Paraguay is now predicted to stay at -03 instead of falling back from -03 to -04. This will be autumn in the southern hemisphere.

1 1

[tz-announce] 2025a release of tz code and data available
by Paul Eggert via tz-announce Jan. 16, 2025

Jan. 16, 2025

The 2025a release of the tz code and data is available. This release contains the following changes: Briefly: Paraguay adopts permanent -03 starting spring 2024. Improve pre-1991 data for the Philippines. Etc/Unknown is now reserved. Changes to future timestamps Paraguay will stop changing its clocks after the spring-forward transition on 2024-10-06, so it is now permanently at -03. (Thanks to Heitor David Pinto and Even Scharning.) This affects timestamps starting 2025-03-22, as well as the obsolescent tm_isdst flags starting 2024-10-15. Changes to past timestamps Correct timestamps for the Philippines before 1900, and from 1937 through 1990. (Thanks to P Chan for the heads-up and citations.) This includes adjusting local mean time before 1899; fixing transitions in September 1899, January 1937, and June 1954; adding transitions in December 1941, November 1945, March and September 1977, and May and July 1990; and removing incorrect transitions in March and September 1978. Changes to data Add zone1970.tab lines for the Concordia and Eyre Bird Observatory research stations. (Thanks to Derick Rethans and Jule Dabars.) Changes to code strftime %s now generates the correct numeric string even when the represented number does not fit into time_t. This is better than generating the numeric equivalent of (time_t) -1, as strftime did in TZDB releases 96a (when %s was introduced) through 2020a and in releases 2022b through 2024b. It is also better than failing and returning 0, as strftime did in releases 2020b through 2022a. strftime now outputs an invalid conversion specifier as-is, instead of eliding the leading '%', which confused debugging. An invalid TZ now generates the time zone abbreviation "-00", not "UTC", to help the user see that an error has occurred. (Thanks to Arthur David Olson for suggesting a "wrong result".) mktime and timeoff no longer incorrectly fail merely because a struct tm component near INT_MIN or INT_MAX overflows when a lower-order component carries into it. TZNAME_MAXIMUM, the maximum number of bytes in a proleptic TZ string's time zone abbreviation, now defaults to 254 not 255. This helps reduce the size of internal state from 25480 to 21384 on common platforms. This change should not be a problem, as nobody uses such long "abbreviations" and the longstanding tzcode maximum was 16 until release 2023a. For those who prefer no arbitrary limits, you can now specify TZNAME_MAXIMUM values up to PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently misbehaved unless TZNAME_MAXIMUM was less than INT_MAX. tzset and related functions no longer leak a file descriptor if another thread forks or execs at about the same time and if the platform has O_CLOFORK and O_CLOEXEC respectively. Also, the functions no longer let a TZif file become a controlling terminal. 'zdump -' now reads TZif data from /dev/stdin. (From a question by Arthur David Olson.) Changes to documentation The name Etc/Unknown is now reserved: it will not be used by TZDB. This is for compatibility with CLDR, which uses the string "Etc/Unknown" for an unknown or invalid timezone. (Thanks to Justin Grant, Mark Davis, and Guy Harris.) Cite Internet RFC 9636, which obsoletes RFC 8536 for TZif format. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2025a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2025a.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 a8e2fcd87bc5f83fec0a76652095e8d7881b0763 dated 2025-01-15 10:47:24 -0800 and tagged '2025a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 308f6a3d6ebfa18446f8296e5c799e18dccecd79ace3ba004d3f233892c7428faae152b217b22d229c59dd4e0faafee797d8b3583b58fa982b81f7cc7347f502 tzcode2025a.tar.gz 93b8f939d39bdfe451e262666f9099c529c96c49d14c08e3611560ca660e12e16d08a22b145d615e00570fb194881618d6f9a0a617c119ab447be03279d747c3 tzdata2025a.tar.gz 1e8c4e141158d63ca5c39babc9d18c32df14e2e59bc7649a7fed8c3e577f7b175bafa43883cf351139ff198515f5f8c22b1418e2ac7efb7f837faa8f61d2574d tzdb-2025a.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjT4TA//dFIBsmsl3OJ7QdI3lnySSQWyNnZQjsue3qtw7dUp0nbbFd7QGegrVDSC zrY+v51AVm9sk9hLdLQuyVFm5xRqXuBp2fC70wFeCCocEMp4HnhOogJVXMqQz+Dy AFZ8U7HmtNUI+ca9MTw6WTpQ5DOy6Of5rer3LbicmzBgVQ/UNcoIFZs4qf+RnMYY GKOHfLDLhs/4fQf3+zfELLbavieOoqcQlp8HntZrCuR2zZZNImVkt0/ljtTnHqd/ b0KUMDbYQ2dGsNbpBQS5GhAUjVPeUB5npqfA0ibS1gv1e99yWwGeMmUY3GqFbQWn dNN5LTceS9/H/+thtgN+70g4b2Haz+So91AiXKMNxgvb9qkjqV+2ZFd04ud4hapz +rRV8y1VDP/QEmXwL4zMnx+xkzGr3xTh+0z67R3RBIbL5eRGQojjKN1BLkYTWRsx VfaI51+GJWKjlX1Mo9OoSGGWgRWPgn591dYcep+cKA9jYSMzO48VOsdABIt3tTbX 7zqONqpDt6JZJJL7UdH2A0Lik8nkGFnSAnuuwW948CGh26odotoXAC15xWbK18VN v6T+zGZoLR8PdVlIYPjNUyS0sqo6tZtHa3Nci99+A5XG30oX+ecz/zlyDuRBLWkI 31bmm5423PHZ4N94Yi2V6xAC2G7mHn9m7eYv71C6Pg6fs5vOTgA= =2Ldn -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2oACgkQ7ZfpDmKq fjREhxAAjB1QDroFoq07V+56IIrJR3pK/x4Z2jBbg53N49Cam1oMZK5Wxm291d0G lPutNQvjiNubnBG4pgMMQ2xEF6jgYY0eFfLlORGK9IoW8e3lnlAqSR9BsOQvWjeA lKfmBkhFXetSJ8gu2ModVybpVIqDaJJ73sNQSsA01MHwz0RLV5CLOHXitJ8lBO68 vdSArRhalLUEIVytAKyy1a0msFdzrrDj/7q6tMV9NDY1xQg4V9TLxnPNds29H0x8 xO2zrDug6zrbg9z994JYkhq9h9DLe5h4F3StnaDwRK8eLLRq5D7ryK77Z8dtyXZf tDPgiNc1MquSg48481dDiUfsRdN5S2OLVFqjyWUuwVKBSkSRv/nBQqisGEybY86T H84D5WA0zlj8mFJyuKFmvGHzzKZ6X7mUNrTObaY3G+QHgHjIKWqO7oog447YOYOG DSA5rSmYrzZp2RXP/doeFZD+2kbNVPlN8zBh6lANABwvFH6IhDI+/OJzGJqeYotz ZWVoU3um6aToMS4Uv2PdBNbH1W1P1pzzMM5TJ/bQO/ujCwaBSTwoDPJT6tW9BLrO gJUWd1AumocieAWc0Vyzbrpzbo7Vc//1LF+s1eI+zWt8925unFrBArvQ4h/PyXsc O5LhOQVm1986y9xy2YyF+Cy5s+xsKvKENQ0NbLIDa+l5MdEdEXc= =NQgW -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmeIA2sACgkQ7ZfpDmKq fjQkcQ/+MWIjE3J5FETCaYxUvElzWIN25Jx4p3dBp4CL/UqD9qW/3CRiRt7KbS5Q 2C1+Hg5DKGAJJ/9/L72t4ttMheskUkGyI/M/xWuG2EKMRPJd3zEPZItSfJOtbBwo vmmTIe9s/yZTkmeoMQ/PVdhci6rwifwUEopxq3V2pTBIBnj6H+hBlSLL8Y7RgbWQ yDlzf1HvfnQ+4xlhtcDNb49iljlrPEwUJZe+2RSPmxAtAHe6SJK4i9tSQlv0fJew whM0//rlihNKRG04TFJ4lw5UeueCKhLL8E/HLbLewVcJcbd4pHMFNmdxi17VHmZj IG1tj75Ff69dyuZiCkuOe9S5SzKlI40FEU3aN1k7wWz3PzBbGBWt9CMxNY35DpLF Di23QeTOvdDEEccjivRVyNc4mwthnylOcmKcE5RYhT45W+Tpr0BhLnE29/ZwZ3Dy EB8wQJvGZWh6LVK2C7unEmQaYmPD+pl8WoZ9MmZHnR0YmNd/NfcefKX/UenLs5+J HIifuTWnzRfA4DQTbV+l/kNUzOo/asoD98qQ6/2inDEQWCZpg1V1sOFcHVYkb6XX LT7PUnC5eiKS8U47KBzTTwkEAWij/LKD+gnksjfkzU/Pn5MpzXm4qwVo7v9yuEal i4nIbqzuY8iK0SYBw0da8W10dFtB3bgtfUuSTXQLCP8sWVI34bY= =B68m -----END PGP SIGNATURE-----

1 0

Re: Windows compile failure for iana time zones
by Paul Eggert Jan. 15, 2025

Jan. 15, 2025

On 1/13/25 05:17, Manuela Friedrich wrote: > It seems that your commit 1ee9daa91818f5d4ab6937352453813fa333e105 > fails with: > localtime.c(309): error C2099: initializer is not a constant Thanks for reporting that. Which compiler are you using and what version and what compiler flags are you using? Does the following uninstalled patch fix things for you? If not, what's the value of _MSC_VER when you use your compiler flags? diff --git a/private.h b/private.h index 0a546e02..3e64da4e 100644 --- a/private.h +++ b/private.h @@ -26,7 +26,11 @@ because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 -# define PORT_TO_C89 0 +# if defined _MSC_VER && _MSC_VER < 1800 +# define PORT_TO_C89 1 +# else +# define PORT_TO_C89 0 +# endif #endif /* SUPPORT_C89 means the tzcode library should support C89 callers Perhaps we could use the patch with a different value in place of 1800, or perhaps we should just remove the " && _MSC_VER < 1800". Microsoft says[1] that it didn't add support for C99-style compound literals until Visual Studio 2013. Are you using an older version of MSVC? If so, it's past end-of-life[2] and I doubt whether we should worry about it. [1]: https://learn.microsoft.com/en-us/previous-versions/visualstudio/visual-stu… [2]: https://devblogs.microsoft.com/visualstudio/support-ends-for-older-versions…

3 5

Paraguay may adopt permanent DST soon
by Heitor David Pinto Jan. 13, 2025

Jan. 13, 2025

Today the Congress of Paraguay passed a bill to observe UTC-3 permanently, equivalent to permanent DST. The bill still needs to be approved by the president. https://www.abc.com.py/politica/2024/09/24/congreso-sanciona-horario-de-ver… The text of the bill says that it would enter into force on the first Sunday in October 2024, the same date currently scheduled to start DST. But in practice, it would only make a difference from the fourth Sunday of March 2025, the date currently scheduled to end DST. https://silpy.congreso.gov.py/web/expediente/132531

10 20

[PROPOSED 1/3] Alias asctime, ctime result
by Paul Eggert Jan. 10, 2025

Jan. 10, 2025

I misread C99, and in a 2022-11-30 patch caused asctime and ctime to return different pointers when !SUPPORT_C89. However, C99 and later still require that these two functions return the same pointers, so revert that part of the 2022-11-30 change. * asctime.c (buf_ctime): Remove. All uses replaced with buf_asctime. --- asctime.c | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/asctime.c b/asctime.c index 1bfcafe9..491d23bf 100644 --- a/asctime.c +++ b/asctime.c @@ -30,16 +30,6 @@ enum { STD_ASCTIME_BUF_SIZE = 26 }; */ static char buf_asctime[2*3 + 5*INT_STRLEN_MAXIMUM(int) + 7 + 2 + 1 + 1]; -/* A similar buffer for ctime. - C89 requires that they be the same buffer. - This requirement was removed in C99, so support it only if requested, - as support is more likely to lead to bugs in badly written programs. */ -#if SUPPORT_C89 -# define buf_ctime buf_asctime -#else -static char buf_ctime[sizeof buf_asctime]; -#endif - /* On pre-C99 platforms, a snprintf substitute good enough for us. */ #if !HAVE_SNPRINTF # include <stdarg.h> @@ -86,8 +76,7 @@ asctime_r(struct tm const *restrict timeptr, char *restrict buf) register const char * mn; int year, mday, hour, min, sec; long long_TM_YEAR_BASE = TM_YEAR_BASE; - size_t bufsize = ((buf == buf_ctime - || (!SUPPORT_C89 && buf == buf_asctime)) + size_t bufsize = (buf == buf_asctime ? sizeof buf_asctime : STD_ASCTIME_BUF_SIZE); if (timeptr == NULL) { -- 2.47.1

1 2

v2024b Mexico rules
by Ertan Küçükoglu Jan. 8, 2025

Jan. 8, 2025

Hello, Below is a section taken from v2024b northamerica file # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - April 30 0:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S Rule Mexico 1940 only - Dec 9 0:00 1:00 D Rule Mexico 1941 only - Apr 1 0:00 0 S Rule Mexico 1943 only - Dec 16 0:00 1:00 W # War Rule Mexico 1944 only - May 1 0:00 0 S Rule Mexico 1950 only - Feb 12 0:00 1:00 D Rule Mexico 1950 only - Jul 30 0:00 0 S Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S If you look closely, the first rule has the full month name April written and not a three letter short version like the rest of the list. I wonder if that is the new format and not an error. Thanks & Regards, Ertan

2 1

[PROPOSED 1/7] Modernize date man page
by Paul Eggert Jan. 8, 2025

Jan. 8, 2025

* date.1: Update the example to next year. Remove duplication of spec with strftime, as this is too much of a pain to maintain separately for what is just a demo; but give an example for clarity. Update list of files accessed, to match current code. --- date.1 | 110 +++++++++------------------------------------------------ 1 file changed, 16 insertions(+), 94 deletions(-) diff --git a/date.1 b/date.1 index 01907bc7..9b025bc9 100644 --- a/date.1 +++ b/date.1 @@ -35,7 +35,7 @@ command without arguments writes the date and time to the standard output in the form .ce 1 -Wed Mar 8 14:54:40 EST 1989 +Sat Mar 8 14:54:40 EST 2025 .br with .B EST @@ -49,92 +49,17 @@ If a command-line argument starts with a plus sign (\c .q "\fB+\fP" ), the rest of the argument is used as a .I format -that controls what appears in the output. -In the format, when a percent sign (\c -.q "\fB%\fP" -appears, -it and the character after it are not output, -but rather identify part of the date or time -to be output in a particular way -(or identify a special character to output): -.nf -.sp -.if t .in +.5i -.if n .in +2 -.ta \w'%M\0\0'u +\w'Wed Mar 8 14:54:40 EST 1989\0\0'u - Sample output Explanation -%a Wed Abbreviated weekday name* -%A Wednesday Full weekday name* -%b Mar Abbreviated month name* -%B March Full month name* -%c Wed Mar 08 14:54:40 1989 Date and time* -%C 19 Century -%d 08 Day of month (always two digits) -%D 03/08/89 Month/day/year (eight characters) -%e 8 Day of month (leading zero blanked) -%h Mar Abbreviated month name* -%H 14 24-hour-clock hour (two digits) -%I 02 12-hour-clock hour (two digits) -%j 067 Julian day number (three digits) -%k 2 12-hour-clock hour (leading zero blanked) -%l 14 24-hour-clock hour (leading zero blanked) -%m 03 Month number (two digits) -%M 54 Minute (two digits) -%n \\n newline character -%p PM AM/PM designation -%r 02:54:40 PM Hour:minute:second AM/PM designation -%R 14:54 Hour:minute -%S 40 Second (two digits) -%t \\t tab character -%T 14:54:40 Hour:minute:second -%U 10 Sunday-based week number (two digits) -%w 3 Day number (one digit, Sunday is 0) -%W 10 Monday-based week number (two digits) -%x 03/08/89 Date* -%X 14:54:40 Time* -%y 89 Last two digits of year -%Y 1989 Year in full -%z -0500 Numeric time zone -%Z EST Time zone abbreviation -%+ Wed Mar 8 14:54:40 EST 1989 Default output format* -.if t .in -.5i -.if n .in -2 -* The exact output depends on the locale. -.sp -.fi -If a character other than one of those shown above appears after -a percent sign in the format, -that following character is output. -All other characters in the format are copied unchanged to the output; -a newline character is always added at the end of the output. -.PP -In Sunday-based week numbering, -the first Sunday of the year begins week 1; -days preceding it are part of -.q "week 0" . -In Monday-based week numbering, -the first Monday of the year begins week 1. -.PP -To set the date, use a command line argument with one of the following forms: -.nf -.if t .in +.5i -.if n .in +2 -.ta \w'198903081454\0'u -1454 24-hour-clock hours (first two digits) and minutes -081454 Month day (first two digits), hours, and minutes -03081454 Month (two digits, January is 01), month day, hours, minutes -8903081454 Year, month, month day, hours, minutes -0308145489 Month, month day, hours, minutes, year - (on System V-compatible systems) -030814541989 Month, month day, hours, minutes, four-digit year -198903081454 Four-digit year, month, month day, hours, minutes -.if t .in -.5i -.if n .in -2 -.fi -If the century, year, month, or month day is not given, -the current value is used. -Any of the above forms may be followed by a period and two digits that give -the seconds part of the new time; if no seconds are given, zero is assumed. +that is processed by +.BR strftime (3) +to determine what to output; +a newline character is appended. +For example, the shell command: +.ce 1 +date +"%Y\*-%m\*-%d %H:%M:%S %z" +.br +outputs a line like +.q "2025\*-03\*-08 14:54:40 \*-0500" +instead. .PP These options are available: .TP @@ -149,16 +74,13 @@ past the epoch of 1970-01-01 00:00:00 UTC, where should be an integer, either decimal, octal (leading 0), or hexadecimal (leading 0x), preceded by an optional sign. .SH FILES -.ta \w'/usr/share/zoneinfo/posixrules\0\0'u +.ta \w'/usr/share/zoneinfo/Etc/UTC\0\0'u /etc/localtime local timezone file .br /usr/lib/locale/\f2L\fP/LC_TIME description of time locale \f2L\fP .br /usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete) -.br -/usr/share/zoneinfo/GMT for UTC leap seconds -.PP -If /usr/share/zoneinfo/GMT is absent, -UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. +/usr/share/zoneinfo/Etc/UTC for UTC leap seconds +.SH SEE ALSO +.BR strftime (3). -- 2.47.1

1 6

Fwd: Bulletin C number 69
by Tim Parenti Jan. 7, 2025

Jan. 7, 2025

No leap second 2025-06-30, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Tue, 7 Jan 2025 at 05:00 Subject: Bulletin C number 69 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 06 January 2025 Bulletin C 69 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2025. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Y2K on the radio
by Arthur Olson Dec. 31, 2024

Dec. 31, 2024

With a New Year looming, an NPR Y2K review. (Alas, no mention of T2G in 2038.) @dashdashado https://www.npr.org/2024/12/28/nx-s1-5116271/y2k-year-2000-preparations

3 2

[PROPOSED] For timestamps compare to HEAD not to index
by Paul Eggert Dec. 30, 2024

Dec. 30, 2024

Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2024-12/msg00245.html * Makefile (set-timestamps.out): When comparing working file to repository, Use ‘git diff HEAD’ instead of plain ‘git diff’. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ffdbfe3b..e00b0f32 100644 --- a/Makefile +++ b/Makefile @@ -1104,7 +1104,7 @@ set-timestamps.out: $(EIGHT_YARDS) touch -md @1 test.out; then \ rm -f test.out && \ for file in $$files; do \ - if git diff --quiet $$file; then \ + if git diff --quiet HEAD $$file; then \ time=$$(TZ=UTC0 git log -1 \ --format='tformat:%cd' \ --date='format:%Y-%m-%dT%H:%M:%SZ' \ -- 2.47.1

1 0

Deprecate two digit year formats %D %g %y
by Brian Inglis Dec. 29, 2024

Dec. 29, 2024

Hi folks, [Spurred by NPR Y2K review article.] Could we please all make a New Year's resolution to stop people from reviving two digit year formats that are starting to reappear, making it impossible to figure out some intended dates, and officially deprecate all two digit year formats %D %g %y across all standards, and tools default to options like gcc's and clang's -Wformat-y2k (included in -Wformat=2) and clang's -Wdeprecate. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Request for inclusion of Trivandrum in the IANA Time Zone Database
by Anish shivaraj Dec. 28, 2024

Dec. 28, 2024

Dear tzdata Maintainers, I am writing to propose the inclusion of Trivandrum (Thiruvananthapuram) as a new entry in the IANA Time Zone Database (tzdata). As the capital city of Kerala, Trivandrum holds significant historical, economic, and technological importance, and its addition to the database would reflect its growing prominence. Justification for Inclusion Population and Prominence With a population exceeding 1 million, Trivandrum is well above the 300,000 threshold for inclusion.The city serves as a political, cultural, and economic hub in southern India. Economic Growth and Commercial Significance Vizhinjam International Seaport: Trivandrum is home to India’s first transshipment port, the Vizhinjam International Seaport, which is expected to position the city as a major player in global shipping and logistics. Emerging Commercial Hub: The growth of the Vizhinjam port has already made Trivandrum an important center for commerce, attractingsignificant investments and fostering local economic development. Technological and Space Research Importance India’s First IT Park: Technopark in Trivandrum is the country’s first and one of the largest IT parks, contributing greatly to India’s IT industry. Space Research and Education: The city houses the Vikram Sarabhai Space Centre (VSSC), a key institution for India’s space exploration efforts. Trivandrum also hosts the Indian Institute of Space Science and Technology (IIST) and the Kerala Space Park, making it a critical hub for space research and innovation. Eligibility Based on Time Zone Criteria Unique Timekeeping History: Trivandrum once had its own local mean time before the adoption of Indian Standard Time (IST), making this distinction relevant for its case. Representative Need: As an emerging commercial, technological,and research center, a separate time zone entry would provide better representation for the region’s users and applications. Alignment with tzdata Objectives - Trivandrum meets the criteria of significant population, historical relevance, and global contributions to shipping, IT, and space research, making it a suitable candidate for inclusion. Proposed Time Zone Entry We suggest adding the following entry: Zone Asia/Trivandrum +05:30 - Trivandrum Standard Time Including Trivandrum in the tzdata database would provide better localization and reflect its growing importance. Thank you for considering this request. Should you require further information or clarification, please do not hesitate to reach out. Best regards, Anish Sivarajan

3 3

Re: Iana build failures on Windows
by Paul Eggert Dec. 19, 2024

Dec. 19, 2024

On 2024-12-17 07:53, Manuela Friedrich wrote: > It's worth noticing that I had to add -DHAVE_SYS_STAT_H=0 to the tools.ini > file we use on Windows. Thanks for mentioning that, but unfortunately I don't know why -DHAVE_SYS_STAT_H=0 was needed (I don't use MS-Windows). Some fumbling with Microsoft documentation eventually led me to <https://learn.microsoft.com/en-us/cpp/c-runtime-library/compatibility?view=…> which hints (but does not say) that by default MS-Windows <sys/stat.h> doesn't define the 'stat' function if you use some compilation options. I installed the attached patch to try to work around this portability problem. Does this patch fix things so that -DHAVE_SYS_STAT_H=0 need not be added to tools.ini? If not, what problems do you observe? With the patch, do you see warnings when compiling? Does compiling with -D_CRT_SECURE_NO_WARNINGS cut down on the number of warnings? What's in your tools.ini file for building tzcode?

2 3

Re: Iana build failures on Windows
by Paul Eggert Dec. 17, 2024

Dec. 17, 2024

On 2024-12-15 23:11, Manuela Friedrich wrote: > localtime.c > d:\devsrc\treasure_test\iana\tmp\private.h(872): warning C4005: 'max': > macro redefinition > C:\Program Files (x86)\Windows > Kits\10\include\10.0.16299.0\ucrt\stdlib.h(1300): note: see previous > definition of 'max' > d:\devsrc\treasure_test\iana\tmp\private.h(873): warning C4005: 'min': > macro redefinition > C:\Program Files (x86)\Windows > Kits\10\include\10.0.16299.0\ucrt\stdlib.h(1301): note: see previous > definition of 'min' > localtime.c(418): error C2065: 'utc': undeclared identifier > localtime.c(418): warning C4047: ':': 'const char *' differs in levels of > indirection from 'int' > localtime.c(1449): error C2065: 'utc': undeclared identifier > localtime.c(1449): warning C4047: 'function': 'const char *' differs in > levels of indirection from 'int' > localtime.c(1449): warning C4024: 'strcpy': different types for formal and > actual parameter 2 > NMAKE : U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64\cl.EXE"' > : return code '0x2' Thanks for reporting these build glitches on MS-Windows. I installed the attached patches; please give them a try, as I don't use that platform.

1 0

Daylight Saving in the news
by Arthur Olson Dec. 15, 2024

Dec. 15, 2024

"Trump vows to end 'very costly' daylight saving time" (While Mexico may not pay for it, Mexico and Canada may follow suit.) https://www.bbc.com/news/articles/cn9gjvgv4neo @dashdashado

3 4

How permanent daylight saving time or permanent standard time would affect the USA
by Jonathan Leffler Dec. 13, 2024

Dec. 13, 2024

Article in the Washington Post about how early or late you would be in the dark if the USA adopted permanent daylight saving time or permanent standard time (compared with now). https://www.washingtonpost.com/nation/interactive/2024/no-daylight-saving-t… With decent interactive graphics. I'm a subscriber; I don't know if there's a paywall in place. -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

12 16

[PROPOSED] Fix asctime.o, strftime.o dependencies
by Paul Eggert Dec. 11, 2024

Dec. 11, 2024

* Makefile (asctime.o): Don’t depend on tzfile.h. (strftime.o): Depend on tzdir.h, as it’s included indirectly via localtime.c if MKTIME_MIGHT_OVERFLOW. --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2aafdc24..8faab6ff 100644 --- a/Makefile +++ b/Makefile @@ -1355,11 +1355,11 @@ long-long.ck unsigned.ck: $(VERSION_DEPS) zonenames: tzdata.zi @$(AWK) '/^Z/ { print $$2 } /^L/ { print $$3 }' tzdata.zi -asctime.o: private.h tzfile.h +asctime.o: private.h date.o: private.h difftime.o: private.h -localtime.o: private.h tzfile.h tzdir.h -strftime.o: localtime.c private.h tzfile.h +localtime.o: private.h tzdir.h tzfile.h +strftime.o: localtime.c private.h tzdir.h tzfile.h zdump.o: version.h zic.o: private.h tzfile.h tzdir.h version.h -- 2.47.1

1 0

[PROPOSED] Fix to2050.tzs timestamp in distributed tarball
by Paul Eggert Dec. 11, 2024

Dec. 11, 2024

* Makefile (TZS_DEPS): Remove asctime.c and add localtime.c. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 5473dedd..2aafdc24 100644 --- a/Makefile +++ b/Makefile @@ -615,8 +615,8 @@ TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs TZS_NEW= to$(TZS_YEAR)new.tzs -TZS_DEPS= $(YDATA) asctime.c localtime.c \ - private.h tzfile.h zdump.c zic.c +TZS_DEPS= $(YDATA) localtime.c private.h \ + strftime.c tzfile.h zdump.c zic.c TZDATA_DIST = $(COMMON) $(DATA) $(MISC) # EIGHT_YARDS is just a yard short of the whole ENCHILADA. EIGHT_YARDS = $(TZDATA_DIST) $(DOCS) $(SOURCES) tzdata.zi -- 2.47.1

1 0

Add ICU's Etc/Unknown Zone to IANA Time Zone Database?
by Justin Grant Dec. 11, 2024

Dec. 11, 2024

Hi TZ friends - Should the time zone identifier "Etc/Unknown" (standardized in Unicode Technical Standard 35 and used by the ICU <https://icu.unicode.org/> library that implements time zone support in all major web browsers, in Java, and in other platforms) be added to the IANA Time Zone Database? Etc/Unknown would behave the same as the existing time zone identifier "Factory". Ideally, Etc/Unknown could be a Zone and Factory could be turned into a Link pointing to Etc/Unknown, because both of them have the meaning of "the time zone of this computer is not known" but Etc/Unknown is more self-describing and is better aligned with modern Zone naming conventions. Here's more context: "Etc/Unknown" is standardized in https://unicode.org/reports/tr35/#Time_Zone_Identifiers. Here's the relevant text from the standard: > There is a special code "unk" for an Unknown or Invalid time zone. > This can be expressed in the tz database style ID "Etc/Unknown", > although it is not defined in the tz database. Following this standard, Etc/Unknown is returned by ICU <https://icu.unicode.org/> when the time zone of a computer cannot be determined. Here's an example of an ICU method that can return Etc/Unknown: icu::TimeZone::detectHostTimeZone() <https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/classicu_1_1TimeZon…> . The fact that Etc/Unknown looks like an IANA identifier but is not actually in TZDB has been a long-running source of problems. Most recently, this week Chrome is rushing out a patch <https://issues.chromium.org/issues/381620359> that reverted a recent change that added support for the "Factory" zone by making it an alias for "Etc/Unknown". GIven that ICU previously didn't recognize Factory and so returned Etc/Unknown for computers in the Factory zone, this was assumed by everyone to be a safe change. But this change turned out to break some 3rd-party libraries and had to be reverted. After discussing this recent bug with engineers at Google, our consensus was that it'd be helpful for the time zone ecosystem if Etc/Unknown stopped being a special case and started being a regular Zone in the IANA Time Zone database. Especially if we could Link-ify Factory at the same time so that Zone picker UIs won't have two distinct "I don't know what time zone this is" choices. Thanks for considering this proposal. Best, Justin Grant

10 28

[PROPOSED] Fix unlikely multithreaded file descriptor leak
by Paul Eggert Dec. 9, 2024

Dec. 9, 2024

On multithreaded platforms, tzset could leak a file descriptor into a forked or execed process. Fix the leak. While we’re at it, don’t let the TZif file become the controlling tty. * NEWS: Mention this. * localtime.c (O_CLOEXEC, O_CLOFORK, O_IGNORE_CTTY, O_NOCTTY): Default to 0. (tzloadbody): Use these flags when opening the TZif file. --- NEWS | 5 +++++ localtime.c | 22 +++++++++++++++++----- 2 files changed, 22 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 79686147..2fc7bb19 100644 --- a/NEWS +++ b/NEWS @@ -56,6 +56,11 @@ Unreleased, experimental changes PTRDIFF_MAX, a limit forced by C anyway; formerly tzcode silently misbehaved unless TZNAME_MAXIMUM was less than INT_MAX. + tzset and related functions no longer leak a file descriptor if + another thread forks or execs at about the same time and if the + platform has O_CLOFORK and O_CLOEXEC respectively. Also, the + functions no longer let a TZif file become a controlling terminal. + Changes to documentation The name Etc/Unknown is now reserved: it will not be used by TZDB. diff --git a/localtime.c b/localtime.c index 492965d9..f92676c6 100644 --- a/localtime.c +++ b/localtime.c @@ -96,12 +96,23 @@ typedef intmax_t timex_t; # define TZ_ABBR_ERR_CHAR '_' #endif /* !defined TZ_ABBR_ERR_CHAR */ -/* -** Support non-POSIX platforms that distinguish between text and binary files. -*/ +/* Port to platforms that lack some O_* flags. Unless otherwise + specified, the flags are standardized by POSIX. */ #ifndef O_BINARY -# define O_BINARY 0 +# define O_BINARY 0 /* MS-Windows */ +#endif +#ifndef O_CLOEXEC +# define O_CLOEXEC 0 +#endif +#ifndef O_CLOFORK +# define O_CLOFORK 0 +#endif +#ifndef O_IGNORE_CTTY +# define O_IGNORE_CTTY 0 /* GNU/Hurd */ +#endif +#ifndef O_NOCTTY +# define O_NOCTTY 0 #endif #ifndef WILDABBR @@ -542,7 +553,8 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } if (doaccess && access(name, R_OK) != 0) return errno; - fid = open(name, O_RDONLY | O_BINARY); + fid = open(name, (O_RDONLY | O_BINARY | O_CLOEXEC | O_CLOFORK + | O_IGNORE_CTTY | O_NOCTTY)); if (fid < 0) return errno; -- 2.47.0

1 0

US Department of Transportation map of US timezones
by Roozbeh Pournader Dec. 7, 2024

Dec. 7, 2024

I just found out through https://x.com/RedistrictNet/status/1863742503242875046 That the US Department of Transportation has just rolled out an official map of US timezones. It's supposed to be at: https://geodata.bts.gov/datasets/usdot::time-zones/about (It doesn't load for me at the moment, possibly due to high demand.) Roozbeh

11 12

[PROPOSED] Fix checknow confusing diagnostics
by Paul Eggert Dec. 7, 2024

Dec. 7, 2024

* checknow.awk: Do not report a duplicate (and confusing) diagnostic when a zone has no data. --- checknow.awk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/checknow.awk b/checknow.awk index 8b7881d2..450490ee 100644 --- a/checknow.awk +++ b/checknow.awk @@ -44,7 +44,7 @@ BEGIN { END { for (zone in zone_data) { data = zone_data[zone] - if (!zonenow[data]) { + if (data && !zonenow[data]) { printf "Zone table should have one of:%s\n", zones[data] zonenow[data] = zone # This suppresses duplicate diagnostics. status = 1 -- 2.47.0

1 0

[PROPOSED 1/3] Pacify gcc -Wsuggest-attribute=format sans snprintf in zdump
by Paul Eggert Dec. 1, 2024

Dec. 1, 2024

* zdump.c (my_snprintf): Now a static function defined only if !HAVE_SNPRINTF, with "#define snprintf my_sprintf" at the end. This lessens disruption to mainline code. All uses changed. Add ATTRIBUTE_FORMAT((printf, 3, 4)) to pacify gcc -Wsuggest-attribute=format. --- zdump.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/zdump.c b/zdump.c index c988f6b3..ea051adf 100644 --- a/zdump.c +++ b/zdump.c @@ -914,13 +914,10 @@ showextrema(timezone_t tz, char *zone, time_t lo, struct tm *lotmp, time_t hi) } } -#if HAVE_SNPRINTF -# define my_snprintf snprintf -#else +/* On pre-C99 platforms, a snprintf substitute good enough for us. */ +#if !HAVE_SNPRINTF # include <stdarg.h> - -/* A substitute for snprintf that is good enough for zdump. */ -static int +ATTRIBUTE_FORMAT((printf, 3, 4)) static int my_snprintf(char *s, size_t size, char const *format, ...) { int n; @@ -948,6 +945,7 @@ my_snprintf(char *s, size_t size, char const *format, ...) va_end(args); return n; } +# define snprintf my_snprintf #endif /* Store into BUF, of size SIZE, a formatted local time taken from *TM. @@ -962,10 +960,10 @@ format_local_time(char *buf, ptrdiff_t size, struct tm const *tm) { int ss = tm->tm_sec, mm = tm->tm_min, hh = tm->tm_hour; return (ss - ? my_snprintf(buf, size, "%02d:%02d:%02d", hh, mm, ss) + ? snprintf(buf, size, "%02d:%02d:%02d", hh, mm, ss) : mm - ? my_snprintf(buf, size, "%02d:%02d", hh, mm) - : my_snprintf(buf, size, "%02d", hh)); + ? snprintf(buf, size, "%02d:%02d", hh, mm) + : snprintf(buf, size, "%02d", hh)); } /* Store into BUF, of size SIZE, a formatted UT offset for the @@ -1000,10 +998,10 @@ format_utc_offset(char *buf, ptrdiff_t size, struct tm const *tm, time_t t) mm = off / 60 % 60; hh = off / 60 / 60; return (ss || 100 <= hh - ? my_snprintf(buf, size, "%c%02ld%02d%02d", sign, hh, mm, ss) + ? snprintf(buf, size, "%c%02ld%02d%02d", sign, hh, mm, ss) : mm - ? my_snprintf(buf, size, "%c%02ld%02d", sign, hh, mm) - : my_snprintf(buf, size, "%c%02ld", sign, hh)); + ? snprintf(buf, size, "%c%02ld%02d", sign, hh, mm) + : snprintf(buf, size, "%c%02ld", sign, hh)); } /* Store into BUF (of size SIZE) a quoted string representation of P. @@ -1106,7 +1104,7 @@ istrftime(char *buf, ptrdiff_t size, char const *time_fmt, for (abp = ab; is_alpha(*abp); abp++) continue; len = (!*abp && *ab - ? my_snprintf(b, s, "%s", ab) + ? snprintf(b, s, "%s", ab) : format_quoted_string(b, s, ab)); if (s <= len) return false; @@ -1114,7 +1112,7 @@ istrftime(char *buf, ptrdiff_t size, char const *time_fmt, } formatted_len = (tm->tm_isdst - ? my_snprintf(b, s, &"\t\t%d"[show_abbr], tm->tm_isdst) + ? snprintf(b, s, &"\t\t%d"[show_abbr], tm->tm_isdst) : 0); } break; -- 2.43.0

1 2

[PATCH 1/2] Be more consistent about macro true/false vs 1/0
by Paul Eggert Nov. 29, 2024

Nov. 29, 2024

* private.h (HAVE_GETTEXT, HAVE_SYS_STAT_H, HAVE_UNISTD_H) (HAVE_STDINT_H, HAVE_STRTOLL, HAVE_STDCKDINT_H) (HAVE_DECL_TIMEGM): * strftime.c (MKTIME_MIGHT_OVERFLOW, DEPRECATE_TWO_DIGIT_YEARS): Default to 1 or 0, not to true or false, since these can be set via the command line as per the Makefile. * private.h (TZ_TIME_T): Set to true or false, not to 1 or 0, since this is boolean and is not set via the command line. --- private.h | 26 +++++++++++++------------- strftime.c | 6 +++--- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/private.h b/private.h index 6088d885..1e4e69a4 100644 --- a/private.h +++ b/private.h @@ -88,11 +88,11 @@ #if !defined HAVE_GETTEXT && defined __has_include # if __has_include(<libintl.h>) -# define HAVE_GETTEXT true +# define HAVE_GETTEXT 1 # endif #endif #ifndef HAVE_GETTEXT -# define HAVE_GETTEXT false +# define HAVE_GETTEXT 0 #endif #ifndef HAVE_INCOMPATIBLE_CTIME_R @@ -125,20 +125,20 @@ #if !defined HAVE_SYS_STAT_H && defined __has_include # if !__has_include(<sys/stat.h>) -# define HAVE_SYS_STAT_H false +# define HAVE_SYS_STAT_H 0 # endif #endif #ifndef HAVE_SYS_STAT_H -# define HAVE_SYS_STAT_H true +# define HAVE_SYS_STAT_H 1 #endif #if !defined HAVE_UNISTD_H && defined __has_include # if !__has_include(<unistd.h>) -# define HAVE_UNISTD_H false +# define HAVE_UNISTD_H 0 # endif #endif #ifndef HAVE_UNISTD_H -# define HAVE_UNISTD_H true +# define HAVE_UNISTD_H 1 #endif #ifndef NETBSD_INSPIRED @@ -312,7 +312,7 @@ ** stdint.h, even with pre-C99 compilers. */ #if !defined HAVE_STDINT_H && defined __has_include -# define HAVE_STDINT_H true /* C23 __has_include implies C99 stdint.h. */ +# define HAVE_STDINT_H 1 /* C23 __has_include implies C99 stdint.h. */ #endif #ifndef HAVE_STDINT_H # define HAVE_STDINT_H \ @@ -386,7 +386,7 @@ typedef int int_fast32_t; # ifdef LLONG_MAX typedef long long intmax_t; # ifndef HAVE_STRTOLL -# define HAVE_STRTOLL true +# define HAVE_STRTOLL 1 # endif # if HAVE_STRTOLL # define strtoimax strtoll @@ -466,7 +466,7 @@ typedef unsigned long uintmax_t; hosts, unless compiled with -DHAVE_STDCKDINT_H=0 or with pre-C23 EDG. */ #if !defined HAVE_STDCKDINT_H && defined __has_include # if __has_include(<stdckdint.h>) -# define HAVE_STDCKDINT_H true +# define HAVE_STDCKDINT_H 1 # endif #endif #ifdef HAVE_STDCKDINT_H @@ -634,9 +634,9 @@ typedef unsigned long uintmax_t; ** typical platforms. */ #if defined time_tz || EPOCH_LOCAL || EPOCH_OFFSET != 0 -# define TZ_TIME_T 1 +# define TZ_TIME_T true #else -# define TZ_TIME_T 0 +# define TZ_TIME_T false #endif #if defined LOCALTIME_IMPLEMENTATION && TZ_TIME_T @@ -753,9 +753,9 @@ void tzset(void); || defined __GLIBC__ || defined __tm_zone /* musl */ \ || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ || (defined __APPLE__ && defined __MACH__)) -# define HAVE_DECL_TIMEGM true +# define HAVE_DECL_TIMEGM 1 # else -# define HAVE_DECL_TIMEGM false +# define HAVE_DECL_TIMEGM 0 # endif #endif #if !HAVE_DECL_TIMEGM && !defined timegm diff --git a/strftime.c b/strftime.c index fc0c87d2..487a5234 100644 --- a/strftime.c +++ b/strftime.c @@ -79,9 +79,9 @@ !defined __NetBSD_Version__ || __NetBSD_Version__ < 600000000) \ && (/* OpenBSD 5.5 (2014-05-01) and later has 64-bit time_t. */ \ !defined OpenBSD || OpenBSD < 201405))) -# define MKTIME_MIGHT_OVERFLOW true +# define MKTIME_MIGHT_OVERFLOW 1 # else -# define MKTIME_MIGHT_OVERFLOW false +# define MKTIME_MIGHT_OVERFLOW 0 # endif #endif /* Check that MKTIME_MIGHT_OVERFLOW is consistent with time_t's range. */ @@ -95,7 +95,7 @@ static_assert(MKTIME_MIGHT_OVERFLOW #endif #ifndef DEPRECATE_TWO_DIGIT_YEARS -# define DEPRECATE_TWO_DIGIT_YEARS false +# define DEPRECATE_TWO_DIGIT_YEARS 0 #endif struct lc_time_T { -- 2.43.0

1 1

[PROPOSED 1/2] Remove dependency of asctime on strftime
by Paul Eggert Nov. 28, 2024

Nov. 28, 2024

Also, remove calls to strlen and strcpy. * asctime.c (ASCTIME_FMT, ASCTIME_FMT_B): Remove; the strings are now merely literals in asctime_r. (SNPRINTF, SNPRINTFBUF): New macros. (asctime_r): Do not call strftime %Y, as this is dicey when tm_year is not a value that could be yielded by localtime. Instead, use snprintf, or sprintf on ancient hosts lacking snprintf. Also, rely on snprintf/sprintf's return value instead of calling strlen, as it's safe to assume C89 b6 now. If snprintf is available, output to the result buffer directly instead of to the stack and then copying. This saves one call to strftime, two calls to strlen, and one call to strcpy. * private.h (HAVE_SNPRINTF): Move here ... * zdump.c: ... from here. --- asctime.c | 96 +++++++++++++++++++++++++++++++------------------------ private.h | 4 +++ zdump.c | 4 --- 3 files changed, 58 insertions(+), 46 deletions(-) diff --git a/asctime.c b/asctime.c index f75ec868..7bc19fd1 100644 --- a/asctime.c +++ b/asctime.c @@ -7,6 +7,7 @@ /* ** Avoid the temptation to punt entirely to strftime; +** strftime can behave badly when tm components are out of range, and ** the output of strftime is supposed to be locale specific ** whereas the output of asctime is supposed to be constant. */ @@ -16,27 +17,6 @@ #include "private.h" #include <stdio.h> -/* -** All years associated with 32-bit time_t values are exactly four digits long; -** some years associated with 64-bit time_t values are not. -** Vintage programs are coded for years that are always four digits long -** and may assume that the newline always lands in the same place. -** For years that are less than four digits, we pad the output with -** leading zeroes to get the newline in the traditional place. -** The -4 ensures that we get four characters of output even if -** we call a strftime variant that produces fewer characters for some years. -** This conforms to recent ISO C and POSIX standards, which say behavior -** is undefined when the year is less than 1000 or greater than 9999. -*/ -static char const ASCTIME_FMT[] = "%s %s%3d %.2d:%.2d:%.2d %-4s\n"; -/* -** For years that are more than four digits we put extra spaces before the year -** so that code trying to overwrite the newline won't end up overwriting -** a digit within a year and truncating the year (operating on the assumption -** that no output is better than wrong output). -*/ -static char const ASCTIME_FMT_B[] = "%s %s%3d %.2d:%.2d:%.2d %s\n"; - enum { STD_ASCTIME_BUF_SIZE = 26 }; /* ** Big enough for something such as @@ -84,8 +64,20 @@ asctime_r(struct tm const *restrict timeptr, char *restrict buf) }; register const char * wn; register const char * mn; - char year[INT_STRLEN_MAXIMUM(int) + 2]; - char result[sizeof buf_asctime]; + int year, mday, hour, min, sec; + size_t bufsize = ((buf == buf_ctime + || (!SUPPORT_C89 && buf == buf_asctime)) + ? sizeof buf_asctime : STD_ASCTIME_BUF_SIZE); +#if HAVE_SNPRINTF + char *result = buf; +# define SNPRINTF snprintf +# define SNPRINTFBUF(buf, bufsize) buf, bufsize +#else + char stackbuf[sizeof buf_asctime]; + char *result = stackbuf; +# define SNPRINTF sprintf +# define SNPRINTFBUF(buf, bufsize) buf +#endif if (timeptr == NULL) { errno = EINVAL; @@ -97,26 +89,46 @@ asctime_r(struct tm const *restrict timeptr, char *restrict buf) if (timeptr->tm_mon < 0 || timeptr->tm_mon >= MONSPERYEAR) mn = "???"; else mn = mon_name[timeptr->tm_mon]; - /* - ** Use strftime's %Y to generate the year, to avoid overflow problems - ** when computing timeptr->tm_year + TM_YEAR_BASE. - ** Assume that strftime is unaffected by other out-of-range members - ** (e.g., timeptr->tm_mday) when processing "%Y". - */ - strftime(year, sizeof year, "%Y", timeptr); - /* - ** We avoid using snprintf since it's not available on all systems. - */ - sprintf(result, - ((strlen(year) <= 4) ? ASCTIME_FMT : ASCTIME_FMT_B), - wn, mn, - timeptr->tm_mday, timeptr->tm_hour, - timeptr->tm_min, timeptr->tm_sec, - year); - if (strlen(result) < STD_ASCTIME_BUF_SIZE - || buf == buf_ctime || buf == buf_asctime) + + year = timeptr->tm_year; + mday = timeptr->tm_mday; + hour = timeptr->tm_hour; + min = timeptr->tm_min; + sec = timeptr->tm_sec; + + /* Vintage programs are coded for years that are always four bytes long + and may assume that the newline always lands in the same place. + For years that are less than four bytes, pad the output with + leading zeroes to get the newline in the traditional place. + For years longer than four bytes, put extra spaces before the year + so that vintage code trying to overwrite the newline + won't overwrite a digit within a year and truncate the year, + using the principle that no output is better than wrong output. + This conforms to ISO C and POSIX standards, which say behavior + is undefined when the year is less than 1000 or greater than 9999. + + Also, avoid overflow when formatting tm_year + TM_YEAR_BASE. */ + + if ((year <= INT_MAX - TM_YEAR_BASE + ? SNPRINTF (SNPRINTFBUF(result, bufsize), + ((-999 - TM_YEAR_BASE <= year + && year <= 9999 - TM_YEAR_BASE) + ? "%s %s%3d %.2d:%.2d:%.2d %04d\n" + : "%s %s%3d %.2d:%.2d:%.2d %d\n"), + wn, mn, mday, hour, min, sec, + year + TM_YEAR_BASE) + : SNPRINTF (SNPRINTFBUF(result, bufsize), + "%s %s%3d %.2d:%.2d:%.2d %d%d\n", + wn, mn, mday, hour, min, sec, + year / 10 + TM_YEAR_BASE / 10, + year % 10)) + < bufsize) { +#if HAVE_SNPRINTF + return buf; +#else return strcpy(buf, result); - else { +#endif + } else { errno = EOVERFLOW; return NULL; } diff --git a/private.h b/private.h index da6dc790..6088d885 100644 --- a/private.h +++ b/private.h @@ -263,6 +263,10 @@ # endif #endif +#ifndef HAVE_SNPRINTF +# define HAVE_SNPRINTF (!PORT_TO_C89 || 199901 <= __STDC_VERSION__) +#endif + #ifndef HAVE_STRFTIME_L # if _POSIX_VERSION < 200809 # define HAVE_STRFTIME_L 0 diff --git a/zdump.c b/zdump.c index 2c6725e5..c988f6b3 100644 --- a/zdump.c +++ b/zdump.c @@ -14,10 +14,6 @@ #include "private.h" #include <stdio.h> -#ifndef HAVE_SNPRINTF -# define HAVE_SNPRINTF (!PORT_TO_C89 || 199901 <= __STDC_VERSION__) -#endif - #ifndef HAVE_LOCALTIME_R # define HAVE_LOCALTIME_R 1 #endif -- 2.43.0

1 1

[PROPOSED 1/2] Move MKTIME_MIGHT_OVERFLOW definition
by Paul Eggert Nov. 27, 2024

Nov. 27, 2024

* private.h (MKTIME_FITS_IN, MKTIME_MIGHT_OVERFLOW): Move definitions from here ... * strftime.c: ... to here, as it’s the only file needing them. --- private.h | 49 ------------------------------------------------- strftime.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 49 deletions(-) diff --git a/private.h b/private.h index fc0b8755..95ab2e1d 100644 --- a/private.h +++ b/private.h @@ -914,55 +914,6 @@ enum { SIGNED_PADDING_CHECK_NEEDED = true }; static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); -/* If true, the value returned by an idealized unlimited-range mktime - always fits into an integer type with bounds MIN and MAX. - If false, the value might not fit. - This macro is usable in #if if its arguments are. - Add or subtract 2**31 - 1 for the maximum UT offset allowed in a TZif file, - divide by the maximum number of non-leap seconds in a year, - divide again by two just to be safe, - and account for the tm_year origin (1900) and time_t origin (1970). */ -#define MKTIME_FITS_IN(min, max) \ - ((min) < 0 \ - && ((min) + 0x7fffffff) / 366 / 24 / 60 / 60 / 2 + 1970 - 1900 < INT_MIN \ - && INT_MAX < ((max) - 0x7fffffff) / 366 / 24 / 60 / 60 / 2 + 1970 - 1900) - -/* MKTIME_MIGHT_OVERFLOW is true if mktime can fail due to time_t overflow - or if it is not known whether mktime can fail, - and is false if mktime definitely cannot fail. - This macro is usable in #if, and so does not use TIME_T_MAX or sizeof. - If the builder has not configured this macro, guess based on what - known platforms do. When in doubt, guess true. */ -#ifndef MKTIME_MIGHT_OVERFLOW -# if defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ -# include <sys/param.h> -# endif -# if ((/* The following heuristics assume native time_t. */ \ - defined_time_tz) \ - || ((/* Traditional time_t is 'long', so if 'long' is not wide enough \ - assume overflow unless we're on a known-safe host. */ \ - !MKTIME_FITS_IN(LONG_MIN, LONG_MAX)) \ - && (/* GNU C Library 2.29 (2019-02-01) and later has 64-bit time_t \ - if __TIMESIZE is 64. */ \ - !defined __TIMESIZE || __TIMESIZE < 64) \ - && (/* FreeBSD 12 r320347 (__FreeBSD_version 1200036; 2017-06-26), \ - and later has 64-bit time_t on all platforms but i386 which \ - is currently scheduled for end-of-life on 2028-11-30. */ \ - !defined __FreeBSD_version || __FreeBSD_version < 1200036 \ - || defined __i386) \ - && (/* NetBSD 6.0 (2012-10-17) and later has 64-bit time_t. */ \ - !defined __NetBSD_Version__ || __NetBSD_Version__ < 600000000) \ - && (/* OpenBSD 5.5 (2014-05-01) and later has 64-bit time_t. */ \ - !defined OpenBSD || OpenBSD < 201405))) -# define MKTIME_MIGHT_OVERFLOW true -# else -# define MKTIME_MIGHT_OVERFLOW false -# endif -#endif -/* Check that MKTIME_MIGHT_OVERFLOW is consistent with time_t's range. */ -static_assert(MKTIME_MIGHT_OVERFLOW - || MKTIME_FITS_IN(TIME_T_MIN, TIME_T_MAX)); - /* ** 302 / 1000 is log10(2.0) rounded up. ** Subtract one for the sign bit if the type is signed; diff --git a/strftime.c b/strftime.c index 7be94de3..fc0c87d2 100644 --- a/strftime.c +++ b/strftime.c @@ -39,6 +39,55 @@ #include <locale.h> #include <stdio.h> +/* If true, the value returned by an idealized unlimited-range mktime + always fits into an integer type with bounds MIN and MAX. + If false, the value might not fit. + This macro is usable in #if if its arguments are. + Add or subtract 2**31 - 1 for the maximum UT offset allowed in a TZif file, + divide by the maximum number of non-leap seconds in a year, + divide again by two just to be safe, + and account for the tm_year origin (1900) and time_t origin (1970). */ +#define MKTIME_FITS_IN(min, max) \ + ((min) < 0 \ + && ((min) + 0x7fffffff) / 366 / 24 / 60 / 60 / 2 + 1970 - 1900 < INT_MIN \ + && INT_MAX < ((max) - 0x7fffffff) / 366 / 24 / 60 / 60 / 2 + 1970 - 1900) + +/* MKTIME_MIGHT_OVERFLOW is true if mktime can fail due to time_t overflow + or if it is not known whether mktime can fail, + and is false if mktime definitely cannot fail. + This macro is usable in #if, and so does not use TIME_T_MAX or sizeof. + If the builder has not configured this macro, guess based on what + known platforms do. When in doubt, guess true. */ +#ifndef MKTIME_MIGHT_OVERFLOW +# if defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ +# include <sys/param.h> +# endif +# if ((/* The following heuristics assume native time_t. */ \ + defined_time_tz) \ + || ((/* Traditional time_t is 'long', so if 'long' is not wide enough \ + assume overflow unless we're on a known-safe host. */ \ + !MKTIME_FITS_IN(LONG_MIN, LONG_MAX)) \ + && (/* GNU C Library 2.29 (2019-02-01) and later has 64-bit time_t \ + if __TIMESIZE is 64. */ \ + !defined __TIMESIZE || __TIMESIZE < 64) \ + && (/* FreeBSD 12 r320347 (__FreeBSD_version 1200036; 2017-06-26), \ + and later has 64-bit time_t on all platforms but i386 which \ + is currently scheduled for end-of-life on 2028-11-30. */ \ + !defined __FreeBSD_version || __FreeBSD_version < 1200036 \ + || defined __i386) \ + && (/* NetBSD 6.0 (2012-10-17) and later has 64-bit time_t. */ \ + !defined __NetBSD_Version__ || __NetBSD_Version__ < 600000000) \ + && (/* OpenBSD 5.5 (2014-05-01) and later has 64-bit time_t. */ \ + !defined OpenBSD || OpenBSD < 201405))) +# define MKTIME_MIGHT_OVERFLOW true +# else +# define MKTIME_MIGHT_OVERFLOW false +# endif +#endif +/* Check that MKTIME_MIGHT_OVERFLOW is consistent with time_t's range. */ +static_assert(MKTIME_MIGHT_OVERFLOW + || MKTIME_FITS_IN(TIME_T_MIN, TIME_T_MAX)); + #if MKTIME_MIGHT_OVERFLOW /* Do this after system includes as it redefines time_t, mktime, timeoff. */ # define USE_TIMEX_T true -- 2.47.0

1 1

[PROPOSED 1/2] Pacify GCC 15ish -Wleading-whitespace=blanks
by Paul Eggert Nov. 27, 2024

Nov. 27, 2024

Normalize indentation in a few source files to pacify gcc -Wleading-whitespace=blanks (in the forthcoming GCC 15). --- localtime.c | 2 +- private.h | 2 +- zdump.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/localtime.c b/localtime.c index ea2a6fb8..e6d79d05 100644 --- a/localtime.c +++ b/localtime.c @@ -1770,7 +1770,7 @@ timesub(const time_t *timep, int_fast32_t offset, dayoff = offset / SECSPERDAY - corr / SECSPERDAY + rem / SECSPERDAY - 3; rem %= SECSPERDAY; /* y = (EPOCH_YEAR - + floor((tdays + dayoff) / DAYSPERREPEAT) * YEARSPERREPEAT), + + floor((tdays + dayoff) / DAYSPERREPEAT) * YEARSPERREPEAT), sans overflow. But calculate against 1570 (EPOCH_YEAR - YEARSPERREPEAT) instead of against 1970 so that things work for localtime values before 1970 when time_t is unsigned. */ diff --git a/private.h b/private.h index bdd00013..fc0b8755 100644 --- a/private.h +++ b/private.h @@ -897,7 +897,7 @@ ATTRIBUTE_PURE time_t time2posix_z(timezone_t, time_t); default: TIME_T_MAX_NO_PADDING) \ : (time_t) -1) enum { SIGNED_PADDING_CHECK_NEEDED - = _Generic((time_t) 0, + = _Generic((time_t) 0, signed char: false, short: false, int: false, long: false, long long: false, default: true) }; diff --git a/zdump.c b/zdump.c index b668022d..2c6725e5 100644 --- a/zdump.c +++ b/zdump.c @@ -687,7 +687,7 @@ yeartot(intmax_t y) return absolute_max_time; seconds = diff400 * SECSPER400YEARS; years = diff400 * 400; - } else { + } else { seconds = isleap(myy) ? SECSPERLYEAR : SECSPERNYEAR; years = 1; } -- 2.43.0

1 1

New timezone Antarctica/Concordia (UTC+8)
by Erik Geletti Nov. 26, 2024

Nov. 26, 2024

Goodmorning. I'm writing here to propose a new time zone for an all-year open Antarctic base. The base is a French–Italian research facility that was built 3,233 m (10,607 ft) above sea level at a location called Dome C on the Antarctic Plateau, Antarctica. https://en.wikipedia.org/wiki/Concordia_Station The timezone is UTC+8 without DST. Best regards, Erik Geletti -- Erik Geletti Servizi Tecnici ed Informatici Istituto Nazionale di Oceanografia e di Geofisica Sperimentale - OGS Borgo Grotta Gigante n. 42/c 34010 Sgonico (Trieste) - Italia Tel. 0402140286 www.ogs.it

8 17

[PROPOSED 1/2] Move iinntt definition
by Paul Eggert Nov. 24, 2024

Nov. 24, 2024

It’s used only in localtime.c, so move its definition there. * localtime.c (IINNTT_MIN, IINNTT_MAX, iinntt): Move to here ... * private.h: ... from here. --- localtime.c | 18 ++++++++++++++++++ private.h | 17 ----------------- 2 files changed, 18 insertions(+), 17 deletions(-) diff --git a/localtime.c b/localtime.c index 14c356e1..1d42fc36 100644 --- a/localtime.c +++ b/localtime.c @@ -29,6 +29,24 @@ static int lock(void) { return 0; } static void unlock(void) { } #endif +/* A signed type wider than int, so that we can add 1900 + tm_mon/12 to tm_year + without overflow. The static_assert checks that it is indeed wider + than int; if this fails on your platform please let us know. */ +#if INT_MAX < LONG_MAX +typedef long iinntt; +# define IINNTT_MIN LONG_MIN +# define IINNTT_MAX LONG_MAX +#elif INT_MAX < LLONG_MAX +typedef long long iinntt; +# define IINNTT_MIN LLONG_MIN +# define IINNTT_MAX LLONG_MAX +#else +typedef intmax_t iinntt; +# define IINNTT_MIN INTMAX_MIN +# define IINNTT_MAX INTMAX_MAX +#endif +static_assert(IINNTT_MIN < INT_MIN && INT_MAX < IINNTT_MAX); + /* On platforms where offtime or mktime might overflow, strftime.c defines USE_TIMEX_T to be true and includes us. This tells us to #define time_t to an internal type timex_t that is diff --git a/private.h b/private.h index 3a699f0f..bdd00013 100644 --- a/private.h +++ b/private.h @@ -450,23 +450,6 @@ typedef unsigned long uintmax_t; #endif /* PORT_TO_C89 */ -/* A signed type wider than int, so that we can add 1900 to tm_year - without overflow. */ -#if INT_MAX < LONG_MAX -typedef long iinntt; -# define IINNTT_MIN LONG_MIN -# define IINNTT_MAX LONG_MAX -#elif INT_MAX < LLONG_MAX -typedef long long iinntt; -# define IINNTT_MIN LLONG_MIN -# define IINNTT_MAX LLONG_MAX -#else -typedef intmax_t iinntt; -# define IINNTT_MIN INTMAX_MIN -# define IINNTT_MAX INTMAX_MAX -#endif -static_assert(IINNTT_MIN < INT_MIN && INT_MAX < IINNTT_MAX); - /* The maximum size of any created object, as a signed integer. Although the C standard does not outright prohibit larger objects, behavior is undefined if the result of pointer subtraction does not -- 2.43.0

1 1

Re: [PROPOSED 4/6] Fix bug near the year 2**31 - 1 - 1900
by Paul Eggert Nov. 23, 2024

Nov. 23, 2024

On 2024-11-22 22:08, Magnus Fromreide wrote: > The definition of iinntt does not guarantee that it is wider than an int, > does something break if INT_MAX == INTMAX_MAX and INT_MIN == INTMAX_MIN? That's checked statically by "static_assert(IINNTT_MIN < INT_MIN && INT_MAX < IINNTT_MAX);". I don't know of any tzcode platform where that static assertion would fail (and thus break the build) because no signed type is wider than 'int'. If you know of one, please let us know.

1 0

(unofficial) Australian Central Western Time
by Stuart Bishop Nov. 22, 2024

Nov. 22, 2024

An article discussing the in-use but technically unofficial timezones in the Western Australian portion of the Nullarbor Plain. https://www.abc.net.au/news/2024-11-22/outback-wa-properties-strange-time-z… -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/

2 1

[PROPOSED] Avoid time_t + int overflow
by Paul Eggert Nov. 22, 2024

Nov. 22, 2024

* localtime.c (increment_overflow_time_int): New function. (time2sub): Use it (instead of relying on possibly-undefined behavior) to check for time_t + int overflow. --- localtime.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/localtime.c b/localtime.c index 07ce41b8..14c356e1 100644 --- a/localtime.c +++ b/localtime.c @@ -1882,6 +1882,21 @@ increment_overflow_iinntt(iinntt *lp, int m) #endif } +static bool +increment_overflow_time_int(time_t *tp, int j) +{ +#ifdef ckd_add + return ckd_add(tp, *tp, j); +#else + if (j < 0 + ? (TYPE_SIGNED(time_t) ? *tp < TIME_T_MIN - j : *tp <= -1 - j) + : TIME_T_MAX - j < *tp) + return true; + *tp += j; + return false; +#endif +} + static bool increment_overflow_time(time_t *tp, int_fast32_t j) { @@ -2155,10 +2170,8 @@ time2sub(struct tm *const tmp, return WRONG; } label: - newt = t + saved_seconds; - if ((newt < t) != (saved_seconds < 0)) + if (increment_overflow_time_int(&t, saved_seconds)) return WRONG; - t = newt; if (funcp(sp, &t, offset, tmp)) *okayp = true; return t; -- 2.47.0

1 0

Dead code in strftime()?
by Tom Lane Nov. 22, 2024

Nov. 22, 2024

strftime() in the 2024b tzcode distribution includes if (!p) { errno = EOVERFLOW; return 0; } AFAICS this is dead code, except maybe in the case that the call passes s = NULL, maxsize = 0, which doesn't seem like a case that the code intends to support (and EOVERFLOW would be a rather odd choice of error code if that's the idea). newstrftime.3.txt offers a clue about the intent: This function may fail if: [EOVERFLOW] The format includes an %s conversion and the number of seconds since the Epoch cannot be represented in a time_t. But the %s conversion code never returns zero. There's a suggestive comment there: /* If mktime fails, %s expands to the value of (time_t) -1 as a failure marker; this is better in practice than strftime failing. */ So it looks to me like somebody changed the error handling in the %s stanza but didn't bother to remove the now-dead path in the caller nor update the man page. Am I missing something? regards, tom lane

3 13

[PROPOSED 1/6] Improve zdump overflow checking
by Paul Eggert Nov. 22, 2024

Nov. 22, 2024

This also pacifies -Wsuggest-attribute=pure on x86 on platforms that lack tm_gmtoff and tm_zone. * zdump.c (xstrsize): Remove; no longer used. (tzalloc, saveabbr): Use plain strlen here, since the string sizes have already been checked. (main): Limit ‘longest’ to INT_MAX - 2 so that a printf with it and two spaces does not flake out. Check for arglen overflow once here, rather than on every alloc. --- zdump.c | 24 ++++++++---------------- 1 file changed, 8 insertions(+), 16 deletions(-) diff --git a/zdump.c b/zdump.c index e8178733..b668022d 100644 --- a/zdump.c +++ b/zdump.c @@ -148,17 +148,6 @@ sumsize(ptrdiff_t a, ptrdiff_t b) size_overflow(); } -/* Return the size of of the string STR, including its trailing NUL. - Report an error and exit if this would exceed INDEX_MAX which means - pointer subtraction wouldn't work. */ -static ptrdiff_t -xstrsize(char const *str) -{ - size_t len = strlen(str); - if (len < INDEX_MAX) - return len + 1; - size_overflow(); -} /* Return a pointer to a newly allocated buffer of size SIZE, exiting on failure. SIZE should be positive. */ @@ -266,7 +255,7 @@ tzalloc(char const *val) static ptrdiff_t fakeenv0size; void *freeable = NULL; char **env = fakeenv, **initial_environ; - ptrdiff_t valsize = xstrsize(val); + ptrdiff_t valsize = strlen(val) + 1; if (fakeenv0size < valsize) { char **e = environ, **to; ptrdiff_t initial_nenvptrs = 1; /* Counting the trailing NULL pointer. */ @@ -425,7 +414,7 @@ saveabbr(char **buf, ptrdiff_t *bufalloc, struct tm const *tmp) if (HAVE_LOCALTIME_RZ) return ab; else { - ptrdiff_t absize = xstrsize(ab); + ptrdiff_t absize = strlen(ab) + 1; if (*bufalloc < absize) { free(*buf); @@ -487,6 +476,7 @@ main(int argc, char *argv[]) register time_t cuthitime; time_t now; bool iflag = false; + size_t arglenmax = 0; cutlotime = absolute_min_time; cuthitime = absolute_max_time; @@ -586,12 +576,14 @@ main(int argc, char *argv[]) now = time(NULL); now |= !now; } - longest = 0; for (i = optind; i < argc; i++) { size_t arglen = strlen(argv[i]); - if (longest < arglen) - longest = min(arglen, INT_MAX); + if (arglenmax < arglen) + arglenmax = arglen; } + if (!HAVE_SETENV && INDEX_MAX <= arglenmax) + size_overflow(); + longest = min(arglenmax, INT_MAX - 2); for (i = optind; i < argc; ++i) { timezone_t tz = tzalloc(argv[i]); -- 2.47.0

1 5

(no subject)
by Cool Gab19 Nov. 8, 2024

Nov. 8, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

[PROPOSED] * NEWS, europe: Belated thanks for Ittoqqortoormiit 2024 fix
by Paul Eggert Nov. 8, 2024

Nov. 8, 2024

--- NEWS | 2 +- europe | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index a109ae9d..8381a197 100644 --- a/NEWS +++ b/NEWS @@ -233,7 +233,7 @@ Release 2023d - 2023-12-21 20:02:24 -0800 changing its time zone from -01/+00 to -02/-01 at the same moment as the spring-forward transition. Its clocks will therefore not spring forward as previously scheduled. The time zone change - reverts to its common practice before 1981. + reverts to its common practice before 1981. (Thanks to Jule Dabars.) Fix predictions for DST transitions in Palestine in 2072-2075, correcting a typo introduced in 2023a. (Thanks to Jule Dabars.) diff --git a/europe b/europe index f9063949..df334fc2 100644 --- a/europe +++ b/europe @@ -1147,7 +1147,7 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # However, Greenland will change to Daylight Saving Time again in 2024 # and onwards. -# From a contributor who wishes to remain anonymous for now (2023-10-29): +# From Jule Dabars (2023-10-29): # https://www.dr.dk/nyheder/seneste/i-nat-skal-uret-stilles-en-time-tilbage-m… # with a link to that page: # https://naalakkersuisut.gl/Nyheder/2023/10/2710_sommertid -- 2.43.0

1 0

[PROPOSED] * NEWS: Belated thanks for Palestine 2072-2075 fix
by Paul Eggert Nov. 7, 2024

Nov. 7, 2024

--- NEWS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 8c315643..a109ae9d 100644 --- a/NEWS +++ b/NEWS @@ -236,7 +236,7 @@ Release 2023d - 2023-12-21 20:02:24 -0800 reverts to its common practice before 1981. Fix predictions for DST transitions in Palestine in 2072-2075, - correcting a typo introduced in 2023a. + correcting a typo introduced in 2023a. (Thanks to Jule Dabars.) Changes to past and future timestamps -- 2.43.0

1 0