- 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. 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>. -Time Soc. 2025-01-21. +Time Soc. 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 et al. +The effects of daylight saving time and clock time transitions on sleep and +sleepiness: a systematic review. Sleep Med Rev. 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> 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>. J Sleep Res. 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>. Sleep. 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 et al. <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 The World Factbook, 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">The +World Factbook</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