- tz - lists.iana.org

false story re canceling DST in Canaries and Spain
by Paul Eggert March 15, 2025

March 15, 2025

Last week saw a widely spread false story that daylight saving time will be canceled in Spain and in the Canary Islands, starting in the year 2026. The story was reported as fact in the Daily Mirror[1], which evidently got it from the Canarian Weekly[2]. Both stories said that the last clock change would be this month (implying permanent daylight saving time), that the change would officially take place in 2026 (contradicting the last-clock-change assertion), and that this had been confirmed by the Official State Gazette (BOE), i.e., Spain's Boletín Oficial del Estado. As Gazette Life noted Thursday[3], the story is false. There is no change to Spain's timekeeping plans. I guess the bogus story is based on a misreading of Order PCM/186/2022 dated 2022-03-11[4], which listed DST transitions for 2022 through 2026. A copy of this old order was recently marked as updated by BOE (I don't know why), and my guess is that the "new" order popped up on some reporter's AI, which generated the hallucination that Spain was discontinuing DST. This reminds me of the 2023 false story about Greenland abolishing DST that was first published, as far as I can determine[5], by Bloomberg's Lebawit Lily Girma. Although I had an email correspondence about that bogus story with two Bloomberg editors, the bogus story was never corrected or retracted. I expect the same thing would happen with the Daily Mail and the Canarian Weekly, so I am not bothering to write them. We can expect more of these falsehoods in the era of generative AI, which makes it easier to write bogus stories that superficially look authentic. I am seeing considerably more use of generative AI even in scholarly papers on the subject. [1]: Bautista A. Huge EU country loved by Brits will stop changing clocks in 2026. The Mirror. 2025-03-11. https://www.mirror.co.uk/travel/huge-eu-country-loved-brits-34832825 [2]: The Canary Islands are set to abandon clock changes from 2026. Canarian Weekly. 2025-03-09. https://www.canarianweekly.com/posts/The-Canary-Islands-are-set-to-abandon-… [3]: No change on clocks for Spain and Canaries. Gazette Life. 2025-03-13. https://gazettelife.com/news/no-change-on-clocks-for-spain-and-canaries/ [4]: Orden PCM/186/2022, de 11 de marzo, por la que se publica el calendario del período de la hora de verano correspondiente a los años 2022 a 2026. https://www.boe.es/eli/es/o/2022/03/11/pcm186 [5]: Eggert P. Did Greenland abolish daylight saving from 2024 on? https://mm.icann.org/pipermail/tz/2023-April/032870.html

1 0

Ireland Time Zone
by Chris Brown March 11, 2025

March 11, 2025

Hello, We received a notification from a customer that the Ireland Time Zones sprung forward too early. According to what I found the following is true: Last Sunday of March 01:00 GMT - Last Sunday of October 01:00 GMT = GMT+1 Last Sunday of October 01:00 GMT - Last Sunday of March 01:00 GMT = GMT+0 As of the time this issue was reported the Eire (GMT+1) and Europe/Dublin (GMT+1) time zones need to be GMT+0, however, they are GMT+1. Are there any standard troubleshooting tips I can pass along to our developers? I’m looking through the documentation I can find and the threads and have seen a couple regarding Irelands time zones, but nothing conclusive on how to solve our issue moving forward. I’d like to understand if this is an error, or if there is a configuration we need to make on our end to ensure the time zones are correct in our system. [cid:image001.jpg@01DB927E.D1C45080] [Meazure Learning]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.meazurelearning.com…> meazurelearning.com [Facebook]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.facebook.com%2FMeaz…> [X]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fx.com%2Fmeazurelearning…> [LinkedIn]<https://us.content.exclaimer.net/?url=https%3A%2F%2Fwww.linkedin.com%2Fcomp…> Christopher Brown Product Manager [cid:image006.png@01DB927E.D1C45080] cbrown(a)meazurelearning.com<mailto:cbrown@meazurelearning.com> [cid:image007.png@01DB927E.D1C45080] 205-807-0349<tel:205-807-0349> [cid:image008.png@01DB927E.D1C45080] 205-807-0349<tel:205-807-0349> [cid:image009.png@01DB927E.D1C45080] Alabama, US (35244) [cid:image010.png@01DB927E.D1C45080]

2 1

Paraguay DST is no longer in use
by Nicolas Elisardo Garcia March 7, 2025

March 7, 2025

Paraguay currently observes Paraguay Time (PYT) all year. DST is no longer in use. Clocks do not change in Paraguay. The previous DST change in Paraguay was on October 15, 2024. Is there a new software release available for this update? Thanks in advance, Regards. Este mensaje y todos los archivos adjuntos a él son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Claro o alguna de las empresas accionistas. La publicación, uso, copia e impresión total o parcial de este mensaje o documentos adjuntos queda prohibida. Cualquier situación y/o comportamiento que pudiera resultar contrario a lo establecido en el Código de Ética disponible en https://www.americamovil.com/Spanish/gobierno-corporativo/Programa-de-Integ… - comunicarlo, incluso anónimamente, a través de la página web https://denuncias.americamovil.com/. This message and any attachments are for exclusive usage of an addressee and may contain confidential or privileged information whose disclosure is subject to penalty by law. If you are not the addressee, please notify the sender by return e-mail, delete the original message and destroy any existing copy no matter if printed or recorded. Any opinions contained in this e-mail are those of the author of the message and do not necessarily coincide with those of Claro or its shareholders. No part of this message or attachments may be used or reproduced in any manner whatsoever. Any situation and/or behavior that could be contrary to the provisions of the Code of Ethics available at https://www.americamovil.com/English/corporate-governance/integrity-and-com… - report it, even anonymously, through the website https://denuncias.americamovil.com/. Este mensaje y todos los archivos adjuntos a él son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por ley. Si usted recibió este mensaje erróneamente, por favor notifíquenos respondiendo al remitente, borre el mensaje original y destruya las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Claro o alguna de las empresas accionistas. La publicación, uso, copia e impresión total o parcial de este mensaje o documentos adjuntos queda prohibida. Cualquier situación y/o comportamiento que pudiera resultar contrario a lo establecido en el Código de Ética disponible en https://www.americamovil.com/Spanish/gobierno-corporativo/Programa-de-Integ… - comunicarlo, incluso anónimamente, a través de la página web https://denuncias.americamovil.com/. This message and any attachments are for exclusive usage of an addressee and may contain confidential or privileged information whose disclosure is subject to penalty by law. If you are not the addressee, please notify the sender by return e-mail, delete the original message and destroy any existing copy no matter if printed or recorded. Any opinions contained in this e-mail are those of the author of the message and do not necessarily coincide with those of Claro or its shareholders. No part of this message or attachments may be used or reproduced in any manner whatsoever. Any situation and/or behavior that could be contrary to the provisions of the Code of Ethics available at https://www.americamovil.com/English/corporate-governance/integrity-and-com… - report it, even anonymously, through the website https://denuncias.americamovil.com/.

7 6

Re: buffer overflow in zic
by Paul Eggert March 6, 2025

March 6, 2025

On 2025-03-05 21:56, Евгений Горбанев wrote: > I found this scenario while researching the postgresql code using Svace > static analyzer. > Well, try this scenario: > > $ cd /tmp > $ wget https://data.iana.org/time-zones/releases/tzdb-2025a.tar.lz > $ tar xf tzdb-2025a.tar.lz > $ cd tzdb-2025a > $ make CFLAGS='-fsanitize=address -g' > $ touch test > $ ./zic -l test -d . Thanks for the explanation and recipe. I can reproduce the problem. Please try the attached proposed patch. I installed it into the development repository <https://github.com/eggert/tz>. Thanks.

1 0

buffer overflow in zic
by Evgeniy Gorbanev March 5, 2025

March 5, 2025

Hello! IfoundthatifI runzictocreatea linkonanotherdevice, the bufferoverflowinzip.c:1422inversion2025awill occur. Inthislinei==0. The commandtoreplay: ./zic -l test -d . -t /path/to/link_on_another_device Best regards, Evgeniy Gorbanyov

4 4

DST offsets other than +1
by Doug Ewell March 4, 2025

March 4, 2025

1. Are there any time zones that currently observe DST with an offset other than adding one hour? (For this question, I am treating “negative DST” zones like Europe/Dublin and Africa/Windhoek as if they observed “standard” time in winter and adjusted time in summer. Also, for this question I am only interested in current practice, not historical.) 2. Is there an easy way I could have looked up this information in the tz files? (“Easy” means without exhaustively parsing all the Rule and Zone lines, as a processor would have to do.) Thanks, -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

6 8

North Dakota HB 1259 requiring year-round standard time
by asinglet＠epic.com March 1, 2025

March 1, 2025

https://legiscan.com/ND/text/HB1259/2025 HB 1259 passed the North Dakota House last week. No idea on whether it will pass the ND Senate or be signed into law. The tricky thing about this bill is that it does not have an implementation time frame. Theoretically if it moves through in the next week or two, we could be looking at a repeat of the Lebanon 2023 fiasco. I hope if they are going to pass it, they take their time.

4 4

Maryland HB1290
by Arthur Olson Feb. 21, 2025

Feb. 21, 2025

The hearing on Maryland House Bill 1290, "Full-Year Daylight Saving Time," has been cancelled: https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb1290 In past years such bills died in committee, but only having had a hearing; this is the earliest death yet for such a bill. Perhaps the state legislators have more important matters on their minds this year. @dashdashado

2 1

EST5EDT should not resolve to America/New_York because they have different offsets
by Austin Hill Feb. 21, 2025

Feb. 21, 2025

Hello - I recently filed a GitHub issue against the perl DateTime::TimeZone library, which uses your database: https://github.com/houseabsolute/DateTime-TimeZone/issues/58#issue-28644459… I noticed that EST5EDT now resolves to America/New_York. This is problematic because the two do not have the same offset - EST5EDT is -5:00 and America/New_York is -04:56:02. My ticket was closed because the behavior appears to be caused by changes in your database in commit a0b09c0 ( https://github.com/eggert/tz/commit/a0b09c0230089252acf2eb0f1ba922e99f7f4a03 ). Is this something that you would consider changing? Thanks! - Austin Hill

9 16

localized date without time
by Alejandro Colomar Feb. 12, 2025

Feb. 12, 2025

Hi Paul, Link: <https://github.com/shadow-maint/shadow/issues/1057> Currently, shadow utils' passwd(1) (and several other programs) uses UTC time when printing. That is: $ passwd -S alx alx P 2023-09-20 0 99999 7 -1 the date from above is a UTC representation of $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 However, shadow utils programs, such as chage(1), use local time in input. That timestamp was set by chage(1), interpreting a local date: $ sudo chage -d 2023-09-21 alx $ sudo cat /etc/shadow | grep alx | cut -f3 -d: 19620 $ date Wed Jul 31 07:54:17 CEST 2024 This is rather confusing, and we think that passwd(1) should also print the date in local time, when printing human-readable dates. However, I think it might be better to show the timezone information together with the date, to be clear that what we're printing is local time. Do you think that's reasonable? Or maybe it's understood that when printing a date some timezone information is implicitly local? I didn't find any way to print timezone information in ISO 8601, if you don't print the time together with the date. That is, ISO 8601 says: C.1.3.1 Date A date string represents one of the following: • year, month, and day (e.g. 2001-02-03) • year and month (e.g. 2008-12 ) • year (e.g. 2008) and C.1.3.2 Date and Time A date/time string is composed according to one of three representations as illustrated in the following three examples: • 2001-02-03T09:30:01 • 2004-01-01T10:10:10Z • 2004-01-01T10:10:10+05:00 but I don't see any way to print something like 2023-09-21+02:00 in standardese. Is this a defect in ISO 8691? I see that in C.1.3.2, it says "Zone-offset may be omitted or included", so I guess we can just omit it. What do you think we should do? Thanks! And have a lovely day! Alex -- <https://www.alejandro-colomar.es/>

5 13