November 2025 - tz - lists.iana.org

Nunavik to stop changing its clocks after March 2026?
by Paul Eggert Sept. 21, 2026

Sept. 21, 2026

Yesterday’s CBC News report “Nunavimmiut have wound back their clocks for the last time”[1] is so light on details that for now I am merely attaching a draft patch to this email for review, rather than installing the patch into the development repository. I found no announcement of the change at www.makivvik.ca. Although I asked for more details by using the form at <https://www.makivvik.ca/contact/>, these sorts of contact forms often do not work, so if anyone has access to more-authoritative info than the CBC report, please let us know. Among other things, details in the news report make me wonder how likely Makivvik would reconsider its decision before the change would take effect about a year from now. [1]: https://www.cbc.ca/news/canada/north/nunavik-daylight-savings-9.6969650

3 2

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

[Feature Request] Add validation in zic for invalid DST intervals
by 任春辉 Dec. 17, 2025

Dec. 17, 2025

Hello tzdata maintainers, I would like to propose a feature enhancement for the zic compiler. Currently, the NOS time zone rules are defined as: Rule NOS 1970 2037 - Jan 27 23:43:01 2:0 SDST Rule NOS 1970 2037 - Jan 28 0:51:01 0 S Zone OS/NOS +7:0:0 NOS NO%s Issue: - The first rule enters DST at 23:43:01 with a +2 hour offset, moving local time to 01:43:01. - The second rule is intended to revert to standard time at 00:51:01. - Due to the offset, 00:51:01 local time never occurs, so the second rule will never trigger. - This creates unreachable local times and may cause incorrect results in time calculations. Proposal: - Add validation in the zic command to detect DST rules where the offset causes the subsequent rule's local time to be unreachable. - The validation could issue a warning or error to alert the author of potentially invalid rules. - This would improve the robustness of time zone definitions and prevent subtle bugs in downstream applications. Thank you for your consideration. Best regards

3 5

backward file for zonenow.tab?
by kirill.gagarski＠gmail.com Nov. 17, 2025

Nov. 17, 2025

Hi. Our software tries to expose a list of supported timezones to an end user for setting up some periodic scheduled task in the UI. Till now we've tried to populate the list of Java supported timezones, filtering out aliases (from backward file). I noticed that zonedata now ships with zonenow.tab file which is exactly what we need for our UI and meets our needs more precisely. Unfortunately it seems quite impossible to migrate old data to this new notation automatically. For example, hte fact that 'Europe/Berlin' is covered by 'Europe/Paris' in zonenow.tab is not mentioned anywhere. Is there a way to determine this fact from tzdata without deep analysis of the rules done by myself? Other simple question: is there a way to know what is "now" in zonenow? Is it defined by the release date of a new version?

4 6

Calendrical Issues Russia section
by Kirill Gagarski Nov. 14, 2025

Nov. 14, 2025

I fully understand that I am trying to engage into a 30 y.o discussion now, but the Russia section in calendars file repeats quite widespread myths about Eternal Calendar with 30th February. I used to believe in that myself, given quite a little information on the internet about the issue. Even Wikipedia spread this myth back in the day. Even the Russian version of Wikipedia spreaded the myth: https://ru.wikipedia.org/w/index.php?title=%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D… Nowadays, Wikipedia is more clean about the issue, providing some source links: https://ru.wikipedia.org/wiki/%D0%9D%D0%B5%D0%BF%D1%80%D0%B5%D1%80%D1%8B%D0… https://en.wikipedia.org/wiki/Soviet_calendar The truth is: - Gregorian calendar was continuously used during the mentioned time - 30th February in USSR is an absolute myth (to be more clear, this is a declined proposal of a new calendar) - Mentioned 5-day weeks and 6-day weeks were in fact an attempt to relabel weekdays (Monday-Sunday) - Relabeling was done in a way, not conflicting with traditional weekdays (they used words like "third day of six-week day" or colors). Traditional names were used in parallel I could not say, the calendar file does not say the truth (after all, it raises doubts in a second quoted message), and all this information is indeed very interesting from a historical point of view, but does not seem relevant to Calendrical Issues. In fact 100 years later no one (unless someone is specifically interested in these weird weekdays) cares if 12th of December of 1937 was "sixth day of six-day week", because it was Sunday at the same time. I'd suggest removing the whole Russia section from this file (you can keep the small note about switching from Julia to Gregorian calendar in 1918), since for the purpose of it it raises nothing but confusion.

2 2

[PROPOSED] Fix unlikely backslash bug in scripts
by Paul Eggert Nov. 12, 2025

Nov. 12, 2025

* tzselect.ksh, workman.sh: Use printf, not echo, if the argument might in theory contain a backslash. --- tzselect.ksh | 9 +++++---- workman.sh | 2 +- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 7cd8679d..85a8c670 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -145,9 +145,11 @@ do t*) # Undocumented option, used for developer testing. zonetabtype=$OPTARG;; -help) - exec echo "$usage";; + say "$usage" + exit;; -version) - exec echo "tzselect $PKGVERSION$TZVERSION";; + say "tzselect $PKGVERSION$TZVERSION" + exit;; -*) say >&2 "$0: -$opt$OPTARG: unknown option; try '$0 --help'"; exit 1;; *) @@ -516,8 +518,7 @@ while ' ="$distance_table" ) echo >&2 'Please select one of the following timezones,' - echo >&2 'listed roughly in increasing order' \ - "of distance from $coord". + say >&2 "listed roughly in increasing order of distance from $coord." doselect $regions region=$select_result tz=$( diff --git a/workman.sh b/workman.sh index 91621b10..5da55654 100644 --- a/workman.sh +++ b/workman.sh @@ -51,6 +51,6 @@ elif (type nroff && type perl) >/dev/null 2>&1; then } ' else - echo >&2 "$0: please install groff, or mandoc and col" + printf >&2 '%s\n' "$0: please install groff, or mandoc and col" exit 1 fi -- 2.51.0

1 0

Melbourne's Shrine of Remembrance
by Tim Parenti Nov. 11, 2025

Nov. 11, 2025

Earlier this year, Julian O'Shea released a short video detailing a peculiarity about the Shrine of Remembrance in Melbourne, "How Daylight Savings Broke this $24 Million Building": https://www.youtube.com/watch?v=mfzsBMUiGGQ The shrine, originally dedicated in 1934 to honor those who served in World War I, was designed with a small aperture in the roof. Each Remembrance Day (11 November) at 11:00am local time, the position of the sun would be perfectly aligned to shine through the aperture, allowing the light of its rays to fall upon an inscribed stone inside, thus commemorating the hour of the Armistice. The problem? Several decades later, in 1971, Victoria adopted DST, but of course the aperture had been tuned to the position of the sun at 11:00am AEST. So what do you do to preserve this meaningful element of an annual ceremony with important dignitaries, when it's effectively been moved an hour earlier to 11:00am AEDT instead? The answer involves a clever system of mirrors. (And the general public still gets to witness the light following its true path an hour later!) Since this is quite a grand physical representation of how we interact with our timekeeping, I've added this to tz-art.html, as well as a few fixups to unclosed HTML tags nearby. -- Tim Parenti

4 3

Cape Town
by Justin Singh Nov. 11, 2025

Nov. 11, 2025

Hello The Timezone for Cape Town is UTC+01:00 The western Northern Cape and Western Cape differ, however. Everywhere on land west of 22°30′ E effectively experiences year-round daylight saving time because of its location in true UTC+01:00 but still being in South African Standard Time. Sunrise and sunset are thus relatively late in Cape Town, compared to the rest of the country.

6 7

Phoenix AZ timezone issue
by akbar＠marketing-qa.com Nov. 5, 2025

Nov. 5, 2025

🧭 Problem Summary Arizona remains one of the few U.S. states that does not observe Daylight Saving Time (DST) since 1968. However, it identifies its time zone as Mountain Standard Time (MST) — which does change to MDT when DST applies elsewhere. Because of this, every spring and fall, Arizona’s effective time alignment shifts: In summer, Arizona matches Pacific Daylight Time (PDT). In winter, it matches Mountain Standard Time (MST). This causes systemic issues in digital calendars, automated scheduling, flight bookings, and cross-state business coordination, requiring frequent manual adjustments. 💡 Recommended Solution Create and declare a dedicated time zone: “Phoenix Standard Time.” This would be a fixed, non-DST time zone officially recognized by IANA (the Internet Assigned Numbers Authority) and major platforms (Microsoft, Apple, Google). All digital devices could use it as a unique time zone identifier that never shifts with DST — eliminating confusion and rescheduling errors. It would function similarly to “UTC+7” year-round but would display as “Phoenix Standard Time (PST)” in software systems. Thank you Akbar Jaffer Akbar Jaffer Office: (415) 335-6950 Mobile: (650) 430-0232 Web: Marketing-QA.com <http://www.marketing-qa.com/> Meeting: Book time W/Akbar <https://calendly.com/ajaffer/> LinkedIn <https://www.linkedin.com/in/akbarjaffer/> | POI Blog <https://pointofintersection.org/>

8 9

How to select zones for a TimeZone picker
by Guillermo Rodriguez Garcia Nov. 3, 2025

Nov. 3, 2025

Hi all, I'm building a TimeZone picker with the following constraints: 1. At least one distinct timezone per country (so that e.g. there is an entry for Atlantic/Reykjavik instead of mapping IS to Africa/Abidjan) 2. Within a country, do not show timezones that currently have identical rules to another timezone in the same country (i.e. historical differences don't matter). Because of (1) I started from zone.tab rather than zone1970.tab. However, I'm not sure how to handle (2). For example, Spain has three zones in zone.tab: Europe/Madrid, Africa/Ceuta, and Atlantic/Canary. But as far as most users are concerned, as of today there are only two timezones in Spain: Madrid and Canary Islands. Ceuta follows Madrid rules, so there should be no need to show this as an option to the user. Another example: the U.S. lists 29 zones, but only 8 are distinct today (ignoring historical changes). So, the question: Any suggestions on how to filter timezones within each country to drop those that as of today are not relevant except for historical differences? Thank you, Guillermo Rodriguez Garcia guille.rodriguez(a)gmail.com

8 17