- tz - lists.iana.org

Error in the Annuaire du Bureau des Longitudes for 1923
by Santoni Francis July 23, 2025

July 23, 2025

Hello, The most surprising thing, when I checked, in the 1980s, the consistency of this date of 1923 in the newspapers of the time, is that even in the daily newspapers there was, the day before, only a very short article, in the inside pages of the newspaper, whereas, in the same newspaper, for the previous years, the article indicating summer hours was always clearly visible. If I remember correctly, during the preceding months, the questioning about summer hours was reduced to procrastination. Le plus étonnant, lorsque j'ai vérifié, dans les années 80, la cohérence de cette date de 1923 dans les journaux de l'époque, c'est que même dans les quotidiens il n'y avait, la veille qu'un très court article, dans les pages intérieures du journal, alors que, dans le même journal, pour les années précédentes, l'article signalant les heures d'été était toujours bien visible. Si je me souviens bien, durant les mois précédents, le questionnement sur les heures d'été se résumait à des atermoiements. Francis Santoni

1 0

Yucatán thinks of moving from -06 to -05
by Paul Eggert July 23, 2025

July 23, 2025

Yucatán, which corresponds to TZDB’s America/Merida, is considering switching from -06 (CST) all year to -05 (EST) all year.[1] This would be akin to observing permanent daylight saving time. (Yucatán last observed DST in 2022, after which Mexico abolished DST except in regions near the US.) There does not seem to be any rush to decide whether to make the change. If Yucatán does switch presumably Campeche will not, so we would therefore need to split America/Merida into two zones, and as Mérida is in Yucatán we would need a new name for Campeche. The largest city in the Mexican state of Campeche is its capital San Francisco de Campeche, commonly called just “Campeche” like the state, so presumably America/Campeche would be the name of the new TZDB zone. One possible date and time for Yucatán’s hypothetical switch would be March 8, 2026 at 02:00, which is when US CST is planned to switch to CDT. Any such transition is purely speculative at this point, though, so I am not now proposing a patch to TZDB. [1]: David Domínguez Massa. Posturas desde el Congreso de Yucatán sobre homologar el horario con Quintana Roo. Diario de Yucatán. 2025-07-05. https://www.yucatan.com.mx/merida/2025/07/05/posturas-desde-el-congreso-de-…

1 0

Should all IDs from backzone be available in backward?
by robertbastian＠unicode.org July 2, 2025

July 2, 2025

The set of IDs (zones and links) in backzone is _almost_ a subset of the IDs in backward; the only ID that is in backzone but not in backward is Asia/Hanoi. Can Asia/Hanoi be added as a link in backward to ensure compatibility with systems that use IDs from backzone? Is this a desirable invariant that can be upheld in the future? This was reported to CLDR (https://unicode-org.atlassian.net/browse/CLDR-11977) so it looks like there are systems that are using these IDs.

6 8

Issue with America/Nuuk tz
by Dan Juskevicius June 20, 2025

June 20, 2025

Dear sir or madam, I'm currently working on an issue that one of our customers has reported with the tz database. Using the latest release (2025b), I have been able to reproduce an issue with America/Nuuk time where it reports at -02 instead of -01; I realize that as of 2023-03-25 the America/Nuuk time zone changed its standard time from -03 to -02, but it appears that it is not represented correctly in the tzdb. All other time zones in the database appear to be represented correctly, so I'm trying to narrow down the root cause of the issue but don't know where to look. Has anyone else reported issue with the America/Nuuk tz, and if so, is there a workaround for this? Cheers, Daniel Juskevicius Systems Software Developer djuskevicius(a)qnx.com QNX - It all starts here ---------------------------------------------------------------------- This email and any attachments are intended solely for the use of the individual or entity to whom they are addressed. This email may contain information that is confidential, privileged, or otherwise protected from disclosure. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this email in error, please immediately contact the sender and delete all copies of this email and any attachments from your systems. Any unauthorized review, use, dissemination, distribution, or reproduction of this email by unintended recipients is not authorized and may be unlawful. Thank you for your cooperation.

5 9

TZif Version Selection Issue in tzcode2025b
by PATAN JEELAN BASHA June 11, 2025

June 11, 2025

Hi All, We have encountered an issue after upgrading to tzcode2025b, where zoneinfo files that were previously generated in TZif3 format are now being generated in TZif2 format. This change appears to be due to the removal of the forced version in the writezone() call in zic.c file. Upon investigation, we found that: ->The logic in stringrule() that sets compat = 2013 based on wdayoff is not meaningful in practice. ->For rules like Sun>=8, wdayoff = 0, so compat = 0, and the compiler now generates TZif2. ->This behavior change appears to result from the removal of the forced version and the introduction of dynamic version selection logic. For example, in the northamerica file, we have: Rule US 2007 max - Mar Sun>=8 2:00 1:00 D Rule US 2007 max - Nov Sun>=1 2:00 0 S These rules are used by zones such as America/Chicago and others. Since Sun>=8 results in wdayoff = 0, the compat value remains 0, and the compiler now generates TZif2 instead of TZif3. This change affects all zones relying on similar rules, even though the rule definitions themselves have not changed. Specifically, the change from: writezone(zpfirst->z_name, envvar, ZIC_VERSION); // older code to: writezone(zpfirst->z_name, envvar, version, defaulttype); // new code has caused the compiler to emit TZif2 for rules that previously resulted in TZif3. We believe this logic does not reliably reflect the need for TZif3 and may lead to inconsistent or unexpected output formats. We would appreciate your thoughts on this and whether a patch or enhancement is planned to address it. Best Regards, Jeelan

3 3

Cape Breton Island "time zone"
by Arthur Olson June 10, 2025

June 10, 2025

"Google and Meta search both report that Cape Breton Island has its own time zone 12 minutes ahead of mainland Nova Scotia time because they are both drawing that information from a Beaverton article I wrote in 2024." --Janel Comeau (The Beaverton is a Canadian satire publication. Folks on this mailing list: be alert for Cape Breton Island come 2026-04-01.) --@dashdashado https://www.threads.com/@janelcomeau/post/DKs2YqBJgqK/google-and-meta-searc… https://thebeaverton.com/2024/07/cape-breton-to-create-new-more-annoying-ti…

1 0

Fix example for zic transition coalescence
by Tim Parenti May 30, 2025

May 30, 2025

I noticed a typo in zic.8 within the "correct" example given for how zic handles/coalesces certain transitions. While I was there, it also made sense to expand a bit more on where the incorrect interpretation could come from, as a further nod to why we choose instead to have zic coalesce transitions as it does. Documentation patch attached and pushed to the development repository. -- Tim Parenti

1 0

Proposal to Add Asia/Penampang to IANA Time Zone Database
by Denis Martin May 30, 2025

May 30, 2025

Dear tz maintainers, I am submitting a formal proposal to add a new time zone entry: Asia/Penampang. The proposal seeks to represent the distinct historical, geographic, and cultural identity of Penampang and greater Kota Kinabalu (Sabah, East Malaysia) in the IANA Time Zone Database. The full proposal is hosted publicly here: https://github.com/dmmartin/Asia-Penampang-Proposal This submission builds on precedent (e.g., Asia/Kuching for Sarawak) and is fully aligned with the IANA project's criteria for regionally distinct zones, even where UTC offsets are identical. Thank you for your time and consideration. Best regards, Denis Martin Sabah Time Zone Advocacy penampang.tzproposal(a)fakemail.org Denis Martin

3 2

PyCon US Time
by Ee Durbin May 20, 2025

May 20, 2025

PyCon US is an annual gathering for the community using and developing the open-source Python programming language. PyCon US has been held in-person and on-location from 2003 to present with exception for 2020 and 2021 in response to the global COVID-19 pandemic. After an initial three year stint in Washington, D.C. USA PyCon US has been hosted in cities across North America in two-year "cycles". PyCon US makes extensive use of software across an annoying number of online and offline systems. These include GNU/Linux servers, PostgreSQL databases, all web browsers, a mobile application, Raspberry Pis, iPads, Zebra printers, printed materials, and human brain matter. These systems persist year-over-year while our timezone does not. This timezone is proposed to provide a durable solution for ensuring agreement between these systems. After over a decade dealing with these concerns, establishment of this timezone will benefit me directly, as well as those who proceed me by reducing churn in our codebases, and entirely obliviate the need to think during stressful periods of conference planning. It will also benefit my co-workers and those who follow them by dissolving an unnecessary cognitive burden when editing records in our systems, communicating deadlines and schedules, and working with one another remotely. It will also benefit attendees in reasoning about these matters. PyCon US Time is defined to be the local time of the city currently hosting the conference. PyCon US Time transitions at the time that last attendee (Larry Hastings, most often) departs the Development Sprints. We are actively working to improve the historic times for this departure, but estimate 8pm local time for years which have not yet been fully verified. Transitions =========== 2003-02-13 First Annual PyCon announced - Reference: https://www.python.org/psf/press-release/pr20030213/ - Location: Washington DC, USA, -5:00 2005-03-25 PyCon US Washington concludes - New Location: Dallas, TX, USA, -6:00 - Last Attendee Departure: Unconfirmed 2007-03-01 PyCon US Dallas concludes - New Location: Chicago, IL, USA, -6:00 - Last Attendee Departure: Unconfirmed 2009-04-02 PyCon US Chicago concludes - New Location: Atlanta, GA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2011-03-17 PyCon US Atlanta concludes - New Location: Santa Clara, CA, USA, -8:00 - Last Attendee Departure: Unconfirmed 2013-03-21 PyCon US Santa Clara concludes - New Location: Montréal, Québec, Canada, -5:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Montréal concludes - New Location: Portland OR, USA, -8:00 - Last Attendee Departure: Unconfirmed 2015-04-16 PyCon US Portland concludes - New Location: Cleveland, OH, USA, -5:00 - Last Attendee Departure: 7:59pm local time 2015-04-16 PyCon US Cleveland concludes - New Location: Worldwide, 0:00 - Last Attendee Departure: Unconfirmed - Reference: https://x.com/pycon/status/1126637785455185920 - Note: After PyCon US 2019, the planned conference cycle in Pittsburgh, PA, USA was undertaken on-line for 2020/2021. 2021-10-12 PyCon US Salt Lake City Launched - New Location: Salt Lake City, UT, USA, -7:00 - Reference: https://pycon.blogspot.com/2021/10/pycon-us-2022-website-and-sponsorship.ht… 2023-04-27 PyCon US Salt Lake City concludes - New Location: Pittsburgh, PA, USA, -5:00 - Last Attendee Departure: Unconfirmed 2025-05-22 PyCon US Pittsburgh concludes (Estimated) - New Location: Long Beach, CA, USA, -8:00 While I appreciate and understand that this submission may appear to be a gag/joke, I am sincere in this request and humbly request that it be considered with sincerity in kind. -Ee Durbin Director of Infrastructure Python Software Foundation

2 2

Request for Update: Iran's Official Time Zone – No Daylight Saving Time Since 2023
by Khalil Kharazi May 19, 2025

May 19, 2025

Dear Time Zone Database Maintainers, I hope this message finds you well. I am writing to bring your attention to an important legal update regarding the official timekeeping policy of the Islamic Republic of Iran. In March 2022, the Iranian Parliament passed legislation to permanently abolish Daylight Saving Time (DST), effective from March 2023. As a result, Iran now observes a fixed time zone of UTC+3:30 throughout the entire year, with no forward or backward clock shifts. This change is now fully implemented across all provinces and official systems within the country. However, it has come to our attention that some international platforms, time services, and applications may still reflect outdated DST rules for Iran, which can lead to errors in scheduling, communication, and automation. Given the widespread reliance on the IANA Time Zone Database (tzdata) by global operating systems and applications, we kindly request that you verify and reflect this official update in the relevant database records (Asia/Tehran) to ensure accurate representation of Iran’s current time zone policy. Should you require further documentation or references to the legislation, I would be glad to provide official sources or translations as needed. Thank you for your attention to this matter and for your continued efforts in maintaining a reliable and globally synchronized time zone system. Sincerely, [Khalil Kharazi]

2 1