- tz - lists.iana.org

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 7

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