- tz - lists.iana.org

Re: Disabling adjustment, hyphenation, SGR, and page headers and footers in man pages
by Paul Eggert Aug. 28, 2025

Aug. 28, 2025

On 2025-08-27 16:42, G. Branden Robinson wrote: > I sent this to tz(a)iana.org a few days ago, but it appears to have gotten > discarded, maybe because I am not subscribed to the list. Yes, it's August and I suspect mailing list reviewers are on vacation. For tz list readers: Branden's original email is archived here: https://lists.gnu.org/r/groff/2025-08/msg00041.html > I have a suggestion for accomplishing all of the tasks named in the > Subject with command-line options to (recent) nroff. If I understand > the "workman.sh" script correctly, all that would be left for your > pipeline is to strip a trailing blank line. Thanks for the suggestion. As TZDB has been shipping *.txt files with single header and trailer lines for some time, I think we can simply prefer that style now for groff; this removes the need to strip a trailing blank line. For traditional nroff the best we can easily do is omit all headers and trailers, to avoid irritating headers elsewhere. > You might find it more convenient to use command-line options than to > append to macro definitions and otherwise inject *roff into nroff's > input stream (which is interpreted only after the macro package is > loaded, a fact that will have important consequences in groff 1.24). Thanks for the suggestion. Although this assumes groff we can do it just for groff (and for mandoc) and continue to do things the traditional way on old-fashioned (by now, very old-fashioned) hosts. I installed the attached proposed patches to implement your suggestion and a bit more.

1 0

Re: question regarding Mongolian timezone /Hovd GMT+/
by Munkh-Erdene Erdenebat Aug. 28, 2025

Aug. 28, 2025

Dear IANA Colleagues, I hope this message finds you well. My name is Munkh-Erdene from Mobicom Corporation, a mobile phone operator in Mongolia. I have a question regarding the Mongolian timezone, specifically for the Hovd region. According to various online sources, Mongolia currently has two time zones: Hovd (UTC+7) and Ulaanbaatar (UTC+8). The Hovd timezone is observed in three provinces: Hovd, Bayan-Ulgii, and Uvs. However, when I checked the tzdata files (zone.tab and zone1970.tab), it lists five provinces under the Hovd timezone. My understanding is that it should be only the three provinces mentioned above. Could you please advise on the process for requesting a correction in tzdata? Are there any specific requirements we need to meet? Also, please let me know if my understanding of the timezone coverage is incorrect. Thank you for your time and support. MUNKH-ERDENE Erdenebat Manager Core Network Department /CND/ CN&BSD/TS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> From: Munkh-Erdene Erdenebat Sent: Wednesday, March 13, 2024 5:28 PM To: tz-owner(a)iana.org<mailto:tz-owner@iana.org> Subject: question regarding Mongolian timezone /Hovd GMT+/ Dear IANA Colleagues, How are you, doing well. I am Munkh-Erdene from Mobicom Corporation, which is Mongolian mobile phone operator. I've question regarding Mongolian timezone. We have some misunderstanding regarding Mongolian timezone, specially for Hovd region. As we checked from internet, it says there is 2 timezone in Mongolia now. Hovd+7 and Ulaanbaatar +8. Behind of Hovd region, there is 3 provinces which is Hovd, Bayan-Ulgii & Uvs. [cid:image004.png@01DC1810.84CC7F10][cid:image007.jpg@01DC1810.84CC7F10] World Time Zone Map (24timezones.com)<https://24timezones.com/timezone-map> Mongolia Time Zone - WhichTimezone<https://whichtimezone.com/asia/mongolia/> But when I checked from tzdata file. Zone.tab & zone1970.tab files. There is 5 aimags behind of Hovd region, it should be 3 provinces which is Hovd, Bayan-Ulgii & Uvs. We want to correct it on tzdata, how can we send request to you and is there any requirements from you? please correct me if I was checked wrongly. [cid:image008.jpg@01DC1810.84CC7F10] [cid:image009.jpg@01DC1810.84CC7F10] MUNKH-ERDENE Erdenebat Department Manager Network Operation & Maintenance Department /NOMD/ TOMD/TOMS [mobicomnewlogo] Peace Avenue 3/1, Post Office-46 Ulaanbaatar-14201, Mongolia. Mobile : (976) 94081000 Web : www.mobicom.mn<http://www.newcom.mn/> ???????? ?????? ????? ?????? ?? (????????????? ????) ?????? ?????? ?????????? ?????????, ?????? ???? ??? ????? ???????? ???????????? ?????. ?? ????? ??????? ??????????? ???????? ?? ??????? ?????????????, ????????? ???????? ?????? ?????? ??????????? ???????????? ???? ?????????? ? ??????? ????????????? ??? ?? ????????????? ??. ????? ?? ?? ????? ??????? ??????? ???????? ?????? ????? ??? ??? ?????? ????? ??????? ????????? ????? ????? ?????? ?????? ?????? ????????, ?????????? ????? ????? ????? ??????? ?????? ????????? ??? ????? ?????? ???? ??????? ???? ??. ???????? ?????? ???????? ??????????? ?????????? ?????? ????????? ?????????, ??????????, ?????? ?????? ????? ?? ??????????? ????????? ??????? ????? ?????? ????, ?? ?????? ????? ????? ??? ?????? ???????? ??. Disclaimer This email (including any attachments) is intended only to be read and used by the addressee. It may contain confidential or legally privileged information, which is not waived if it is mistakenly delivered to you. If you are not the intended recipient, please immediately notify the sender by return email and delete both messages from your system; any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

3 3

Asia/Riyadh TZ abbreviation "+03"?
by Peter Chamberlin Aug. 25, 2025

Aug. 25, 2025

Wouldn’t this be better defined as "AST" for Arabia Standard Time per https://24timezones.com/Riyadh/time?

5 9

[PROPOSED 1/3] Fix adjustment and hyphenation in *.txt files
by Paul Eggert Aug. 24, 2025

Aug. 24, 2025

* date.1: Remove no-longer-needed .nh and .na. * workman.sh: Modernize the code that disables adjustment and hyphenation, to work in groff 1.23 too. Add comments. --- date.1 | 2 -- workman.sh | 18 +++++++++++++++--- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/date.1 b/date.1 index 3a02e7c2..5f334358 100644 --- a/date.1 +++ b/date.1 @@ -4,8 +4,6 @@ .SH NAME date \- show and set date and time .SH SYNOPSIS -.if n .nh -.if n .na .B date [ .B \-u diff --git a/workman.sh b/workman.sh index 29f317cb..ad1a9532 100644 --- a/workman.sh +++ b/workman.sh @@ -9,12 +9,24 @@ if (type nroff && type perl) >/dev/null 2>&1; then # Tell groff not to emit SGR escape sequences (ANSI color escapes). export GROFF_NO_SGR=1 - echo ".am TH -.hy 0 + printf '%s\n' '. +.\" -- Tailor groff -man -- +. +.\" Left-adjust and do not hyphenate. +.ds AD l +.nr HY 0 +. +.\" -- Tailor traditional troff -man -- +. +.\" Left-adjust and do not hyphenate. +.am TH .na +.hy 0 .. +.\" Omit page headers and footers. .rm }H -.rm }F" | nroff -man - ${1+"$@"} | perl -ne ' +.rm }F +.' | nroff -man - ${1+"$@"} | perl -ne ' binmode STDIN, '\'':encoding(utf8)'\''; binmode STDOUT, '\'':encoding(utf8)'\''; chomp; -- 2.50.1

1 2

Possible upcoming change to America/Argentina/*, from -03 to -04
by Salvador Pardiñas Aug. 23, 2025

Aug. 23, 2025

Hi all! I wanted to warn you about a potential change to all the Argentinean timezones, as a law proposal looking to move the entire country to GMT-4 has now passed the Lower Chamber of Parliament, and is now waiting for approval by the Upper Chamber of Parliament: https://www.lanacion.com.ar/politica/la-camara-de-diputados-le-dio-media-sa… https://www.infobae.com/sociedad/2025/08/21/cambio-de-huso-horario-en-argen…

1 0

[PATCH] Mention Qinling Station opened in Antarctica on 2024-02-07.
by Collin Funk Aug. 16, 2025

Aug. 16, 2025

Hi Paul, Regarding this comment at the top of the antartica file: # From Paul Eggert (1999-11-15): # To keep things manageable, we list only locations occupied year-round; see # COMNAP - Stations and Bases # http://www.comnap.aq/comnap/comnap.nsf/P/Stations/ [...] You may want to update it to link to page which is not dead [1]. It contains a link to "COMNAP Antarctic Facilities List", which is a file that is updated periodically as things change in Antarctica (not often, I assume?). Currently it is this [2]. Anyways, China opened a new year-round base in 2024 that it is probably worth mentioning [3]. It has a higher population than their other ones, if Wikipedia is to be trusted [4]. Patch attached. Collin [1] https://www.comnap.aq/antarctic-facilities-information [2] https://www.comnap.aq/s/Facilities_Nov2024.csv [3] https://www.reuters.com/world/china/china-opens-antarctic-station-south-aus… [4] https://en.wikipedia.org/wiki/Qinling_Station

2 1

DST in Baja California 1973
by Alois Treindl Aug. 6, 2025

Aug. 6, 2025

TZ maintains for zone America/Tijuana that there was not DST observed between 1961 and 1975. > # Baja California > Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 7:00u > -7:00 - MST 1924 > -8:00 - PST 1927 Jun 10 > -7:00 - MST 1930 Nov 15 > -8:00 - PST 1931 Apr 1 > -8:00 1:00 PDT 1931 Sep 30 > -8:00 - PST 1942 Apr 24 > -8:00 1:00 PWT 1945 Aug 14 23:00u > -8:00 1:00 PPT 1945 Nov 15 # Peace > -8:00 - PST 1948 Apr 5 > -8:00 1:00 PDT 1949 Jan 14 > -8:00 - PST 1950 May 1 > -8:00 1:00 PDT 1950 Sep 24 > -8:00 - PST 1951 Apr 29 2:00 > -8:00 1:00 PDT 1951 Sep 30 2:00 > -8:00 - PST 1952 Apr 27 2:00 > -8:00 1:00 PDT 1952 Sep 28 2:00 > -8:00 - PST 1954 > -8:00 CA P%sT 1961 > -8:00 - PST 1976 > -8:00 US P%sT 1996 > -8:00 Mexico P%sT 2001 > -8:00 US P%sT 2002 Feb 20 > -8:00 Mexico P%sT 2010 > -8:00 US P%sT A user of our astrology service, born in 1973 in he border town Mexicali claimed that they observed DST in his town, just like on the other side of the border in California, when he was born on 30 May 1973. I did a quick newspaper archive research on https://hndm.iib.unam.mx/ and found that Título: Periódico Oficial del Estado de Baja California Norte Fecha: 1973-04-20 states clearly that DST was observed from last Sunday in April to last Sunday in October. This means the the TZ table above is false, at least for 1973. I assume that the same is the case for several other years. I attach the screenshot for 1973 The page https://hndm.iib.unam.mx/consulta/publicacion/visualizar/558075be7d1e63c9fe… should allow to search for other years as well. I used the keywords *hora legal* for my search, though do not see that now in the URL.

4 7

Fwd: Bulletin C number 70
by Tim Parenti Aug. 4, 2025

Aug. 4, 2025

No leap second 2025-12-31, per below. See attached patch. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jul 2025 at 05:43 Subject: Bulletin C number 70 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, 07 July 2025 Bulletin C 70 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 2025. 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

4 11

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

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

Re: wrong last-modified timestamp in NIST leap-seconds.list
by Paul Eggert April 24, 2025

April 24, 2025

On 2025-04-24 07:04, Judah Levine wrote: > Your comments have adequately addressed the #$ timetamp definition, which is described in the comments to the file. It has been defined this way for as long as I have prepared the file. There has been no leap second for a long time, and that time stamp reflects that fact. The name of the file is chosen in the same way - it changes only when a new leap event is announced, and now points to a time years ago. > I choose the expiration date of the file so that the list of leap seconds in the file will be correct at least until that date. I use IERS Bulletin C, IERS Bulletin A, and other IERS data to derive that date. It includes a prediction of the evolution of UT1-UTC by the IERS, and is more comprehensive than the simple announcement of a leap second in Bulletin C. > Apart from the recent and continuing drama in the environment here, the file has always been updated long before the expiration date arrives - usually when a new Bulletin C is published. The expiration date is intended to be a safety valve if (and only if) there are more serious problems. I regret that I cannot assure you that the current high level of drama is decreasing. > The leap second file is distributed by FTP. The method has very significant difficulties - it is a long and tedious process to update the file, and there are various reports that it is difficult to access. I don't have a choice about this, at least for now. The other alternatives, such as a web page, would be even more difficult to maintain. Thanks for the heads-up. This makes it clear that the NIST vs IERS leap-seconds.list metadata differences are intentional. I installed the attached proposed patch to TZDB to try to document this in a way that TZDB users can easily understand. If it weren't for the problems with FTP and with NIST's lagging expiration timestamps, I'd prefer the NIST metadata as they're less volatile. For now, though, the proposed patch merely changes commentary, rather than changing the default leap-second data source from the IERS back to the NIST (which was the source for many years, until TZDB release 2024a). Perhaps after things have settled down we can help coordinate the IERS and NIST leap-seconds.list files so that they agree not just about data, but also about the last-modified and expiration timestamps. This would help reduce confusion in the future.

2 1

[PATCH] Don't mention boulder.nist.gov
by Collin Funk April 24, 2025

April 24, 2025

The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves. From the Internet Archive for boulder.nist.gov it seems like it was a redirect for nist.gov until it was later deleted. The attached patch removes reference to it. Collin [1] https://web.archive.org/web/20180901000000*/boulder.nist.gov

6 13

[PROPOSED 1/6] * Makefile: Modernize comment.
by Paul Eggert April 21, 2025

April 21, 2025

--- Makefile | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2130582c..502fe2fa 100644 --- a/Makefile +++ b/Makefile @@ -10,10 +10,11 @@ # To affect how this Makefile works, you can run a shell script like this: # # #!/bin/sh -# make CC='gcc -std=gnu23' "$@" +# make CFLAGS='-O2 -DHAVE_GETTEXT=0' "$@" # -# This example script is appropriate for a circa 2024 GNU/Linux system -# where a non-default setting enables this package's optional use of C23. +# This example script is appropriate for a GNU/Linux system +# which needs more optimization than default, and which does not want +# gettext's internationalion of diagnostics. # # Alternatively, you can simply edit this Makefile to tailor the following # macro definitions. -- 2.48.1

2 7

SBOM required for tzdata2025b and tzcode2025b
by Sahil Sharma D April 21, 2025

April 21, 2025

Hi team, Could you please share the SBOM for tzdata2025b and tzcode2025b? Regards, Sahil

4 6