February 2026 - tz - lists.iana.org

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

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