July 2026 - tz - lists.iana.org

Fwd: Bulletin C number 72
by Tim Parenti July 6, 2026

July 6, 2026

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

1 0

[PROPOSED] Morocco goes to plain UTC on 2026-09-20
by Paul Eggert July 4, 2026

July 4, 2026

This also affects Western Sahara * NEWS: Mention this. * africa (Morocco): Remove transitions after 2026. (Africa/Casablanca, Africa/El_Aaiun): Switch to +00 on 2026-09-20 at 02:00. --- NEWS | 5 ++ africa | 169 ++++----------------------------------------------------- 2 files changed, 15 insertions(+), 159 deletions(-) diff --git a/NEWS b/NEWS index 07e5fc69..459af904 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: Alberta moved to permanent -06 on 2026-06-18. + Morocco moves to permanent +00 on 2026-09-20. More integer overflow bugs have been fixed in zic. Changes to future timestamps @@ -16,6 +17,10 @@ Unreleased, experimental changes 02:00 instead, for the same reason we introduced a similarly temporary hack for British Columbia in 2026b. + Morocco plans to move back to permanent UTC, without daylight + saving time transitions, on 2026-09-20 at 02:00. This also + affects Western Sahara. + Changes to code zic no longer overflows integers when processing outlandish input diff --git a/africa b/africa index ec067bee..3517b84c 100644 --- a/africa +++ b/africa @@ -850,33 +850,12 @@ Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis # The return to legal GMT time will take place this Sunday, March 19 at 3 a.m. # ... the return to GMT+1 will be made on Sunday April 23, 2023 at 2 a.m. # https://www.mmsp.gov.ma/fr/actualites/passage-à-l%E2%80%99heure-gmt-à-parti… -# -# From Paul Eggert (2023-03-14): -# For now, guess that in the future Morocco will fall back at 03:00 -# the last Sunday before Ramadan, and spring forward at 02:00 the -# first Sunday after one day after Ramadan. To implement this, -# transition dates and times for 2019 through 2087 were determined by -# running the following program under GNU Emacs 28.2. (This algorithm -# also produces the correct transition dates for 2016 through 2018, -# though the times differ due to Morocco's time zone change in 2018.) -# (let ((islamic-year 1440)) -# (require 'cal-islam) -# (while (< islamic-year 1511) -# (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year))) -# (b (+ 1 (calendar-islamic-to-absolute (list 10 1 islamic-year)))) -# (sunday 0)) -# (while (/= sunday (mod (setq a (1- a)) 7))) -# (while (/= sunday (mod b 7)) -# (setq b (1+ b))) -# (setq a (calendar-gregorian-from-absolute a)) -# (setq b (calendar-gregorian-from-absolute b)) -# (insert -# (format -# (concat "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 3:00\t-1:00\t-\n" -# "Rule\tMorocco\t%d\tonly\t-\t%s\t%2d\t 2:00\t0\t-\n") -# (car (cdr (cdr a))) (calendar-month-name (car a) t) (car (cdr a)) -# (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b))))) -# (setq islamic-year (+ 1 islamic-year)))) + +# From Paul Eggert (2026-06-25): +# https://www.moroccoworldnews.com/2026/06/325034/confirmed-morocco-to-restor… +# Today the Moroccan government adopted Decree No. 2.26.530, which abrogates +# the 2018 decree that put it at +01 with daylight saving during Ramadan. +# The plan is to go back to +00 without DST on 2026-09-20 at 02:00. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Morocco 1939 only - Sep 12 0:00 1:00 - @@ -936,143 +915,14 @@ Rule Morocco 2025 only - Feb 23 3:00 -1:00 - Rule Morocco 2025 only - Apr 6 2:00 0 - Rule Morocco 2026 only - Feb 15 3:00 -1:00 - Rule Morocco 2026 only - Mar 22 2:00 0 - -Rule Morocco 2027 only - Feb 7 3:00 -1:00 - -Rule Morocco 2027 only - Mar 14 2:00 0 - -Rule Morocco 2028 only - Jan 23 3:00 -1:00 - -Rule Morocco 2028 only - Mar 5 2:00 0 - -Rule Morocco 2029 only - Jan 14 3:00 -1:00 - -Rule Morocco 2029 only - Feb 18 2:00 0 - -Rule Morocco 2029 only - Dec 30 3:00 -1:00 - -Rule Morocco 2030 only - Feb 10 2:00 0 - -Rule Morocco 2030 only - Dec 22 3:00 -1:00 - -Rule Morocco 2031 only - Jan 26 2:00 0 - -Rule Morocco 2031 only - Dec 14 3:00 -1:00 - -Rule Morocco 2032 only - Jan 18 2:00 0 - -Rule Morocco 2032 only - Nov 28 3:00 -1:00 - -Rule Morocco 2033 only - Jan 9 2:00 0 - -Rule Morocco 2033 only - Nov 20 3:00 -1:00 - -Rule Morocco 2033 only - Dec 25 2:00 0 - -Rule Morocco 2034 only - Nov 5 3:00 -1:00 - -Rule Morocco 2034 only - Dec 17 2:00 0 - -Rule Morocco 2035 only - Oct 28 3:00 -1:00 - -Rule Morocco 2035 only - Dec 9 2:00 0 - -Rule Morocco 2036 only - Oct 19 3:00 -1:00 - -Rule Morocco 2036 only - Nov 23 2:00 0 - -Rule Morocco 2037 only - Oct 4 3:00 -1:00 - -Rule Morocco 2037 only - Nov 15 2:00 0 - -Rule Morocco 2038 only - Sep 26 3:00 -1:00 - -Rule Morocco 2038 only - Oct 31 2:00 0 - -Rule Morocco 2039 only - Sep 18 3:00 -1:00 - -Rule Morocco 2039 only - Oct 23 2:00 0 - -Rule Morocco 2040 only - Sep 2 3:00 -1:00 - -Rule Morocco 2040 only - Oct 14 2:00 0 - -Rule Morocco 2041 only - Aug 25 3:00 -1:00 - -Rule Morocco 2041 only - Sep 29 2:00 0 - -Rule Morocco 2042 only - Aug 10 3:00 -1:00 - -Rule Morocco 2042 only - Sep 21 2:00 0 - -Rule Morocco 2043 only - Aug 2 3:00 -1:00 - -Rule Morocco 2043 only - Sep 13 2:00 0 - -Rule Morocco 2044 only - Jul 24 3:00 -1:00 - -Rule Morocco 2044 only - Aug 28 2:00 0 - -Rule Morocco 2045 only - Jul 9 3:00 -1:00 - -Rule Morocco 2045 only - Aug 20 2:00 0 - -Rule Morocco 2046 only - Jul 1 3:00 -1:00 - -Rule Morocco 2046 only - Aug 5 2:00 0 - -Rule Morocco 2047 only - Jun 23 3:00 -1:00 - -Rule Morocco 2047 only - Jul 28 2:00 0 - -Rule Morocco 2048 only - Jun 7 3:00 -1:00 - -Rule Morocco 2048 only - Jul 19 2:00 0 - -Rule Morocco 2049 only - May 30 3:00 -1:00 - -Rule Morocco 2049 only - Jul 4 2:00 0 - -Rule Morocco 2050 only - May 15 3:00 -1:00 - -Rule Morocco 2050 only - Jun 26 2:00 0 - -Rule Morocco 2051 only - May 7 3:00 -1:00 - -Rule Morocco 2051 only - Jun 18 2:00 0 - -Rule Morocco 2052 only - Apr 28 3:00 -1:00 - -Rule Morocco 2052 only - Jun 2 2:00 0 - -Rule Morocco 2053 only - Apr 13 3:00 -1:00 - -Rule Morocco 2053 only - May 25 2:00 0 - -Rule Morocco 2054 only - Apr 5 3:00 -1:00 - -Rule Morocco 2054 only - May 10 2:00 0 - -Rule Morocco 2055 only - Mar 28 3:00 -1:00 - -Rule Morocco 2055 only - May 2 2:00 0 - -Rule Morocco 2056 only - Mar 12 3:00 -1:00 - -Rule Morocco 2056 only - Apr 23 2:00 0 - -Rule Morocco 2057 only - Mar 4 3:00 -1:00 - -Rule Morocco 2057 only - Apr 8 2:00 0 - -Rule Morocco 2058 only - Feb 17 3:00 -1:00 - -Rule Morocco 2058 only - Mar 31 2:00 0 - -Rule Morocco 2059 only - Feb 9 3:00 -1:00 - -Rule Morocco 2059 only - Mar 23 2:00 0 - -Rule Morocco 2060 only - Feb 1 3:00 -1:00 - -Rule Morocco 2060 only - Mar 7 2:00 0 - -Rule Morocco 2061 only - Jan 16 3:00 -1:00 - -Rule Morocco 2061 only - Feb 27 2:00 0 - -Rule Morocco 2062 only - Jan 8 3:00 -1:00 - -Rule Morocco 2062 only - Feb 12 2:00 0 - -Rule Morocco 2062 only - Dec 31 3:00 -1:00 - -Rule Morocco 2063 only - Feb 4 2:00 0 - -Rule Morocco 2063 only - Dec 16 3:00 -1:00 - -Rule Morocco 2064 only - Jan 27 2:00 0 - -Rule Morocco 2064 only - Dec 7 3:00 -1:00 - -Rule Morocco 2065 only - Jan 11 2:00 0 - -Rule Morocco 2065 only - Nov 22 3:00 -1:00 - -Rule Morocco 2066 only - Jan 3 2:00 0 - -Rule Morocco 2066 only - Nov 14 3:00 -1:00 - -Rule Morocco 2066 only - Dec 26 2:00 0 - -Rule Morocco 2067 only - Nov 6 3:00 -1:00 - -Rule Morocco 2067 only - Dec 11 2:00 0 - -Rule Morocco 2068 only - Oct 21 3:00 -1:00 - -Rule Morocco 2068 only - Dec 2 2:00 0 - -Rule Morocco 2069 only - Oct 13 3:00 -1:00 - -Rule Morocco 2069 only - Nov 17 2:00 0 - -Rule Morocco 2070 only - Oct 5 3:00 -1:00 - -Rule Morocco 2070 only - Nov 9 2:00 0 - -Rule Morocco 2071 only - Sep 20 3:00 -1:00 - -Rule Morocco 2071 only - Nov 1 2:00 0 - -Rule Morocco 2072 only - Sep 11 3:00 -1:00 - -Rule Morocco 2072 only - Oct 16 2:00 0 - -Rule Morocco 2073 only - Aug 27 3:00 -1:00 - -Rule Morocco 2073 only - Oct 8 2:00 0 - -Rule Morocco 2074 only - Aug 19 3:00 -1:00 - -Rule Morocco 2074 only - Sep 30 2:00 0 - -Rule Morocco 2075 only - Aug 11 3:00 -1:00 - -Rule Morocco 2075 only - Sep 15 2:00 0 - -Rule Morocco 2076 only - Jul 26 3:00 -1:00 - -Rule Morocco 2076 only - Sep 6 2:00 0 - -Rule Morocco 2077 only - Jul 18 3:00 -1:00 - -Rule Morocco 2077 only - Aug 22 2:00 0 - -Rule Morocco 2078 only - Jul 10 3:00 -1:00 - -Rule Morocco 2078 only - Aug 14 2:00 0 - -Rule Morocco 2079 only - Jun 25 3:00 -1:00 - -Rule Morocco 2079 only - Aug 6 2:00 0 - -Rule Morocco 2080 only - Jun 16 3:00 -1:00 - -Rule Morocco 2080 only - Jul 21 2:00 0 - -Rule Morocco 2081 only - Jun 1 3:00 -1:00 - -Rule Morocco 2081 only - Jul 13 2:00 0 - -Rule Morocco 2082 only - May 24 3:00 -1:00 - -Rule Morocco 2082 only - Jun 28 2:00 0 - -Rule Morocco 2083 only - May 16 3:00 -1:00 - -Rule Morocco 2083 only - Jun 20 2:00 0 - -Rule Morocco 2084 only - Apr 30 3:00 -1:00 - -Rule Morocco 2084 only - Jun 11 2:00 0 - -Rule Morocco 2085 only - Apr 22 3:00 -1:00 - -Rule Morocco 2085 only - May 27 2:00 0 - -Rule Morocco 2086 only - Apr 14 3:00 -1:00 - -Rule Morocco 2086 only - May 19 2:00 0 - -Rule Morocco 2087 only - Mar 30 3:00 -1:00 - -Rule Morocco 2087 only - May 11 2:00 0 - -# For dates after the somewhat-arbitrary cutoff of 2087, assume that -# Morocco will no longer observe DST. At some point this table will -# need to be extended, though quite possibly Morocco will change the -# rules first. # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco %z 1984 Mar 16 1:00 - %z 1986 0:00 Morocco %z 2018 Oct 28 3:00 - 1:00 Morocco %z + 1:00 Morocco %z 2026 Sep 20 2:00 + 0:00 - %z # Western Sahara # @@ -1088,7 +938,8 @@ Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún -1:00 - %z 1976 Apr 14 0:00 Morocco %z 2018 Oct 28 3:00 - 1:00 Morocco %z + 1:00 Morocco %z 2026 Sep 20 2:00 + 0:00 - %z # Botswana # Burundi -- 2.53.0

4 6

Re: [PROPOSED] Morocco goes to plain UTC on 2026-09-20
by Mounir EL MOKHTARI July 4, 2026

July 4, 2026

Hi, As a follow-up to the recent discussion regarding Morocco's upcoming transition to permanent UTC (abrogating Decree No. 2.18.855), I would like to confirm that the official decree has now been published by the General Secretariat of the Government (SGG). Decree No. 2.26.530 has been officially gazetted in the latest issue of the Moroccan Official Gazette (Bulletin Officiel No. 7521, dated June 29, 2026). You can access the official legal text (in Arabic) directly on the SGG production server via the following URL: https://www.sgg.gov.ma/BO/AR/3111/2026/BO_7521_Ar.pdf This publication constitutes the official and final enactment of the law. Best regards, *Mounir EL MOKHTARI* *Computer Engineer* *Rabat, Morocco*

1 0

Regional District of East Kootenay announces survey for time change
by James Bellaire July 4, 2026

July 4, 2026

The press release reads (in part): A new public survey has been launched to gather input on time observance in the southeast corner of BC. The survey is open through August 3 and is being done in partnership between the Regional District of East Kootenay, Town of Golden, and Columbia Shuswap Regional District (CSRD) Electoral Area A. “A dedicated project page has been set up that has the online survey along with other information. While it is being hosted by the RDEK, the survey covers the entire southeast corner of BC that is still on Mountain Time and is being done in partnership with all the local governments in the East Kootenay, Golden and CSRD Area A,” says RDEK Communications Manager, Loree Duczek. The survey can be found on https://engage.rdek.bc.ca/timechange and will remain open until 11:59pm on August 3. https://www.rdek.bc.ca/news/entry/regional_survey_launches_to_gather_feedba… The three options presented are "No Change" (continue to change clocks), Permanent Standard Time (UTC -7 or BC Time) or Permanent Daylight Time (UTC -6 or Alberta Time).

1 0

[PATCH] zic: don't use zone FORMAT field as a printf format string
by Syed Abdul Khaliq July 3, 2026

July 3, 2026

In doabbr(), the zone line's FORMAT field (zp->z_format) was passed directly as the format argument of sprintf(): sprintf(abbr, format, letters); FORMAT comes from zone data, which is not always trusted: zic is also used to compile third-party or user-supplied zone description files. Passing such data as a printf format string is the classic uncontrolled-format-string anti-pattern (CWE-134 / CERT FIO30-C), and it is what makes this line the sole -Wformat-nonliteral warning in doabbr under -Wformat=2. inzsub() already restricts a slash-less FORMAT to at most one '%s' conversion (a '%z' is rewritten to '%s' earlier), so expand that lone conversion explicitly with mempcpy()/strcpy() instead of handing the data to sprintf(). This removes the format-string sink while keeping the output byte-for-byte identical for every valid FORMAT, so the generated TZif files are unchanged. * zic.c (doabbr): Expand FORMAT's single '%s' by hand rather than using FORMAT as a printf format string. --- diff --git a/zic.c b/zic.c index af2bb80..7cc48ef 100644 --- a/zic.c +++ b/zic.c @@ -3135,7 +3135,15 @@ doabbr(char *abbr, struct zone const *zp, char const *letters, letters = "%s"; else if (letters == disable_percent_s) return 0; - sprintf(abbr, format, letters); + /* Expand FORMAT's lone "%s" (see inzsub) without treating + FORMAT, which comes from zone data, as a printf format string. */ + cp = strchr(format, '%'); + if (cp) { + char *dp = mempcpy(abbr, format, cp - format); + dp = mempcpy(dp, letters, strlen(letters)); + strcpy(dp, cp + 2); + } else + strcpy(abbr, format); } else if (isdst) strcpy(abbr, slashp + 1); else { -- 2.50.1 (Apple Git-155)

2 2

B.C. Permanent Daylight Savings
by Matthew Lee July 2, 2026

July 2, 2026

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

7 10

[PROPOSED] Add “PacT” to candidate BC abbreviations
by Paul Eggert July 2, 2026

July 2, 2026

* northamerica: Someone associated with the BC government who prefers to remain anonymous suggested “PacT” as a possible abbreviation to be suggested by the government. This seems better than some of my more-fanciful suggestions, though it still has problems of confusion with the longstanding use of “Pacific Time” in both Canada and the US. Add it to the list of possible candidates, and remove more-fanciful suggestions. --- northamerica | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/northamerica b/northamerica index 3a47ee77..18112ac1 100644 --- a/northamerica +++ b/northamerica @@ -2027,7 +2027,7 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep # on March 8 will be the last time change, ending twice-yearly clock changes.” # https://news.gov.bc.ca/releases/2026AG0013-000209 # -# From Paul Eggert (2026-03-07): +# From Paul Eggert (2026-07-02): # The law says that 21 hours after the usual 2026-03-08 02:00 switch from # PST to PDT, the next day inaugurates the new standard time Pacific Time, # i.e., just one clock change but two name changes separated by 21 hours. @@ -2053,10 +2053,7 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep # PST - straightforward but even more confusing, # and will likely break much software that assumes PST is -08 # -07 - accurate and clear in itself, but makes BC look odd vs neighbors -# CPT, CPST - for Canadian Pacific (Standard) Time, -# by analogy with AEST in Australia -# P-T - conforming approximation to “PT” -# PT+ - like P-T but suggesting one-hour advance over PST +# PacT - straightforward but novel abbreviation for Pacific Time # From Chris Walton (2026-03-15): # The Regional District of East Kootenay is planning to move to year-round -- 2.53.0

1 0

[PROPOSED 1/2] tzalloc fails with EFTYPE on invalid TZif files
by Paul Eggert July 1, 2026

July 1, 2026

* localtime.c (tzloadbody): For a TZif file that is not regular or that has a bad format, fail with errno set to EFTYPE, not EINVAL. This fits better with BSD tradition going back to 4.4BSD and Berkeley DB in the early 1990s, and is what NetBSD already does when the file is not a regular file. This changes user-visible behavior only for the value of errno just after tzalloc fails. * private.h (EFTYPE): Default to EINVAL, so that behavior does not change on platforms lacking EFTYPE. --- localtime.c | 30 +++++++++++++++--------------- private.h | 3 +++ 2 files changed, 18 insertions(+), 15 deletions(-) diff --git a/localtime.c b/localtime.c index e3b8bb94..158f0150 100644 --- a/localtime.c +++ b/localtime.c @@ -1025,7 +1025,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, < 0) return errno; if (!S_ISREG(st.st_mode)) - return EINVAL; + return EFTYPE; } fid = OPENAT_TZDIR ? openat(dd, relname, oflags) : open(name, oflags); err = errno; @@ -1049,7 +1049,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, } up = &lsp->u.u; nread = read(fid, up->buf, sizeof up->buf); - err = tzheadsize <= nread ? 0 : nread < 0 ? errno : EINVAL; + err = tzheadsize <= nread ? 0 : nread < 0 ? errno : EFTYPE; } close(fid); if (err) @@ -1077,7 +1077,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, && 0 <= charcnt && charcnt <= TZ_MAX_CHARS && 0 <= ttisstdcnt && ttisstdcnt <= TZ_MAX_TYPES && 0 <= ttisutcnt && ttisutcnt <= TZ_MAX_TYPES)) - return EINVAL; + return EFTYPE; datablock_size = (timecnt * stored /* ats */ + timecnt /* types */ @@ -1087,12 +1087,12 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, + ttisstdcnt /* ttisstds */ + ttisutcnt); /* ttisuts */ if (nread < tzheadsize + datablock_size) - return EINVAL; + return EFTYPE; if (skip_datablock) p += datablock_size; else if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) && (ttisutcnt == typecnt || ttisutcnt == 0))) - return EINVAL; + return EFTYPE; else { int_fast64_t prevtr = -1; int_fast32_2s prevcorr; @@ -1115,7 +1115,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, ? TIME_T_MIN : at); if (timecnt && attime <= sp->ats[timecnt - 1]) { if (attime < sp->ats[timecnt - 1]) - return EINVAL; + return EFTYPE; sp->types[i - 1] = 0; timecnt--; } @@ -1128,7 +1128,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, for (i = 0; i < sp->timecnt; ++i) { unsigned char typ = *p++; if (sp->typecnt <= typ) - return EINVAL; + return EFTYPE; if (sp->types[i]) sp->types[timecnt++] = typ; } @@ -1142,18 +1142,18 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, cause trouble both in this file and in callers. Also, it violates RFC 9636 section 3.2. */ if (utoff < -TWO_31_MINUS_1) - return EINVAL; + return EFTYPE; ttisp = &sp->ttis[i]; ttisp->tt_utoff = utoff; p += 4; isdst = *p++; if (! (isdst < 2)) - return EINVAL; + return EFTYPE; ttisp->tt_isdst = isdst; desigidx = *p++; if (! (desigidx < sp->charcnt)) - return EINVAL; + return EFTYPE; ttisp->tt_desigidx = desigidx; } for (i = 0; i < sp->charcnt; ++i) @@ -1172,7 +1172,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, /* Leap seconds cannot occur before the Epoch, or out of order. */ if (tr <= prevtr) - return EINVAL; + return EFTYPE; /* To avoid other botches in this code, each leap second's correction must differ from the previous one's by 1 @@ -1184,7 +1184,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, ? corr == prevcorr + 1 : (corr == prevcorr || corr == prevcorr - 1)))) - return EINVAL; + return EFTYPE; prevtr = tr; prevcorr = corr; @@ -1206,7 +1206,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, ttisp->tt_ttisstd = false; else { if (*p != true && *p != false) - return EINVAL; + return EFTYPE; ttisp->tt_ttisstd = *p++; } } @@ -1218,7 +1218,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, ttisp->tt_ttisut = false; else { if (*p != true && *p != false) - return EINVAL; + return EFTYPE; ttisp->tt_ttisut = *p++; } } @@ -1303,7 +1303,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, } } if (sp->typecnt == 0) - return EINVAL; + return EFTYPE; return 0; } diff --git a/private.h b/private.h index 1e6db08c..b0faaeb9 100644 --- a/private.h +++ b/private.h @@ -243,6 +243,9 @@ strnlen (char const *s, size_t maxlen) # define EINVAL ERANGE #endif +#ifndef EFTYPE +# define EFTYPE EINVAL +#endif #ifndef ELOOP # define ELOOP EINVAL #endif -- 2.54.0

2 3

[PROPOSED] Reject ".." in TZ only when privileged
by Paul Eggert July 1, 2026

July 1, 2026

This better matches the behavior of tzcode 2025b and earlier, and is more compatible with what FreeBSD does. * localtime.c (fstatat) [!AT_FDCWD]: New placeholder function. (tzloadbody): Use O_RESOLVE_BENEATH only when privileged. Use similar logic when on platforms lacking O_RESOLVE_BENEATH; this entails moving the stat check to just before the open/openat, in using fstatat when using openat. --- localtime.c | 47 ++++++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 17 deletions(-) diff --git a/localtime.c b/localtime.c index 0091b81e..e3b8bb94 100644 --- a/localtime.c +++ b/localtime.c @@ -227,7 +227,7 @@ struct timespec { time_t tv_sec; long tv_nsec; }; /* How many seconds to wait before checking the default TZif file again. Negative means no checking. Default to 61 if DETECT_TZ_CHANGES - (as circa 2025 FreeBSD builds its localtime.c with -DDETECT_TZ_CHANGES), + (as circa 2026 FreeBSD builds its localtime.c with -DDETECT_TZ_CHANGES), and to -1 otherwise. */ #ifndef TZ_CHANGE_INTERVAL # ifdef DETECT_TZ_CHANGES @@ -288,10 +288,12 @@ typedef intmax_t timex_t; # endif #endif -/* Placeholders for platforms lacking openat. */ +/* Placeholders for platforms lacking AT_FCWD, openat, and fstatat. */ #ifndef AT_FDCWD # define AT_FDCWD (-1) /* any negative value will do */ static int openat(int dd, char const *path, int oflag) { unreachable (); } +static int fstatat(int dd, char const *path, struct stat *st, int flags) +{ unreachable(); } #endif /* Port to platforms that lack some O_* flags. Unless otherwise @@ -425,8 +427,7 @@ static char const *utc = etc_utc + sizeof "Etc/" - 1; approach of opening "/usr/share/zoneinfo/America/Los_Angeles". Although the OPENAT_TZDIR approach is less efficient, suffers from spurious EMFILE and ENFILE failures, and is no more secure in practice, - it is how bleeding edge FreeBSD did things from August 2025 - through at least September 2025. */ + bleeding edge FreeBSD started doing it this way in August 2025. */ #ifndef OPENAT_TZDIR # define OPENAT_TZDIR 0 #endif @@ -917,6 +918,7 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, int dd = AT_FDCWD; int oflags = (O_RDONLY | O_BINARY | O_CLOEXEC | O_CLOFORK | O_IGNORE_CTTY | O_NOCTTY | O_REGULAR); + bool might_escape = false; int err; struct stat st; st.st_ctime = 0; @@ -943,16 +945,8 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, continue; else if (issetugid()) return ENOTCAPABLE; - else if (!O_REGULAR) { - /* Check for devices, as their mere opening could have - unwanted side effects. Though racy, there is no - portable way to fix the races. This check is needed - only for files not otherwise known to be non-devices. */ - if (stat(name, &st) < 0) - return errno; - if (!S_ISREG(st.st_mode)) - return EINVAL; - } + else + might_escape = true; } if (relname[0] != '/') { @@ -964,8 +958,12 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, for (component = relname; component[0]; component++) if (component[0] == '.' && component[1] == '.' && component[2] == '/' - && (component == relname || component[-1] == '/')) - return ENOTCAPABLE; + && (component == relname || component[-1] == '/')) { + if (issetugid()) + return ENOTCAPABLE; + might_escape = true; + break; + } } if (OPENAT_TZDIR && !SUPPRESS_TZDIR) { @@ -978,7 +976,10 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, | O_BINARY | O_CLOEXEC | O_CLOFORK | O_DIRECTORY)); if (dd < 0) return errno; - oflags |= O_RESOLVE_BENEATH; + if (O_RESOLVE_BENEATH && issetugid()) { + oflags |= O_RESOLVE_BENEATH; + might_escape = false; + } } } @@ -1014,6 +1015,18 @@ tzloadbody(char const *name, struct state *sp, char tzloadflags, #endif } + /* For a platform that lacks O_REGULAR and a file that might + be outside TZDIR, check that it is a regular file, + as merely opening a device could have unwanted side effects. + Though racy, there is no portable way to fix the race. */ + if (!O_REGULAR && might_escape) { + /* (oflags & O_RESOLVE_BENEATH) must be zero here. */ + if ((OPENAT_TZDIR ? fstatat(dd, relname, &st, 0) : stat(name, &st)) + < 0) + return errno; + if (!S_ISREG(st.st_mode)) + return EINVAL; + } fid = OPENAT_TZDIR ? openat(dd, relname, oflags) : open(name, oflags); err = errno; if (0 <= dd) -- 2.54.0

2 2