- tz - lists.iana.org

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