- tz - lists.iana.org

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

Proposed correction for zone.tab and Link: Europe/Uzhgorod to Europe/Uzhhorod
by Sorel Si May 17, 2025

May 17, 2025

Dear tz database maintainers, I would like to propose a correction to the spelling of the Ukrainian city Uzhhorod in the tz database. Currently, the city is referenced as "Uzhgorod" in `zone.tab` and as a Link target: In `zone.tab`: UA +4837+02218 Europe/Uzhgorod Zakarpattya west Link definition (in the `europe` data file): Link Europe/Kyiv Europe/Uzhgorod The spelling "Uzhgorod" (with a 'g') appears to be a transliteration from the Russian language form of the city's name ("Ужгород"). However, Uzhhorod is a city in Ukraine. The official Ukrainian name is "Ужгород". According to the current official Ukrainian national system for romanization of Ukrainian Cyrillic (approved by Resolution No. 55 of the Cabinet of Ministers of Ukraine, January 27, 2010), the Ukrainian letter "г" (which is present in "Ужгород") is transliterated as "h". Therefore, the correct romanized form from Ukrainian is "Uzhhorod". This spelling ("Uzhhorod") is consistently used by official Ukrainian sources, including the Uzhhorod City Council (e.g., uzhhorod-rada.gov.ua) and in national legislative documents. Given this, I propose the following changes for accuracy and consistency with Ukrainian national standards: 1. Update the entry in `zone.tab` to: `UA +4837+02218 Europe/Uzhhorod Zakarpattya west` 2. Update the Link target name to `Europe/Uzhhorod`: `Link Europe/Kyiv Europe/Uzhhorod` This would align the tz database with the official and correct transliteration of the city's name from its native language. Thank you for your time and consideration. Sincerely, Arsenii

5 4

[PROPOSED] Don’t mention iso3166.tab in zone1970.tab comment
by Paul Eggert May 16, 2025

May 16, 2025

* zone1970.tab: Remove mention of iso3166.tab in comment. In FreeBSD iso3166.tab is not installed, which makes the comment confusing in an installed file. Although FreeBSD gets around this problem by editing zone1970.tab, it’d be better if FreeBSD could use zone1970.tab unmodified. --- zone1970.tab | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zone1970.tab b/zone1970.tab index 36535bdf..f3227405 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -2,14 +2,14 @@ # # This file is in the public domain. # -# From Paul Eggert (2018-06-27): +# From Paul Eggert (2025-05-15): # This file contains a table where each row stands for a timezone where # civil timestamps have agreed since 1970. Columns are separated by # a single tab. Lines beginning with '#' are comments. All text uses # UTF-8 encoding. The columns of the table are as follows: # # 1. The countries that overlap the timezone, as a comma-separated list -# of ISO 3166 2-character country codes. See the file 'iso3166.tab'. +# of ISO 3166 2-character country codes. # 2. Latitude and longitude of the timezone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, -- 2.49.0

2 1

opposition to recent time zone change in Paraguay
by Paul Eggert May 6, 2025

May 6, 2025

An article last week in El Nacional reports ongoing public opposition to Paraguay's decision to not fall back on March 22, which means sunrise might not occur until after 07:45 in western Paraguay in June. Sen. Blanca Ovelar will promote going back to the old -04/-03-with-DST regime. Other possibilities include changing government schedules for schools, banks, etc. to in effect revert the change for some people. Although I do not expect this to affect TZDB in the short run, we should keep an eye on the situation. Nuevo horario divide al Paraguay. El Nacional. 2025-04-29. https://elnacional.com.py/politica/nuevo-horario-divide-paraguay-n84973

1 0