- tz - lists.iana.org

time keeps on slipping into the future
by Bradley White Oct. 15, 2022

Oct. 15, 2022

tzfile.5 says: > After the second header and data comes a newline-enclosed, > POSIX-TZ-environment-variable-style string for use in handling > instants after the last transition time stored in the file I had imagined that the reference implementation would apply the future rule for all of the future, but I currently observe that UTC-offset changes get stuck after a while for many (but not all) zones. For example, for *"Australia/Sydney"*, whose POSIX TZ string is *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the following civil times at the given instants: 14745254399 = 2437-04-05T02:59:59+1100 14745254400 = 2437-04-05T02:00:00+1000 14760979199 = 2437-10-04T01:59:59+1000 14760979200 = 2437-10-04T03:00:00+1100 That looks good ... daylight time from the first Sunday in Oct through the first Sunday in Apr, shifting at 03:00. But once we hit 2438, the UTC offset is stuck at +1100. For example, in July we would expect to see standard time, but instead get: 14784296400 = 2438-07-01T00:00:00+1100 And it never seems to recover after that. I'm pretty sure this used to work.

2 8

Jordan DST - News
by Issam AlZawairi Oct. 11, 2022

Oct. 11, 2022

Hello, The Council of Ministers in Jordan decided Wednesday 5th October 2022, that daylight saving time (DST) will be throughout the year. Here's a link from an official news website https://en.royanews.tv/news/37769/2022-10-05 Thanks for creating a new TZ DB version. P Please consider the environment before printing this email Issam Al-Zuwairi DevOps Manager - Technology and Digital Innovation Zain Jordan [cid:image001.png@01D8D8B7.02E841A0] M: 00962797612342 T: 00962797900900 ext: 5809 E: <mailto:%7bemail%7d> issam.alzawairi(a)jo.zain.com<mailto:issam.alzawairi@jo.zain.com> www.jo.zain.com<http://www.jo.zain.com/> [cid:image002.jpg@01D8D8B7.02E841A0]

3 4

[tz-announce] 2022e release of tz code and data
by Paul Eggert via tz-announce Oct. 11, 2022

Oct. 11, 2022

The 2022e release of the tz code and data is available. This release reflects the following changes: Briefly: Jordan and Syria switch from +02/+03 with DST to year-round +03. Changes to future timestamps Jordan and Syria are abandoning the DST regime and are changing to permanent +03, so they will not fall back from +03 to +02 on 2022-10-28. (Thanks to Steffen Thorsen and Issam Al-Zuwairi.) Changes to past timestamps On 1922-01-01 Tijuana adopted standard time at 00:00, not 01:00. Changes to past time zone abbreviations and DST flags The temporary advancement of clocks in central Mexico in summer 1931 is now treated as daylight saving time, instead of as two changes to standard time. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022e.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit c4eb3fcf2fc736b7924176cf9c3f9c305c398b8b dated 2022-10-11 11:13:02 -0700 and tagged '2022e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 7b3771bfa024d0bf445256f4d837a046eaba910ca3f2a5b4fcaf72ddd5fe34a9318a68f94ee09c0de120f3bdea41e9a16b0e82763896df8a6254ced0b454c060 tzcode2022e.tar.gz 3b63ba2662930ee13dec79290f57545d71d21d4ddb76f94498a7096edaee0b3150e501c221c4d596df6af7c1d770c211f88feb5add13c5e3bed979218b4544da tzdata2022e.tar.gz 6b316ac2d9dfe615685164accd126ee29c363fafe0d3483ac155644c5693693758e7315aa9f55c0a3e3c027d38f1125462d84a13fd424458b86f6be33f153cc7 tzdb-2022e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBIACgkQ7ZfpDmKq fjR5uxAAncvLsl0jRRUoY/5t92LNweU9UG3qTV6k3Y8GMlY6vOl3LFPM/Be9RKzr oJ6z3JNjOHTeE69Y8xWDqzcxyKiFIyJV3l9p0Pc6JiBWWmI/MOarja3PjGsw8v0C jv4pV+Qm5zObEvtIBboOsK5WE26/5zzP0mlW+zseAu9Qj2Ed9MuAB4xw7SDHlzWN k49SwPeeIrnW6z4iIx55KHZv2bn7XSytw1X5ZsVEizEzO+uNJh0/P0VfS9FCWdyY tOop5WYBzFfPfqHP4Daq1UbZF79lJS0W+7d7VFjgWq4dLI1C9B0H1LAO3TDPIHj+ lbq4RyGEuevl1pFXLQcum34tzlPfv5vrJF6elHWAzxZESRQwuUQ4ZEl3dkdU6P2l h/V9haUG8NHzFHsa+gVABqJ+HbNYeh6U8ve313PB/7kYtCG3ECQuKMouVQkTdNTE yh96FvKQcfqLGEdbLl9F4FyMAD2LVCQZsJeflBYQjXoMJWI/UDW5EJewxosx6ltG OizhQFY7VYnTSdv5PLevfaT0b+qQ5VJ7kNGdyRo+jjtReN8jt/Nr/ZOu7kgx2e2V fDtGfOdEe/3Hc2ZkxhdAP4q/mw17feiEC+ngbHhmtdvGO+Zm02lOwcfVb3vURTHf Pgb74iYpEioxMSlmeNjeHXeo2zPOsAfZDKv1jTuExEkrEZRKAZQ= =Bfnc -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBMACgkQ7ZfpDmKq fjRUzxAAvpQHbranZRCN7Kf5XHR+0oQEio4zDl0ETg/dXmndWUN360JwHIcmzGQR H6XHIPihZX/iBq9R+1gzYDijRagWGJ4YgUnp9qJ9GnM2Xj7+DNkTBjuy+p5fMXU2 /tofAxlaJx4Mb1C7BDLuRc4jtU+36VxCvycwOyEYocngOapOGr/7xooTgYsT6BdR UcxdM6E+M/9PR8Mocz7PrVGyA3QanUp/tLtw6Q7s43Ch9E4W7TTX1T9tVF2b/9Ka 5PmamLEUVBpo0Ia4ofydr0W41sU4A0WRfVu9VjwikNbSJ7Vkw7hEWcgR6aH+GfCN 2ZfGq7JMPhJh3oWuNOTYx6h2ySS3EgRXo3x+4ktm2UIdublCnjzaXl45Hokuqu2F 9RzNeSDc5S1obh72SeALH3FymeeI/dUk3nNqZbM1UvxrJtICn6xcbGA5g78ItExb BOK19dLzkAo8dduBrBRFo7gZ1wB5hudJn5xeY4jsh1Q6lcnYKdWk6k7DcnirNuJG NkbvSlXq+83zxT6DpZXlCpN8qRV6crFcGSq1UUbpX2bRmkqdvmuAOwfdEjqLoH54 fMHPMBSszzaJdMyGmFM7VaJYWmH/I5mUZHQmT+XagL7ZDjGgwMNsoeCGKPBa7vLx lQZU9rwMgqWBm+LimwaZRJrXAoNgk1O+xeYvjNg4cUmiJOgy2wI= =XYNS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBQACgkQ7ZfpDmKq fjSNbQ/9FMWPzYHrbPVJH6IZjnfbz0Zc1XeZTDZLvK6BEARPy2fs7/8hWlvuSpz3 nPSIyK3gZyEyd88xSgkzpvf6AvbYRz/KN+6ntOTq1tYoxIcRcqEG8MFqDQ0ZhQuK EqzqGFZHwZbCR4iiZXxiCC7SqX7kRs/rGdXjCZPas/lUn1wkAKoG9oF0JlNCZn8e TdipevHL0AkuG2/mRHTV3r2NAQcs9MTOd0UJyA2gRBDL/BU02jhmaqm13kjsdAEl 5/K8c/o1jGpiuq5nm0fMMMtvnemdu6vWsY8rfbTl9UUKu421Ky6CZ1qVjG0jsGf9 12W5poAbnNQwqxuCCu66QIbwl6CKS3qveSaEvfKMg1OKF1Zc8B3bxVG/oXgAWNo2 jDl/RaTrUVDQC2fxIJjJTHJjwZRAeBH+J8iy3gnuZqeZUvXZLibiIeVCVUfTa5Mf 2ZwxuNcIjY05Ox4ldlAgSmy4ozzRRl8J7X5YoNKR+/H1Nc+t6pzJELCkA+cqXO6c dyBUk7imH08zy+J3EpujEJhFG1s3dunKr0TA494wT8xlXgZm0PNIjz3P4pgsWbUc IWeVvlGhlOOMaIug2JroYGM3yFiyDdcXo3olelZFqAukakQxTb8XFiJGuFtq+USg Hxn09bCLS2BCf8ut3T1TO8g8CF/rAFIASVPvpAZK4fCHOIq+Kq8= =Ttyr -----END PGP SIGNATURE-----

1 0

Re: [tz] What's your idea of a perfect date?
by dpatte Oct. 11, 2022

Oct. 11, 2022

In Canada, the official method for today is 11/10/2022, except if you are a programmer, or from Quebec, where 2022-10-11 (ISO style) is more common. But I sometimes get cheques (checks) from the USA which for today would be 10/11/2022. So here at least, we see cheques with all 3 formats. Most Canadians no longer use cheques - now I see why. US chains (Walmart) often print their receipts in the US format, but Canadian businesses generally use Canadian or ISO format. Its a huge headache if you have a small business and count your pennies on your receipts at tax time - especially if your corp year end is not Dec 31st. 'Was this receipt for last tax year or this tax year'. I personally convinced Ottawa International Airport to convert their displays to ISO format. Their original display software was setup with the USA format. ----- Original Message ----- From: Fred Gleason via tz [mailto:tz@iana.org] To: "Tz Database IANA" <tz(a)iana.org> Sent: Tue, 11 Oct 2022 11:59:10 -0400 Subject: Re: [tz] What's your idea of a perfect date? On Oct 11, 2022, at 11:40, Brooks Harris via tz <tz(a)iana.org> wrote: I once had a check from a UK client (wait, I guess it must have been a cheque?) with a date like "19-7-2015". My American bank would not accept it because the date made no sense to them. It took phone calls and a visit to the bank to sort it out. :-) Even weirder (from a strictly parochial American POV) is a convention I’ve seen in German documents from the the early/mid-twentieth century (and perhaps today?), where the year would be expressed in Roman numerals. Thus: s/19-7-1932/19-7-XXXII/. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | The nice thing about standards is that there are so many of them | | to choose from. | | | | -- Andrew S. Tanenbaum | |---------------------------------------------------------------------|

2 1

What's your idea of a perfect date?
by Brooks Harris Oct. 11, 2022

Oct. 11, 2022

5 7

Regarding email subject "What's your idea of a perfect date?" -Brooks
by Brooks Harris Oct. 11, 2022

Oct. 11, 2022

My apologies for the email with subject "What's your idea of a perfect date?". It has only a .jpg, so it looks very much like spam or phish, as John Hawkinson pointed out to me. I didn't think of that, sorry. Its just a joke I thought the list might find amusing. -Brooks

1 0

Wrong timezone Information provided
by Markus Torshizi Moghaddam Oct. 11, 2022

Oct. 11, 2022

Hello, some weeks ago the timezone data for Europe/Luxembourg changed on your side and a "Link Europe/Brussels Europe/Luxembourg" was added to https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications. Can you please fix this. Thanks Best, Markus Torshizi Moghaddam Markus Torshizi Moghaddam Head of Customer Service markus.torshizi-moghaddam(a)cituro.com<mailto:markus.torshizi-moghaddam@cituro.com> Peter-Dörfler-Straße 30 | 86199 Augsburg Tel. +49 821 999 739 40 www.cituro.com/<https://www.cituro.com/> cituro GmbH, Amtsgericht Augsburg, HRB 36662 Geschäftsführung: Florian Heymel, Angie Wodarczyk [cid:image001.png@01D8D95B.2C271600]<https://www.cituro.com/> [cid:image002.png@01D8D95B.2C271600]<https://www.instagram.com/cituro_booking/> [cid:image003.png@01D8D95B.2C271600] <https://www.facebook.com/cituroDACH/> [Ein Bild, das Text, Transport, Axt, Rad enthält. Automatisch generierte Beschreibung] <https://twitter.com/cituroDACH> [Ein Bild, das Text, ClipArt enthält. Automatisch generierte Beschreibung] <https://www.xing.com/pages/cituro-gmbh> [cid:image006.png@01D8D95B.2C271600] <https://www.linkedin.com/company/cituro/> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

7 12

New Yorker article on David Mills and NTP
by scs＠eskimo.com Oct. 7, 2022

Oct. 7, 2022

Readers of this list may be interested in this article: "The Thorny Problem of Keeping the Internet's Time" https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-k… There are a few bobbles: the author seems a bit confused over whether NTP is an Internet RFC or a piece of software, and whether NTP is the IETF's only concern. And the New Yorker's predilection for diereses in English is rather comically distracting when ritually applied to the phrase "Coordinated Universal Time". Nevertheless, a nice read, covering both the technical issues and the people involved, with a particularly touching portrait of Mills himself.

14 23

Re: [tz] New Yorker article on David Mills and NTP
by dpatte Oct. 6, 2022

Oct. 6, 2022

I follow numerous astronomy lists, and there is serious discussion at the IAU (International Astronomical Union) to get rid of leap seconds altogether, and possibly replace them by something else, perhaps leap minutes (or even leap hours) - making them far less common. I believe they expect to make a decision soon, though they have been discussing it for years and had planned to make a decision 2 or 3 years ago. In this case we would add or drop a minute (or hour), when UT1 and UTC were more than a half-minute (or half-hour) out of sync. The concept with hours is that it would work more like a day-light savings transition, and named UTC1, UTC2, etc. Had this been done originally, there would have been no leap-second transitions up to now at all, in fact. ----- Original Message ----- From: Fred Gleason via tz [mailto:tz@iana.org] To: "Time Zone Database discussion" <tz(a)iana.org> Sent: Tue, 4 Oct 2022 13:05:49 -0400 Subject: Re: [tz] New Yorker article on David Mills and NTP On Oct 4, 2022, at 12:07, Steve Allen via tz <tz(a)iana.org> wrote: The implementation of time in computing systems is fragile because itis based on an unrealistic notion that clocks are always right andnever need to be reset. I suspect that one of the primary reasons that such time resets have been so fraught (and hence bitterly opposed by many ‘operations’ type folks) is their relative rarity. There have been only 27 leap seconds introduced since 1972, which means that deployed systems rarely have to cope with one and thus get the inevitable bugs identified and shaken out. It would almost be beneficial if such an event would occur at least once per annum, to allow the ‘reset’ logic to be regularly exercised. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | There cannot be a crisis next week. My schedule is already full. | | | | -- Henry Kissinger | |---------------------------------------------------------------------|

13 19

new update to Asia/Amman TZ
by obadeh.alqatawna＠orange.com Oct. 6, 2022

Oct. 6, 2022

Dears in IANA Organization Good day, Our government here in Jordan has just announced to keep working with GMT +3 TZ all the year in Jordan and here is the official news (Arabic version) https://petra.gov.jo/Include/InnerPage.jsp?ID=225894&lang=ar&name=news we need your support on this by having a new version of tz file that includes this update. Thanks in advance. Best Regards Obadeh Al-Qatawna IN & VAS Operations Team Leader - Orange Jordan Mobile: +962 7 7659 8434 [cid:image001.png@01D8D974.02A74520] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 4

Syria adopting "Permanent DST"
by Steffen Thorsen Oct. 6, 2022

Oct. 6, 2022

Various Syrian sources say Syria is adopting year-round DST, starting this autumn. However, some areas are not controlled by the Syria government, and therefore not affected by this. Some quotes (translations are not perfect!) From https://www.sana.sy/?p=1754885 "The Cabinet decided to adopt summer time throughout the year and abolish winter time." >From https://www.alsouria.net/%D8%AD%D9%83%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%86%… "The Council of Ministers in the regime’s government decided to adopt daylight saving time throughout the year. During its weekly session, in the presence of Prime Minister Hussein Arnous, today, Tuesday, the Council decided to cancel the winter time, which has been in place for decades in Syria. [...] permanent adoption of daylight saving time." From https://www.enabbaladi.net/archives/607812 "This [the decision] came after the weekly government meeting today, Tuesday 4 October [...]" "The decisions of the regime’s government to delay and advance the clock only apply to the areas under its control, while the northern countryside of Aleppo, which is administratively controlled by Turkey, depends on keeping daylight saving time during all months of the year, as is the case in Turkey, and the reason is due to direct relations with the Turkish state in the field of trade exchange. Public institutions and crossings. Thus, daylight saving time will remain in these two control areas." From https://sourpress.net/?p=170398 "In a statement to Al-Watan, the head of the Astronomical Society in Syria, Muhammad Al-Asiri, considered that this decision has great benefits on the level of energy savings, as well as on the economic level, especially tourism." We will soon publish an English summary in our time zone news section: https://www.timeanddate.com/news/time/ Best regards, Steffen Thorsen - timeanddate.com

2 1

Permanent DST in Jordan
by Even Scharning Oct. 6, 2022

Oct. 6, 2022

The government of Jordan has decided to observe permanent daylight saving time according to this source: https://www.arabiaweather.com/en/content/a-government-decision-to-install-d… Even Scharning Time.is - exact time for any time zone https://time.is/

1 1

Re: [tz] New Yorker article on David Mills and NTP
by dpatte Oct. 5, 2022

Oct. 5, 2022

Thanks Michael. Its nice to see the draft. Of course this has been proposed before and no firm decision was made then. Whatever they decide, I see UTC is an unfortunate but fair compromise between SI standard length seconds, and keeping our digital clocks close to being in sync with the variable length seconds of UT1. ----- Original Message ----- From: Michael H Deckers [mailto:michael.h.deckers@googlemail.com] To: "dpatte" <dpatte(a)relativedata.com>, <tz(a)iana.org> Sent: Tue, 4 Oct 2022 20:15:25 +0000 Subject: Re: [tz] New Yorker article on David Mills and NTP On 2022-10-04 19:01, dpatte via tz wrote: > I follow numerous astronomy lists, and there is serious discussion at the IAU (International Astronomical Union) to get rid of leap seconds altogether, and possibly replace them by something else, perhaps leap minutes (or even leap hours) - making them far less common. I believe they expect to make a decision soon, though they have been discussing it for years and had planned to make a decision 2 or 3 years ago. The BIPM is now in charge, and the CGPM on 2022-11-15..18 in Paris will vote on the proposal D on pages 7..8 and 23..24 in [https://www.bipm.org/documents/20126/66742098/Draft-Resolutions-2022.pdf/2e…] Michael Deckers.

1 0

[PATCH] MEXICO Law Inititive: End of DST after 2022
by hdcg＠ier.unam.mx Oct. 4, 2022

Oct. 4, 2022

From: Aztec Eagle' Turbo <turbo(a)cie.unam.mx> http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… Waiting for publishing in Diario Oficial de la Federación (DOF reference here when available) No new time zones created All border municipalities remain sync with US DST. All other zones remain same UTC offset, but no longer apply DST --- northamerica | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/northamerica b/northamerica index da84f354..7220905e 100644 --- a/northamerica +++ b/northamerica @@ -2616,6 +2616,14 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From <hdcg(a)ier.unam.mx>: End of DST 2022 Law Inititive +# http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… +# Waiting for publishing in Diario Oficial de la Federación +# (DOF reference here when available) +# No new time zones created +# All border municipalities remain sync with US DST. +# All other zones remain same UTC offset, but no longer apply DST + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2631,8 +2639,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u -- 2.37.3

2 1

[PATCH] MEXICO Law Inititive: End of DST after 2022
by Aztec Eagle' Turbo Oct. 4, 2022

Oct. 4, 2022

http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… Waiting for publishing in Diario Oficial de la Federación (DOF reference here when available) No new time zones created All border municipalities remain sync with US DST. All other zones remain same UTC offset, but no longer apply DST --- northamerica | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/northamerica b/northamerica index da84f354..7220905e 100644 --- a/northamerica +++ b/northamerica @@ -2616,6 +2616,14 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # 5- The islands, reefs and keys shall take their timezone from the # longitude they are located at. +# From <hdcg(a)ier.unam.mx>: End of DST 2022 Law Inititive +# http://sil.gobernacion.gob.mx/Archivos/Documentos/2022/09/asun_4385449_2022… +# Waiting for publishing in Diario Oficial de la Federación +# (DOF reference here when available) +# No new time zones created +# All border municipalities remain sync with US DST. +# All other zones remain same UTC offset, but no longer apply DST + # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Mexico 1931 only - May 1 23:00 1:00 D Rule Mexico 1931 only - Oct 1 0:00 0 S @@ -2631,8 +2639,8 @@ Rule Mexico 1996 2000 - Apr Sun>=1 2:00 1:00 D Rule Mexico 1996 2000 - Oct lastSun 2:00 0 S Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 6:00u -- 2.37.3

1 0

[PROPOSED] Treat 1931 changes in Mexico as DST
by Paul Eggert Sept. 30, 2022

Sept. 30, 2022

Mexico’s Chamber of Deputies was supposed to vote today on legislation abolishing DST in most of Mexico. Although the vote was delayed due to Internet problems, news coverage of the non-event led me to review our sources for DST in Mexico, and I found that tzdb considered the transitions in 1931 to be two changes to standard time, whereas it is considered to be DST in today’s news coverage, as well as in our main source, the history of Mexican local time published by the Investigation and Analysis Service of the Mexican Library of Congress. Fix this by considering the 1931 changes to be DST, not standard time. * NEWS: Mention this. * northamerica (Mexico): Add DST rules for 1931. (America/Mexico_City, America/Ojinaga, America/Chihuahua) (America/Hermosillo, America/Mazatlan, America/Bahia_Banderas): Use them. --- NEWS | 9 +++++++++ northamerica | 26 ++++++++------------------ 2 files changed, 17 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 64327d0..bcdad41 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,14 @@ News for the tz database +Unreleased, experimental changes + + Changes to past time zone abbreviations and DST flags + + The temporary advancement of clocks in central Mexico in summer + 1931 is now treated as daylight saving time, instead of as two + changes to standard time. + + Release 2022d - 2022-09-23 12:02:57 -0700 Briefly: diff --git a/northamerica b/northamerica index 13fb064..f848228 100644 --- a/northamerica +++ b/northamerica @@ -2617,6 +2617,8 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # longitude they are located at. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S +Rule Mexico 1931 only - May 1 23:00 1:00 D +Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S Rule Mexico 1940 only - Dec 9 0:00 1:00 D @@ -2667,9 +2669,7 @@ Zone America/Monterrey -6:41:16 - LMT 1921 Dec 31 23:18:44 Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 Mexico C%sT 2001 Sep 30 2:00 -6:00 - CST 2002 Feb 20 -6:00 Mexico C%sT @@ -2680,9 +2680,7 @@ Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2692,9 +2690,7 @@ Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2703,9 +2699,7 @@ Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2743,9 +2737,7 @@ Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2755,9 +2747,7 @@ Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 Zone America/Bahia_Banderas -7:01:00 - LMT 1921 Dec 31 23:59:00 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 -- 2.37.3

2 2

Moving more zones to 'backzone'
by Paul Eggert Sept. 29, 2022

Sept. 29, 2022

Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b. It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues. Comments welcome.

18 50

Re: [tz] Direct implementation of mktime_z
by Ted Phelps Sept. 28, 2022

Sept. 28, 2022

Hi Tony, On 2022-09-24, Tony Finch wrote: > You might also like https://dotat.at/@/2008-09-10-counting-the-days.html > (That does things the hard way, rather than relying on tm_yday) > and https://dotat.at/@/2008-09-15-the-date-of-the-count.html Wow, that's some clever math you've done there; far nicer than the clumsy approach I'd used to canonicalize the year, month and day. It's a little slower than my clumsy approach in the case where the year, month and day are already in canonical form, but can be much faster when they're not. I'll incorporate those changes into my git project in the coming days, thank you! -Ted

4 7

[news] DOT to map out nation’s time zones after report shows no official map exists
by Tony Finch Sept. 27, 2022

Sept. 27, 2022

https://edition.cnn.com/2022/09/22/politics/time-zone-map-transportation-de… : Federal transportation officials are now at work creating an accurate : map of the nation’s time zones, according to a report by the inspector : general for the Department of Transportation. : : The issue came up, the inspector general’s office said, after the US : Senate passed legislation this year to end the biannual time turn by : making Daylight Saving Time permanent. : : Investigators found no single map accurately showing the boundaries : nationwide and said several sources of time information on the DOT : website contained errors, such as inaccurately noting the time practices : in some localities. For example, one map incorrectly identifies a : deviation in Nevada: “Elko County, NV is shown as the location that : changed time zones rather than the correct location, the city of West : Wendover.” : : “The official boundaries are narratively described [in federal : regulations] with various types of coordinates and geographic features : such as lines of longitude, State or county lines, and rivers,” the : report stated. -- Tony Finch <dot(a)dotat.at> https://dotat.at/ Sole: Northwest 5 to 7, occasionally gale 8 until later. Rough or very rough. Rain or showers. Good, occasionally poor.

1 0

Direct implementation of mktime_z
by Ted Phelps Sept. 24, 2022

Sept. 24, 2022

Hi folks, I'm not sure if this is of interest here or not, but... I recently found myself needing to be able to convert a timestamp to broken-down time in multiple different time zones in a multi-threaded program. My plan was to use the localtime_rz and mktime_z functions included in the tzcode distribution, but I found that while localtime_rz is slightly faster than glibc's localtime_r, mktime_z is substantially slower than mktime. Poking around in the code, I was a bit surprised to find mktime_z just does a binary search of the whole time_t range, though I did appreciate this comment: Adapted from code provided by Robert Elz, who writes: The "best" way to do mktime I think is based on an idea of Bob Kridle's (so its said...) from a long time ago. does a binary search of the time_t space. Since time_t's are just 32 bits, its a max of 32 iterations (even at 64 bits it would still be very reasonable). I ended up writing my own localtime_rz and mktime_z with the assumption that time_t is always 64-bits and neither would ever be used with leap seconds (which was fine for the problem at hand) but that got me thinking: how hard would it be to extend that to support leap seconds. I ended up getting something that appears to work; you can see the results here: https://github.com/tphelps/tz64/ The performance improvement is substantial; on my laptop (Intel i7-8550U, 4GHz) it takes about 35ns to convert a struct tm to a time_t; whereas mktime_z takes about 3,300ns. Which, finally, brings me to my question: is there any interest in reworking tzcode's mktime to use a more efficient algorithm? I realize that it's a reference implementation, so correctness is very important, and you folks might not want to make such a significant change. If, however, you are interested, perhaps we can review what I've done to find and address any shortcomings in the approach I've taken (or to decide that it's fatally flawed, of course) before trying to use them in localtime.c. Any thoughts? -Ted

3 6

[tz-announce] 2022d release of tz code and data available
by Paul Eggert via tz-announce Sept. 24, 2022

Sept. 24, 2022

The 2022d release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine transitions are now Saturdays at 02:00. Simplify three Ukraine zones into one. Changes to future timestamps Palestine now springs forward and falls back at 02:00 on the first Saturday on or after March 24 and October 24, respectively. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. (Thanks to Heba Hamad.) Changes to past timestamps Simplify three Ukraine zones to one, since the post-1970 differences seem to have been imaginary. Move Europe/Uzhgorod and Europe/Zaporozhye to 'backzone'; backward-compatibility links still work, albeit with different timestamps before October 1991. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022d.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 0fc8f915a527d1d6610b9545aa3958cf89511927 dated 2022-09-23 12:02:57 -0700 and tagged '2022d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 54491ef8dbab7c41754eb3f2990b8ccb2a10960098c7d78d94375d7f1362540f0d71ba77a46bcaf95f419f8d01a23bdf940cdc9c7906c23ad6c40cd1c788b1c2 tzcode2022d.tar.gz f0d9f1dc6b7613598a861a3860f249e5beff75d8c4bb12bae21018ee617044cf25065dff08f81b0e6ed2c43602f2166dd6407a989a369a004e068260f2eece30 tzdata2022d.tar.gz bb1873550d5bb3fb0d1b595f321e2e90e63bba11bbd80a8c3d440903cb7a9ecd1db58644751b0925bc2854c2b17107238b3a2b9d5f8f91188e3b80b0b67f2673 tzdb-2022d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBjEACgkQ7ZfpDmKq fjQAEg//W+Dm8r7XHCZXNi/H87476tS4AZ8LiggRU+SAnkm7JDj7rAHhpR5uAO1s e1wXaKSMsfxHtUHCjmDn9qguGA3OPUaySaIw6+BGplfCAXarBj5tCrwsiF6T0tvY z3gTeu2E1DDzz2vree0y3boX9aTuFGmc9Ru+dUOVR/O4dun5RbN4VvKBdVRBIOpJ nXVSB12ZRRuTRoXeoSmKfXNPocM330yquWu/HvEdoWSspnx1hptY53DmG+BrSwvS 4uGfqTs5D4zleOaFXLNFb2igwmTS7g2nJGusud7ClXNeU8PkBUiS8ptFTX2n+TnQ SQxuVh+hTlMUjOMFWAkWxDPPRMM4sH3IgRj3y8sgSVOEaCfP9CGH0AgrgH6UuTlQ RtlQeFW2iYSyzmnvatEoE4tGu0bPjnJD7cnMFj6JWdJmks/A8ZgkkOCSAQ9tnqRj pMih15BOeRiQD6JSf8UJ7CIVhe44pN52DKIVZUxFzd6wyj25QRzF7yARykXYUAb6 quwy/WqkLV56MuZ21BuSWPXra1VXXygDctYHPSUuoXdHPEqY5BYtDNXD77e2vPiM X3oLLFe1j4rlY1tWQOymAFWJXL580l+kgzCS8Hf2cbPC0/on4Juol4rY4EB3RZHc FxhWPNDu9E1IIS4BP0BRLG56PQ9sGCy9NUFyxcimWBG2ApXHPTA= =MG7s -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkQACgkQ7ZfpDmKq fjQPuQ/9HOGp0hSxUup5vWDn0Eb5LChS+5J3nP1e6f6hjghGtOotMEmg/4Fc0w1w HqdEniaTzxMa//UxArnHrUP+rXNiodUIiykHXWXxGcEuYF3VX/PtFfBtodLRszRS gTbzRABrlzuyEvecX1/0rU+msi4IHAFV+/YFMv+2C5Fp8ra/nkailbN667m1MG6y HmHLov/lOfuZNKWGa1Z6B/gr7Oh3LmeQ+sPJc0v4OvKmPEER6E+Zwc4DvMJechD4 IJmdwkfHngyjgDHI2my8lvxWkWQnYgC2WXM/tZ/FAMSErakpwnpUo0FbzLs4Dfy1 WERS59Xqi8tiA+7hLxMGPirnXAF21hyb+L2E96FOVDv/ebQrwkfdekGN6MNYPLpy +pCbfwC+0zcfPc9BbvyxxPwdmpvzsFBQ3VwFO/M0jJQ8K6S/5OkTOi5OuKYaKVhV Wb6cXDE1Mf4EctOW/lyuA+xxJLRadjqFg6Cc5brFKLm7bf05JevGi/oboVo8sXIh qdYc8kqEEBdOzymeSwuo71jNaAYK2hN4hsDaJfxHQdObRx2p53AMTu+99pYiYHiT jOEXBQv6HwA4ve1oz2iMqsS2WTNfLctIVxYsFOLDXVHBkgxm5J9FQqJRvoDc30PK eYNRahWQ3MBGtaDRHQU5Vhru+au5CywihGTDvItvLpgVAO5LwJs= =VLZ9 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkgACgkQ7ZfpDmKq fjSHIxAAplxEGo1Sl94i7OXjVBJameXZ3p2J5AQ7LN3P1N8BOYiCPDaQzfjXprix Ev9Rm+FUOBx0ZDvm03av0MvH1b2sWhFp3VtxcKFiTpyGCRBOPgSG7IsKiLndlcgh eFFc1IOXWPdm9nTma9XxOI0y2oAl8xdK6F43cULpBslkjPyB5diBu/emI28sJ5Jo d8rgCH9mrvBKPCOgOC56T3rSsCXU71lon49l44tjfBw9FcQRgdB4GRnBKpJYPMqb QUZT6WI6sbRqWrKyVxNC8zks4n1zq0eFhFXSlXFHKUicR63h/PoCEzWX3v2yxZc2 gAFq9cb2Ivab/wz4l1khot9PZBdvYSe4fzcbmNG97fmqkLEg3Lw2ZuqEZBYv3WLn yGnPmDQGwvLwNe28nrAJwmZDccC348XQ8mO8wc5FOk+pWmSx0mW/trgDADTdgK89 pgN9chj3OjC1yagMG8DZWu6LoV+jOdrqI/hRAE9ws/z3iizfebadNYVzN8dLt4xk 7bcKUQ9oddA/kHBtDg28LCEd/3yodVocRpltP2JJgbDdJd8KjrGdBlp/VGbIOCpi KM3N8IXZPVfO/7oUGhFYWCskVLgWQSvwpBXI2+J3fFq3NYHlV20zXhaDeRDYLqxD wNUvDpPZZ8nTO5bhr5AYsW5fa7+tz/itQw/foju2/lp/Wh9XLL8= =sBcz -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make DATAFORM=rearguard tailored_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

US DoT report on time zone impacts and uniformity
by Tim Parenti Sept. 23, 2022

Sept. 23, 2022

Time zones eking their way into popular media again… CNN reports tonight that officials at the US Department of Transportation are working on translating their official time zone boundaries (described in regulatory texts) into the form of an official map, after — gasp! — "investigators found no single map accurately showing the boundaries nationwide", along with several inconsistencies on their own websites. https://www.cnn.com/2022/09/22/politics/time-zone-map-transportation-depart… Of course, beneath the surface, this was just one finding from a 28-page report published by the DoT's Office of Inspector General on Tuesday: DOT Can Improve Processes for Evaluating the Impact of Time Zone Changes and Promoting Uniform Time Observance, 2022-09-20 https://www.oig.dot.gov/sites/default/files/DOT%20Time%20Zone%20Final%20Rep… Among the other major findings of the report are that DoT is "responsible for evaluating whether requests to change time zones serve the convenience of commerce," but lacks "written guidance for how…officials should validate the information provided by petitioners" when a time zone change is proposed, making it difficult to address the potential impacts associated with a change. The report recommended "evaluat[ing] the relevance of the convenience of commerce questions" developed to weigh such considerations, and updating the questions, if necessary, to "reflect modern commerce-related impacts of time zone changes". And while DoT finds it "has no role in DST exemptions, …it is responsible for fostering and promoting uniform time observance, including DST", but again lacks "processes for tracking or monitoring localities" whose observances deviate from those assigned. The absence of an "official repository of detailed maps" was found to be limiting the DoT's ability to monitor "non-uniform time observance" as well as the public's ability to identify it. A note in an appendix further points out that a portion of the official Central–Mountain time zone boundary through Stanley County, South Dakota (near Pierre) refers to a railway river crossing… and that the railway went out of business in 1995. -- Tim Parenti

1 0

Timezone name changes
by Ростислав Салабай Sept. 22, 2022

Sept. 22, 2022

Greetings! Due to the ongoing war in Ukraine, for a few months now, Ukrainian based transliterations of city names are getting more and more commonly used. Firstly, it started with Kyiv, and now other names follow along. Some names like Odessa or Kharkov are still more commonly using Russian transliterations, but two other cities, Uzhgorod and Zaporizhzhia, on tz timezone list, aren't like that. It can be seen online, for example, on social media or on platforms like Google Analytics. So, I think that it's time to change Europe/Zaporozhye to Europe/Zaporizhzhia and Europe/Uzhgorod to Europe/Uzhhorod. Of course, while leaving old timezone names as links to new ones, for fallback reasons

2 1

Re: [tz] winter & Summer time in the State Of Palestine
by heba.hamad＠mtit.gov.ps Sept. 20, 2022

Sept. 20, 2022

the text is correct and matches with the cabinet decision that is attached previously ,so kindly ignore the illustration we will correct the illustration in the announcement and send the link again but to keep time we confirm that the text is correct we hope the TZ release will be issued as soon as possible في الأحد, سبتمبر 04, 2022 17:53 EDT, Paul Eggert <eggert(a)cs.ucla.edu> كتب: On 9/4/22 06:00, Michael H Deckers wrote: > The illustration on that page makes it clear that the > Arabic text is probably meant to say > winter time starts with the value 2 am on Saturday 2022-10-29 > rather than > the switch to winter time occurs when summer time would > have assumed the value 2 am on Saturday 2022-10-29 > as it was wrongly interpreted in the proposed changes > to Rule Palestine. Ouch. My guess is just the opposite. That is, my guess is that the illustration[1] (attached) in [2] is wrong, and I guess that the text is correct. That is, I think the illustration should show the clock moving backward from 2am to 1am, not from 3am to 2am. Heba Hamad, can you please confirm which is correct here? The illustration or the text? The text matches the document you already sent us. Thanks. [1]: https://mtit.pna.ps/Content/imgs/news/-8585393378987544401IMG-20220903-WA00… [2]: https://mtit.pna.ps/Site/New/1453

9 21

Re: [tz] tz Digest, Vol 132, Issue 8
by Paul Eggert Sept. 12, 2022

Sept. 12, 2022

On 9/11/22 23:22, Vaibhav Shrivastava wrote: > This case is Failing: (we have our custom batch to parse iana files). I suggest modifying the custom batch script to do the equivalent of the following 'sed' command first thing: sed 's/#.*//; /^[[:space:]]*$/d' That is, remove all comments and empty lines. This might work around the bug in the script. > Zone Africa/Sao_Tome 0:26:56 - LMT 1884 > #STDOFF -0:36:44.68 > --> > comment in the middle of rule > -0:36:45 - LMT 1912 Jan 1 00:00u # Lisbon MT > 0:00 - GMT 2018 Jan 1 01:00 > 1:00 - WAT 2019 Jan 1 02:00 > 0:00 - GMT Surely the bug is more complicated than merely comments before a continuation line, as tzdata has had comments like that for decades. For example, something like the following has been in the 'europe' file since 1995. Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks & Pottenger say it switched to C-Eur in 1981; # go with EU rules instead, since Greece joined Jan 1. 2:00 EU EE%sT

1 0