July 2026 - tz - lists.iana.org

Installing new tzdata on old system
by Rune Torgersen July 13, 2026

July 13, 2026

Hi I maintain a telephony (voicemail) system based on an ancient Linux version (Kernel 2.6.25, GCC 4.1.2, GLIBC 2.5, PowerPC (32bit, BE)). I need to update timezones for the upcoming Canada permanent DST. Last time I successfully installed new TZ files on this system was using tzdata2016c and tzcode 2016c. Updating compiler and glibc is not possible, as we have quite the installed base of these, with old software I can get tzcode+data 2026c to compile/install (with a warning), but the resulting files do not work with the glibc version I have (date command returns time without tz info). I could use some help in generating a version of tz files that will work. The compile line I used was: make CFLAGS='-std=gnu99 -DHAVE_LINK=0' TZDIR=/usr/share/zoneinfo DATAFORM=rearguard install (HAVE_LINK=0 to force symlinks instead of hardlinks, as that is what the system expects). date --version date (GNU coreutils) 6.9 gcc --version gcc (GCC) 4.1.2 Copyright (C) 2006 Free Software Foundation, Inc. Warnings when compiling: strftime.c:70:39: warning: integer overflow in preprocessor expression In file included from strftime.c:95: localtime.c:267:39: warning: integer overflow in preprocessor expression (I did get help here getting things to compile with the 2023 version, but I never actually used the output, nor check ed that it was working with the system) Thanks, Rune Torgersen Innovative Systems LLC.

1 2

US House to vote on bill to make daylight saving time permanent
by Jacob Pratt July 10, 2026

July 10, 2026

Article: https://www.reuters.com/world/us/us-house-vote-bill-make-daylight-saving-ti… Looking at the text of the bill itself[^1], there is no date of effectiveness, so it would take effect immediately upon signing. States currently not observing DST (i.e. Hawaii and most of Arizona) can remain on standard time, but everyone else would be advanced an hour year-round. Because no territories currently observe DST, the bill would de facto have no effect there. Interestingly, there is nothing that specifies whether standard or daylight time is used in Hawaii, Arizona, and the territories if they don't explicitly pass a bill, but I presume common sense would prevail in that nothing changes. A parallel bill (S.29) was introduced in the Senate. [^1]: https://www.congress.gov/bill/119th-congress/house-bill/139/text Jacob Pratt

3 3

DST in the "news" of 2022
by Arthur Olson July 9, 2026

July 9, 2026

It's only today that I discovered this 2022 item from my hometown humor source. "Republicans Blame Biden for Losing an Hour on Daylight Savings" https://takomatorch.com/index.php/2022/03/13/republicans-blame-biden-for-lo… @dashdashado

1 0

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

July 8, 2026

The 2026c release of the tz code and data is available. This release’s main urgency is Alberta’s decision to stop changing its clocks and stay on permanent UTC-06, which has a practical effect starting 2026-11-01 at 02:00. Like the similar British Columbia changes in the previous release, there will likely be problems downstream as CLDR’s latest release cannot handle it as specified. So we’re releasing now so that downstream has some time to test and adjust. Also, Morocco is moving to permanent UTC on 2026-09-20. This will likely cause fewer problems among downstream CLDR users. Although quite possibly we’ll soon need another TZDB release to accommodate similar changes planned for Northwest Territories, these changes have not been formalized yet. This release contains the following 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 Alberta’s 2026-03-08 spring forward was its last foreseeable clock change, as it moved to permanent -06 thereafter. (Thanks to Roozbeh Pournader and others.) Model this with its traditional abbreviation CST. Although the change to permanent -06 legally took place on 2026-06-18, temporarily model the change to occur on 2026-11-01 at 02:00 instead, for the same reason we introduced a similarly temporary hack for British Columbia in 2026b. Although another TZDB release will likely be needed soon because Northwest Territories will likely follow Alberta, the legal formalities have not yet taken place. 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 like ‘Zone Ouch 0 - LMT 9223372036854775807’, ‘Zone Ouch 0 2562047788015215 LMT’, ‘Zone Ouch -2562047788015215:30:08 - LMT’, and ‘Zone Ouch -2562047788015215:30:08 - %%z’. This avoids undefined behavior in C. (Problems reported by Naveed Khan.) On platforms that have EFTYPE, tzalloc now fails with errno set to EFTYPE, not EINVAL, if it detects that the TZif file has an invalid format or is not a regular file. Formerly it did this only on NetBSD, and only when the file was not a regular file. Unprivileged programs no longer require TZif files to be regular files or reject relative names containing ".." components. This reverts to the more-permissive 2025b behavior, as the stricter behavior did not catch on in FreeBSD. zic now reports any failure to remove a temporary file when cleaning up after a previous failure. (Problem reported by Tom Lane.) Changes to commentary Northwest Territories is expected to move to permanent -06 prior to 2026-11-01 02:00, when clocks would otherwise fall back. (Thanks to Tim Parenti and James Bellaire.) Model this with its traditional abbreviation CST. Unfortunately the change is not yet official, so it is currently present only as comments that can be uncommented as needed. Changes to build procedure The undocumented ‘typecheck’ Makefile check rule has been removed. It stopped working in 2025a and evidently nobody noticed. The rule was superseded by ‘check_time_t_alternatives’ in 2013d. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2026c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2026c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2026c.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 71f28b9ab3b67c0f9466803f6151812d4fc8e357 dated 2026-07-08 10:23:58 -0700 and tagged '2026c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: ad1aadf26b9aaca487a4f780d7a8ebf1d7383472ce587b06cb63852d4eb030dbd190b537e393e75d59530318581e9d3f492ff5f97bbac78f548d0755c4f7257f tzcode2026c.tar.gz e0b4b7044b66fbc27bc21d13d18063abcdf78ab58d5ba5fd64bd1a88d86e9d495f45add4d8e65bb6c40249f9c94ca29b72c8ebba8d0e4c468f2965ac77932ef0 tzdata2026c.tar.gz 3e5aec7d93522efc875fc8af553f78029677aaa9be8db396c862d687bdedb930379ba6246b33a15c5fb3a76d24e937dac4f4f66d6f9edf69a668bb21e9eeada7 tzdb-2026c.tar.lz Here are GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmpOiy0ACgkQ7ZfpDmKq fjRS/hAApD5lVCI/pMXFa6G1WT/Lx3Fydw0Frzo/uCeRtopN+HwLt7e5mwsWQBPe ju7nUs6Zg434ZlY7Rt/xKDPqFZnWmRdNqselkNsUpWi7ajm3VWm6TwJU7Gltkjbo 34DVY7Mn2Pmvma9bsPj1LJCqi+lsILVTobGZhGxh6NcgZ+CUFnVJKTWenDFuSzGA QltBeA74BH0zxIhCnqRjwaUtF1IS9WaX52I58k7llPn05AkGH8po+mkaz6jmqF+N BoL8lgTbNqkDzOaiVY0u2fjx6SoXW3tHPywpTGJeyfgD4KbYQOustw8zMXEANR6I W4M1p1j1aNo8Ss2ZXsNDDP9ZSAD3jRmNV18V4vB/cADff6K/Y/Phq8mHTiKjjS4W 4Fy54avRkk3HEgboytA6R7vwD1naB6L1FE4SM3TbIXO22BeHs4qhBjSRB3Wfk+1u AuGQsCNORi8GXYRSLPUm4ekss9WTU46JXqwa7yHPQH6sKRiHyFci4V1qk0Hhlh2Z 2DCURjXhI/9L+blozsZRZg3bxDN32iFEZAdE+iMmW0VPP39VrlL1gH/GisORzKL0 XCtIducsD7ZvV/cvCADUBwy3zgatXh0VaP2ozWHnnt/9hMVT6it6/2GMY0vY/D61 TUw2Rfa2P3y7IpRfGcT24kFjKv8rxx4A8mM9HndW/fYkUN2O3W4= =kK0H -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmpOiy0ACgkQ7ZfpDmKq fjR6yA/9H1+9KOGi6LIatyM5HSQb6UrOQ5X+Zs1SrBZk95yXBcgYRU6Ycfy3gGM8 +TWBKmMDiN3F1kRBeNgu4h/BAnXkpND50qyyLXKl5ztYdbRaZXZCMizPB7px7+CG YQuOErpS//MEEmtzKNRQBdgOAHv+eAMFIn6keLl8RbIeS1sQ2gewto2BeIDyYSx/ IuDNikI4/6ogyJYaxEKQgmpV/WcPLr5m+GCvW2zzpa7n5RHwR+UyksTGwD1vbQsi +DglIW3IjrdTM5/zuXsjmCxZX2MwxL7vZ62IDiEIlZefpz+7PdROU6fFwqZLryJB bHMTJpD+tjpxIv1j/xKSXA1f6KIOALVpA5eIaPc/S4ZGc4ZAHqghwzsE62fTv/3R 5M20csuAeP5nhEeLpa1UH7+4qLg9HAosXVYfbALeJunLYSUCiBmN2/XmA4W4Q3OD btS8fvt68Lax6srHkcHWFv39doXZNWkPTPFbsWJzqWVW0vhIh1YWJWCtobZ93wGM huKVTG49JGvB8qZQAnYaZdMrIYmNI/x9YYwV9rsvcpTANTRKAHEMoz4jX7fxGjrS xjqmr2RpoDpnd1xvyXIirnn4WkQeO2OF2xhABsAvMstfZf+PAhXl7flucLH2oTNy /8ZIzbItjoFWrbXqtEwE7goMq5XcP4BGOmr+nj2EukJF7CqWkj0= =r0JP -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmpOiy4ACgkQ7ZfpDmKq fjS51g//XdOjk0dzan2ashSNf6NiJ90VuBhCJAeCPBqr3BCVOD94K1riazP1ZbnN q2ex9llB63ZXuZ52W0Q5NigP1eQ+SOzYFN1WD8bQc4uUDfhF8vCO2bAF7bFyzWPd PD+geLWT23lkDtMGFDNePHYgiaOnBvqvadRryUbiPuXTJnEb0VCFU6catuAp+bG8 HADbnFAYQosiR+O2WVvhDmVdDtbJqaPFZFILSK4J+uxD6Kf8sS0/twEm5+hmJiPE Hy7yI65yKGKDcCCp0OFu/+412ZAOgExjVdC58/IGHYit8pAzI35mMm2xfzicShCk Sj1cm8mKLDC8w6J9huqNMK+p8NW4RrjMoeJaa11vgy3ARYkqVnfNZI+YPxQO5LKB yrgw8NF5ZafJYSYR+ZmjiZWTGe/1tMoC6GRmzwfIYmaLFlAIw4fTAe4ySqRIVgKo J5u28wneVxjCbueIE1qgWWvCIvz8xVB6ytx90SPigp6FumKTJiZm2/vF/Hem/5Hk gwKFSxGRBwBIVh5uaWWJEft2nSvpG5lONo1rZ2ygPTfbczjZMDZpoxEmWIeZjQ+r LrzNaDpzxFecfLvlUMrIOr4iwH14cDwkdGtCIJ5N/7uBwLfg+7sYts4pmAVdBZxd sCbAuEN/GtkNPV4cSYnDyF0FbM4zPGbztlOxxiOQG1RtJ51rbjI= =VYnI -----END PGP SIGNATURE-----

6 6

Time Zone Database
by EL MAAYATI Afaf July 8, 2026

July 8, 2026

Dear Paul, I'm Afaf EL MAAYATI from National Telecommunications Regulatory Agency in Morocco. Actually, in the current version of Time Zone Database (https://www.iana.org/time-zones) for Africa region, and especially for Morocco, it’s mentionned that a program will be running to implement the transition dates. According to this program, the next transition dates (during 2023) are as below : - March 19, 2023 (switching to GMT). - April 30, 2023 (switching back to GMT+1). In fact, we will switch back to GMT+1, advancing 60 minutes, on Sunday, April 23 at 2:00 a.m (not on April 30). Please refer to the official annoncement, published by the Ministry of Digital Transition and Administration Reform: https://www.mmsp.gov.ma/fr/actualites/passage-%C3%A0-l%E2%80%99heure-gmt-%C… So, would you please update the program, in order to consider « April 23 at 2:00 a.m » (for switching back to GMT+1). Thank you in advance for your feedback and for your habitual support. Thank you. Best Regards, Afaf EL MAAYATI National Telecommunications Regulatory Agency Morocco [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

2 6

[PROPOSED 1/3] zic: fix translation typo
by Paul Eggert July 7, 2026

July 7, 2026

* zic.c (checkabbr): Fix typo introduced by my “zic: refactor calls to gettext” change (2026-06-21): the mp diagnostic was not translated as it should be. --- zic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.c b/zic.c index 0b9dc37f..d5e521d6 100644 --- a/zic.c +++ b/zic.c @@ -4215,7 +4215,7 @@ checkabbr(char const *string) if (*cp != '\0') mp = N_("time zone abbreviation differs from POSIX standard"); if (mp != NULL) - warning(N_("%s (%s)"), mp, string); + warning(N_("%s (%s)"), _(mp), string); } } -- 2.53.0

1 2

Request for consideration of a dedicated time zone identifier for Coyhaique, Aysén Region, Chile
by Victor Alfonso July 7, 2026

July 7, 2026

Dear Time Zone Database Maintainers, I am writing from Coyhaique, the capital city of the Aysén Region in Chile, regarding the recent adoption of UTC−03:00 in our region. Currently, many operating systems, applications, and online services identify our location using the existing "America/Punta_Arenas" time zone. While this provides the correct UTC offset, Coyhaique and the Aysén Region do not appear as a selectable or identifiable location in many systems. This can create confusion for local users, organizations, businesses, and visitors who are attempting to verify or configure the correct local time. I would like to respectfully inquire whether the creation of a dedicated time zone identifier, such as "America/Coyhaique", could be considered for inclusion in the IANA Time Zone Database. I understand that new identifiers are generally created when there are historical differences or the possibility of future divergence in timekeeping rules. However, the Aysén Region now operates under UTC−03:00 and has a distinct regional identity and administrative significance that may justify separate representation within systems that rely on the IANA database. In addition, Coyhaique serves as one of the principal gateways to Chilean Patagonia and is the administrative, commercial, and logistical center of the Aysén Region. Every year, the city receives a significant number of domestic and international visitors who rely on digital systems to coordinate flights, accommodations, tours, transportation, and business activities. The absence of a specific identifier for Coyhaique in many operating systems and platforms may create uncertainty regarding the local time zone, particularly for visitors who are unfamiliar with the relationship between Aysén and the "America/Punta_Arenas" identifier. A dedicated reference to Coyhaique could improve clarity and user experience for travelers, businesses, service providers, and software systems operating within the region. If a new identifier is not currently considered necessary, I would greatly appreciate any clarification regarding the criteria that would need to be met for such consideration in the future. Thank you for your time and for the important work you do in maintaining this essential global resource. Kind regards, Víctor Alfonso Coyhaique, Aysén Región. Chile

6 7

Re: Alberta time zone change is now official
by Aoun Khan July 7, 2026

July 7, 2026

Hello, I was following the discussion regarding Alberta’s planned switch to permanent UTC-6:00. I would like to provide the following update that the Act to switch time zones has indeed officially gone through proclamation as of June 18, 2026. https://www.alberta.ca/proclamations Red Tape Reduction Statutes Amendment Act, 2026 (SA 2026 c12). Sections 3, 5(3) to (8) and 11 proclaimed in force on June 18, 2026. Amends the Daylight Saving Time Act(RSA 2000 cD-5), the Gaming, Liquor and Cannabis Act (RSA 2000 cG-1) and the Natural Gas Marketing Act (RSA 2000 cN-1). Section 9(1), (2)(f), (h) and (j), (4) to (6), (9), (11)(a), (68)(a) and (78)(a), (b) and (e) proclaimed in force on September 1, 2026. Amends the Land Titles Act (RSA 2000 cL-4). It’s possible you may already be aware of this, but I just wanted to let you know as the discussion intrigues me. Sincerely, Aoun Khan

4 3

Compiler warnings about zic.c in 2026b
by Tom Lane July 6, 2026

July 6, 2026

I'm observing a few compiler warnings when building 2026b with MSVC 19.50.35726: ../pgsql/src/timezone/zic.c(353): warning C5287: operands are different enum types '<unnamed-enum-RF_NAME>' and '<unnamed-enum-LF_TARGET>'; use an explicit cast to silence this warning ../pgsql/src/timezone/zic.c(353): warning C5287: operands are different enum types '<unnamed-enum-RF_NAME>' and '<unnamed-enum-LP_YEAR>'; use an explicit cast to silence this warning This is with a somewhat modified file, but what it's pointing at is the same in the released 2026b sources: /* The maximum number of fields on any of the above lines. (The "+"s pacify gcc -Wenum-compare.) */ enum { MAX_FIELDS = max(max(+RULE_FIELDS, +LINK_FIELDS), max(+LEAP_FIELDS, +EXPIRES_FIELDS)) }; Perhaps instead of the "+"s, do explicit casts to int? ../pgsql/src/timezone/zic.c(1654): warning C4146: unary minus operator applied to unsigned type, result still unsigned This one is unhappy about /* The largest uintmax_t that is a multiple of BASE**6. Any random uintmax_t value that is this value or greater, yields a biased remainder when divided by BASE**6. UNFAIR_MIN equals the mathematical value of ((UINTMAX_MAX + 1) - (UINTMAX_MAX + 1) % BASE**6) computed without overflow. */ uint_fast64_t unfair_min = - ((UINTMAX_MAX % base__6 + 1) % base__6); Don't immediately have a suggestion about silencing this one. (This one is showing up on substantially older MSVC versions than the first two, as far back as MSVC 19.29.30159. I don't see these warnings on any non-Microsoft compiler.) regards, tom lane

4 11

Re: [PROPOSED] Morocco goes to plain UTC on 2026-09-20
by Anass Taghjichte July 6, 2026

July 6, 2026

Hi, Following up on the earlier request to wait for the official decree before finalizing this change: the decree has now been published in the Moroccan Official Gazette (Bulletin Officiel), so there is now an authoritative primary source beyond the press reports. Reference: - Décret n° 2.26.530 of 9 Muharram 1448 (25 June 2026), concerning legal time ("l'heure légale"). - Published in Bulletin Officiel n° 7521, page 3768. - Direct link (Arabic): https://www.sgg.gov.ma/BO/AR/3111/2026/BO_7521_Ar.pdf Unofficial translation of the operative articles: - Article 1: At 02:00 on Sunday, 20 September 2026, Morocco returns to legal time based on GMT (per Royal Decree 455.67 of 2 June 1967), by setting the clocks back 60 minutes. - Article 2: Decree 2.18.855 of 26 October 2018 (which had added the permanent +1 hour) is repealed, effective the same date. This confirms the proposed transition to +00 on 2026-09-20 at 02:00. Per Article 1, the change applies throughout the national territory of the Kingdom, consistent with the single legal time in force across the country. I'm happy to help translate any specific wording from the decree if useful. Regards, -- *Anass TAGHJICHTE* Phone:+212675716127 <212675716127> Email: taghjichte(a)gmail.com <taghjichte(a)gmail.com> Skype: Mr-Anass <https://webapp.wisestamp.com/> <http://ma.linkedin.com/in/taghjichte> <http://twitter.com/AnassTaghjichte> <http://www.facebook.com/taghjichte>

2 1

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