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 1

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