- tz - lists.iana.org

Northern Ontario (Canada)
by Chris Walton Oct. 15, 2022

Oct. 15, 2022

On January 1, 1970, the twin cities of Fort William and Port Arthur were merged to form the City of Thunder Bay. The TZ database currently shows that Thunder Bay has observed daylight saving every year from 1970 onwards with the exception of 1973. Back in July I raised some doubts on this mailing list about the 1973 data. I now have more proof that it is wrong. Somebody from the Thunder Bay Public Library was kind enough to send me two newspaper scans from 1973. Both scans are from the Chronicle Journal which has been a local Thunder Bay newspaper since 1972. *Chronicle Journal - Saturday April 28, 1973 - page 1* This page contains a slightly corny but very relevant notice titled "*Clocks Move Ahead Sunday*''. It reads: > Advancing an hour glass one hour for daylight saving time appears to pose > a problem for Pat Plachta. She knows DST begins at 2 a.m. Sunday and she'll > have one less hour to sleep in the morning but she'll make it up in the > Fall. Above the article is a picture of a woman holding an hourglass. Being that this is a Thunder Bay newspaper, the implication is that Thunder Bay did observe daylight saving in 1973. For completeness, I will also mention that the same newspaper page also contains a generic Canadian Press article titled "*Canadians Will Lose Hour Sleep*". The article briefly documents daylight saving practices across the country with no mention of any specific towns or cities. It starts out with: > OTTAWA (CP) — 12:01 a.m. becomes 1:01 a.m. in Canada Sunday. ... Clearly that first line is not entirely correct because most (but not all) of Canada was doing the switch at 2:00a.m. instead of 12:01a.m. I am not quoting the entire article here because it is not specific to Thunder Bay and there is nothing in it that we do not already know. *Chronicle Journal - Saturday October 27, 1973 - page 1* This page contains a notice titled "*Extra Sleep*". It reads: > Tonight city residents can look forward to gaining an extra hour of rest, > as Thunder Bay goes from Daylight Saving Time to Eastern Standard Time. So > don't forget to set your clocks back an hour tonight at 12:01 a.m. I will assume that 12:01 is an error; since most cities and towns in Ontario switched at 2:00a.m. Regardless, the notice provides additional proof that Thunder Bay did observe daylight saving in 1973. The TZ database entry for *America/Thunder_Bay* should be updated to include the observance of daylight saving in 1973. This change will make *America/Thunder_Bay* identical to *America/Toronto* from October 26, 1969 until present. Ultimately, *America/Thunder_Bay *could be replaced with a link. It could also be maintained in the backzone file using pre-1970 history from either Port Arthur or Fort William. Both Port Arthur and Fort William started their first experiments with daylight saving on May 2, 1908 which is not currently reflected in the *America/Thunder_Bay* data. Unfortunately I do not have a complete history for Port Arthur or Fort William however there are a couple of sources to start with: https://www.thunderbay.ca/en/inc/blog.aspx (scroll to the bottom) http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… Also, I would also like to see *America/Nipigon *and* America/Rainy_River* converted into link entries because I have zero faith in the current Shanks based data. America/Nipigon --> America/Toronto America/Rainy_River --> America/Winnipeg I am not convinced it is worth saving the data for either of these two questionable zones inside the backzone file. As I pointed out in July, the TZ database shows that Nipigon started daylight saving in 1974, but newspaper evidence shows it was already using daylight saving at least as far back as 1972. https://news.ourontario.ca/npl/122271/page/2 And FYI: The *America/Nipigon* and *America/Rainy_River* boundaries were removed from OpenStreetMap back in August. The *America/Toronto* boundary was restored to include most of Ontario east of 90°W. I was happy to see it done. -chris

2 1

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

Re: [tz] tz Digest, Vol 132, Issue 8
by vaibhav shrivastava Sept. 9, 2022

Sept. 9, 2022

Helllo, There is #STDOFF comment introduced for some of the tzdata in the middle of the rule. Causing parsing issue in tzdata to create correct utc and dst information. Regards, Vaibhav On Fri, 9 Sep 2022, 03:19 , <tz-request(a)iana.org> wrote: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. tz database. (Kiley Walbom) > 2. Re: tz database. (Kim Davies) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 7 Sep 2022 16:35:58 +0000 > From: Kiley Walbom <kiley.walbom(a)taxography.com> > To: Paul Eggert via tz <tz(a)iana.org> > Cc: Bradley Curl <bcurl(a)taxography.com> > Subject: [tz] tz database. > Message-ID: > < > MWHPR17MB19834868386572D03AB05182E4419(a)MWHPR17MB1983.namprd17.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Paul, > > My colleague is having issues subscribing to the TZ database. > He keeps getting a "Forbidden" error message when registering. > And he sent an email to mailman-request(a)iana.org<mailto: > mailman-request(a)iana.org> and received and undeliverable notice. > > bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> > > Any advice you could offer? > > > Kiley Walbom > Lead Cartographer > Geographic Information Systems Dept. > Taxography, INC > 6353 N. Rosebury Ave > St Louis, MO 63105 > 314-863-9292 ext. 130 > 314-925-1751 (Direct) > > "A map is the greatest of all epic poems. Its lines and colors show the > realization of great dreams." > --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 > > [cid:image001.jpg@01D8C1F4.71CB4EC0] > Address standardization and tax jurisdiction assignment web services. > Taxography uses county supplied parcel-level data, geographic boundaries, > and assessor verified address-level jurisdiction assignments to provide you > with the most current, authoritative, and auditable jurisdiction > assignments possible. > > >

2 1

Re: [tz] tz database.
by Kim Davies Sept. 8, 2022

Sept. 8, 2022

Hello, You can subscribe at https://mm.icann.org/mailman/listinfo/tz by submitting the address through the form. I hope this helps. I believe the mailman-request(a)iana.org<mailto:mailman-request@iana.org> method is long deprecated, did you see that in documentation somewhere that we need to update? kim -- Kim Davies VP, IANA Services, ICANN President, PTI From: tz <tz-bounces(a)iana.org> on behalf of Kiley Walbom via tz <tz(a)iana.org> Reply to: Kiley Walbom <kiley.walbom(a)taxography.com> Date: Thursday, 8 September 2022 at 2:47 pm To: Paul Eggert via tz <tz(a)iana.org> Cc: Bradley Curl <bcurl(a)taxography.com> Subject: [tz] tz database. Hi Paul, My colleague is having issues subscribing to the TZ database. He keeps getting a “Forbidden” error message when registering. And he sent an email to mailman-request(a)iana.org<mailto:mailman-request@iana.org> and received and undeliverable notice. bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> Any advice you could offer? Kiley Walbom Lead Cartographer Geographic Information Systems Dept. Taxography, INC 6353 N. Rosebury Ave St Louis, MO 63105 314-863-9292 ext. 130 314-925-1751 (Direct) "A map is the greatest of all epic poems. Its lines and colors show the realization of great dreams." --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 [cid:image001.jpg@01D8C392.287EF4C0] Address standardization and tax jurisdiction assignment web services. Taxography uses county supplied parcel-level data, geographic boundaries, and assessor verified address-level jurisdiction assignments to provide you with the most current, authoritative, and auditable jurisdiction assignments possible.

1 0

tz database.
by Kiley Walbom Sept. 7, 2022

Sept. 7, 2022

Hi Paul, My colleague is having issues subscribing to the TZ database. He keeps getting a "Forbidden" error message when registering. And he sent an email to mailman-request(a)iana.org<mailto:mailman-request@iana.org> and received and undeliverable notice. bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> Any advice you could offer? Kiley Walbom Lead Cartographer Geographic Information Systems Dept. Taxography, INC 6353 N. Rosebury Ave St Louis, MO 63105 314-863-9292 ext. 130 314-925-1751 (Direct) "A map is the greatest of all epic poems. Its lines and colors show the realization of great dreams." --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 [cid:image001.jpg@01D8C1F4.71CB4EC0] Address standardization and tax jurisdiction assignment web services. Taxography uses county supplied parcel-level data, geographic boundaries, and assessor verified address-level jurisdiction assignments to provide you with the most current, authoritative, and auditable jurisdiction assignments possible.

1 0

Amsterdam timezone prior to 1937 incorrect?
by Loek Engels Sept. 6, 2022

Sept. 6, 2022

Hi, Between 2022a an b the timezone info for Europe/Amstedam is removed: Z Europe/Amsterdam 0:19:32 - LMT 1835 The timezone info for Brussels around that date differs from Amsterdams timezone info. Determining the timezone information for dates around that period on my Linux system in python returns since the latest update an offset of 0 minutes as opposed to the 19 minutes previously. Is the removal for this timezone information intentional or a bug? Regards, Loek

3 2

winter & Summer time in the State Of Palestine
by heba.hamad＠mtit.gov.ps Sept. 4, 2022

Sept. 4, 2022

Dear Sir, We would like to inform you that winter time will begin in Palestine from Saturday 10-29, 02:00 AM by 60 minutes backwards Also the state of Palestine adopted the summer and winter time for the years: 2023,2024,2025,2026 as following below: * Summer time will begin in Palestine from Saturday, 02:00 AM by 60 minutes forwards as shown in the table below. * winter time will begin in Palestine from Saturday ,02:00 AM by 60 minutes backwards as shown in the table below YearSummer TimeWinter Time202325/328/10202430/326/10202529/325/10202628/324/10 .Kindly find the attachment below that includes the decision of the Palestinian cabinet With Respects,

5 10

Mexico may eliminate DST next year- except parts of some northern states
by wtz＠worldtimezone.com Sept. 2, 2022

Sept. 2, 2022

According to some news published on Wednesday, July 6, 2022 Mexico may eliminate DST next year- except parts of some northern states. "AMLO sends bill to eliminate daylight saving; Mexico to return to 'God's time'" https://mexiconewsdaily.com/news/amlo-sends-bill-to-eliminate-daylight-savi… https://www.reuters.com/world/americas/mexico-president-presents-bill-elimi… "Mexico president presents bill to eliminate daylight saving time" "It's likely that the clocks won't change next year in most states" "The bill only requires a simple majority to pass the federal legislature, meaning that it is likely to become law. With the support of its allies, the ruling Morena party commands a majority in both the lower and upper houses. Energy Minister Rocío Nahle and Health Minister Jorge Alcocer appeared at the president's morning press conference on Tuesday to present arguments in favor of getting rid of the twice-a-year time change...... ..................... However, God's clock and health worries may not apply in parts of some northern states where clock changes have been synchronized with states in the southern U.S. to facilitate cross-border trade and other connections. Energy Minister Nahle said on Tuesday that there would continue to be exceptions in some northern border municipalities." Regards, WorldTimeZone.com team

3 2

Canonica and non-canonical timezone question
by Andriy Hromyak Aug. 30, 2022

Aug. 30, 2022

Hello and good day I have posted a question about a problem I am dealing with here: https://github.com/moment/moment-timezone/issues/828#issuecomment-1228548097 could you please assist on providing info on how we can distinguish canonical and non-canonical timezones. Some services do not allow non-canonical timezones yet lib we use provide some time non-canonical ones. so we need way not to receive non-canonical timezones or have marker that we can know that and maybe you can provide the best racice way to map it to canonical. best regards -- Hromyak Andriy | Lead software developer andriy.hromyak(a)visiquate.com

2 1

[PROPOSED 1/2] Additional sourcing for Crimea 2014 switch
by Paul Eggert Aug. 28, 2022

Aug. 28, 2022

From: Tim Parenti <tim(a)timtimeonline.com> Reference from previous discussion: https://mm.icann.org/pipermail/tz/2019-July/028260.html --- europe | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/europe b/europe index c3a3cc4..956f670 100644 --- a/europe +++ b/europe @@ -2615,10 +2615,14 @@ Zone Europe/Simferopol 2:16:24 - LMT 1880 # From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html -# From Paul Eggert (2014-03-30): -# Simferopol and Sevastopol reportedly changed their central town clocks -# late the previous day, but this appears to have been ceremonial -# and the discrepancies are small enough to not worry about. +# From Tim Parenti (2022-07-01), per Paul Eggert (2014-03-30): +# The clocks at the railway station in Simferopol were put forward from 22:00 +# to 24:00 the previous day in a "symbolic ceremony"; however, per +# contemporaneous news reports, "ordinary Crimeans [made] the daylight savings +# time switch at 2am" on Sunday. +# https://www.business-standard.com/article/pti-stories/crimea-to-set-clocks-… +# https://www.reuters.com/article/us-ukraine-crisis-crimea-time/crimea-switch… +# https://www.bbc.com/news/av/world-europe-26806583 2:00 EU EE%sT 2014 Mar 30 2:00 4:00 - MSK 2014 Oct 26 2:00s 3:00 - MSK -- 2.37.2

2 7

Re: [tz] No time zone on Solaris servers
by Paul Eggert Aug. 26, 2022

Aug. 26, 2022

On 8/26/22 10:06, W CUI wrote: > We are running 64-bit Solaris as showing from the "isainfo -v" output. Fine, but Solaris 10 /usr/bin/date is a 32-bit executable and is dynamically linked to a 32-bit C library /lib/libc.so.1 that is reading your TZif files. Presumably your "isainfo -v" outputs something like this: 64-bit sparcv9 applications vis2 vis 32-bit sparc applications vis2 vis v8plus div32 mul32 and the last two lines are what matter here. I expect that 64-bit Solaris 10 apps don't have this problem. To find out whether I'm right, you can run '/usr/bin/sparcv9/ls -l' on a new file and look at the resulting timestamp. Regardless, if this issue is a real problem for you then it's time to file a bug report with Oracle (you can tell them I sent you :-). And in the meantime you can get by with 'zic -b fat'.

3 2

No time zone on Solaris servers
by W CUI Aug. 25, 2022

Aug. 25, 2022

Hi list, We downloaded tzdb2022c and compiled it on a Solaris 10 server with TOPDIR=/newtz and other default config parameters. After compiling is finished, the zoneinfo directory is copied to an other Solaris server, then the date command does not show any time zone on the host. It seems the server is at UTC time zone. Can anybody point me on how to fix it? Thank you very much! Wei Sent from Yahoo Mail for iPhone

2 4

Western Australia's continuing argument over DST
by Gilmore Davidson Aug. 24, 2022

Aug. 24, 2022

"Daylight saving push in WA likely dead on arrival as government, opposition dismiss private member's bill" https://www.abc.net.au/news/2022-08-24/renewed-push-for-daylight-saving-in-… <https://www.abc.net.au/news/2022-08-24/renewed-push-for-daylight-saving-in-…> > Daylight Saving Party MLC Wilson Tucker has called on Premier Mark McGowan to legislate the return of the practice to Western Australia, instead of holding another referendum. > > Labor Minister Sue Ellery, who as leader of the government in the Upper House effectively controls the likelihood of Mr Tucker's bill being considered, was dismissive. Premier Mark McGowan reinforced the dismissal late yesterday, confirming the government would look to "respect" the results of the previous four referendums. > > […] > > Mr Tucker, who sits on the crossbench of Western Australia's Upper House, won his seat after he was elected with just 98 votes, or 0.2 per cent of the vote, and represents WA's Mining and Pastoral region where voters have delivered strong no votes in daylight saving referendums in 1975, 1984, 1992, and 2009. It should also be pointed out that Wilson Tucker wasn’t even living in Australia when he was elected (via weird voting preference deals that have resulted in calls to update the WA voting legislation).

1 0

file "zoneinfo2tdf.pl" is missing from latest release 2022c!
by chris＠gensler-it-support.de Aug. 19, 2022

Aug. 19, 2022

Maybe that's intended, but it disappeared without notice. Chris

2 1

Add option to act like global-tz
by Paul Eggert Aug. 18, 2022

Aug. 18, 2022

I wangled a bit of free time and wrote the attached proposed patch, which adds an option that causes 'make install' to generate time zone data (TZif files) that are byte-for-byte identical to what Stephen Colebourne's global-tz currently generates. This is done via a few lines of awk script. The idea is to give an option to distros that prefer a separate Zone per ISO 3166 country, just as we already have build-time options for rearguard/vanguard form, TZif truncation, leap seconds, etc. I haven't installed this in the development database. Comments welcome as usual.

5 22

time_t truncation occurrence in tzcode
by Jan Engelhardt Aug. 18, 2022

Aug. 18, 2022

Due to an update of the Coverity Scan analyzer itself, it has identified a new issue in timezone code. In version 2022c (the excerpt is copypasted from an own project, so line numbers don't mean much), it has flagged: <<< 1757 while (year_lengths[isleap(y)] <= idays) { 1758 int tdelta = idays / DAYSPERLYEAR; 1759 int_fast32_t ydelta = tdelta + !tdelta; 1760 time_t newy = y + ydelta; 1761 register int leapdays; 1762 leapdays = leaps_thru_end_of(newy - 1) - 1763 leaps_thru_end_of(y - 1); 1764 idays -= ydelta * DAYSPERNYEAR; 1765 idays -= leapdays; 1766 y = newy; 1767 } 1768 1769 if (!TYPE_SIGNED(time_t) && y < TM_YEAR_BASE) { CID 1491244 (#1 of 1): Use of 32-bit time_t (Y2K38_SAFETY) 1. store_truncates_time_t: A time_t value is stored in an integer with too few bits to accommodate it. The expression y is cast to int. 1770 int signed_y = y; ^^^^^^^^^^^^ 1771 tmp->tm_year = signed_y - TM_YEAR_BASE; 1772 } else if ((!TYPE_SIGNED(time_t) || INT_MIN + TM_YEAR_BASE <= y) 1773 && y - TM_YEAR_BASE <= INT_MAX) 1774 tmp->tm_year = y - TM_YEAR_BASE; 1775 else { 1776 errno = EOVERFLOW; 1777 return NULL; 1778 } 1779 tmp->tm_yday = idays; >>> On e.g. x86_64-linux-gnu, time_t is 64 bits (signed) wide, and while the specific code path is not executed on that particular platform, the warning about a truncation to a 32-bit signed int seems justified.

3 2

Official Chilean Goverment Decret for timezone changes 2022-2026
by Eduardo Romero Urra Aug. 18, 2022

Aug. 18, 2022

Dear Paul, I've send a copy of presidential decret for Summer time changes for the Republic of Chile, officially published at August 13th 2022: https://www.diariooficial.interior.gob.cl/publicaciones/2022/08/13/43327/01… I've review your update 2022b TZdata and it's ok for this year where the summer time starts the second saturday of September ( Sep 10th at midnight), but the next years ( 2023 to 2026 ) is need to precise that the summer time event affects only for this year according to avoid problem confusions to a Votation Day schedule to the next sunday Sept 4th (the original summer time change was schedule at Saturday Sep 3th midnight). Also consider this also affects to Easter Island Time Zone (Pacific/Easter) and not affects to Chile/Punta_Arenas Time Zone. At resume (page #2 of document): 2022: - Chile/Continental ( America/Santiago ): Summer time starts at Saturday 10th Sep. at 24:00 Hrs, adding 1hour ( GMT -03) - Chile/Easter (Pacific/Easter) : Summer time starts at Saturday 10th Sep. at 22:00 Hrs, adding 1hour ( GMT -05) - Chile/Punta_Arenas (America/Punta_Arenas): No changes, keeps on GMT -03 2023-2025 - Chile/Continental ( America/Santiago ): Summer time ends at first saturday of Abril 24:00 Hrs, backward 1hour ( GMT -04) , and Summer time starts the first saturday of September at 24:00 , adding 1hour ( GMT -03) - Chile/Easter (Pacific/Easter) : Summer time ends at first saturday of Abril at 22:00 Hrs, backward 1hour ( GMT -06), and Summer time starts the first saturday of September at 24:00 , adding 1hour ( GMT -05) - Chile/Punta_Arenas (America/Punta_Arenas): No changes , keeps on GMT -03 2026: - Chile/Continental ( America/Santiago ): Summer time ends at first saturday of Abril 24:00 Hrs, backward 1hour ( GMT -04) - Chile/Easter (Pacific/Easter) : Summer time ends at first saturday of Abril at 22:00 Hrs, backward 1hour ( GMT -06) (the decret has no mentions for future time changes plans) - Chile/Punta_Arenas (America/Punta_Arenas): No changes , keeps on GMT -03 I've check the rules on southamerica file , but i'm not sure if apply correctly for Easter Island changes Rule Chile 2019 max - Apr Sun>=2 3:00u 0 - Rule Chile 2019 2021 - Sep Sun>=2 4:00u 1:00 - Rule Chile 2022 only - Sep Sun>=9 4:00u 1:00 - Rule Chile 2023 max - Sep Sun>=2 4:00u 1:00 - [...] Zone Pacific/Easter -7:17:28 - LMT 1890 -7:17:28 - EMT 1932 Sep # Easter Mean Time -7:00 Chile -07/-06 1982 Mar 14 3:00u # Easter Time -6:00 Chile -06/-05 I'm very appreciated your assistance for this changes. Thanks in Advance. ━━━━━━━━ Eduardo Romero Urra Asesor de Sistemas División de Redes y Seguridad Informática +56224863218 Ministerio del Interior y Seguridad Pública Gobierno de Chile CONFIDENCIALIDAD Y USO EXCLUSIVO: La información contenida en este mensaje y/o en los archivos adjuntos son de carácter confidencial y está destinada al uso exclusivo del emisor y/o de la persona o entidad a quien va dirigida, y por lo mismo pueden ser consultados y revisados por la entidad emisora o propietaria de los sistemas desde donde fueron enviados.- Si usted no es el destinatario, cualquier almacenamiento, divulgación, distribución o copia de esta información está estrictamente prohibida y sancionada por la ley. Si recibió este mensaje por error, por favor infórmenos inmediatamente respondiendo este mismo mensaje y borre éste y todos los archivos adjuntos. Considerando que no existe certidumbre de que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico, el emisor original no será responsable si el contenido del mismo ha sido modificado. Ministerio del Interior y Seguridad Publica<https://www.interior.gob.cl>

3 3

Re: [tz] tzdata 2022b and 2022c location
by Paul Eggert Aug. 17, 2022

Aug. 17, 2022

On 8/16/22 01:07, Alex Goldberg3 wrote: > We usually get tzdata files from https://github.com/unicode-org/icu-data/tree/main/tzdata/icunew , where metaZones.res, timezoneTypes.res, etc are located. However, the latest release there is 2022a. Are 2022b and 2022c not officially released or may be changed location? I suspect that you're talking about ICU's files concerning time zones as opposed to the tzdata files themselves, as the repository you mention stopped mirroring tzdata files after tzdata 2011k. ICU is downstream from tzdata and an ICU forum would be a good place to ask about ICU's status. A request for ICU to update to match tzdata 2022b (and 2022c) is here: https://unicode-org.atlassian.net/browse/ICU-22118 and I expect you can monitor and/or comment there. Currently nobody is assigned to the task.

1 0

[tz-announce] 2022c release of tz code and data available
by Paul Eggert via tz-announce Aug. 16, 2022

Aug. 16, 2022

The 2022c release of the tz code and data is available. This release reflects the following changes, which do not affect timestamps unless your system has the awk bug mentioned below: Briefly: Work around awk bug in FreeBSD, macOS, etc. Improve tzselect on intercontinental Zones. Changes to code Work around a bug in onetrueawk that broke commands like 'make traditional_tarballs' on FreeBSD, macOS, etc. (Problem reported by Deborah Goldsmith.) Add code to tzselect that uses experimental structured comments in zone1970.tab to clarify whether Zones like Africa/Abidjan and Europe/Istanbul cross continent or ocean boundaries. (Inspired by a problem reported by Peter Krefting.) Fix bug with 'zic -d /a/b/c' when /a is unwritable but the directory /a/b already exists. Remove zoneinfo2tdf.pl, as it was unused and triggered false malware alarms on some email servers. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022c.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 ce4d77644d2793027bb27f095dec7b530edcd947 dated 2022-08-15 17:47:18 -0700 and tagged '2022c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3373fa16a12007415c3dc3a75c4a0d61d6ae54968eeecedcdf4bcfd7f554020a15c4687dde107b90462b75d848eebe1e200c33322ebe0d3f1ad11bc769cade06 tzcode2022c.tar.gz e2ae92abac6d87ce4ab4ba9012e868e1791b842e083293489debc0c671b9cf135b5b70426dacb6dbebbf6eba24463205225ae45bb7df891a086b25475f85ee0b tzdata2022c.tar.gz e51a9044da116a52906bc0fc22a3dde0e1a6d4e486f9e610a63aa6634ccc1ebd0bc2d47d2faa84bde2b78cc890fe3fb08f6c1ac4e1e0c147d45de5c21d26b26a tzdb-2022c.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL66eQACgkQ7ZfpDmKq fjSarBAAp6iKJluMo3MOD4YQUwB5aUsVg1zSXPYs1WH88gXaHLxm2G0fv8Ar4FFg gDOBxyazc/4fB7zwec3rMKo5KVV/pRil1go93BetefoU1ffhrLYbrVw89/VsesXP nQ5FXkVLd/u5vuOXf2WoS+hmJANlC2ljhHTN1MX0hoChyLA/paBYvS18mTn45Tm4 PCH6cPKX//gwGSmOavRqlT9wp95NCpCeXX7Yl5aYIgpdGAJAGZJrzGcn1Rp0NoOJ BQfoaC4SuGEeBbqsUdoFrXE6V1rI1pAvPXq8fwTjrh7LDIaGmIHY+HAeJUDwT4d5 rEXNJ9D5mun4VDkVMiyMlITTletu1wnHyspLZk4h9g6H75C2c0pipCI4FGfEn+wh 2l54bVAwJE2An5UKdqukaC2B9MGxEFTbgE5Za93OwOyrb6FFGUrMjj2Ua1nf1h6E 5VefqyKepF1TY/ApWy2OObTioBew2lVuXRsQrD1cDo/rqAyMYLlkrye0nQspvkAA jv5LKH8fmapBee7JaFYYbnCMZwpyr0iP4LOiH34a9vsFrUtERUTUKxhPv1epNyyc F6ECJz7wknYwRszyp/2ai7nc8yCHc+76dmgXM6fPwcghuVv0ihl7uOkNx1Rp2MHr oZ7r0KV7HcAOQgCWJuh4l1QNX3qX7XqmRJP1rNCmMbUnENme6MQ= =7xd7 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL66eQACgkQ7ZfpDmKq fjTHhQ//YaTZjsHEvJuVFRcqjuIByGySv7aUnvldFGZ4vuAgIX0g7hlaoCdSlVri qjqhGSM7ShcRs1PtvBGUmFrrfvhg+vW6D6etkf3GO8h/Vztz26GIkY/PLv/wFu4i bf915wfbsMmaoI/MVlLsNMzQ63qS5i+JwouJAKOmUb95wNMrmKlBi4XXcQNvUdTF pp7uGq7jJdcETAgH5UQkeiXBghahdS6SEK8raFplW2hK8SqyAAjG9hRBjMqyoSUS cPK0UwrjLZvd9KOB73RFryglkNpTthqvsr4vZ7K4WzZuIYxHLzG2LEG6Rhuuq8Z/ 2u3g4KMLJ29NQJRIjAYWU9F2IruzgQJjxRjMtbxysR7Jiru+xzg5nha1eRdp/G4z F9aqc2NR79I9kpUQAIxhi3C6v/mreMNm0HfBskA3Ws1R7Mi7MSpnIhi/gwUUnQV2 AMBOo2qAz24d3kt65Opc2bHWZemtfzXTkMQhIiIgCkHrb5H9EKUYac+aJeJpRZKU jdZ/5rLzKJyUraBb1a0h6UXCuxk0yVelVIcDEjaJTfpgMF5qmwrFaCBZUZ0zbQvT 9VhltgpkWGGUMJxn+OTyGsZRO8oUXg/3SbaMQr0tAnR59tcorvhF5wU5aNH/PYoa dDwW+qmDW3ky10DiF2fzjZWwRBiiLJF61stHXaNy9RvHC/V3yFY= =nylY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL66eYACgkQ7ZfpDmKq fjS8Dg//fnZzYIPMv90un2mPyAnVZbVSS6O8CG2YSdHPkXwVZE8DbyrIVNaJTLNG zaGgQ0/+enf3HZlM8NTBJO6Zf4Sv1ZFrnifqF0JmUZ5P/OxlhKLdt3OgQ0oGAX48 SacJoXf3JX8At10Ar+NVtAneJpG1wVsD4nPFrNS/rWRwfMMKdnP2HxlEVHCbNikk r1/F+065qbXYOhYD3UpqJI9dKaA3OFjEANQJJHw3+h7m0YZFcMATSw5anrnvGotx +lgQffLQvKIKc5E7CsppEk0SnFmKncUceepajJzqnyNTT9kecSAlu6qrnJCgHtu+ qhQfMfklixqocCwj6yJyZDKuv9e8vKjb7U2HYhNRhBWS3eE4ozE6fDDacehRyUrz HLgotpRuYWImP3MA+AhOqSQThY2y3tSOHAKxMDixaq4dkpXGgg+5KR/VRLD8//99 m19yu3QqpzjKGPiQpfdU5tpk/2JegFpCbYwsMkw0XfCVvmRwjKGexS3hIHLF4WkQ XMjkf8Bj+AS0Ld+9IBE97BrG6qDN+NPI9EhC7/YvyxqcDcSWbG65JbiYkyDUkBgt rUFPTlUUTD2hcdfbQQZ4f23F/iJpbJXOyhqxxHl9RnkJkEkgDcO+apps74V4IN/6 YSP3pvW32hZ0Z8iXKD4VVbYBqIw6rLb8HpaA5zQEHs/S2A/kcfs= =BW2X -----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

[PROPOSED 1/2] Prefer " to ' in HTML attributes
by Paul Eggert Aug. 15, 2022

Aug. 15, 2022

--- tz-art.html | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/tz-art.html b/tz-art.html index 73be9f9c..f1bd4c57 100644 --- a/tz-art.html +++ b/tz-art.html @@ -483,19 +483,19 @@ Supernaw.</td></tr> <ul> <li> The webcomic xkcd has the strip -"<a href='https://xkcd.com/673/'>The Sun</a>" (2009-12-09) and the panels -"<a href='https://xkcd.com/1017/'>Backward in Time</a>" (2012-02-14), -"<a href='https://xkcd.com/1061/'>EST</a>" (2012-05-28), -"<a href='https://xkcd.com/1179/'>ISO 8601</a>" (2013-02-27), -"<a href='https://xkcd.com/1335/'>Now</a>" (2014-02-26), -"<a href='https://xkcd.com/1655/'>Doomsday Clock</a>" (2016-03-14), -"<a href='https://xkcd.com/1799/'>Bad Map Projection: Time Zones</a>" +"<a href="https://xkcd.com/673/">The Sun</a>" (2009-12-09) and the panels +"<a href="https://xkcd.com/1017/">Backward in Time</a>" (2012-02-14), +"<a href="https://xkcd.com/1061/">EST</a>" (2012-05-28), +"<a href="https://xkcd.com/1179/">ISO 8601</a>" (2013-02-27), +"<a href="https://xkcd.com/1335/">Now</a>" (2014-02-26), +"<a href="https://xkcd.com/1655/">Doomsday Clock</a>" (2016-03-14), +"<a href="https://xkcd.com/1799/">Bad Map Projection: Time Zones</a>" (2017-02-15), -"<a href='https://xkcd.com/1883/'>Supervillain Plan</a>" (2017-08-30), -"<a href='https://xkcd.com/2050/'>6/6 Time</a>" (2018-09-24), -and "<a href='https://xkcd.com/2266/'>Leap Smearing</a>" (2020-02-10). +"<a href="https://xkcd.com/1883/">Supervillain Plan</a>" (2017-08-30), +"<a href="https://xkcd.com/2050/">6/6 Time</a>" (2018-09-24), +and "<a href="https://xkcd.com/2266/">Leap Smearing</a>" (2020-02-10). The related book What If? has an entry -"<a href='https://what-if.xkcd.com/26/'>Leap Seconds</a>" (2012-12-31). +"<a href="https://what-if.xkcd.com/26/">Leap Seconds</a>" (2012-12-31). </li> <li> Pig kills time in <a @@ -504,11 +504,11 @@ Before Swine (2016-11-06)</a>. </li> <li> Stonehenge is abandoned in <a -href='https://www.gocomics.com/nonsequitur/2017/03/12'>Non Sequitur +href="https://www.gocomics.com/nonsequitur/2017/03/12">Non Sequitur (2017-03-12)</a>. <li> The boss freaks out in <a -href='https://dilbert.com/strip/1998-03-14'>Dilbert (1998-03-14)</a>. +href="https://dilbert.com/strip/1998-03-14">Dilbert (1998-03-14)</a>. </li> <li> Peppermint Patty: "What if the world comes to an end tonight, Marcie?" @@ -516,7 +516,7 @@ Peppermint Patty: "What if the world comes to an end tonight, Marcie?" Marcie: "I promise there'll be a tomorrow, sir ... in fact, it's already tomorrow in Australia!" -(Charles M. Schulz, <a href='https://www.gocomics.com/peanuts/1980/06/13'>Peanuts, 1980-06-13</a>) +(Charles M. Schulz, <a href="https://www.gocomics.com/peanuts/1980/06/13">Peanuts, 1980-06-13</a>) </li> </ul> <h2>Jokes</h2> -- 2.34.1

1 1

Re: [tz] Trivial questions about Tz
by dpatte Aug. 15, 2022

Aug. 15, 2022

Thanks Paul It is theoretically possible that such a triple midnight could happen, but I assume it could happen only if some goverment/administration had poorly chosen their walltime transition times. ----- Original Message ----- From: Paul Eggert [mailto:eggert@cs.ucla.edu] To: "dpatte" <dpatte(a)relativedata.com> Cc: tz(a)iana.org Sent: Mon, 15 Aug 2022 15:46:55 -0700 Subject: Re: [tz] Trivial questions about Tz On 8/15/22 14:23, dpatte via tz wrote: > Are there any known cases in the tz database where two close offset and save changes in one region cause wall times in that region to have not just one but two repeats of the original wall times, such as 3 midnights with the same date? I dimly recall we used to have examples of that but eventually removed them from TZDB since they were surely mistakes. Quite possibly my memory is incorrect. > I am also curious what the largest single change to a save-time is in the database, and the largest single change to a GMT offset-time (though I assume the answer to this second one is Western Samoa). The following shell command: zdump -i $(awk '/^Zone/{print $2}' main.zi) | awk 'o!="" && $3!="" && o!=$3 {print o, $3} {o = $3}' | sort -u prints output that should help answer your question. Each line of output is a distinct pair of (before, after) %z-style abbreviations that is observed somewhere in tzdb. I get 579 lines of output with current tzdb.

1 0

Trivial questions about Tz
by dpatte Aug. 15, 2022

Aug. 15, 2022

I was just curious... Generally, when a region comes off Daylight/Summer time, the wall time is set back, causing a wall clock to repeat a portion of wall times (albeit with a different time abbreviation). Likewise, if a region elects a new GMT offset that is further west than before, the wall time is also set back, also causing a repeat of wall times (again with a different time abbreviation). Are there any known cases in the tz database where two close offset and save changes in one region cause wall times in that region to have not just one but two repeats of the original wall times, such as 3 midnights with the same date? I am also curious what the largest single change to a save-time is in the database, and the largest single change to a GMT offset-time (though I assume the answer to this second one is Western Samoa).

3 2

make traditional_tarballs fails on macOS for 2022b
by Deborah Goldsmith Aug. 15, 2022

Aug. 15, 2022

This is a regression from 2022a. This is on macOS 13.0 but I suspect it will fail the same way on macOS 12. Also note that macOS does not have nroff installed, but that doesn’t look like a fatal error. Debbie debbie 6:11PM tz ✓ % make traditional_tarballs { (type git) >/dev/null 2>&1 && \ V=`git describe --match '[0-9][0-9][0-9][0-9][a-z]*' \ --abbrev=7 --dirty` || \ if test 'unknown' = unknown && V=`cat version`; then \ case $V in *-dirty);; *) V=$V-dirty;; esac; \ else \ V='unknown'; \ fi; } && \ printf '%s\n' "$V" >version.out mv version.out version awk -v EXPIRES_LINE=0 \ -f leapseconds.awk leap-seconds.list >leapseconds.out mv leapseconds.out leapseconds LC_ALL=C sh workman.sh `expr tzselect.8.txt : '$.*$\.txt$'` >tzselect.8.txt.out workman.sh: line 16: nroff: command not found mv tzselect.8.txt.out tzselect.8.txt LC_ALL=C sh workman.sh `expr zic.8.txt : '$.*$\.txt$'` >zic.8.txt.out workman.sh: line 16: nroff: command not found mv zic.8.txt.out zic.8.txt awk \ -v DATAFORM=`expr main.zi : '$.*$.zi'` \ -v PACKRATDATA='' \ -v PACKRATLIST='' \ -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out awk: syntax error at source line 110 source file ziguard.awk context is stdoff_column = 2 * /^Zone/ >>> + <<< 1 awk: illegal statement at source line 110 source file ziguard.awk awk: illegal statement at source line 110 source file ziguard.awk make: *** [main.zi] Error 2

4 26

Time in Eucla (Western Australia)
by Robert Elz Aug. 13, 2022

Aug. 13, 2022

A friend has relatives driving towards Perth (from eastern AU). They sent him the attached photo (after I asked if they could confirm the time there as they passed through) from the local motel entrance. This is just a confirmation of what we already knew. Photo date is 13 August 2022; since it is a photo of clocks, the time is self evident (note, daylight, not near midnight). kre

1 0

[PROPOSED] Remove zoneinfo2tdf.pl
by Paul Eggert Aug. 12, 2022

Aug. 12, 2022

* Makefile (MISC, VERSION_DEPS): Remove mention of removed file. * NEWS: Mention this. * zoneinfo2tdf.pl: Remove. --- Makefile | 4 ++-- NEWS | 3 +++ zoneinfo2tdf.pl | 53 ------------------------------------------------- 3 files changed, 5 insertions(+), 55 deletions(-) delete mode 100755 zoneinfo2tdf.pl diff --git a/Makefile b/Makefile index 88240ad..ae0f3fd 100644 --- a/Makefile +++ b/Makefile @@ -538,7 +538,7 @@ DATA= $(TDATA_TO_CHECK) backzone iso3166.tab leap-seconds.list \ leapseconds $(ZONETABLES) AWK_SCRIPTS= checklinks.awk checktab.awk leapseconds.awk \ ziguard.awk zishrink.awk -MISC= $(AWK_SCRIPTS) zoneinfo2tdf.pl +MISC= $(AWK_SCRIPTS) TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs @@ -567,7 +567,7 @@ VERSION_DEPS= \ tzfile.5 tzfile.h tzselect.8 tzselect.ksh \ workman.sh zdump.8 zdump.c zic.8 zic.c \ ziguard.awk zishrink.awk \ - zone.tab zone1970.tab zoneinfo2tdf.pl + zone.tab zone1970.tab # And for the benefit of csh users on systems that assume the user # shell should be used to handle commands in Makefiles. . . diff --git a/NEWS b/NEWS index 9042cd8..4c1c48d 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,9 @@ Unreleased, experimental changes Fix bug with 'zic -d /a/b/c' when /a is unwritable but the directory /a/b already exists. + The script zoneinfo2tdf.pl has been removed, as it was unused and + triggered false malware alarms on some email servers. + Release 2022b - 2022-08-10 15:38:32 -0700 diff --git a/zoneinfo2tdf.pl b/zoneinfo2tdf.pl deleted file mode 100755 index 176fce9..0000000 --- a/zoneinfo2tdf.pl +++ /dev/null @@ -1,53 +0,0 @@ -#! /usr/bin/perl -w -# Summarize .zi input in a .zi-like format. - -# Courtesy Ken Pizzini. - -use strict; - -#This file released to the public domain. - -# Note: error checking is poor; trust the output only if the input -# has been checked by zic. - -my $contZone = ''; -while (<>) { - my $origline = $_; - my @fields = (); - while (s/^\s*((?:"[^"]*"|[^\s#])+)//) { - push @fields, $1; - } - next unless @fields; - - my $type = lc($fields[0]); - if ($contZone) { - @fields >= 3 or warn "bad continuation line"; - unshift @fields, '+', $contZone; - $type = 'zone'; - } - - $contZone = ''; - if ($type eq 'zone') { - # Zone NAME STDOFF RULES/SAVE FORMAT [UNTIL] - my $nfields = @fields; - $nfields >= 5 or warn "bad zone line"; - if ($nfields > 6) { - #this splice is optional, depending on one's preference - #(one big date-time field, or componentized date and time): - splice(@fields, 5, $nfields-5, "@fields[5..$nfields-1]"); - } - $contZone = $fields[1] if @fields > 5; - } elsif ($type eq 'rule') { - # Rule NAME FROM TO - IN ON AT SAVE LETTER/S - @fields == 10 or warn "bad rule line"; - } elsif ($type eq 'link') { - # Link TARGET LINK-NAME - @fields == 3 or warn "bad link line"; - } elsif ($type eq 'leap') { - # Leap YEAR MONTH DAY HH:MM:SS CORR R/S - @fields == 7 or warn "bad leap line"; - } else { - warn "Fubar at input line $.: $origline"; - } - print join("\t", @fields), "\n"; -} -- 2.37.1

1 0

[PROPOSED] Fix bug with 'zic -d /a/b/c' if /a is unwriteable
by Paul Eggert Aug. 12, 2022

Aug. 12, 2022

If the directory /a/b already exists, it is not an error if /a is unwritable when you invoke zic -d /a/b/c. Problem found on Solaris 10, where mkdir("/a", ...) can fail with EACCES in this situation, which POSIX allows. * NEWS: Mention the fix. * private.h (ELOOP) [!ELOOP]: Define to EINVAL. * zic.c (mkdirs): Do not fail merely because mkdir fails with errno == EACCES, as the parent directory may already exist but be unwritable. For example --- NEWS | 2 ++ private.h | 3 +++ zic.c | 9 +++++++-- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 7291030a..af99e2b7 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,8 @@ Unreleased, experimental changes Work around a bug in macOS 'awk' that broke commands like 'make traditional_tarballs'. (Problem reported by Deborah Goldsmith.) + Fix bug with 'zic -d /a/b/c' when /a is unwritable but the + directory /a/b already exists. Release 2022b - 2022-08-10 15:38:32 -0700 diff --git a/private.h b/private.h index 9b9389f3..9c31ec54 100644 --- a/private.h +++ b/private.h @@ -168,6 +168,9 @@ # define EINVAL ERANGE #endif +#ifndef ELOOP +# define ELOOP EINVAL +#endif #ifndef ENAMETOOLONG # define ENAMETOOLONG EINVAL #endif diff --git a/zic.c b/zic.c index a29f6792..ff047937 100644 --- a/zic.c +++ b/zic.c @@ -3670,9 +3670,14 @@ mkdirs(char const *argname, bool ancestors) some other process might have made the directory in the meantime. Likewise for ENOSYS, because Solaris 10 mkdir fails with ENOSYS if the - directory is an automounted mount point. */ + directory is an automounted mount point. + Likewise for EACCES, since mkdir can fail + with EACCES merely because the parent directory + is unwritable. Likewise for most other error + numbers. */ int err = errno; - if (err != EEXIST && err != ENOSYS) { + if (err == ELOOP || err == ENAMETOOLONG + || err == ENOENT || err == ENOTDIR) { error(_("%s: Can't create directory %s: %s"), progname, name, strerror(err)); exit(EXIT_FAILURE); -- 2.34.1

1 0

Chile Timezone change
by Juan Luis Orellana Aug. 11, 2022

Aug. 11, 2022

Dear IANA Team, I'm glad I can be in touch with you, this mail has as objective, to ask for a tzdata update package, our Chilean Goverment changed the timezone change date from 09/03/23:59 to 09/10 23:59 (America/Santiago), due to political reasons. Please if you can answer me or guide me to make that change on the files, I'll apretitate that I'm struggling to correct that across from more than a thousand servers. I'll be in touch. Kind regards. Juan Luis Orellana E. +56954151809

4 4

[tz-announce] 2022b release of tz code and data available
by Paul Eggert via tz-announce Aug. 11, 2022

Aug. 11, 2022

The 2022b release of the tz code and data is available. This release reflects the following changes: Briefly: Chile's DST is delayed by a week in September 2022. Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. New zic -R option Vanguard form now uses %z. Finish moving duplicate-since-1970 zones to 'backzone'. New build option PACKRATLIST New tailored_tarballs target, replacing rearguard_tarballs Changes to future timestamps Chile's 2022 DST start is delayed from September 4 to September 11. (Thanks to Juan Correa.) Iran plans to stop observing DST permanently, after it falls back on 2022-09-21. (Thanks to Ali Mirjamali.) Changes to past timestamps Finish moving to 'backzone' the location-based zones whose timestamps since 1970 are duplicates; adjust links accordingly. This change ordinarily affects only pre-1970 timestamps, and with the new PACKRATLIST option it does not affect any timestamps. In this round the affected zones are Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake and Pacific/Wallis, and the affected links are Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap. From fall 1994 through fall 1995, Shanks wrote that Crimea's DST transitions were at 02:00 standard time, not at 00:00. (Thanks to Michael Deckers.) Iran adopted standard time in 1935, not 1946. In 1977 it observed DST from 03-21 23:00 to 10-20 24:00; its 1978 transitions were on 03-24 and 08-05, not 03-20 and 10-20; and its spring 1979 transition was on 05-27, not 03-21. (Thanks to Roozbeh Pournader and Francis Santoni.) Chile's observance of -04 from 1946-08-29 through 1947-03-31 was considered DST, not standard time. Santiago and environs had moved their clocks back to rejoin the rest of mainland Chile; put this change at the end of 1946-08-28. (Thanks to Michael Deckers.) Some old, small clock transitions have been removed, as people at the time did not change their clocks. This affects Asia/Hong_Kong in 1904, Asia/Ho_Chi_Minh in 1906, and Europe/Dublin in 1880. Changes to zone name Rename Europe/Kiev to Europe/Kyiv, as "Kyiv" is more common in English now. Spelling of other names in Ukraine has not yet demonstrably changed in common English practice so for now these names retain old spellings, as in other countries (e.g., Europe/Prague not "Praha", and Europe/Sofia not "Sofiya"). Changes to code zic has a new option '-R @N' to output explicit transitions < N. (Need suggested by Almaz Mingaleev.) 'zic -r @N' no longer outputs bad data when N < first transition. (Problem introduced in 2021d and reported by Peter Krefting.) zic now checks its input for NUL bytes and unterminated lines, and now supports input line lengths up to 2048 (not 512) bytes. gmtime and related code now use the abbreviation "UTC" not "GMT". POSIX is being revised to require this. When tzset and related functions set vestigial static variables like tzname, they now prefer specified timestamps to unspecified ones. (Problem reported by Almaz Mingaleev.) zic no longer complains "can't determine time zone abbreviation to use just after until time" when a transition to a new standard time occurs simultanously with the first DST fallback transition. Changes to build procedure Source data in vanguard form now uses the %z notation, introduced in release 2015f. For example, for America/Sao_Paulo vanguard form contains the zone continuation line "-3:00 Brazil %z", which is simpler and more reliable than the line "-3:00 Brazil -03/-02" used in main and rearguard forms. The plan is for the main form to use %z eventually; in the meantime maintainers of zi parsers are encouraged to test the parsers on vanguard.zi. The Makefile has a new PACKRATLIST option to select a subset of 'backzone'. For example, 'make PACKRATDATA=backzone PACKRATLIST=zone.tab' now generates TZif files identical to those of the global-tz project. The Makefile has a new tailored_tarballs target for generating special-purpose tarballs. It generalizes and replaces the rearguard_tarballs target and related targets and macros, which are now obsolescent. 'make install' now defaults LOCALTIME to Factory not GMT, which means the default abbreviation is now "-00" not "GMT". Remove the posix_packrat target, marked obsolescent in 2016a. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022b.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 b61a7acb4d267872f1c5319f30889a927b441b8f dated 2022-08-10 15:38:32 -0700 and tagged '2022b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 851622eb8e6dc8f8201bf05e1f7e411ca32b2ed0f4dc9f6b875f4482c05c4a3302259b78c3e8e2dadda52ae19d4d34ffa3463fee10f70fa3a8b08b19f1417f79 tzcode2022b.tar.gz a51418cda50386bc2e82a26201178c282ec225e04867e70a47ef90f42371a4014c70bffebb52ac09ccd893dfa17b0acc782f31527b3579ebdc4a302a9367ddb1 tzdata2022b.tar.gz b5bd93401c9586047e865a49b9f7fd0bdf451973be24a433786633f41a1ecc2f7eacdeb78d9a906c3526bfd3b236edab72682e5bc09add42156f8dcc2497694a tzdb-2022b.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL0NEoACgkQ7ZfpDmKq fjTVbw/8Cu33QgaVXIWhyQDv9gFBtGJvgVNa7IL1FP9nz1O6unqjTr57i7sameO0 aTu/v7JiCgIg5fsqqsi5yJQnYn8mZDC4MbOlqBtE237p4BwEZbvii0UWuWo/N4ep KNpbd3ezgOCYYXA+VS4azIW1LRAHhB4ZOvoUZuoRkPfoA5bR1VfZ8NRh0SfVK17R hoeRU7nlDofxHapL5zAqikGROLHhS++PVQ+x0gi5lQmDdHLtXZeiKor/y6sqb8R3 cQt8RyM6GzA9t4rsoUnMGBZIwaLYADJAmxVpBgS1EEwVfL7nx5WLur2ui+BK2GoF nN2QUG/N9TRPPFK722PiFAqoULKWamgUmRFl302TtIbygdaaKd7fxPMmgTL22REw 6qbVamP6Gk6jpG7+/FHusHB1Vz4TiTbSwK0g5UpTrps7QpoCXIU8sbScUXZzPYiY 1V2e9Fnrd2QE2+83guQhY4OX156Z32SPixl+qfK8+MMykibU6PGvCxhwHa7BzYBo X38rmsCri8vo+P27/godd6RBfsAkb8/PtB3Hlo0OGmhyggUMruVB+poip/xK8zJA bbjFB9pwi+gzkXVEkHIMuh5wgXswO+Tko7/P4ZH1t5xocc3BlrSxDvQuAVGb3hZw H3oyG5KP7sX4HCvZ42+3QTX05hFcJFgFtoncEVWAj+fPMJUm/yc= =IUf2 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL0NEoACgkQ7ZfpDmKq fjSfew/+P1NUMCiqlH5FlO5YyVGjc3Gxmpb6ToKsFloI7pn4KGlgQFy224VFmCVn ImSlurAuKydmZI6r+JPnjYIx0hcFUK/Wi2Y9tJKMlPDuOrexLa2toDvoXMlhBgQk RH+iaIGk8FC2mP/tdif0pzr43a87zRQiPuJ3MdoXYxEARXmc6wNtk07RS5jMlBUS G8dF2h023pTP3fD04Q77q+wUg3k5UuLw3DWrCCci1oeW/Vp+NzOsMb4vcxaWiH0M ecF0+FMpmqehJdKYZsS29D3aX8acZp3zXlAKoWHRCasCeKcltVEIyHHqdQrrR1SP R/r/OCOhIuOR3f9viPAAo56Obb63M+0siQYJmFy2Jr00lFjAzRIeajrCxSU7vxW7 6ljfdtSK8Ruv9FKrYD1Rdqa6jCpZLs6lnLk54WBStvdzJawjhZibBu3hK9LIagr/ Hb2x3H87swfId8lUZK46kjYhRYU7Jijtu+fPms5Fhrauaj2Dq56DrPyI+LyGKqBz Os0T28QUM6i67Rd0JOoMtDMesx2C/jvy9G09wwDq0mUdqg1OnfWeaUpYwCZJYdo0 Hm+zOPaxXIQph3f/MrFbrmwwggwFdjeCikOAH3uFPDp0UoHrGVq493sIGG3ulPYK 2FErRNNaeAyzniUK/35IqCQBB82GPiw6pxVf/O/HhPjLyUk55lU= =5vEv -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmL0NEsACgkQ7ZfpDmKq fjS9Yw/7BgRppySA/2mXbL+EqkGG1tmelEVx1TaHN/E2a/k1yji38Fs5+e0oHikb 95Xy2vApK5qMF0oye6nnsmtV+JquJSzwaQ4YDGLoPOtwCVNQU6WEOSlL7zfQXFsI AQy9x+yoQzevjiA+MK1Xx/s6a0G50uNZNFN1huRd4ENPPEw6qEEgLLo2qaP75uGz SM/RVIMjSTWdTdsefV1l/fIOPEqtX0S7SuldUbZh19NDLUn6vedwnO4i2qn71Guu EvZOr8RNtRpKeKOuyvLd+mKB1o4s3rUU/HlAAOcwJueNFstYH83QtrLKbjomPalI DC3E0x21Zlu3PoMsiaM+3BQknFBhx9JZI/pZz5+mUGlnjuNWTOcvxG9UGtRH+6Gr hVintjNuL2oabTuStxI7iuy+Dy6xbZ82Hs6Zy5xKuLixds/DutIfJHjLpsA3vaj+ PAkvEmPyF9zZY0C7QM3frMjqFc9vXY1114EKkVDknJ1jcOM1hszASgV/I3+j3NkN U2+++Y0fFWrWeGSm6mI5Pc2Z18OYfoIYS7q+k8fb1gzjiEWFav4U1cdm/npRca27 Mhkbbk4obVNyKGkRqpYQ40h99/Nl6uymMYx8N6zVin3tFXY23PeZnlJ6wS1yxOv1 i1g41pviERYjpp6JjBkosv5aVkxA+WKxqoWaE7x6fPXd1D3giAY= =H4rJ -----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

[Change] DST dates for Chile will change in 2022-2023
by Juan Correa Aug. 9, 2022

Aug. 9, 2022

Hello there: As of moments ago, the Internal Affairs Ministry (Ministerio del Interior) informed DST for America/Santiago will start on midnight of September 11th; and will end on April 1st, 2023. Magallanes region (America/Punta Arenas) will keep UTC -3 "indefinitely" If I recall correctly, this might alter at least the switch for 2023 This is because on September 4th we will have a voting whether to approve a new Constitution Source: https://twitter.com/min_interior/status/1556981967551209472

3 4

[PROPOSED 1/3] * theory.html: Source data can do subseconds.
by Paul Eggert Aug. 1, 2022

Aug. 1, 2022

--- theory.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/theory.html b/theory.html index bfadc4f0..2b14c511 100644 --- a/theory.html +++ b/theory.html @@ -723,8 +723,8 @@ href="https://www.dissentmagazine.org/blog/booked-a-global-history-of-time-vanes than what the <code><abbr>tz</abbr></code> code can handle. For example, from 1880 to 1916 clocks in Ireland observed Dublin Mean Time (estimated to be <abbr>UT</abbr> - −00:25:21.1), but the <code><abbr>tz</abbr></code> - code cannot represent the fractional second. + −00:25:21.1); although the <code><abbr>tz</abbr></code> + source data can represent the .1 second, TZif files and the code cannot. In practice these old specifications were rarely if ever implemented to subsecond precision. </li> -- 2.34.1

9 18

IANA timezone database - request to add Omaha, Nebraska
by Bob Wilmes Aug. 1, 2022

Aug. 1, 2022

Hello Paul Eggert, Can you please tell me how I request that Omaha, Nebraska, USA which is in the Americas Central time zone and uses daylight savings time, can be added to the "Olson" timezone database used by Ubuntu? Regards, Bob Wilmes Omaha, Nebraska bobwilmes(a)gmail.com -- Bob Wilmes bobwilmes(a)gmail.com

10 22

Re: [tz] [PROPOSED 3/3] Vanguard form now uses subsecond precision -Brooks
by Steve Allen July 31, 2022

July 31, 2022

On Sat 2022-07-30T13:24:01-0400 Brooks Harris hath writ: > On 2022-07-30 1:01 PM, Paul Eggert via tz wrote: > > Given the other comments in this thread I'm inclined to revert the > > effect of this change, so that vanguard form continues to use integer > > multiples of a second. So I installed the attached further patches, the > > last of which does the reversion. > I think that's best for civil time. But I had a thought. Steve Allen seemed > to like the idea and I'm sympathetic to his needs as astronomer. Maybe > subsecond precision could be added to "right" instead of vanguard? No, tz does not need subsecond precision, not for anyone, not in any era. The French law of 9m 21s is an example. The legislators should have known about the funds which had been expended as part of the two century effort to establish the offset between Greenwich and Paris, and that the disagreements of many 0.1 s in their own lifetimes were from the techniques employed by the astronomers, not from the telegraphs or radios. The sub-second astronomical offsets all date from before the 1970 cutoff. 1970 was when the CCIR was persuaded to assert that one second is close enough for everyone. Historically the best time comparisons had poor precision. Before the 20th century offsets were many 0.1 s or even > 1 s. In the early 20th century offsets were still many 0.01 s or even > 1 s. Attempts to reach a precision of 0.0001 s were not widespread until the International Geophysical Year of 1957/1958. Offsets of many 0.001 s persisted after the adoption of the cesium-based coordinated time because the Soviets used their own coordination scheme and other countries did not convert from UT2 to coordinated cesium time until the late 1960s. tz has rightfully eschewed the notion of trying to track local offsets recorded in Bulletin Horaire and Circular T. The legal time of the US was offset by 0.035 seconds from the BIH at 1958-01-01. The USNO and US NBS did not attempt to bring their time scales into microsecond agreement until 1968. Over a long interval in this century the legal time of Hungary was 50 microseconds different from UTC in most other places because the time lab there declined to perform a reset of their cesium. Thinking of encoding these things is a world of pain that tz does not need. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Check that ziguard substitutions revert
by Paul Eggert July 29, 2022

July 29, 2022

Add a check that substitutions to vanguard or rearguard form can be reverted. This supports possible future uses when continental files are in vanguard form and you want rearguard (or vice versa). * Makefile (check): Depend on ... (check_ziguard): ... this new target. * ziguard.awk: Fix some in_comment typos, as these column numbers do not depend on whether we’re in a comment. Use sub(X,Y) instead of $I = Y to preserve whitespace. Fix Japan and Morocco substitutions so that they are reversible. --- Makefile | 9 ++++++++- ziguard.awk | 58 ++++++++++++++++++++++++++++++++++++----------------- 2 files changed, 48 insertions(+), 19 deletions(-) diff --git a/Makefile b/Makefile index e3e5c0dd..52d7fdbe 100644 --- a/Makefile +++ b/Makefile @@ -754,7 +754,7 @@ tzselect: tzselect.ksh version check: check_character_set check_white_space check_links \ check_name_lengths check_slashed_abbrs check_sorted \ - check_tables check_web check_zishrink check_tzs + check_tables check_web check_ziguard check_zishrink check_tzs check_character_set: $(ENCHILADA) test ! '$(UTF8_LOCALE)' || \ @@ -839,6 +839,13 @@ check_theory.html check_tz-art.html check_tz-how-to.html check_tz-link.html: test ! -s $@.out || { cat $@.out; exit 1; } mv $@.out $@ +check_ziguard: rearguard.zi vanguard.zi ziguard.awk + $(AWK) -v DATAFORM=rearguard -f ziguard.awk vanguard.zi | \ + diff -u rearguard.zi - + $(AWK) -v DATAFORM=vanguard -f ziguard.awk rearguard.zi | \ + diff -u vanguard.zi - + touch $@ + # Check that zishrink.awk does not alter the data, and that ziguard.awk # preserves main-format data. check_zishrink: check_zishrink_posix check_zishrink_right diff --git a/ziguard.awk b/ziguard.awk index 171b952d..c39e0d65 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -134,8 +134,7 @@ DATAFORM != "main" { || in_comment + 3 == NF)))) if (Rule_Namibia || Zone_using_Namibia_rule) { if ((Rule_Namibia \ - ? ($(in_comment + 9) ~ /^-/ \ - || ($(in_comment + 9) == 0 && $(in_comment + 10) == "CAT")) \ + ? ($9 ~ /^-/ || ($9 == 0 && $10 == "CAT")) \ : $(in_comment + 1) == "2:00" && $(in_comment + 2) == "Namibia") \ == (DATAFORM != "rearguard")) { uncomment = in_comment @@ -219,43 +218,66 @@ DATAFORM != "main" { stdoff_column = 2 * /^Zone/ + 1 stdoff_column_val = $stdoff_column if (stdoff_column_val == stdoff_subst[0]) { - $stdoff_column = stdoff_subst[1] + sub(stdoff_subst[0], stdoff_subst[1]) if (until_subst[0] && $NF == until_subst[0]) { - $NF = until_subst[1] + sub(until_subst[0], until_subst[1]) } } else if (stdoff_column_val != stdoff_subst[1]) { stdoff_subst[0] = 0 } } - if (DATAFORM == "rearguard") { - - # In rearguard form, change the Japan rule line with "Sat>=8 25:00" - # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. - if (/^Rule/ && $2 == "Japan") { + # In rearguard form, change the Japan rule line with "Sat>=8 25:00" + # to "Sun>=9 1:00", to cater to zic before 2007 and to older Java. + if (/^Rule/ && $2 == "Japan") { + if (DATAFORM == "rearguard") { if ($7 == "Sat>=8" && $8 == "25:00") { sub(/Sat>=8/, "Sun>=9") sub(/25:00/, " 1:00") } + } else { + if ($7 == "Sun>=9" && $8 == "1:00") { + sub(/Sun>=9/, "Sat>=8") + sub(/ 1:00/, "25:00") + } } + } - # In rearguard form, change the Morocco lines with negative SAVE values - # to use positive SAVE values. - if ($2 == "Morocco") { - if (/^Rule/) { - if ($4 == 2018 && $6 == "Oct") { + # In rearguard form, change the Morocco lines with negative SAVE values + # to use positive SAVE values. + if ($2 == "Morocco") { + if (/^Rule/) { + if ($4 ~ /^201[78]$/ && $6 == "Oct") { + if (DATAFORM == "rearguard") { sub(/\t2018\t/, "\t2017\t") + } else { + sub(/\t2017\t/, "\t2018\t") } - if (2019 <= $3) { - if ($9 == "0") { + } + + if (2019 <= $3) { + if ($8 == "2:00") { + if (DATAFORM == "rearguard") { sub(/\t0\t/, "\t1:00\t") } else { + sub(/\t1:00\t/, "\t0\t") + } + } else { + if (DATAFORM == "rearguard") { sub(/\t-1:00\t/, "\t0\t") + } else { + sub(/\t0\t/, "\t-1:00\t") } } } - if ($1 == "1:00" && $3 == "+01/+00") { - sub(/1:00\tMorocco\t\+01\/\+00$/, "0:00\tMorocco\t+00/+01") + } + if ($1 ~ /^[+0-9-]/ && NF == 3) { + if (DATAFORM == "rearguard") { + sub(/1:00\tMorocco/, "0:00\tMorocco") + sub(/\t\+01\/\+00$/, "\t+00/+01") + } else { + sub(/0:00\tMorocco/, "1:00\tMorocco") + sub(/\t\+00\/+01$/, "\t+01/+00") } } } -- 2.34.1

1 0

[PROPOSED 1/2] New ‘make’ target tailored_tarballs
by Paul Eggert July 28, 2022

July 28, 2022

* Makefile (tailored_tarballs, tailored_tarballs_version) (tzdata$(VERSION)-tailored.tar.gz): New rules. (CREATE_EMPTY): New macro. (tzdata$(VERSION)-rearguard.tar.gz, tzdata$(VERSION)-vanguard.tar.gz): Use it. --- Makefile | 66 ++++++++++++++++++++++++++++++++++++++++++++------------ NEWS | 6 ++++++ 2 files changed, 58 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 79910d8..65dc0d8 100644 --- a/Makefile +++ b/Makefile @@ -1039,9 +1039,9 @@ REARGUARD_ASC = \ ALL_ASC = $(TRADITIONAL_ASC) $(REARGUARD_ASC) \ tzdb-$(VERSION).tar.lz.asc -tarballs rearguard_tarballs traditional_tarballs \ +tarballs rearguard_tarballs tailored_tarballs traditional_tarballs \ signatures rearguard_signatures traditional_signatures: \ - version set-timestamps.out rearguard.zi + version set-timestamps.out rearguard.zi vanguard.zi VERSION=`cat version` && \ $(MAKE) AWK='$(AWK)' VERSION="$$VERSION" $@_version @@ -1054,6 +1054,8 @@ rearguard_tarballs_version: \ tzdata$(VERSION)-rearguard.tar.gz traditional_tarballs_version: \ tzcode$(VERSION).tar.gz tzdata$(VERSION).tar.gz +tailored_tarballs_version: \ + tzdata$(VERSION)-tailored.tar.gz signatures_version: $(ALL_ASC) rearguard_signatures_version: $(REARGUARD_ASC) traditional_signatures_version: $(TRADITIONAL_ASC) @@ -1071,30 +1073,65 @@ tzdata$(VERSION).tar.gz: set-timestamps.out gzip $(GZIPFLAGS) >$@.out mv $@.out $@ +# Create empty files with a reproducible timestamp. +CREATE_EMPTY = TZ=UTC0 touch -mt 202010122253.00 + +# The obsolescent *rearguard* targets and related macros are present +# for backwards compatibility with tz releases 2018e through 2022a. +# They should go away eventually. To build rearguard tarballs you +# can instead use 'make DATAFORM=rearguard tailored_tarballs'. tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out - rm -fr tzdata$(VERSION)-rearguard.dir - mkdir tzdata$(VERSION)-rearguard.dir - ln $(COMMON) $(DATA) $(MISC) tzdata$(VERSION)-rearguard.dir - cd tzdata$(VERSION)-rearguard.dir && \ - rm -f $(TDATA) $(PACKRATDATA) version + rm -fr $@.dir + mkdir $@.dir + ln $(COMMON) $(DATA) $(MISC) $@.dir + cd $@.dir && rm -f $(TDATA) $(PACKRATDATA) version for f in $(TDATA) $(PACKRATDATA); do \ - rearf=tzdata$(VERSION)-rearguard.dir/$$f; \ + rearf=$@.dir/$$f; \ $(AWK) -v DATAFORM=rearguard -f ziguard.awk $$f >$$rearf && \ $(SET_TIMESTAMP_DEP) $$rearf ziguard.awk $$f || exit; \ done - sed '1s/$$/-rearguard/' \ - <version >tzdata$(VERSION)-rearguard.dir/version + sed '1s/$$/-rearguard/' <version >$@.dir/version : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. - TZ=UTC0 touch -mt 202010122253.00 \ - tzdata$(VERSION)-rearguard.dir/pacificnew - touch -cmr version tzdata$(VERSION)-rearguard.dir/version + $(CREATE_EMPTY) $@.dir/pacificnew + touch -cmr version $@.dir/version LC_ALL=C && export LC_ALL && \ - (cd tzdata$(VERSION)-rearguard.dir && \ + (cd $@.dir && \ tar $(TARFLAGS) -cf - \ $(COMMON) $(DATA) $(MISC) pacificnew | \ gzip $(GZIPFLAGS)) >$@.out mv $@.out $@ +# Create a tailored tarball suitable for TZUpdater and compatible tools. +# For example, 'make DATAFORM=vanguard tailored_tarballs' makes a tarball +# useful for testing whether TZUpdater supports vanguard form. +tzdata$(VERSION)-tailored.tar.gz: set-timestamps.out + rm -fr $@.dir + mkdir $@.dir + : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. + cd $@.dir && \ + $(CREATE_EMPTY) $(PRIMARY_YDATA) $(NDATA) backward pacificnew + (grep '^#' tzdata.zi && echo && cat $(DATAFORM).zi) \ + >$@.dir/etcetera + touch -cmr tzdata.zi $@.dir/etcetera + sed -n \ + -e '/^# *version *$.*$/h' \ + -e '/^# *ddeps */H' \ + -e '$$!d' \ + -e 'g' \ + -e 's/^# *version *//' \ + -e 's/\n# *ddeps */-/' \ + -e 's/ /-/g' \ + -e 'p' \ + <tzdata.zi >$@.dir/version + touch -cmr version $@.dir/version + LC_ALL=C && export LC_ALL && \ + (cd $@.dir && \ + tar $(TARFLAGS) -cf - \ + $(TDATA_TO_CHECK) version \ + `test $(DATAFORM) = vanguard || echo pacificnew` | \ + gzip $(GZIPFLAGS)) >$@.out + mv $@.out $@ + tzdb-$(VERSION).tar.lz: set-timestamps.out set-tzs-timestamp.out rm -fr tzdb-$(VERSION) mkdir tzdb-$(VERSION) @@ -1153,6 +1190,7 @@ zic.o: private.h tzfile.h version.h .PHONY: tarballs tarballs_version .PHONY: traditional_signatures traditional_signatures_version .PHONY: traditional_tarballs traditional_tarballs_version +.PHONY: tailored_tarballs tailored_tarballs_version .PHONY: typecheck .PHONY: zonenames zones .PHONY: $(ZDS) diff --git a/NEWS b/NEWS index 33261ee..eac1f0a 100644 --- a/NEWS +++ b/NEWS @@ -7,6 +7,7 @@ Unreleased, experimental changes Rename Europe/Kiev to Europe/Kyiv. New zic -R option Vanguard form now uses %z. + New tailored_tarballs target, replacing rearguard_tarballs Changes to future timestamps @@ -70,6 +71,11 @@ Unreleased, experimental changes to use %z eventually; in the meantime maintainers of zi parsers are encouraged to test the parsers on vanguard.zi. + The Makefile has a new tailored_tarballs target for generating + special-purpose tarballs. It generalizes and replaces the + rearguard_tarballs target and related targets and macros, which + are now obsolescent. + 'make install' now defaults LOCALTIME to Factory not GMT, which means the default abbreviation is now "-00" not "GMT". -- 2.37.1

2 2

Re: [tz] IANA timezone database - request to add Omaha, Nebraska
by Paul Eggert July 26, 2022

July 26, 2022

On 7/26/22 13:15, John Hawkinson wrote: >> If it means to enumerate only Zones and omit Links, which is what I think >> you mean, then readlink will work only if Links are implemented via symbolic >> links. Although Debian and Red Hat based systems do that, the default TZDB >> installation does not (it uses hard links), and Alpine, macOS, NetBSD, >> OpenBSD, OpenSUSE etc. use the default either because it is the default or >> because it is a bit more efficient. > You sure? > > My MacOS 12.5 laptop uses a symlink for /etc/localtime Oh, I was referring to links like these on Ubuntu 22.04: $ ls -l /usr/share/zoneinfo/Europe/Belfast lrwxrwxrwx 1 root root 6 Mar 21 11:29 /usr/share/zoneinfo/Europe/Belfast -> London I was not talking about /etc/localtime, which is a different kettle of fish. PS. Based on my misreading of a quick Google search I said in that quote above that macOS uses hard links for aliases like Europe/Belfast. However, Guy just reported[1] that current Ventura beta uses copies, just like FreeBSD does. Apologies for the error. [1] https://mm.icann.org/pipermail/tz/2022-July/031706.html

3 3

Meta engineers oppose leap seconds
by Paul Eggert July 26, 2022

July 26, 2022

Monty Solomon writes that Meta engineers Oleg Obleukhov and Ahmad Byagowi have come out against leap seconds in “It’s time to leave the leap second in the past”[1], which gives a shoutout to the leap-seconds.list file that Tim just updated in TZDB’s development version. Meta uses a 17-hour quadratic smear starting at midnight UTC, whereas Google and Amazon use a 24-hour linear smear from noon to noon UTC.[2] Obleukhov and Byagowi list several reasons leap seconds are a pain, say that the leap second is doing more harm than good (take that, scientists and astronomers!) and conclude that they “are supporting a larger community push to stop the future introduction of leap seconds”. Although I don’t see any new technical material there, their note prompted me to reread [2] and notice that Google provides an unsmear library[3] that’s worth mentioning, so I installed the attached proposed patch into the development version. [1] https://engineering.fb.com/2022/07/25/production-engineering/its-time-to-le… [2] https://developers.google.com/time/smear [3] https://github.com/google/unsmear

1 0

Leap second announcement July 2022
by Howard Hinnant July 26, 2022

July 26, 2022

https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt There will be no leap second at the end of Dec. 2022. The leap second file expiration date should be updated prior to releasing 2022b. Howard

2 2

[PROPOSED] Use %z in vanguard form
by Paul Eggert July 22, 2022

July 22, 2022

* europe (Atlantic/Azores, Atlantic/Madeira): Add comments containing a vanguard equivalent. * ziguard.awk (get_minutes, offset_abbr): New functions. Support the special case for the Azores and Madeira. Convert to and from %z form. --- NEWS | 9 ++++++ europe | 12 ++++++-- ziguard.awk | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 102 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 4904819..33261ee 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,7 @@ Unreleased, experimental changes Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. New zic -R option + Vanguard form now uses %z. Changes to future timestamps @@ -61,6 +62,14 @@ Unreleased, experimental changes Changes to build procedure + Source data in vanguard form now uses the %z notation, introduced + in release 2015f. For example, for America/Sao_Paulo vanguard + form contains the zone continuation line "-3:00 Brazil %z", which + is simpler and more reliable than the line "-3:00 Brazil -03/-02" + used in main and rearguard forms. The plan is for the main form + to use %z eventually; in the meantime maintainers of zi parsers + are encouraged to test the parsers on vanguard.zi. + 'make install' now defaults LOCALTIME to Factory not GMT, which means the default abbreviation is now "-00" not "GMT". diff --git a/europe b/europe index 0c008b4..776504d 100644 --- a/europe +++ b/europe @@ -2399,9 +2399,13 @@ Zone Europe/Lisbon -0:36:45 - LMT 1884 0:00 W-Eur WE%sT 1992 Sep 27 1:00s 1:00 EU CE%sT 1996 Mar 31 1:00u 0:00 EU WE%sT -# This Zone can be simplified once we assume zic %z. Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT +# Vanguard section, for zic and other parsers that support %z. +# -2:00 Port %z 1966 Apr 3 2:00 +# -1:00 Port %z 1983 Sep 25 1:00s +# -1:00 W-Eur %z 1992 Sep 27 1:00s +# Rearguard section, for parsers lacking %z; see ziguard.awk. -2:00 Port -02/-01 1942 Apr 25 22:00s -2:00 Port +00 1942 Aug 15 22:00s -2:00 Port -02/-01 1943 Apr 17 22:00s @@ -2413,11 +2417,14 @@ Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada -2:00 Port -02/-01 1966 Apr 3 2:00 -1:00 Port -01/+00 1983 Sep 25 1:00s -1:00 W-Eur -01/+00 1992 Sep 27 1:00s +# End of rearguard section. 0:00 EU WE%sT 1993 Mar 28 1:00u -1:00 EU -01/+00 -# This Zone can be simplified once we assume zic %z. Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal -1:07:36 - FMT 1912 Jan 1 1:00u # Funchal MT +# Vanguard section, for zic and other parsers that support %z. +# -1:00 Port %z +# Rearguard section, for parsers lacking %z; see ziguard.awk. -1:00 Port -01/+00 1942 Apr 25 22:00s -1:00 Port +01 1942 Aug 15 22:00s -1:00 Port -01/+00 1943 Apr 17 22:00s @@ -2427,6 +2434,7 @@ Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal -1:00 Port -01/+00 1945 Apr 21 22:00s -1:00 Port +01 1945 Aug 25 22:00s -1:00 Port -01/+00 1966 Apr 3 2:00 +# End of rearguard section. 0:00 Port WE%sT 1983 Sep 25 1:00s 0:00 EU WE%sT diff --git a/ziguard.awk b/ziguard.awk index 25de617..91f6896 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -23,6 +23,33 @@ # of the input data as best it can within the constraints of the # rearguard format. +# Given a FIELD like "-0:30", return a minute count like -30. +function get_minutes(field, \ + sign, hours, minutes) +{ + sign = field ~ /^-/ ? -1 : 1 + hours = +field + if (field ~ /:/) { + minutes = field + sub(/[^:]*:/, "", minutes) + } + return 60 * hours + sign * minutes +} + +# Given an OFFSET, which is a minute count like 300 or 330, +# return a %z-style abbreviation like "+05" or "+0530". +function offset_abbr(offset, \ + hours, minutes, sign) +{ + hours = int(offset / 60) + minutes = offset % 60 + if (minutes) { + return sprintf("%+.4d", hours * 100 + minutes); + } else { + return sprintf("%+.2d", hours) + } +} + BEGIN { dataform_type["vanguard"] = 1 dataform_type["main"] = 1 @@ -85,6 +112,16 @@ DATAFORM != "main" { } } + # If this line should differ due to Portugal benefiting from %z if supported, + # uncomment the desired version and comment out the undesired one. + if (/^#?[\t ]+-[12]:00[\t ]+Port[\t ]+[%+-]/) { + if (/%z/ == (DATAFORM == "vanguard")) { + uncomment = in_comment + } else { + comment_out = !in_comment + } + } + if (uncomment) { sub(/^#/, "") } @@ -92,6 +129,52 @@ DATAFORM != "main" { sub(/^/, "#") } + # Prefer %z in vanguard form, explicit abbreviations otherwise. + if (DATAFORM == "vanguard") { + sub(/^(Zone[\t ]+[^\t ]+)?[\t ]+[^\t ]+[\t ]+[^\t ]+[\t ]+[-+][^\t ]+/, \ + "&CHANGE-TO-%z") + sub(/-00CHANGE-TO-%z/, "-00") + sub(/[-+][^\t ]+CHANGE-TO-/, "") + } else { + if (/^[^#]*%z/) { + stdoff_column = 2 * /^Zone/ + 1 + rules_column = stdoff_column + 1 + stdoff = get_minutes($stdoff_column) + rules = $rules_column + stdabbr = offset_abbr(stdoff) + if (rules == "-") { + abbr = stdabbr + } else { + dstabbr_only = rules ~ /^[+0-9-]/ + if (dstabbr_only) { + dstoff = get_minutes(rules) + } else { + # The DST offset is normally an hour, but there are special cases. + if (rules == "Morocco" && NF == 3) { + dstoff = -60 + } else if (rules == "NBorneo") { + dstoff = 20 + } else if (((rules == "Cook" || rules == "LH") && NF == 3) \ + || (rules == "Uruguay" \ + && /[\t ](1942 Dec 14|1960|1970|1974 Dec 22)$/)) { + dstoff = 30 + } else if (rules == "Uruguay" && /[\t ]1974 Mar 10$/) { + dstoff = 90 + } else { + dstoff = 60 + } + } + dstabbr = offset_abbr(stdoff + dstoff) + if (dstabbr_only) { + abbr = dstabbr + } else { + abbr = stdabbr "/" dstabbr + } + } + sub(/%z/, abbr) + } + } + if (DATAFORM == "rearguard") { # In rearguard form, change the Japan rule line with "Sat>=8 25:00" -- 2.36.1

1 0

[PATCH] * europe: Fix a few more "Kiev"s in comments.
by Paul Eggert July 21, 2022

July 21, 2022

--- europe | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/europe b/europe index 55217a1..0c008b4 100644 --- a/europe +++ b/europe @@ -2845,18 +2845,18 @@ Zone Europe/Simferopol 2:16:24 - LMT 1880 2:00 - EET 1992 Mar 20 # Central Crimea used Moscow time 1994/1997. # -# From Paul Eggert (2022-04-18): -# The _Economist_ (1994-05-28, p 45) reports that central Crimea switched -# from Kiev to Moscow time sometime after the January 1994 elections. +# From Paul Eggert (2022-07-21): +# The _Economist_ (1994-05-28, p 45) reported that central Crimea switched +# from Kyiv to Moscow time sometime after the January 1994 elections. # Shanks (1999) says "date of change uncertain", but implies that it happened # sometime between the 1994 DST switches. Shanks & Pottenger simply say # 1994-09-25 03:00, but that can't be right. For now, guess it # changed in May. This change evidently didn't last long; see below. 2:00 C-Eur EE%sT 1994 May -# From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. +# From IATA SSIM (1994/1997), which also said that Kerch is still like Kyiv. 3:00 C-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s -# IATA SSIM (1997-09) says Crimea switched to EET/EEST. +# IATA SSIM (1997-09) said Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. 3:00 - MSK 1997 Mar lastSun 1:00u # From Alexander Krivenyshev (2014-03-17): @@ -4078,7 +4078,7 @@ Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. # The law documents themselves are at # http://w1.c1.rada.gov.ua/pls/zweb_n/webproc4_1?id=&pf3511=41484 -# From Vladimir in Moscow via Alois Treindl re Kiev time 1991/2 (2014-02-28): +# From Vladimir in Moscow via Alois Treindl re Kyiv time 1991/2 (2014-02-28): # First in Ukraine they changed Time zone from UTC+3 to UTC+2 with DST: # 03 25 1990 02:00 -03.00 1 Time Zone 3 with DST # 07 01 1990 02:00 -02.00 1 Time Zone 2 with DST -- 2.36.1

1 0

[PATCH 1/3] * backward: Add backward-compatibility comment.
by Paul Eggert July 21, 2022

July 21, 2022

--- backward | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/backward b/backward index a8fd620..5a86400 100644 --- a/backward +++ b/backward @@ -8,6 +8,10 @@ # also present in the file 'backzone', which has data important only # for pre-1970 timestamps and so is out of scope for tzdb proper. +# Although this file is optional and tzdb will work if you omit it by +# building with 'make BACKWARD=', in practice downstream users +# typically use this file for backward compatibility. + # Link TARGET LINK-NAME Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu -- 2.36.1

1 2

Re: [tz] Fixing GeoNames timezone error
by dpatte July 19, 2022

July 19, 2022

I may be mistaken, but these other zones may be based on Indigenous reservations in these areas, some of which may not have used daylight saving time. ----- Original Message ----- From: Chris Walton via tz [mailto:tz@iana.org] To: "Evan Siroky" <evan.siroky(a)yahoo.com> Cc: kerry(a)shetline.com, tz(a)iana.org Sent: Tue, 19 Jul 2022 12:49:12 -0400 Subject: Re: [tz] Fixing GeoNames timezone error I mentioned earlier in this email thread that a large portion of Ontario (including the city of Barrie) is currently within the America/Nipigon boundary in Openstreetmap (OSM). I am 100% convinced the boundary is completely wrong. e.g. #1: The city of Barrie has been using daylight saving (during summer months) since at least 1930 which means it should be included within the America/Toronto boundary instead of the America/Nipigon boundary. Here are some newspaper pages containing Barrie daylight saving announcements for several different years that I picked at random: 1930: https://news.ourontario.ca/2760660/page/1835517 1946: https://news.ourontario.ca/2909650/page/13 1960: https://news.ourontario.ca/2919309/page/2280030 1970: https://news.ourontario.ca/2914181/page/2325462 1972: https://news.ourontario.ca/2917630/page/2349924 e.g. #2: I found documented proof that Prince Edward County was using daylight saving in 1970 which means it too should be moved from America/Nipigon to America/Toronto. Realistically it has probably been using daylight saving since WWII or earlier. The Kingston Whig Standard published this blurb on April 25, 1970:PICTON — Clocks go ahead one hour here Saturday night or Sunday morning, whichever you prefer, as Daylight Saving Time takes over in Prince Edward County. OSM mapper "ArcticGnome" claims to have based the OSM boundaries for America/Nipigon and America/Toronto on Shanks and Pottenger's International Atlas without realizing that much of the Shanks & Pottenger data was fake. Both myself and ArcticGnome are now pondering whether the inaccuracy of the data warrants eliminating the following zones from OSM. America/Nipigon America/Rainy_River America/Thunder_Bay America/Glace_Bay I believe that that decision should depend on whether Paul decides to continue maintaining them as dedicated zones in the TZ database. In my opinion, none of the data for these zones is trustworthy. America/Nipigon: Currently the TZ database shows that America/Nipigon adopted daylight saving in 1974. I don't have a complete history of daylight saving for Nipigon, but I did find a page from the Nipigon Gazette that clearly shows daylight saving ending for the 1972 season on October 29, 1972. https://news.ourontario.ca/npl/122271/page/2 The implication is that Nipigon has been using daylight saving since at least 1972 and therefore the data we are using for America/Nipigon is bogus. America/Rainy_River: I could not find any useful information to prove that the data for this zone is either correct or incorrect. America/Thunder_Bay: The TZ database shows that Thunder Bay and Toronto have been in sync since 1970 except for the year 1973. The database shows Thunder Bay skipped daylight saving in 1973. However, a relatively recent article in the Bayview Magazine seems to indicate that Thunder Bay did not actually skip daylight saving in 1973: http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… I sent an email to both the author of that article and one of the Thunder Bay archivists. In the email I asked for clarification about 1973. I will post here if I actually get a response. America/Glace_Bay: The TZ database shows Glace Bay adopted daylight saving in 1972. It is possible that this data is correct, but I am a bit skeptical. Glace Bay is a small town about 10km from Sydney. According to this document, Sydney was observing daylight saving in the year 1969: https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000135.000.h… There is no compelling reason to believe that Sydney would have abandoned daylight saving in 1970 and 1971. And there is no compelling reason to believe that Glace Bay would have kept its clocks out of sync with Sydney during the summers of 1970 and 1971. The truth about Glace Bay (and other communities in Cape Breton) will likely exist in the archives of the Cape Breton Post which are maintained on microfilm at the Cape Breton Regional Library in Sydney and at the Nova Scotia Archives in Halifax. -chris On Fri, 8 Jul 2022 at 05:33, Evan Siroky <evan.siroky(a)yahoo.com> wrote: I agree with Chris. I'm adding a reference to the GitHub issue that Kerry created. https://github.com/evansiroky/timezone-boundary-builder/issues/131 Evan On Friday, 8 July 2022 at 04:22:26 am GMT+2, Chris Walton via tz <tz(a)iana.org> wrote: The Nipigon/Toronto is a pet peeve of mine. It is the result of some questionable data inside Openstreetmap (OSM). Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km. To put this into perspective: -Nipigon contains 0.01% of Ontario's total population. -Nipigon makes up 0.01% of Ontario's total land area. Inside OSM, somebody moved 73% of the land in Ontario into the America/Nipigon timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference. After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong. I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions. The OSM relations are listed below. Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this. The relations are large and may take some time to load in your browser. OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135 OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573 >From a daylight saving standpoint, both zones have been the same since 1974. It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference). -chris On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz(a)iana.org> wrote:I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point. > Evan Siroky <evan.siroky(a)yahoo.com> writes: > > Hello, > I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. > Evan

1 0

Re: [tz] Fixing GeoNames timezone error
by Kerry Shetline July 19, 2022

July 19, 2022

I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point. > Evan Siroky <evan.siroky(a)yahoo.com> writes: > > Hello, > I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. > Evan

4 4

Re: [tz] [PROPOSED] New file tzdata.zi for text-format tzdata
by Dot T July 12, 2022

July 12, 2022

With a few exceptions, all files in the tz code and data (including this one) are in the public domain. The exceptions are date.c, newstrftime.3, and strftime.c, which contain material derived from BSD and which use the BSD 3-clause license.

1 0

Re: [tz] [PROPOSED] New file tzdata.zi for text-format tzdata
by Dot T July 12, 2022

July 12, 2022

With a few exceptions, all files in the tz code and data (including this one) are in the public domain. The exceptions are date.c, newstrftime.3, and strftime.c, which contain material derived from BSD and which use the BSD 3-clause license.

1 0

[PROPOSED 1/5] * zic.8: fix minus typo
by Paul Eggert July 12, 2022

July 12, 2022

--- zic.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.8 b/zic.8 index 0cd0781..e8816e5 100644 --- a/zic.8 +++ b/zic.8 @@ -145,7 +145,7 @@ outputs data intended only for nonnegative timestamps that fit into 31-bit signed integers. On platforms with GNU .BR date , -.q "zic \-r @$(date +%s)" +.q "zic \*-r @$(date +%s)" omits data intended for past timestamps. Although this option typically reduces the output file's size, the size can increase due to the need to represent the timestamp range -- 2.34.1

1 4

[PATCH] Add -R option to zic
by Paul Eggert July 12, 2022

July 12, 2022

(Need suggested by Almaz Mingaleev.) * NEWS, zic.8: Document option. * zic.c (usage): Mention new option. (redundant_time): New static var. (redundant_time_option): New function. (main, writezone, outzone): Support -R. --- NEWS | 4 ++++ zic.8 | 11 +++++++++++ zic.c | 44 +++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 56 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 60deee4..850e38b 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. + New zic -R option Changes to future timestamps @@ -38,6 +39,9 @@ Unreleased, experimental changes Changes to code + zic has a new option '-R @N' to output explicit transitions < N. + (Need suggested by Almaz Mingaleev.) + 'zic -r @N' no longer outputs bad data when N < first transition. (Problem introduced in 2021d and reported by Peter Krefting.) diff --git a/zic.8 b/zic.8 index 3f228a6..0cd0781 100644 --- a/zic.8 +++ b/zic.8 @@ -159,6 +159,17 @@ Also see the .B "\*-b slim" option for another way to shrink output size. .TP +.BI "\*-R @" hi +Generate redundant trailing explicit transitions for timestamps +that occur less than +.I hi +seconds since the Epoch, even though the transitions could be +more concisely represented via the extended POSIX TZ string. +This option does not affect the represented timestamps. +Although it accommodates nonstandard TZif readers +that ignore the extended POSIX TZ string, +it increases the size of the altered output files. +.TP .BI "\*-t " file When creating local time information, put the configuration link in the named file rather than in the standard location. diff --git a/zic.c b/zic.c index 19e145a..e081c3d 100644 --- a/zic.c +++ b/zic.c @@ -579,7 +579,8 @@ usage(FILE *stream, int status) _("%s: usage is %s [ --version ] [ --help ] [ -v ] \\\n" "\t[ -b {slim|fat} ] [ -d directory ] [ -l localtime ]" " [ -L leapseconds ] \\\n" - "\t[ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -t localtime-link ] \\\n" + "\t[ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -R '@hi' ] \\\n" + "\t[ -t localtime-link ] \\\n" "\t[ filename ... ]\n\n" "Report bugs to %s.\n"), progname, progname, REPORT_BUGS_TO); @@ -681,6 +682,9 @@ static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t lo_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t hi_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); +/* The time specified by the -R option, defaulting to MIN_TIME. */ +static zic_t redundant_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); + /* The time specified by an Expires line, or negative if no such line. */ static zic_t leapexpires = -1; @@ -712,6 +716,22 @@ timerange_option(char *timerange) return true; } +/* Generate redundant time stamps up to OPT. Return true if successful. */ +static bool +redundant_time_option(char *opt) +{ + if (*opt == '@') { + intmax_t redundant; + char *opt_end; + redundant = strtoimax(opt + 1, &opt_end, 10); + if (opt_end != opt + 1 && !*opt_end) { + redundant_time = max(redundant_time, redundant); + return true; + } + } + return false; +} + static const char * psxrules; static const char * lcltime; static const char * directory; @@ -764,7 +784,8 @@ main(int argc, char **argv) } else if (strcmp(argv[k], "--help") == 0) { usage(stdout, EXIT_SUCCESS); } - while ((c = getopt(argc, argv, "b:d:l:L:p:r:st:vy:")) != EOF && c != -1) + while ((c = getopt(argc, argv, "b:d:l:L:p:r:R:st:vy:")) != EOF + && c != -1) switch (c) { default: usage(stderr, EXIT_FAILURE); @@ -851,12 +872,23 @@ _("%s: invalid time range: %s\n"), } timerange_given = true; break; + case 'R': + if (! redundant_time_option(optarg)) { + fprintf(stderr, _("%s: invalid time: %s\n"), + progname, optarg); + return EXIT_FAILURE; + } + break; case 's': warning(_("-s ignored")); break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) usage(stderr, EXIT_FAILURE); /* usage message by request */ + if (hi_time + (hi_time < ZIC_MAX) < redundant_time) { + fprintf(stderr, _("%s: -R time exceeds -r cutoff\n"), progname); + return EXIT_FAILURE; + } if (bloat == 0) { static char const bloat_default[] = ZIC_BLOAT_DEFAULT; if (strcmp(bloat_default, "slim") == 0) @@ -2139,7 +2171,10 @@ writezone(const char *const name, const char *const string, char version, rangeall.defaulttype = defaulttype; rangeall.count = timecnt; rangeall.leapcount = leapcnt; - range64 = limitrange(rangeall, lo_time, hi_time, ats, types); + range64 = limitrange(rangeall, lo_time, + max(hi_time, + redundant_time - (ZIC_MIN < redundant_time)), + ats, types); range32 = limitrange(range64, INT32_MIN, INT32_MAX, ats, types); /* TZif version 4 is needed if a no-op transition is appended to @@ -2893,6 +2928,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) max_year = min_year + years_of_observations; } } + max_year = max(max_year, (redundant_time / (SECSPERDAY * DAYSPERNYEAR) + + EPOCH_YEAR + 1)); max_year0 = max_year; if (want_bloat()) { /* For the benefit of older systems, @@ -3061,6 +3098,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) offset = oadd(zp->z_stdoff, rp->r_save); if (!want_bloat() && !useuntil && !do_extend && prevrp && lo_time <= prevktime + && redundant_time <= ktime && rp->r_hiyear == ZIC_MAX && prevrp->r_hiyear == ZIC_MAX) break; -- 2.34.1

1 0

to Pierre Cashon
by Petro Ordynskyi July 12, 2022

July 12, 2022

1 0

Moderation note 2
by Petro Ordynskyi July 12, 2022

July 12, 2022

1 0

Timezone error (Kyiv not Kiev)
by Yana Sukhoversha July 12, 2022

July 12, 2022

Dear Sirs and Madams, I've noticed the Timezone error , the correct spelling according to orthographic rules is Kyiv not Kiev. I hope this accidental mistake will be amended urgently , taking into consideration Ukrainian-Russian relations nowadays as well as your strive to improvement and lightning-fast response to error corrections Hope to see the correct variant Kyiv very soon Sincerely, *Yana Sukhoversha*

10 14

Moderation note
by Kim Davies July 12, 2022

July 12, 2022

We have temporarily introduced some moderation controls in light of the repetitive and externally coordinated nature of the Kyiv naming requests being sent to this group. This is not a measure we take lightly. Continuous restatement of the same talking points and casting aspersions at people's motives does not advance productive discussion and drives well intentioned participants away. I would encourage all participants to not relitigate the same arguments back and forth that are now very familiar to list members. It is useful to consider ICANN's expected standards of behavior which can be reviewed at https://www.icann.org/resources/pages/expected-standards-2016-06-28-en kim -- Kim Davies VP, IANA Services, ICANN President, PTI

1 0

Why Kyiv has not been changed yet?
by Artur Nakonia July 10, 2022

July 10, 2022

Hello, What is the problem with Kyiv? Why it is still as Kiev? Thank you, Artur Nakonia

2 2

Absolute error to use Kiev instead of Kyiv
by Pavlo Neberelytskyi July 10, 2022

July 10, 2022

Hi, There is an error in naming Kiev instead of Kyiv. Kyiv is the only correct variant since 1992, please correct. Thanks, Pavlo

1 0

Re: [tz] Moving more zones to 'backzone'
by dpatte July 9, 2022

July 9, 2022

Thank you. This is something I have been trying to say as well. The db format should allow us to collect historical tz information for any region, even locations that are only different before 1970. This is of use for those that do historical time-of-day research in any field, such as astronomy. Eventually all locations on earth, going backward, revert to local solar (sundial) time, so we only need to collect data which is other than local solar time, generally going back to the dates of implementation of local mean time for various locations. Obviously, such a collection can never be complete, like any historical data, but it does provide information which is useful to some, and constantly improving. ----- Original Message ----- From: Christos Zoulas via tz [mailto:tz@iana.org] To: "Time zone mailing list" <tz(a)iana.org> Sent: Sat, 9 Jul 2022 07:01:08 -0400 Subject: Re: [tz] Moving more zones to 'backzone' I view maintaining the pre-1970 data as an exercise in improving the historical record of timezone information. Historians don't simply discard information when they are not certain about its accuracy. They constantly work to make it better. In extreme cases it is called https://en.wikipedia.org/wiki/Historical_revisionism. I don't see any other group of people trying to do this work, so like it or not we are the best positioned group to maintain this information right now. I believe that we should provide the best information to our knowledge instead of giving up and discarding it because of convenience. I also agree with kre that the arcane zic format needs to be redesigned to ease maintenance. Best, christos

1 0

On simultaneously experiencing daylight
by Tim Parenti July 8, 2022

July 8, 2022

A friend shared an article investigating a recent claim on Reddit that earlier today, 8 July 2022, at 11:15 UTC, "99% of the world’s population" would simultaneously find themselves between dawn and dusk. This claim was soon popularized into a related claim that a similar percentage would "experience daylight" at that time. https://earthsky.org/earth/99-percent-worlds-population-receive-sunlight/ Spoiler: The original claim of 99% holds only if you use the most *technical* definition of twilight — including civil, nautical, and astronomical. In practice, most folks living in areas falling into the latter categories would perceive nighttime. But, as the article goes on to explore, however you slice it, it's still an impressive percentage of the global population "experiencing daylight" by any definition. -- Tim Parenti

1 0

question re zone America/Punta_Arenas in Chile
by Alois Treindl July 7, 2022

July 7, 2022

In 2016, Chile introduced a new time zone for it south-most province Magallanes, and for this reason a new zone Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03 has been created. before it followed Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1946 Jul 15 -4:00 1:00 -03 1946 Sep 1 # central Chile -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 The new zone differs from zone Santiago at two points: - it does not have the 1946/47 DST - it differs from 2016 Dec 4, the reason of its creation. I wonder on which basis the 1946/47 DST was left out for Puntas_Arenas? Is that documented somewhere? The main reason why I ask: My two sources Shanks and Gabriel have always claimed that zone America/Santiago is only good for the province of Santiago, but that the rest of Chile did not have DST between 1927 and 1932. This is why in my private pre-1970 TZ extension I have an extra zone for 'rest of Chile besides Santiago' Zone America/Chile/Antofagasta -4:41:36 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 0 follow America/Santiago which leaves out the 1927-1932 DST. It has however the 1946/47 DST. I have another zone, based on Shanks and Gabriel, for Vaparaiso, which leaves out the 1946/47 DST, but has a one-summer 1931/1932 DST. Zone America/Chile/Vina_del_Mar -4:46:16 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1931 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 0 follow America/Santiago Sadly, I have currently no sources for that beyond Shanks and Gabriel. We would need local newspaper archives from a non-Santiago newspaper for 1927-1932 to confirm. But it this is true, we have to assume that province Magellanes behaved like 'the rest of Chile' and not like Santiago before the split in 2016. That means that it should be: Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03

4 6

Re: [tz] Fixing GeoNames timezone errors
by dpatte July 6, 2022

July 6, 2022

I use the free geonames database in several of my projects. It is a user-contributed db, so all users are welcome to make corrections. They also have a paid version which is more heavily scrutinized for errors. ----- Original Message ----- From: Kerry Shetline via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Wed, 6 Jul 2022 15:50:02 -0400 Subject: [tz] Fixing GeoNames timezone errors For those not familiar with the website, geonames.org provides a Creative Commons-licensed database of city, towns, geographic features, etc. Among other things, this DB provides latitude, longitude, and IANA timezone for millions of places around the world. The problem is I’m finding many of the timezone values provided in this DB are incorrect. This mostly seems to be caused by places with coordinates near timezone boundaries being incorrectly assigned a nearby but incorrect timezone. For example, Walpole Island, Ontario, Canada, right next to the US border, is set to America/Detroit instead of the correct value of America/Toronto. It’s at least easy to spot some errors like this, when a particular timezone is known to definitely belong to a different country, but there are many other errors at national, and state/province/prefect/etc. boundaries not so easy to spot. I was trying to create a timezone lookup based on country, state (admin level 1), and county (admin level 2) by going through the millions of entries in the database, building lists of which timezones were used where, but it quickly became apparent that the data was contaminated by many errors. Does anyone know of a more reliable source for determining the timezone of a location on Earth, either by its latitude and longitude, or by the country and other administrative hierarchy information? I’ve found downloads of shape files meant to define timezone boundaries, but they don’t seem to be very accurate. In fact, I suspect that the use of inaccurate timezone boundaries is the source of many of the errors in the Geonames DB, and that Geonames isn't even applying the help of the zone.tab file to rule out some of the errors caused by this.

1 0

Fixing GeoNames timezone errors
by Kerry Shetline July 6, 2022

July 6, 2022

For those not familiar with the website, geonames.org provides a Creative Commons-licensed database of city, towns, geographic features, etc. Among other things, this DB provides latitude, longitude, and IANA timezone for millions of places around the world. The problem is I’m finding many of the timezone values provided in this DB are incorrect. This mostly seems to be caused by places with coordinates near timezone boundaries being incorrectly assigned a nearby but incorrect timezone. For example, Walpole Island, Ontario, Canada, right next to the US border, is set to America/Detroit instead of the correct value of America/Toronto. It’s at least easy to spot some errors like this, when a particular timezone is known to definitely belong to a different country, but there are many other errors at national, and state/province/prefect/etc. boundaries not so easy to spot. I was trying to create a timezone lookup based on country, state (admin level 1), and county (admin level 2) by going through the millions of entries in the database, building lists of which timezones were used where, but it quickly became apparent that the data was contaminated by many errors. Does anyone know of a more reliable source for determining the timezone of a location on Earth, either by its latitude and longitude, or by the country and other administrative hierarchy information? I’ve found downloads of shape files meant to define timezone boundaries, but they don’t seem to be very accurate. In fact, I suspect that the use of inaccurate timezone boundaries is the source of many of the errors in the Geonames DB, and that Geonames isn't even applying the help of the zone.tab file to rule out some of the errors caused by this.

2 1

Re: [tz] Timezone error (Kyiv not Kiev)
by Stephen Trainor (Crookneck) July 6, 2022

July 6, 2022

Steve Summit wrote: > What end-user interfaces are there that present raw tz identifiers > for selection, and that might therefore confuse or offend users > if the spellings are culturally inappropriate? I’ve seen them shown (and have used them myself 'as-is') in multiple astronomy apps. (I double checked some apps today, and they are there.) I’ve never quite understood the "don’t show them to the user" argument. When I first became involved in using time zone data in a desktop application some years ago (via geonames and other downstream tzdata repackaging projects), from memory there was no mention of this guidance. It would be wrong to assume downstream consumers even know about it. And given that TZ IDs conspicuously pass the "duck test” it’s hardly surprising to see them making public appearances. They appear perfectly suited to show in a UI (with underscores replaced by spaces, I suppose). That said, replacing them with an anonymous identifier (e.g. 7252) would be a major negative for usability of the data (at least from a development/testing perspective). And while it would kick the problem downstream, it’s not going to eliminate it. I imagine many of the new set of downstream TZ ID-to-human readable translation errors or disputes that would undoubtedly ensue would land back on this list anyway. > As regulars well know, but newcomers may not, time zone identifiers > are just that: identifiers. True, but clearly there’s major inertia when it comes to changing them, as evidenced by the last several years of debate on K**v. So which is it? Easily mutable identifiers that users supposedly never see or human consumable ‘readable’ IDs?

3 4

Error Correction Request: Europe/Kiev to Europe/Kyiv
by Ivanka Kvitka July 5, 2022

July 5, 2022

Hello, Please be aware that 'Kiev' is an error. The correct name is 'Kyiv'. When are you planning to correct the mistake? Please advise. Best regards, -- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it!

5 8

tzdata comments link to an April Fools article
by Jeff Epler July 5, 2022

July 5, 2022

I was poking around and found the following in the "australiasia" file: # From Paul Eggert (2018-04-01): # The Guardian Express of Perth, Australia reported today that the # government decided to advance the clocks permanently on January 1, # 2019, from UT +08 to UT +09. The article noted that an exemption # would be made for people aged 61 and over, who "can apply in writing # to have the extra hour of sunshine removed from their area." See: # Daylight saving coming to WA in 2019. Guardian Express. 2018-04-01. # https://www.communitynews.com.au/guardian-express/news/exclusive-daylight-s… However, this article is a joke (note that it is dated April 1 and says some rather silly things). Maybe everyone was in on the joke, but I very nearly wasn't. I think it would be best if this reference were removed or if not clearly marked as humor. In the unlikely event that this actually reflects reality, perhaps a different reference could be used. Please cc: me on replies. Jeff

7 7

the tzdb information schema
by Michael H Deckers July 4, 2022

July 4, 2022

Some recent difficulties with tzdb updates have led me to consider how they could have been avoided. • The fact that two timezones agree since 1970 is not represented independently from the data of each timezone. This leads to "update anomalies" well-known from database theory. For instance, before Africa/Khartoum switched to UTC - 02 h in 2017, Africa/Juba was a link (in the file africa) to Africa/Khartoum. After the switch, new Zone data for Africa/Juba had to appear in the file africa. Actually, Zone data for Africa/Juba had survived in the file backzone but this was overlooked, so that we had Zone data for Africa/Juba in both files africa and backzone from 2017c until 2018b, and these Zone data did not even agree. And all this happened for Africa/Juba even though civil time in Juba was not changed at all at the time. It appears that this error would not have happened if all African Zone data had been kept in the file africa (rather than in africa and in backzone) -- it was not the Zone data of Africa/Juba that had changed, but only the fact that Africa/Juba ws merged with Africa/Khartoum because their Zone data agreed since 1970. Unfortunately, this fact was not (and still is not) representable as an independently changeable item in tzdb. • Most of the Zone data currently contained in the file backzone have in earlier versions been stored in the "continental" files (africa, antarctica, asia, australasia, europe, northamerica, southamerica), and the reason why they are in backzone is that their Zone data agree with other Zone data since 1970. And since this may well change in the future, we have to keep these Zone data in backzone current. The file backzone is an integral part of the tzdb data, not just a container for additional data of lesser quality. The quality of any Zone data (and any Rule data) in tzdb should always be "to the best of our current knowledge" -- it just does not make sense to keep Zone data in tzdb that are not updated when we acquire relevant new information for them. Thus we should get rid of Zone data for Argentina/Rosario etc (or else update them); keeping data that are known to be wrong is not only useless, it is an invitation for consequential errors. • Letting derived data (such as whether two timezones should be merged because they agree since 1970) decide about the storage location of the Zone data for a timezone not only implies unnecessary data moves upon data updates, it may also disrupt commentary text and its references. Easily understandable comments (such as which facts were deduced from which document) are crucial for later updates, where the effect of a newly found document has to be determined, often after several years, and likely by a different contributor. • The fact that two timezones agree since 1970 has nothing to do with the fact that some timezones have changed their names, with the old names being kept as Links to the new names. Currently, however, Links representing one or both facts are kept in the same file backward, and cannot be distinguished. This leads to information loss and update anomalies: Currently, the file backward has a Link from Africa/Asmera to Africa/Nairobi -- the information that Asmera is an outdated spelling of Asmara can only be found in the file backzone. The name America/Virgin had been replaced by America/St_Thomas in version 95k, and this fact could be seen in the file backward until 2021a when this information was lost. It reappeared (in backzone) only in version 2021c. Keeping one type of information (spelling changes) in different locations (files backward or backzone) depending on an independent condition (that may even change over time) certainly causes unnecessary maintenance effort. While some of these points may sound like theoretical claims for normal forms as taught in computer science, my point here is only practical simplicity: each basic fact to be recorded in tzdb should have its obvious place where it is stored and where it can be looked up and updated; and updates of independent facts should be possible without mutual side effects. This appears to be a necessity for a collaborative project. Last Saturday, Paul Eggert has very nicely summarized the history and some of the guiding principles of tzdb. It is largely due to his immense work on the maintenance and evolvement of tzdb that the tzdb system was such a tremendous success in its first 30 years. As a means for the success over the next 30 years, I propose a simplification of the tzdb schema, so as to avoid the update anomalies described above, and thus decrease the maintenance burden, currently mainly shouldered by Paul. The information schema used in the fork produced by Stephen Colebourne is already much simpler, and it is apparently what is needed by several power users contributing to the widespread success of tzdb. Michael Deckers.

2 1

Kyiv not Kiev
by Petro Ord July 2, 2022

July 2, 2022

Hello, Please be informed that your database has an error in naming Ukrainian city Kyiv. It is provided in the tz database as 'Kiev'. In June 2019 the name *Kyiv* was officially adopted by the United States Board on Geographic Names as the only correct one. Please correct the mistake Thank you

18 66

Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d
by Peter Krefting July 1, 2022

July 1, 2022

Hi! I am creating timezone data for an embedded device, and with space as a premium I run zic with the -r parameter to cut off all time change information from before the software release date, as this is not relevant for the system. Since commit 5f06f9a3182d2c2942be1b678e4defa9c7400653 (included in 2021d), this causes the Etc/GMT+xx and Etc/GMT-xx timezones not to work, they always report GMT ("-00"): ~ # TZ=Europe/Oslo date Mon Mar 21 13:08:32 CET 2022 ~ # TZ=Europe/London date Mon Mar 21 12:08:36 GMT 2022 ~ # TZ=Etc/GMT+1 date Mon Mar 21 12:08:43 -00 2022 ~ # TZ=Etc/GMT+2 date Mon Mar 21 12:08:45 -00 2022 This is particularly severe for our devices since previous versions of our software only supported UTC offsets, and these are automatically updated to these GMT+xx and GMT-xx timezones on update, so many of our customers are expected to have these zones configured. We are running with "-r cutoff -b fat", where cutoff depends on the release date, and the embedded software currenlty is using GNU libc 2.20. Reverting 5f06f9a3182d2c2942be1b678e4defa9c7400653 fixes the issue for us, but is probably not the correct approach. -- \\// Peter - http://www.softwolves.pp.se/

3 6

Re: [tz] tz Digest, Vol 129, Issue 1
by Santoni Francis July 1, 2022

July 1, 2022

Hello for Iran and 1977 the effective change is only 20 october (UIT n°143 17.XI.1977) and not 23 september (UIT n°141 13.IX.1977) UIT is the Operational Bulletin of International Telecommunication Union Francis Santoni

3 2

[PROPOSED] Refactor by using max and min macros
by Paul Eggert July 1, 2022

July 1, 2022

* localtime.c (SMALLEST, BIGGEST): Remove. All uses replaced by min and max. * private.h (max, min): New macros. * zdump.c (main): * zic.c (growalloc, timerange_option): Prefer max and min to doing it by hand. --- localtime.c | 17 ++++++----------- private.h | 5 +++++ zdump.c | 2 +- zic.c | 6 +++--- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/localtime.c b/localtime.c index 8644aa6..3db7821 100644 --- a/localtime.c +++ b/localtime.c @@ -102,9 +102,6 @@ struct lsinfo { /* leap second information */ int_fast32_t ls_corr; /* correction to apply */ }; -#define SMALLEST(a, b) (((a) < (b)) ? (a) : (b)) -#define BIGGEST(a, b) (((a) > (b)) ? (a) : (b)) - /* This abbreviation means local time is unspecified. */ static char const UNSPEC[] = "-00"; @@ -112,7 +109,7 @@ static char const UNSPEC[] = "-00"; This needs to be at least 1 for null termination in case the input data isn't properly terminated, and it also needs to be big enough for ttunspecified to work without crashing. */ -enum { CHARS_EXTRA = BIGGEST(sizeof UNSPEC, 2) - 1 }; +enum { CHARS_EXTRA = max(sizeof UNSPEC, 2) - 1 }; #ifdef TZNAME_MAX #define MY_TZNAME_MAX TZNAME_MAX @@ -131,9 +128,8 @@ struct state { time_t ats[TZ_MAX_TIMES]; unsigned char types[TZ_MAX_TIMES]; struct ttinfo ttis[TZ_MAX_TYPES]; - char chars[BIGGEST(BIGGEST(TZ_MAX_CHARS + CHARS_EXTRA, - sizeof gmt), - (2 * (MY_TZNAME_MAX + 1)))]; + char chars[max(max(TZ_MAX_CHARS + CHARS_EXTRA, sizeof gmt), + 2 * (MY_TZNAME_MAX + 1))]; struct lsinfo lsis[TZ_MAX_LEAPS]; /* The time type to use for early times or if no transitions. @@ -394,8 +390,7 @@ union local_storage { } u; /* The file name to be opened. */ - char fullname[BIGGEST(sizeof(struct file_analysis), - sizeof tzdirslash + 1024)]; + char fullname[max(sizeof(struct file_analysis), sizeof tzdirslash + 1024)]; }; /* Load tz data from the file named NAME into *SP. Read extended @@ -2086,10 +2081,10 @@ time2sub(struct tm *const tmp, && (yourtm.TM_GMTOFF < 0 ? (-SECSPERDAY <= yourtm.TM_GMTOFF && (mytm.TM_GMTOFF <= - (SMALLEST(INT_FAST32_MAX, LONG_MAX) + (min(INT_FAST32_MAX, LONG_MAX) + yourtm.TM_GMTOFF))) : (yourtm.TM_GMTOFF <= SECSPERDAY - && ((BIGGEST(INT_FAST32_MIN, LONG_MIN) + && ((max(INT_FAST32_MIN, LONG_MIN) + yourtm.TM_GMTOFF) <= mytm.TM_GMTOFF)))) { /* MYTM matches YOURTM except with the wrong UT offset. diff --git a/private.h b/private.h index e8c0942..b083c1b 100644 --- a/private.h +++ b/private.h @@ -632,6 +632,11 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TYPE_SIGNED(type) (((type) -1) < 0) #define TWOS_COMPLEMENT(t) ((t) ~ (t) 0 < 0) +/* Minimum and maximum of two values. Use lower case to avoid + naming clashes with standard include files. */ +#define max(a, b) ((a) > (b) ? (a) : (b)) +#define min(a, b) ((a) < (b) ? (a) : (b)) + /* Max and min values of the integer type T, of which only the bottom B bits are used, and where the highest-order used bit is considered to be a sign bit if T is signed. */ diff --git a/zdump.c b/zdump.c index 8b6788a..b10f574 100644 --- a/zdump.c +++ b/zdump.c @@ -548,7 +548,7 @@ main(int argc, char *argv[]) for (i = optind; i < argc; i++) { size_t arglen = strlen(argv[i]); if (longest < arglen) - longest = arglen < INT_MAX ? arglen : INT_MAX; + longest = min(arglen, INT_MAX); } for (i = optind; i < argc; ++i) { diff --git a/zic.c b/zic.c index 436677f..c0ff561 100644 --- a/zic.c +++ b/zic.c @@ -488,7 +488,7 @@ growalloc(void *ptr, size_t itemsize, ptrdiff_t nitems, ptrdiff_t *nitems_alloc) return ptr; else { ptrdiff_t nitems_max = PTRDIFF_MAX - WORK_AROUND_QTBUG_53071; - ptrdiff_t amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; + ptrdiff_t amax = min(nitems_max, SIZE_MAX); if ((amax - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("integer overflow")); *nitems_alloc += (*nitems_alloc >> 1) + 1; @@ -707,8 +707,8 @@ timerange_option(char *timerange) } if (*hi_end || hi < lo || max_time < lo || hi < min_time) return false; - lo_time = lo < min_time ? min_time : lo; - hi_time = max_time < hi ? max_time : hi; + lo_time = max(lo, min_time); + hi_time = min(hi, max_time); return true; } -- 2.36.1

2 1

[PROPOSED] Upgrade GCC_DEBUG_FLAGS to GCC 12
by Paul Eggert June 30, 2022

June 30, 2022

* Makefile (GCC_DEBUG_FLAGS): Add -Wbidi-chars=any,ucn and -Wuse-after-free=3, from GCC 12. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 56c4404..cbf5b96 100644 --- a/Makefile +++ b/Makefile @@ -264,7 +264,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ $(GCC_INSTRUMENT) \ -Wall -Wextra \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ - -Wbad-function-cast -Wcast-align=strict -Wdate-time \ + -Wbad-function-cast -Wbidi-chars=any,ucn -Wcast-align=strict -Wdate-time \ -Wdeclaration-after-statement -Wdouble-promotion \ -Wduplicated-branches -Wduplicated-cond \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ @@ -278,7 +278,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ - -Wtrampolines -Wundef -Wuninitialized -Wunused-macros \ + -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ -Wno-type-limits -Wno-unused-parameter -- 2.36.1

1 0

Correct time zone name
by Danylo Moshenskyi June 28, 2022

June 28, 2022

Hello! It's the perfect time to change officially "Europe/Kiev" to "Europe/Kyiv". Please check this post, Ukrainians support and need it so much: https://www.linkedin.com/posts/activity-6945658723713355776-NKJm

3 3

Ukraine time zone error
by Євген Доманський June 27, 2022

June 27, 2022

Dear All It has been 19 170 days since IANA time zone database has an error for Ukraine time zone. Be brave to support Ukraine in the war against russia and correct the mistake as quickly as possible. Thank you *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

1 0

Re: [tz] Europe/Kiev update for 1992-1995
by Doug Ewell June 26, 2022

June 26, 2022

Євген Доманський wrote: > 'Kyiv' has been used word-wide as the only correct Latin spelling of > Ukrainian city since the V century. 'Kiev' was only used in soviet > union and russia for a relatively small period of time. > Here is a example of the book written in 1570 - see KYIV You accidentally attached a picture of a book written in Greek, in the Greek script. I'm sure you meant to attach one that had something to do with English and the Latin script. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

2 3

Error in Ukraine time zone
by Євген Доманський June 26, 2022

June 26, 2022

Dear All It has been 19 169 days since IANA time zone database has an error for Ukraine time zone. Be brave to support Ukraine in the war against russia and correct the mistake as quickly as possible. Thank you *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

1 0

Kyiv not Kiev error
by Євген Доманський June 24, 2022

June 24, 2022

Dear All There is an error in name of the capital city of Ukraine - Kiev ('Київ' in Ukrainian language). Kiev is the transliteration of the city name from Russian language. The only correct transliteration is Kyiv. Please update the name. Best regards. *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

11 26

Change Request: Europe/Kiev to Europe/Kyiv
by Oleksandr Leskiv June 23, 2022

June 23, 2022

The history of timezones has some existing cases where a specific timezone has been renamed. For example, the *Asia/Calcutta* timezone has been deemed obsolete and replaced by *Asia/Kolkata*. In Ukraine, according to international standards, there is a timezone called *Europe/Kiev*. The capital of Ukraine is officially and internationally should be spelled as "Kyiv". "Kiev" is an incorrect version that emerged a long time before the Soviet Union collapsed in 1991. We have a really large community of programmers that would like to start the process of renaming the Europe/Kiev timezone to Europe/Kyiv. We understand that it will take a long time for everybody to transition, but it has to be done in the long term. Sincerely, Oleksandr. TakeUsEat.

7 10

time zone boundaries contributing to higher traffic fatalities
by BASTIAN Michelle June 13, 2022

June 13, 2022

Hi all, I thought you might be interested in this recent paper on time zone boundaries and links with traffic fatalities - just published in Time & Society https://journals.sagepub.com/doi/full/10.1177/0961463X221104675 Living in the wrong time zone: Elevated risk of traffic fatalities in eccentric time localities Jeffery Gentry, Jayson Evaniuck, Thanchira Suriyamongkol, Ivana Mali Abstract Chronobiology research has uncovered a host of maladies linked to social jetlag (SJL), the sleep-disrupting disconnect between solar time and social time. This interdisciplinary study applies chronobiology theory to the potential effect of misaligned time zones on motor-vehicle deaths. In the U.S. 53 million residents live in counties located outside their official time zones' standard 15° span of longitude, based on degrees west of the prime meridian. We refer to these counties as eccentric time localities (ETLs), all of which lie west of their time zones' standard western border in the U.S. In contrast, counties within 7.5° of their time zone's standard geographic center are what we call solar zones. Solar zones do not vary more than 30 minutes from true solar time. ETL residents are forced to rise before dawn, possibly restricting their sleep-time and suppressing both morning and evening zeitgebers that would support their circadian entrainment. Hypothesizing that living in ETLs amplifies social jetlag, data on 417,399 traffic fatalities in the U.S. between 2006 and 2017 from the Fatality Analysis Reporting System (FARS) census were analyzed via GIS mapping and population-data statistics. Road fatalities among residents of solar zones were compared to those living in ETLs within the same official time zone. ETL residents across the U.S. indicated 21.8% higher fatality-rates than solar residents, with a mean of 1286 additional (i.e., unexpected) deaths-per-year. Results support circadian entrainment theory and are consistent with the SJL construct. The socio-political ramifications of these findings are discussed, as well as the subject of best practices when analyzing whole-population data. The authors conclude that the unquestioned rhetoric of time-zone boundaries should be reconsidered in social policy. Best, Michelle. --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh Mid-Career Fellow, Independent Social Research Foundation (Project info<https://www.isrf.org/fellows-projects/michelle-bastian/>) (2021-2022) Associate Professor II, Oslo School of Environmental Humanities, University of Oslo (2022-2024) Level 1, Room 303B, The Maltings | Minto House, 20-22 Chambers Street, Edinburgh, EH1 1JZ | 0131 651 5779 Work hours: I normally work 8am-4pm M-F. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

1 0

Invalid tm handling in %s pattern in strftime
by Almaz Mingaleev June 7, 2022

June 7, 2022

Hi Paul, https://github.com/eggert/tz/commit/8b238ec54c09556eb2aa405c1741eedfd12c4a8… added validation of tm argument. I wonder why localtime_r call is done: 1) According to the man page mktime sets errno if tm is invalid. Why is it not safe to just check errno value (saving and restoring it if needed)? 2) man page says that in error case mktime "returns (time_t) -1 and does not alter the members of the broken-down time structure". Wouldn't it be enough to check that tm.tm_yday is >= 0? Thanks, Almaz

4 11

Subject: Re: Change Turkey to Turkiye or not?
by nadir altinbas June 7, 2022

June 7, 2022

@ Topic 4. Re: Change Turkey to Turkiye or not? (Ian Abbott) i am resident in Istanbul, Istanbul is a city where a bridge of between Europe and Asia? most of the part of istanbul city is in Europe side. Telephony numbering coding system for PBX Europe is 0212 and Asia 0216 begins. Turkey -Turkiye- Turquie (Tr) name can be positined name as it Tr /Turkiye-Istanbul (Europe -Asia) ....... This is my idea. regards , nadir ALTINBAS nadiraltinbas(a)yahoo.com n.altinbas

1 0

Change Turkey to Turkiye or not?
by 柳芯宇 June 7, 2022

June 7, 2022

In some of the tz files, I found several mentions of "Turkey", this could be confusing since in my dictionaries, Turkey points to a food made by chicken, rather than a country. As recently UN and NATO suggests, I think it would be better and more representative to use Turkiye instead of Turkey, as we shound't setup times for just foods, right?

8 8

Re: [tz] Change Turkey to Turkiye or not?
by Doug Ewell June 6, 2022

June 6, 2022

柳芯宇 wrote: > In some of the tz files, I found several mentions of "Turkey", this > could be confusing since in my dictionaries, Turkey points to a food > made by chicken, rather than a country. I checked with a few turkeys (the bird) and they objected loudly to the notion that they are actually chickens. All joking aside: 1. The country has been known in English as "Turkey" for centuries, and although this has certainly given rise to some jokes, no one is genuinely confused when the word is used in context. 2. The identifier in the tz database which has by far the greatest visibility and relevance to users is "Europe/Istanbul", which avoids the issue altogether. 3. The rule name "Turkey" is comparatively invisible to most users, and there does not seem to be any mechanism for changing rule names, as there is for zone identifiers. 4. Any other mentions, such as in comments, can be changed freely, but there seems little point in doing so, at least at this time. > As recently UN and NATO suggests, I think it would be better and more > representative to use Turkiye instead of Turkey, as we shound't setup > times for just foods, right? "Turkiye" is not the name of the country in any language; the Turkish name is spelled "Türkiye" with diaeresis. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

3 3

Historical data for Iran
by Roozbeh Pournader June 6, 2022

June 6, 2022

Hi, The timezone database currently lists Iran switching to standard time in 1946. I've been doing some research on the history of the adoption of standard time by Iran, and while it's very hard to find much, I found that the correct date is actually 1935. Here's an order from the Cabinet to the rest of the government to switch to Tehran time, which is mentioned to be already at +03:30: https://qavanin.ir/Law/TreeText/180138 Just in case that goes away, I also saved a copy at archive.org: https://web.archive.org/web/20220530111940/https://qavanin.ir/Law/TreeText/… Here's my translation: "Circular on Matching the Hours of Governmental and Official Circles in Provinces Approved 1314/03/22 [=1935-06-13] According to the ruling of the Honorable Cabinet, it is ordered that from now on in all internal provinces of the country, governmental and official circles set their time to match Tehran time (three hours and half before Greenwich). It is required to mind the above order. For Minister of Judiciary, Dr Matin-Daftari" Now, I still haven't found out when Tehran itself switched to +03:30 (let's assume some time earlier in 1935), but it is clear that standard time in Iran started on 1935-06-13 and not 1946. Thanks, Roozbeh

4 7

Yet more historical data for Iran
by Roozbeh Pournader June 2, 2022

June 2, 2022

Yet another discovery, which clarifies what happened in 1977 and 1978 in Iran. This is from Kayhan newspaper, one of the major Iranian newspapers, from March 20, 1978, page 2: "Pull the clocks 60 minutes forward As we informed before, from the fourth day of the month Farvardin of the new year [=1978-03-24], clocks will be pulled forward, and people's daily work and life program will start one hour earlier than the current program. On the 1st day of the month Farvardin of this year [=1977-03-21], they had pulled the clocks forward by one hour, but in the month of Mehr [=1977-09-23], the clocks were pulled back by 30 minutes. In this way, from the 4th day of the month Farvardin, clocks will be ahead of the previous years by one hour and a half. According to the new program, during the night of 4th of Farvardin, when the midnight, meaning 24 o'clock is announced, the hands of the clock must be pulled forward by one hour and thus consider midnight 1 o'clock in the forenoon." This implies that in September 1977, when the daylight savings time was done with, Iran didn't go back to +03:30, but immediately to +04:00. I'm still trying to figure out when exactly did Iran go back from +4:00 to +03:30. I'll report back when I find it. Based on the time of true noon announced in newspapers of the time, I've triangulated it to some time between 1978-11-05 and 1979-01-15, but it looks like major Iranian newspapers were stopped from publishing during most of that time period, so I can't figure out more using this method. For now, two changes are needed in tzdata, first is the start of daylight saving in 1978, the other the switch to +4:00/+5:00, which is currently listed as Nov 1977, but should change to exactly the end of daylight saving time in 1977. Thanks again, Roozbeh

2 1

End date of daylight saving in Iran in 1978
by Roozbeh Pournader June 1, 2022

June 1, 2022

I just found the date daylight savings ended in Iran in 1978. This is from the major Iranian newspaper Ettela'at, dated 1968-08-03, page 32. It looks like they decided to get the clocks back to +4:00 just in time for Ramadan that year: "Tomorrow Night, Pull the Clocks Back by One Hour At 1 o'clock in the forenoon of Saturday 14 Mordad [=1978-08-05], the clocks will be pulled one hour back and instead of 1 o'clock in the forenoon, Radio Iran will announce 24 o'clock. This decision was made in the Cabinet of Ministers meeting of 25 Tir [=1978-07-16], [...] At the beginning of the year 2537 [=March 1978: Iran was using a different year number for a few years then, based on the Coronation of Cyrus the Great], the country's official time was pulled forward by one hour and now the official time is one hour and a half ahead compared to last year, because in Farvardin of last year [=March 1977], the official time was pulled forward one hour and this continued until the second half of last year [=September 1977] until in the second half of last year the official time was pulled back half an hour and that half hour still remains." This matches the time of the true noon published in the newspapers, as they clearly go from +05:00 to +04:00 after that date (which happened during a long weekend in Iran). This means tzdata needs to fix the end of daylight saving in Iran for 1978 from October 20 to August 5. Thanks again, Roozbeh

1 0

Wrong behaviour with truncated TZif files
by Almaz Mingaleev June 1, 2022

June 1, 2022

Hi Paul, I've built TZif files with following commands: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data # Truncate at 1 Jan 2100. ./zic -b fat -r "/@4102444800" -d ./data rearguard.zi make TZDIR="./data" all Then I've compiled attached file: g++ mktime_test.cpp localtime.o Test tries to find epoch timestamp for 2 Jul 1980 midnight at America/Los_Angeles. With a truncated TZif file it prints 331344000. With non-truncated one it prints 331372800. The latter is the right answer. Also, date command is wrong on certain time zones: make TZDIR="./data" date TZ=Antarctica/Palmer ./date -r -631152000 prints "Sat Dec 31 20:00:00 -04 1949" even though 1 Jan 1950 offset should be zero <https://github.com/eggert/tz/blob/df4699ddfc9caf6f875f1e38703dd0ef41826175/…> . Thanks, Almaz

2 7

More historical data for Iran
by Roozbeh Pournader June 1, 2022

June 1, 2022

Two more pieces of information about historical timezone changes in Iran, this time in the late 1970s: I just ran into an academic paper that looks into the psychology of daylight savings in Iran, and it has the exact times for the change in 1977 and the beginning of the change in 1979 (but not its end, unfortunately). https://www.jstor.org/stable/178704 Here's the quotes from the paper: 1. '"Iran's official time keeper moved the clock one hour forward as from March 22, 1977 (Farvardin 2, 2536) to make maximum use of daylight and save in energy consumption. Thus Iran joined such other countries as Britain in observing what is known as 'daylight saving.' The proposal was originally put forward by the Ministry of Energy, in no way having any influence on observing religious ceremonies. Moving time one hour forward in summer means that at 11:00 o'clock on March 21, the official time was set as midnight March 22. Then September 24 will actually begin one hour later than the end of September 23 [...]." Iran's time base thus continued to be Greenwich Mean Time plus three and one-half hours (plus four and one-half hours in summer).' The article sources this from Iran Almanac and Book of Facts, 1977, Tehran: Echo of Iran, which is on Google Books at https://www.google.com/books/edition/Iran_Almanac_and_Book_of_Facts/9ybVAAA…. (I confirmed it by searching for snippets.) 2. "After the fall of the shah, the revolutionary government returned to daylight-saving time (DST) on 26 May 1979." This seems to have been announced just one day in advance, on 25 May 1979. The change in 1977 clearly seems to be the first daylight savings effort in Iran. But the article doesn't mention what happened in 1978 (which was still during the shah's government), or how things continued in 1979 onwards (which was during the Islamic Republic). This data doesn't seem to match tzdata: First, an entry for 1977 needs to be added, for which we seem to have complete data. Second, the beginning of daylight saving time in 1979 needs to be changed to May 26. Thanks, Roozbeh

2 2

Re: [tz] Kiev -> Kyiv
by Doug Ewell May 31, 2022

May 31, 2022

Jacob Pratt wrote: >> I know you are all busy, but you made a mistake in the timezone name. >> Just want to make a request to change "Kiev" to "Kyiv". > > This change has already been made. People keep asking for this because the currently released version of the tz database (2022a) still has "Europe/Kiev". The fact that the change to "Europe/Kyiv" is in the GitHub development repo, and will eventually make its way to a released version, is not helpful to these people. They want to see it in a release. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

2 1

Kiev -> Kyiv
by Roman Dmytriv May 30, 2022

May 30, 2022

Hello IANA team! "After Ukraine's 1991 independence, the Ukrainian government introduced the national rules for transliteration of geographic names <https://en.wikipedia.org/wiki/Romanization_of_Ukrainian> into the Latin alphabet for legislative and official acts in October 1995,[23] <https://en.wikipedia.org/wiki/Name_of_Kyiv#cite_note-:1-23> according to which the Ukrainian name Київ is romanized <https://en.wikipedia.org/wiki/Romanization> as *Kyiv*. These rules are applied for place names and addresses, as well as personal names in passports, street signs, and so on." I know you are all busy, but you made a mistake in the timezone name. Just want to make a request to change "Kiev" to "Kyiv". I will be grateful for the answer. Thank you! Best regards, Roman Dmytriv tel: +380633709302

2 2

Change some timezone names
by gusak ivanov May 27, 2022

May 27, 2022

Good evening! I’ve read some great news, that you are finally changing Europe/Kiev to Europe/Kyiv. Can other Ukrainian timezones get the same treatment, and so get Europe/Uzhgorod to be changed to Europe/Uzhhorod and Europe/Zaporozhye to Europe/Zaporizhzhia? All according to the officially recognized UNGEGN World Geographical Names. Thanks

7 8

Duplicated shell commands on the tz-link.html IANA page
by Max Nikulin May 25, 2022

May 25, 2022

Hi, Some time ago I have noticed that shell commands are duplicated in the "Downloading the tz database" section on the following page https://data.iana.org/time-zones/tz-link.html#download > mkdir tzdb > cd tzdb > wget https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz > wget https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz > gzip -dc tzcode-latest.tar.gz | tar -xf - > gzip -dc tzdata-latest.tar.gz | tar -xf - I think it is better to remove some commands.

2 2

Unexpected last transition in Africa/Casablanca
by Almaz Mingaleev May 19, 2022

May 19, 2022

Hi Paul, Here are the last transitions in Africa/Casablanca output (rearguard format): transition,type,[UTC time],[Type offset],[Type isDST] 3672612000,1,2086-05-19T02:00:00Z,PT1H,DST 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD So change is from standard to standard, even though offset changes from 0h to 1h. Is that expected behaviour? As Africa/El_Aaiun is using Morocco rules, its transitions are also affected. This affects 64-bit section only, 32-bit section looks fine to me. Thanks, Almaz Data above is output of debug tools used in Android. The way I've built data an byte manipulations if needed: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data ./zic -b fat -d ./data rearguard.zi byte manipulations: Let's skip 32-bit header: xxd -seek 20 -c 4 -l 24 data/Africa/Casablanca typecnt: 94 timecnt: 5 charcnt: 12 32-bit block size = 94 * 4 + 94 + 5 * 6 + 12 = 512 64-bit start = 44 + 512 = 556 64-bit header: xxd -seek 576 -c 4 -l 24 data/Africa/Casablanca: timecnt: 196 typecnt: 4 <- 32-bit section has 5 charcnt: 12 transition types offset: 556 + 44 + 196 * 8 = 2168 xxd -seek 2168 -c 1 -l 196 data/Africa/Casablanca ... 00000934: 02 . 00000935: 01 . 00000936: 02 . 00000937: 01 . 00000938: 02 . 00000939: 01 . 0000093a: 02 . 0000093b: 03 . <- the last transition local time records offset = 556 + 44 + 196 * 9 = 2364 xxd -seek 2364 -c 6 -l 24 data/Africa/Casablanca 0000093c: ffff f8e4 0000 ...... 00000942: 0000 0e10 0104 ...... 00000948: 0000 0000 0008 ...... <- standard time 0000094e: 0000 0e10 0004 ...... <- also standard time

6 13

Change IANA time zone identifier for Kyiv to Europe/Kyiv.
by Luda Melnykova May 19, 2022

May 19, 2022

Hello, Hope this email finds you well. I would like to raise a request for a value change in TZ DB. I believe, that current IANA time zone identifier for Kyiv (Europe/K*ie*v) is not fully correct. Background of this request lies in a transliteration of a city name. *Kyiv* is derived from the Ukrainian language name Київ, while *Kiev* is derived from the Russian language name Киев) as the name of the Ukrainian capital. Kyiv is already in use in international lists for IATA, ICAO and other organizations, which follow the decision of the U.S. Board on Geographic Names. Kyiv, as a name of Ukrainian capital, is also mentioned on time.is site Kyiv: 19:42 (time.is) <https://time.is/Kyiv>. So, I believe, it is fully logical to follow latest guidelines and rename IANA time zone identifier as well. If you are interested to learn more about it, please check out this wiki article: KyivNotKiev - Wikipedia <https://en.wikipedia.org/wiki/KyivNotKiev> Please let me know if any questions or concerns. Many thanks. Regards, Liudmyla

2 1

Time in Russian occupied Ukraine
by alois＠astro.ch May 14, 2022

May 14, 2022

Does anyone know which time zone is used in the "separatist" or Russian occupied areas of eastern Ukraine? Or in the areas temporarily occupied during Russian invasion in the north of Kiev, from which Russia has withdrawn again? Until 27 March 2022, Ukraine was on 2h east, while western Russia was on 3h east (Europe/Moscow), like Crimea (Europe/Simferopol). Now since the begin of DST they have the same time offset.

2 2

2021e Asia/Dushanbe
by Nick Deguillaume May 14, 2022

May 14, 2022

Hello, I am currently developing a C++ time-zone database parser, building on top of Howard Hinnant's work. I am writing thorough checks. One Zone check that I am experimenting with is: *If the FORMAT field contains either a "%s" or a '/' then the RULES field must contain a named rule.* However line 3840 of the asia file in: https://data.iana.org/time-zones/releases/tzdata2021e.tar.gz fails this check, as highlighted in yellow in the table below. # Tajikistan # From Shanks & Pottenger. # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Dushanbe 04:35:12 - LMT 1924 May 2 5:00 - +05 1930 Jun 21 6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s 5:00 1:00 +05/+06 1991 Sep 9 2:00s 05:00 - +05 My guess is that '+05/+06' should be '+05'. I may well be wrong. Could you let me know either way? If you are interested, I have found a few other bits and pieces where the data files are in slight variance with the documentation but are not show-stoppers. Most of these occur in the very early releases. (I am testing every database available on https://data.iana.org/time-zones/releases/) Regards Nick Deguillaume +44 75 2828 6473

3 7

Changes to timezone names
by Ростислав Салабай May 12, 2022

May 12, 2022

Good morning! Since Kyiv became an official spelling of the capital of Ukraine, few years have passed. And people more and more use the new spelling, instead of Kiev. That includes large and small news sites, posts of politicians and most social media feeds (seeing Kiev right now is much more rare than Kyiv). Even Wikipedia and Oxford English Dictionary have changed their spellings to Kyiv too, and large companies like Apple follow along. And actually, using Kiev causes more inconvenience for some people than Kyiv, in things that use tz database, as many are unable to find the right timezone (and this isn't something made up, I've seen lots of complains in forums and GitHub issue requests that Kyiv is missing or spelled wrong). Also, the outgoing war in Ukraine has sped up that process of switching Ukraine to Ukrainian-based things, and not Russian ones. So, in my opinion, it's the perfect time to finally ditch Kiev for good, and start using Kyiv (and so the Europe/Kyiv timezone) as the only name for that beautiful city. Rostyslav

2 1

Updates on Iranian Time Zone (IRDT)
by Mohammad Ali Tofighi May 11, 2022

May 11, 2022

Hi. Recently the Iranian parliament has decided to remove daylight saving from the Iranian time zone, eliminating the one-hour shift in the summer time. Hence, it is always going to be UTC+3:30. *This is not their final decision yet* and there is a final confirmation to be made, but I just wanted to inform you about the update to prepare possible modifications. I'm a software engineer and if we have the update on *tzdata* package as soon as possible, the software companies can adjust themselves accordingly. Please read these official news: https://www.isna.ir/news/1400122419045/ https://www.yjc.news/00Xw0k Regards, Ali Tofighi

6 13

Request to provide .tar.gz tarballs for tzdb
by Kim Davies May 6, 2022

May 6, 2022

Dear colleagues, We’ve been asked by this correspondent to forward this request on to this list. In response to the original request we explained the lzip distribution is largely an amalgam of the gzip distributions, and they indicated they still wanted gzip to be considered specifically to increase “availability for low end systems as lzip isn’t that widely supported”: Subject: Provide .tar.gz tarballs for tzdb Date: Mon, 2 May 2022 13:23:15 +0300 From: "Firas Khalil Khana" <firasuke(a)gmail.com> To: iana(a)iana.org Hey there, I've come to notice that both tzcode and tzdata have .tar.gz tarballs but tzdb only has .tar.lz (lzip) tarballs which isn't a commonly used format. Would it be possible to provide gzipped tarballs for tzdb as well? Thanks! -- Kim Davies VP, IANA Services, ICANN President, PTI

5 5

Changes to the tz database
by Shlomi Sasson May 1, 2022

May 1, 2022

hi, i opened this PR <https://github.com/rogierschouten/tzdata-generate/pull/11> on GitHub and I've been told I need to contact you, and specifically Paul Eggert, to fix it. The fix should replace the Ukrainian city Kiev with the official name Kyiv, put Kiev in the legacy zone and add Kyiv to a new zone (per Rogier Schouten <https://github.com/rogierschouten>) Can u pls help me fix that? -- Shlomi Sasson Engineering Group Manager, Bringg +972-52-4440986

3 4

Prague Astronomical Clock simulation
by Kerry Shetline April 21, 2022

April 21, 2022

While not precisely a timezone topic, I thought a simulation of the Prague Astronomical Clock might be of interest to the readers of this mailing list. I stumbled into this topic a few months ago and I find it fascinating. There aren't too many pieces of machinery that are over 600 years old and still running. Now, of course, it's not still all the original equipment in place today, and there has been a lot of downtime over the centuries as interest waxed and waned over keeping the clock running. Major components of the original clock, however, are still in service today. Having looked at other old astronomical clocks, the one in Prague, in my opinion, beats them all. For something first operational in 1410, it's a very ambitious and clever design that puts a lot of information into view all at once, in an attractive and compelling way: two different ways of counting the hours of the day, phases of the moon, position of the moon and the sun in the sky, sun rise and set times, and sidereal time. One of the things I discovered was Jan Tošovský's simulation of clock, which had some attractive SVG graphics, but a user interface that's a bit out of date and clunky by modern UI standards. I used his graphics as a starting point for my own simulation, which can now be found at https://orloj.org/orloj/. I received a lot of help and advice from Petr Král, the current "clock master", and founder of the Czech Horological Society, about the real, physical clock, its operation and history -- not to mention that he helped make sure my translation to Czech wasn't too far out of whack. By the way, if anyone takes a look at the site who speaks Spanish, French, or German, I'd love to hear about any suggestions for improved translations you might have. I used to do a lot of work in the past to make sure code was internationalizable, but this is my first multi-language Angular web application.

1 0

some problems with tzdata for Simferopol
by Michael H Deckers April 18, 2022

April 18, 2022

In version 2022a of the file "europe", we read for Simferopol: # The _Economist_ (1994-05-28, p 45) reports that central Crimea switched # from Kiev to Moscow time sometime after the January 1994 elections. # Shanks (1999) says "date of change uncertain", but implies that it happened # sometime between the 1994 DST switches. Shanks & Pottenger simply say # 1994-09-25 03:00, but that can't be right. For now, guess it # changed in May. 2:00 C-Eur EE%sT 1994 May # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. 3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s # IATA SSIM (1997-09) says Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. 3:00 Russia MSK/MSD 1997 3:00 - MSK 1997 Mar lastSun 1:00u • The quoted text is inconsistent: The comment says that Simferopol uses Moscow time since 1994 May, but the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" contradicts it (Moscow had other switching times between summer and winter times). Which is correct? • It is not clear what "IATA SSIM (1994/1997)" actually says. They probably do not specify the switching times expressed with the Zone line "3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s" or do they? • The Zone line "3:00 Russia MSK/MSD 1997" is redundant. Michael Deckers.

2 1

No permanent Maryland DST
by Arthur David Olson April 12, 2022

April 12, 2022

This year's regular session of Maryland's state legislature has ended. House Bill 126, establishing permanent Daylight Saving time (with contingencies) had been approved by the House of Delegates on a 108-24 vote; it was not approved by the Senate. We'll see what (if anything) happens at the national level. @dashdashado

1 0

Re: [tz] Wrong name of timezone
by Pierpaolo Bernardi April 11, 2022

April 11, 2022

Il giorno 25 ottobre 2021, alle ore 16:58, Igor Melnyk via tz <tz(a)iana.org> ha scritto: >But Ukraine has the Ukrainian language and Kiev is in russian language. The correct name of the capital city of Ukraine is Kyiv. Kiev is English language, as every other name in the db, not russian. It is only a coincidence that the English name is more similar to russian than to Ukrainian.

6 5

Timekeeping videos
by Tim Parenti April 5, 2022

April 5, 2022

A pair of time-related videos in my recommendations today, Monday 2022-04-04: At 16:00 BST (+01), Tom Scott published a video called "How does Britain know what time it is?" about the radio time broadcasts from the UK's National Physical Laboratory, which disseminates UTC(NPL). https://www.youtube.com/watch?v=yqciKS_N0K8 Typical of his attention to detail, the wall clock Tom holds continues to tick true to time throughout the entire video, even as it cuts away to interview shots and B-roll. A couple hours later, at 18:00 BST, the British comedy panel quiz show "QI" published a clip of their episode "Rude", originally aired 2020-05-28, in which the panel discusses, among other things, how Denmark hasn't updated its laws to officially use UTC instead of Mean Solar Time. https://www.youtube.com/watch?v=jRMD9LRmRA4 -- Tim Parenti

1 0

[Confirmation] America/Punta_Arenas will keep UTC -3 "indefinitely"
by Juan Correa April 3, 2022

April 3, 2022

Hello everyone: As almost all Continenal Chile just jumped back to UTC -4; I found there was a decree published last Thursday that will keep Magallanes region to UTC -3 "indefinitely" The decree is available at https://www.diariooficial.interior.gob.cl/publicaciones/2022/03/31/43217-B/… ; and it's a modification of Decreto 1286/2018 Its only paragraph say: "Nevertheless the aforementioned, the change of the Chile Continental Official time for Magallanes and Antártica Chile region will be extended indefinitely; and will be permanently set to GMT (sic) -3" -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

2 1

zone file format very strict
by Alois Treindl April 1, 2022

April 1, 2022

Hi I noticed that the last line of a zone file like # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Kabul 4:36:48 - LMT 1890 4:00 - +04 1945 4:30 - +0430 does not suffer a trailing TAB character, behind the +0430 I think the zone file compiling mechanism could be a bit more tolerant of trailing white space. The issue came about because I employ a zone file generator utility, which accidentally created such trailing tabs in some cases. I fixed my generator, but wanted to mention this anyway.

2 2

TZDB talk tomorrow at LibrePlanet 2022
by Paul Eggert April 1, 2022

April 1, 2022

Tomorrow, March 19, at 21:15–22:00 UTC (17:15–18:00 US Eastern time) I plan to deliver a talk "TZDB and some challenges of long data" at the all-online LibrePlanet 2022 conference. LibrePlanet is a conference about software freedom, happening on March 19–20, 2022. The event is hosted by the Free Software Foundation, and brings together software developers, law and policy experts, activists, students, and computer users to learn skills, celebrate free software accomplishments, and face upcoming challenges. Newcomers are welcome, and LibrePlanet 2022 will feature programming for all ages and experience levels. You can register for the conference in advance at <https://my.fsf.org/civicrm/event/info?reset=1&id=99>.

6 6

Some typo fixes
by Sascha Wildner March 31, 2022

March 31, 2022

Hi, please consider the attached patch which fixes three of typos in the tz files. Best regards Sascha Wildner

3 3

indentation in localtime.c
by Roland Illig March 31, 2022

March 31, 2022

Hi, I had a look at tzcode/localtime.c today, and the indentation looks like a mess. It's a wild mixture between 2 spaces, 4 spaces, 1 tab, 2 tabs, and I couldn't see any pattern or reasonable rule set that would account for the whole file. Is this apparent mess intentional? If so, what is the history and rationale behind it? If not, who can fix this? Roland

5 4

Regarding time zone changes in Chile
by Juan Correa March 31, 2022

March 31, 2022

Hello everyone: A few days ago, I've seen some mails regarding time zone changes, specially regarding Punta Arenas. I found https://www.horaoficial.cl/historia_hora.php ; a page (with a terrible slider) with more details regarding time zones in Chile What comes for bringing this page is for 2 points, brought by Alois Treindl a few weeks ago: - From January 10, 1910, the Official Time Zone for all of Chile was set to GMT -5. I've got to check through the exact wording, but it's important to keep track that legally, all Chile has an uniform common time zone (that, obviously, started to change from 1916). - On August 22, 1927, DST was established as "hora oficial de invierno" and "hora oficial de verano"; jumping from a relative time zone from Lo Espejo observatory (-4:42:46) to UTC -5 during winter (and GMT -4 during summer). As there's a decree establishing that, I will request it to share; but using the same principle, the time zone for all of Chile was standardized using those 2 time zones (until further notice) In other matters, I've repeatedly contacted the Ministry of Energy (as Tim could see ;) ) by Twitter, through their Information Office and now by telephone, regarding America/Punta_Arenas this saturday. What they just told me is they have to check the interpretation of the decree (…), as it says "permanently", but seems everyone skipped the date before that word. I've also checked Diario Oficial (our legislation gazette) from March 1; and there is no decree yet. I will try other ways to get as soon as possible that information. However, vox populi, everyone is assuming Punta Arenas (and Magallanes) will keep UTC -3; so I think it was a sensible assumption back in the day -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

1 0

America/Dawson_Creek
by Michael Ewert March 28, 2022

March 28, 2022

Hello. TZ is a great database for all the different clocks in the world, and their changes. Thank-you for researching and maintaining such a great resource. America/Dawson_Creek has coordinates listed as +5946-12014, however I believe that the intended coordinates are +5546-12014. Thank-you for your work keeping the world ticking. Michael Ewert

2 1

Time zone in the news
by Arthur David Olson March 27, 2022

March 27, 2022

'Autocorrect in @washingtonpost <https://twitter.com/washingtonpost/>: "Gare de l'Est" becomes "Gare de l'Eastern time." Article by @Claremch <https://twitter.com/Claremch/>, "How Russian emigres scratched out a living once they lost their world of riches." Also an editing lapse of course, and no, I couldn't find this article online.' https://twitter.com/Seth4MC/status/1508059818598219777 (Not-so-fun fact: in one round of C language standardization, it took months of repeated effort to get "time zone name" changed to "time zone name or abbreviation.") @dashdashado

2 1

Maryland permanent DST hearing
by Arthur David Olson March 24, 2022

March 24, 2022

A Maryland State Senate committee hearing covering (among other things) a Maryland-specific permanent Daylight Saving Time bill is set to begin at 1:00 USEDT. The link... https://www.youtube.com/channel/UCYqghFoT_BDQ0N5xjvTacgg/videos ...will get you to the Youtube channel where the hearing should be viewable. @dashdashado

2 2

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by heba.hamad＠mtit.gov.ps March 24, 2022

March 24, 2022

Dear Sir, kindly find the attachment below that includes the response of your comments about the first part of Palestines specification Time Zone BR,في الاثنين, يناير 24, 2022 05:15 EST, "Clive D.W. Feather" <clive(a)davros.org> كتب: Heba Hamad via tz said: > Dear Sir, > > Hope this email finds you well and wishing you a joyful new year . > We would like to inform you that The State of Palestine has adopted the > first part of the specification for its time zone. > Kindly refer to the attachment below, which includes the specification > and please provide me with any comments or notes you have regarding > this specification. > Ps: Please provide me with any comments you have. > Sincerely Yours, > > Eng.Heba Hamad Dear Mr Hamad, My apologies for the length of time this reply has taken, but here are some comments on your document. Page 6 item 2: the second paragraph looks more like a definition of local time than of UTC. Compare with item 6 on the next page. Page 7 item 7: while this is the commonest form of "daylight saving time" or "summer time", as it is usually known in Europe, it is not the only possibility: * Some countries have two switches forward and two back per year, for example to move back to standard time for Ramadan then forward for the rest of the summer. * At least historically, some places have had two forward shifts at different points in spring and then two backwards shifts at different point in the autumn. * Not all shifts are an hour: Lord Howe Island in Australia has a shift of 30 minutes forward in the summer. * At least one country defines "standard time" as being the time in the summer, with a shift back to "winter time" in autumn and then forward to standard time in spring. * There is at least one historical record where an area put the clocks forward in winter because of an unusual geography. You might at least want to delete the words "one hour from standard time". Page 8: note 1 to entry contradicts the definitions. Item 6 on page 7 implies that "standard time" is a fixed offset from UTC whereas this implies it isn't. Page 9 item 1: the range of dates under consideration affects time zones. The IANA database normally only looks at the situation from 1970 onwards. Picking other starting dates will affect which time zones exist because places differed in time before 1970 but not after it. This is why the IANA database has both Asia/Gaza and Asia/Hebron. Page 9 item 4: this is a description of the IANA TZ database. It is possible for other TZ databases to exist and they might not match that defintion. Also note that updates can be for changes made other than by political bodies (the IANA TZ database works on what actually happens on the ground, not what politicians say what happens). Page 10 item 5: "Government is expected to select these names alone" is, I'm afraid, false. Each database owner selects these names. The IANA database normally uses names of the form "continent/city" or "continent/region/city", but another database might use simple numbers or randomly allocated four-letter strings instead. Page 10 item 6: the description doesn't bear any relationship to the Palestinian Government. Page 11 first line: is the text beginning "This specification" meant to be the start of a new item? It doesn't seem to have anything to do with "Observance". Page 11 item 1: I'm not clear what the purpose of this item is. Page 11 item 2: the first paragraph describes the IANA TZ database rules and other TZ databases may differ. The last sentence of the second paragraph is not true, I'm afraid, since each TZ author can pick their own values and accept registrations or other information from anyone. I suspect you may have got your concepts confused. May I please suggest alternative wording? ==== BEGIN ==== The Structure: 1. Palestine Time Zone Palestine will use a single time zone. The State of Palestine is the Palestine Time Zone owner. It has the sole right to determine: - the UTC offset for the zone - the rules for changing this offset at different times of the year - the names and abbreviations used for the time in Palestine in official Palestinian documents. Note: before 2013 Palestine had two time zones using the meaning under "Fundamental Principles". Therefore some distributions may continue to use two time zones in order to represent pre-2013 data. 2. Names and abbreviations Palestine will use the terms and abbreviations "Palestine Standard Time (PSST)" for the time in Palestine during standard time and "Palestine Daylight Time (PSDT)" for the time in Palestine during Daylight Savings. ==== END ==== Legal clause: you of course have the right to determine the name used in official Palestinian documents and the official time used in Palestine. But you cannot determine the name of the time zone in any given database because that's decided by the database owner. Note, here, the difference between your official names (e.g. "PSST"), which you ahve the exclusive right to decide, and names used by others (e.g. "Asia/Gaza" or "A261"), which you don't. Yours sincerely, Clive D.W. Feather -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

2 1

Re: [tz] Unexpected last transition in Africa/Casablanca
by Kerry Shetline March 23, 2022

March 23, 2022

This image might make the issue clearer: https://i.imgur.com/6PFLDeWh.png What happened is that what used to be called DST is now considered the standard time for this timezone, and what used to be standard time is now *negative* DST. > Here are the last transitions in Africa/Casablanca output (rearguard > format): > > transition,type,[UTC time],[Type offset],[Type isDST] > 3672612000,1,2086-05-19T02:00:00Z,PT1H,DST > 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD > 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD > > So change is from standard to standard, even though offset changes from 0h > to 1h. Is that expected behaviour?

2 1

zic man page vs RFC8536
by Almaz Mingaleev March 22, 2022

March 22, 2022

Man page says that AT can be "260:00" [1]. Though in the RFC hour part in the footer is in [-167, 167] range [2]. Is man page information correct / safe to use? Thanks, Almaz [1] https://github.com/eggert/tz/blob/64c5d196f739b7662497b0986d4d94c418a3fd85/… [2] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1

2 1

Announcing global-tz - 2022ag (beta)
by Stephen Colebourne March 21, 2022

March 21, 2022

As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute). As previously discussed, and given the unwillingness of the tz-coordinator to alter his opinion in any way, it is unfortunately the case that a fork of tzdb is required. I have created such a fork, one that is intended to be as directly derivable from iana-tz as possible so that iana-tz itself can still be the golden source for the raw data. https://github.com/JodaOrg/global-tz The basic rules guiding the data that global-tz includes are: * An identifier for each region of the world where clocks have differed since 1970-01-01. * At least one identifier for each inhabited ISO 3166-1 code. * For these identifiers the data returned shall be the best available, including pre-1970 history. The first release of the fork is 2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections. https://github.com/JodaOrg/global-tz/releases/tag/2022ag-beta1 The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*. A GitHub Action script runs a few times a day that reads the iana-tz repo and runs a script that moves data from backzone to the appropriate main file. The result is an iana-tz compatible source code repo: Output tzdb source files: https://github.com/JodaOrg/global-tz/tree/global-tz Comparison between iana-tz and global-tz: https://github.com/JodaOrg/global-tz/compare/iana-tz...global-tz Genaration script: https://github.com/JodaOrg/global-tz/blob/main/actions.txt https://github.com/JodaOrg/global-tz/blob/main/GlobalTzMain.java The only maintenance that the fork should need is if iana-tz removes further pre-1970 history. Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward. Please can I ask anyone that is interested to test out the 2022ag-beta1 release before I make it final. PRs / Issues are welcome, provided they relate to aspects under the control of global-tz. thanks Stephen

7 13

Re: [tz] Review incorrect man-pages commit
by Alejandro Colomar (man-pages) March 20, 2022

March 20, 2022

Hi, Branden! On 3/20/22 11:52, G. Branden Robinson wrote: > > Sure! The punctuation does get a bit bewildering. > [...] Thanks for the great explanation! > > Now, for the part people actually care about, which is how to fix it: > take the escape character off of that `. > > You thus want > > +to "\fI[a\('a\(`a\(:a\(^a]\fP", that is, I applied a patch with this. > > If you wanted to write this without using any aliases, you could adopt > groff syntax. > > +to "\fI[a\[a aa]\[a ga]\[a ad]\[a a^]\fP", that is, I'm going to hold this for later, so that we decide globally how to format all pages, and not just this one. I prefer global consistency here. > > I don't know if people regard that as more or less impenetrable. It is > more _flexible_, and admits usage of diacritics/combining characters not > envisioned by AT&T troff or ISO Latin-1. groff supports a baker's > dozen. They are in a table titled "Accents" in groff_char(7) (1.22.4). > >> diff --git a/man8/zic.8 b/man8/zic.8 >> index 940d6e814..aeca0e726 100644 >> --- a/man8/zic.8 >> +++ b/man8/zic.8 >> @@ -293,7 +293,7 @@ nor >> .q + . >> To allow for future extensions, >> an unquoted name should not contain characters from the set >> -.q !$%&'()*,/:;<=>?@[\e]^`{|}\(ti . >> +.q !$%&'()*,/:;<=>?@[\e]^\`{|}\(ti . > > You didn't proffer any complaints about the foregoing, so I assume it > was just for context (to include the whole commit, maybe). Yep > Nevertheless I think it can be further improved. > > That neutral apostrophe and caret/circumflex should be changed as well, > to ensure that they don't render as a directional closing (right) single > quote, ’ U+2019 and modifier letter circumflex ˆ U+02C6. This advice is > also in groff 1.22.4's groff_man(7) page. > > +.q !$%&\(aq()*,/:;<=>?@[\e]\(ha\`{|}\(ti . > > Moreover, as partly noted in our discussion about double quotes in macro > arguments, there were no special characters for the double quote or > neutral apostrophe in Unix troff. Since we're not getting 50 years of > backward compatibility anyway, for the Linux man-pages project I > recommend going ahead and using groff-style escape sequences for these. > > +.q !$%&\[aq]()*,/:;<=>?@[\[rs]]\[ha]\`{|}\[ti] . > > Are you willing to settle for 30 years of backward compatibility? ;-) I do :) However, I'm not going to fix this page, according to MAINTAINER_NOTES: $ cat MAINTAINER_NOTES Externally generated pages ========================== A few pages come from external sources. Fixes to the pages should really go to the upstream source. tzfile(5), zdump(8), and zic(8) come from the tz project (https://www.iana.org/time-zones) bpf-helpers(7) is autogenerated from the kernel sources using scripts. See man-pages commit 53666f6c30451cde022f65d35a8d448f5a7132ba for details. So now I wonder why this commit was written in the first place, since it breaks one page, and fixes another that shouldn't be fixed. I CCd the tz mailing list in case they want to fix the upstream page (which I couldn't find, BTW). > > In my opinion it is more helpful in dense contexts like this to have the > paired delimiters [ ] to demarcate the glyph identifier then to achieve > portability to systems that don't support identifiers you need anyway. Yes, I agree with that. > > (I note that `q` is a page-local macro and therefore bad style for > portability reasons. That said, I have been _sorely_ tempted to add a > `Q` macro for this precise purpose to groff man(7). I have hopes that > it would give people something to reach for besides bold and italics for > every damn thing.) > > Most--I hope all--of the above is discussed comprehensively in the > current version of groff_char(7)[2], which I have rewritten completely > since groff 1.22.4 and substantially modified even since the last Linux > man-pages snapshot at > <https://man7.org/linux/man-pages/man7/groff_char.7.html>. I now know > the answers to many questions of the form "why the **** is {groff,troff} > this way?", and have endeavored to share them. The "History" section is > completely new. > > Regards, > Branden > > [1] groff's own man pages are not without sin in this regard. I have > cleaned them up a lot since 1.22.4, but a few adventurous stragglers > remain that define and use page-local macros pervasively. All are > on the long side. > > [2] https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_char.7.man > > I recommend that for source perusal only; do not try to render it > with man-db man(1) or groff 1.22.4, because groff 1.23.0 will be > adding a new macro, `MR`, for man page cross references[3] and its > own pages have already been ported to use it. (This is where I > flagellate myself for not having a groff 1.23.0-rc2 out yet. :( ) > > [3] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n165 I like your references usually containing other references themselves. It's funny :-) Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/

1 0

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson March 18, 2022

March 18, 2022

I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > Thanks for bringing that to the mailing list (if I could shut off GitHub > pull requests I would). Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. https://github.com/eggert/tz/pulls?q=kiev Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. -- jhawk(a)alum.mit.edu John Hawkinson

10 13

Unfortunate time zone names in the United States
by John Levine March 18, 2022

March 18, 2022

Here's the soon to be screwed up definition of US time zones. 15 USC 261 says For the purpose of establishing the standard time of the United States, the territory of the United States shall be divided into nine zones in the manner provided in this section. Except as provided in section 260a(a) of this title, the standard time of the first zone shall be Coordinated Universal Time retarded by 4 hours; that of the second zone retarded by 5 hours; that of the third zone retarded by 6 hours; that of the fourth zone retarded by 7 hours; that of the fifth zone retarded 8 hours; that of the sixth zone retarded by 9 hours; that of the seventh zone retarded by 10 hours; that of the eighth zone retarded by 11 hours; and that of the ninth zone shall be Coordinated Universal Time advanced by 10 hours. 15 USC 263 says: The standard time of the first zone shall be known and designated as Atlantic standard time; that of the second zone shall be known and designated as eastern standard time; that of the third zone shall be known and designated as central standard time; that of the fourth zone shall be known and designated as mountain standard time; that of the fifth zone shall be known and designated as Pacific standard time; that of the sixth zone shall be known and designated as Alaska standard time; that of the seventh zone shall be known and designated as Hawaii-Aleutian standard time; that of the eighth zone shall be known and designated as Samoa standard time; and that of the ninth zone shall be known as Chamorro standard time. Section 260a currently has the daylight saving rule, advance in March, fall back in November. The bill passed by the Senate deletes 260a, and updates 261 to change each of the numbers by an hour, 4 changes to 3, 5 to 4, and so forth 11 changes to 10 and the final 10 changes to 11. But it does *not* change section 263. This means that the official US names of the time zones change, which is really stupid. Since Hawaii, Samoa, and Guam do not use daylight time, Hawaii will now be in Alaska standard time, Samoa in Hawaii-Aleutian standard time, and Guam in a time zone with no name. I hope the House will fix this if they take up the bill, but I wouldn't make any changes to my time zone files yet. With respect to Canada, history shows that their timezones follow the US so if the US make a change like this, a bill in Ottawa will change Canada to match. There are currently places where you change time when you cross the border, like between Maine and New Brunswick, but it would be too painful for Montreal and Toronto and Windsor not to match New York and Detroit, and Vancouver not to match Seattle. R's, John

8 12

permanent DST and North American time zone names
by Chris Walton March 18, 2022

March 18, 2022

Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database. I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do. For this database I can envision four options moving forward: *Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04) *Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04) *Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04) *Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03) Did I miss anything? -chris

13 17

Iran DST change cancelled and step to avoid DST changing in their Linux system
by S Sathish S March 18, 2022

March 18, 2022

Hi Team, Customer running with Asia/Tehran (+0330, +0330) timezone, where Daylight saying is cancelled by their Iran government recently. Our Operator are requesting to avoid DST changing in their Linux system and expect tzdata patch from IANA (or) if possible any workaround to avoid this DST change in their systems. Thanks and Regards, S Sathish S

3 4

tzData Update for Iran DST
by Jahar Tyagi March 17, 2022

March 17, 2022

Hi, Recently learned that Iran has decided to stop DST changes that was about to be applied on 22nd March 2022. 2022a tzData is already released on 15th March 2022 and Iran (Asia/Tehran) DST changes are not part of this release. I want to ask what is the plan to include (Asia/Tehran) changes in tzData? Regards, Jahar Tyagi

2 2

Daylight saving in Iran changed
by Shahab Ouraie March 17, 2022

March 17, 2022

Hello. As new rule approved by government, the daylight saving time in Iran/Tehran (which was +4:30) will no longer be applied and the whole year time will be +3:30 Please consider updating this which will take effect in 4 days from now (2022 March 21st).

1 0

[tz-announce] 2022a release of tz code and data available
by Paul Eggert via tz-announce March 17, 2022

March 17, 2022

The 2022a release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine will spring forward on 2022-03-27, not -03-26. zdump -v now outputs better failure indications. Bug fixes for code that reads corrupted TZif data. Changes to future timestamps Palestine will spring forward on 2022-03-27, not 2022-03-26. (Thanks to Heba Hamad.) Predict future transitions for first Sunday >= March 25. Additionally, predict fallbacks to be the first Friday on or after October 23, not October's last Friday, to be more consistent with recent practice. The first differing fallback prediction is on 2025-10-24, not 2025-10-31. Changes to past timestamps From 1992 through spring 1996, Ukraine's DST transitions were at 02:00 standard time, not at 01:00 UTC. (Thanks to Alois Treindl.) Chile's Santiago Mean Time and its LMT precursor have been adjusted eastward by 1 second to align with past and present law. Changes to commentary Add several references for Chile's 1946/1947 transitions, some of which only affected portions of the country. Changes to code Fix bug when mktime gets confused by truncated TZif files with unspecified local time. (Problem reported by Almaz Mingaleev.) Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) When reading a version 2 or later TZif file, the TZif reader now validates the version 1 header and data block only enough to skip over them, as recommended by RFC 8536 section 4. Also, the TZif reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. zdump -v now outputs "(localtime failed)" and "(gmtime failed)" when local time and UT cannot be determined for a timestamp. Changes to build procedure Distribution tarballs now use standard POSIX.1-1988 ustar format instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead of " ". The two formats are planned to diverge more significantly for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar format becomes obsolete and the tarballs switch to pax format, an extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022a.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 95ecc37d29c2f5cf711af43b0ef3a35fc2847aa1 dated 2022-03-15 23:02:01 -0700 and tagged '2022a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3f047a6f414ae3df4a3d6bb9b39a1790833d191ae48e6320ab9438cd326dc455475186a02c44e4cde96b48101ab000880919b1e0e8092aed7254443ed2c831ed tzcode2022a.tar.gz 542e4559beac8fd8c4af7d08d816fd12cfe7ffcb6f20bba4ff1c20eba717749ef96e5cf599b2fe03b5b8469c0467f8cb1c893008160da281055a123dd9e810d9 tzdata2022a.tar.gz ece0b7a9ad3d365f8605e8f98a8a78b7fdbbb8aa615b585f21256d9401c59845fcdc951f5fc876293f1b7956b1a2d3fa2baf85099d637a91d4199ee30cf4307e tzdb-2022a.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjRXfw/8DC6daRCaFirmN6821H+CA0D/e0Iod9e2g/Z5/yyx5HGCEAfRBhJ6ThWA O1I8oCuwp2kaP2ZH87+HKXT1WXGMx/819FU5fqY2TNncHAUxVUSmAm1yVHWaY2nU qFt3gDTx4vDV0lfSDtKYJJdVeE+VcAdSDUDnYIqMNCKuTkKdTfPVparsAPIZ8egr EC4IBiGolLoLkMiiwvvPNg0J505I+DUYeHEuo+ezhgBzBiLNhCWDfCcghoDYakHr CEH+aq6BVhhn/3w1203ExN7iEr/5iTwC/PjRZoJlBqDS7eAhycgFYHjglHGYSs8P RVNnkTAhDMxONZH97QqKlOo56a5QLMvTDNbBLdX0b4K4lmEfCRe03MbH4ybDkA9S +eYfkeX2kUYKnHTT3XXTiVvjDFGemu+l8QGlJoF9Qu44cUGLPZQZEq/YzbZUw8ax RaT4V0ZkH3+yMYAAWaoa85xXs7a/MnE7Gl9glSFzlijC6iZoRmrXy2ra44TzvwWr E/7Het1lctaiKWcdYH5+vYyzzWZTt4hKAXsCUgBGQy0/mE2KoHRQHk6zfZPY1TvD ib6Dkh9LWYrXsNGCe1H4SpjKEX51Nb27FgIw1DNrbOJpTna5/OKmceu5IIlGJseF nfwPHZ3ATpVfVwdiRqbNC9GNVBev9n5UI67zGQ2494kknR2JMhs= =4JUm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjTlWw/7BrBTwRx7HvTlNaIbCaj/uOIEomJafNOq8Kdbx2JXrZu8qhj/0vMdwIzQ CEIqVuGKD8WJB4nsBYlFU8Jn1JfRbglnWK1f7yRY1EaXuIFh+FMbRYEk8O3HYPy2 14QCJNjsCwIzztmiuxXqET2eQRpT2iojGKhZbToJE4DpC/w5xCPrUqAIsK8nfC3u TZC8l09zL/xTSl/QMStH/Kh8oJD4uftVMxYZE5zakZaH5M017gwjDdM/7I/D4MME sTm7XEL7IdzzZyTxzeVVbXfyqoEb1ueJJImYnQfGgCnoJKtMjVROzL6BBJSZLkZN tR7/V9mHZKoItzhOv5gwfk0YMy8792rAioqfMUG/KvrvCTNy3PqrE1jO1/nv+FPS WWuixsnRx1Xz2COb88pKnYX17Zt8rBIumcfpgolsBvLKGI7ZLEAekjteKubgpebn jnf6CLAdcRoIdauG483LG/OQ6M9PEUBYTrX56Q8/C3kdOPuuMJ/6qd6k7lNt/fWx O2lBg+lkIagZu8j5pU5mHOsVe2P1f7p7oIt1NF2oAD2cIq6EFWOdcOCyvgC69xE1 +jt6lIQkIfBM8dfxf70z9KZQvOr9bwZaCirWNTgIMxrn/n4vvo5HCbYx+P4LSAhH G1UY/x67Swnl0p6+69d8Ww/SrdOP3T30KxjIaQXx5NgjeU2zIEo= =OX/x -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhEACgkQ7ZfpDmKq fjTWBQ//T8ICtN33H3kcz/4P9gWArfgV7huztvWW9KKBkQpWEa9gIlpYi7jx80wF qnAHZCpRedj+CJXqswkG+lIMVLEHjwVT2hdeP5wPV2y5rJ0J9Ssh2i0voSdX000T WED4u/OyR1shKm4VIxdgY6eqaN6Hedc0+Eib/VoIQAzCM2nP3c4IMAWkBKLiCSIZ n6JVI90jRgAnzhRJjiddJRFMBovzKNIxpqGGZYaxaG0O5AYfsItdRte3RCOn/tc+ tsMSJ+iUt8nTonq4P1nUE4zmvx33V7iOJhaj03fdJal0U8Egc/Ib5exsS2KipEjG iknyi8dUQcbNBFnFoN26SAO9/QMpDDE/vOnGGyWySLSwQg/xmy+LwmIZGqVftDeX JrUeRboH/39aDx6kKIrqXeIlG9bNka/6ThOJEZNr+OejDRyFeqgcatpomRkoExRs pPR88cyA0ZsN3PHhi9eXO+Zyk9GBA0o7m7G0ECK2j6w2axPh8/xPQ94zdFRTcd3V 3xC94N42eoNKeWgEmyvNEXdq5hZXhPK/Lu8D0NScbS440ovMJJtcr8Q+/bihHyGG eOCrxVF5KXLOYvptQ/xhUGodzRm8PuZ6DkJoCtW9PQL82LZDSHAi880YgzsdWzzy 6m6g8KmOmTkmQ6vztMyDr04KW2QDxp53q7hdErh0bW0iyvELd7I= =egWc -----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 rearguard_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

Permanent DST in the United States
by Jacob Pratt March 16, 2022

March 16, 2022

The "Sunshine Protection Act" has passed the US Senate with unanimous consent. It now moves on to the House. My reading of the text is that this would mandate permanent DST for the 48 states that currently observe it, with Arizona (sans the Navajo Nation) and Hawaii able to choose. Notably there is no clause that delays implementation, so it looks like it would take effect immediately. This could be problematic if the bill becomes law near or after the November clock change. https://www.congress.gov/bill/117th-congress/senate-bill/623/text Jacob Pratt

4 5

gmtime failed messages for zdump on Windows with latest git code
by Manuela Friedrich March 16, 2022

March 16, 2022

Hello Paul, I noticed that zdump on Windows from the latest git code now produces "localtime failed" and "gmtime failed" messages. Is that expected? Does it also happen on Linux? New behaviour with git code: zdump.exe -v d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 (gmtime failed) = -9223372036854775808 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 (gmtime failed) = -67768040609740801 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = -67768040609740800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = -67768040609739833 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 (gmtime failed) = 67768036191676800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 (gmtime failed) = 9223372036854775807 (localtime failed) Output from 2021e zdump.exe -v d:\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 = NULL d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 = NULL Thank you! Regards Manuela Friedrich

2 2

Wouldn't it be simpler if…
by Torsten Louland March 15, 2022

March 15, 2022

https://xkcd.com/1061/

2 1

Daylight Saving: Iran
by MohamadReza Farhadi March 15, 2022

March 15, 2022

Greetings, Today Iranian Parliament approved the cancelation of the Daylight Saving Time practice. The link for the article can be found here: https://www.bbc.com/persian/iran-60734716 Kindest Regards, MohamadReza Farhadi

1 0

Hong Kong listed as UK not China
by Shelley Finerty March 15, 2022

March 15, 2022

Hi there, I was using a tool that allows me to look at people’s birthdate, time and location and noticed that you still have Hong Kong listed as part of the UK with throws off the timezone for their birthdate. I had to choose another city close to Hong Kong to use it correctly. Is this something that can be changed or updated? Or are you keeping it for historical purposes? Is there a way to do both? Thanks for keeping the time so accurately - I appreciate the work you’re doing. Shelley Finerty Canada

3 2

2022a timeline?
by Deborah Goldsmith March 15, 2022

March 15, 2022

Hi, Is there an ETA for the release of (I assume) 2022a with the change for Palestine? Thank you, Deborah Goldsmith

2 1

[PATCH] URL housekeeping
by Paul Eggert March 12, 2022

March 12, 2022

* tz-link.html: Omit no-longer-active projects, and update URLs. Mention "pytz: The Fastest Footgun in the West". --- tz-link.html | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/tz-link.html b/tz-link.html index 48724ad..92da48f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -89,7 +89,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, title="Web Operating System">webOS</abbr></a>, <a href="https://en.wikipedia.org/wiki/IBM_AIX"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, -<a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, <a href="https://www.apple.com/ios"><abbr title="iPhone OS">iOS</abbr></a>, <a href="https://www.apple.com/macos">macOS</a>, @@ -243,18 +242,18 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://www.ibm.com/developerworks/aix/library/au-aix-olson-time-zone/index…"><abbr>AIX</abbr></a>, +for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a -href="http://userguide.icu-project.org/datetime/timezone"><abbr +href="https://unicode-org.github.io/icu/userguide/datetime/timezone/"><abbr title="International Components for Unicode">ICU</abbr></a>, -<a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr> +<a href="https://www.ibm.com/support/pages/java-sdk-time-zone-update-utility"><abbr>IBM</abbr> JDK</a>, <a href="https://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>, <a href="https://nodatime.org/userguide/tzdb">Noda Time</a>, and <a -href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html#usage">OpenJDK/Oracle JDK</a>. +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">OpenJDK/Oracle JDK</a>. Sources for the <code><abbr>tz</abbr></code> database are <a href="https://en.wikipedia.org/wiki/UTF-8"><abbr @@ -488,11 +487,6 @@ many of which also support runtimes lacking the <samp>timeZone</samp> option. href="https://github.com/formatjs/date-time-format-timezone"><samp>Intl.DateTimeFormat</samp> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a -href="https://github.com/kshetline/compact-time-zone-generator">CompactTimeZoneGenerator</a> -compiles time zone data into a compact form designed for -JavaScript. It is freely available under a combination of -the <abbr>MIT</abbr> license and the Apache License.</li> <li>The <a href="https://date-fns.org/">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. @@ -546,9 +540,9 @@ It is freely available under a <abbr>BSD</abbr>-style license.</li> Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. -In code that can assume Python 3.9 or later it is superseded by -<a href="#python-zoneinfo"><code>zoneinfo.ZoneInfo</code></a> -and the <a href="#pypi-tzdata"><code>tzdata</code> Python package</a>.</li> +In code that can assume Python 3.6 or later it is largely superseded; see <a +href="https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html">pytz: +The Fastest Footgun in the West</a>.</li> <li><a href="https://tzinfo.github.io">TZInfo – Ruby Timezone Library</a> compiles <code><abbr>tz</abbr></code> source into @@ -610,11 +604,11 @@ is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>Python has a <a id="python-zoneinfo" -href="https://docs.python.org/3.9/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> +href="https://docs.python.org/3/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> class</a> that reads <abbr>TZif</abbr> data and creates objects that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the -<a href="https://docs.python.org/3.9/license.html">Python Software Foundation +<a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> @@ -641,7 +635,7 @@ available under a <abbr>BSD</abbr>-style license.</li> <li><a href="https://foxclocks.org">FoxClocks</a> is an extension for <a href="https://www.google.com/chrome/">Google Chrome</a> and for <a -href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Toolkit_API">Mozilla +href="https://wiki.mozilla.org/Modules/Toolkit">Mozilla Toolkit</a> applications like <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> and <a href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. @@ -1010,14 +1004,11 @@ specifies a <a href="https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"><abbr>DHCP</abbr></a> option for a server to configure a client's time zone and daylight saving settings automatically.</li> -<li><a -href="https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical -Times</a> explains more abstruse astronomical time scales like +<li><a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time +Scales</a> describes astronomical time scales like <abbr title="Terrestrial Dynamic Time">TDT</abbr>, <abbr title="Geocentric Coordinate Time">TCG</abbr>, and <abbr title="Barycentric Dynamic Time">TDB</abbr>. -<a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time -Scales</a> goes into more detail, particularly for historical variants.</li> <li>The <a href="https://www.iau.org"><abbr title="International Astronomical Union">IAU</abbr></a>'s <a href="http://www.iausofa.org"><abbr -- 2.32.0

1 0

Just :)
by Sergiusz Wolicki March 11, 2022

March 11, 2022

Ryan Reynolds (@VancityReynolds) wysłał/a Tweeta o godz. 3:29 PM on pt., mar 11, 2022: As if making #TheAdamProject hadn’t satisfied enough of my childhood dreams, this happened. (I still loathe Daylight Savings.) https://t.co/9lAjYzjOnW ( https://twitter.com/VancityReynolds/status/1502290590242910208?t=zCwO45RshV… )

1 0

Re: [tz] Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear sir, regarding to summer time for this year , the timing will be on 3/27/2022, but this does not necessarily mean that the change for the coming years will be on the same date. You will be provided with any new decisions about summer and winter times for the coming years and we will try to provide you with any changes more earlier than previous years. BR, في الخميس, مارس 10, 2022 14:26 EST, Paul Eggert <eggert(a)cs.ucla.edu> كتب: 3/04:50,http://www.palestinecabinet.gps/portal/Meeting/Details/51955 heba.hamad(a)mtit.gov.ps wrote: > We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Thanks, do you have a URL for that announcement? It sounds like Palestine is changing its spring-forward rules, so that Palestine will now spring forward at 00:00 on the first Sunday on or after March 25, whereas during 2020 and 2021 Palestine sprang forward at 00:00 on the first Saturday after March 24. Is my understanding correct? Knowing the transition rule would be helpful, because TZDB makes predictions about future years, some computer applications rely on this (perhaps unwisely, but that's what they do), and the more accurate the predictions the better off everybody will be. This is related to Clive Feather's point that we need plenty of advance notice of rule changes (we'd like a year's notice). Without knowing the answers to the above questions, I installed the attached proposed patch into the TZDB development version. If possible, I'd like to improve this (based on answers to the above questions) before the next TZDB release, which should happen soon.

1 0

Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear Sir, Greeting from Ministry of telecom and information technology, Palestine We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Kindly find the attachment below that includes the decision of the Palestinian cabinet. BR

3 2

Jordan summer time zone is not updated in IANA database
by Abugharbieh, Raghad March 2, 2022

March 2, 2022

Hello I’m sure if you’re already aware of this or not , but in Jordan the timezone was changed on Thursday to meet summer changes. So currently , time zone in IANA database is behind the real time in Jordan by 1 hour . this is causing some time issues in websites that use IANA database. I’m sending this to check if there’s anything I can do to update the timezone for Jordan in the database to fix the root cause instead of handling the issues we have in a hacky way . Best regards , Raghad Abugharbieh

2 1

DST in mainstream media
by Arthur David Olson Feb. 28, 2022

Feb. 28, 2022

"Freezing the clock: Nationwide push for permanent daylight saving time gains momentum" Washington Post, 2022-02-28 (timeanddate.com gets a shoutout.) https://www.washingtonpost.com/dc-md-va/2022/02/28/permanent-daylight-savin… @dashdashado

1 0

backzone Africa/Lubumbashi
by Alois Treindl Feb. 28, 2022

Feb. 28, 2022

In file backzone there is an entry for Africa/Lubumbashi # Democratic Republic of the Congo (east) Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 2:00 - CAT There are scarce sources for time zones of former Belgian Congo. My main source for its time zone history is Henri le Corre, Régimes horaires pour l'Europe et l'Afrique. He has for the eastern provinces of Zaire GMT + 1 between 1897 Nov 9 GMT + 2 since 1920 Apr 25. Shanks follows le Corre. As does Francoise Schneider Gauquelin in he book Problèmes de l'heure resolus pout le monde entier. I think this is sufficient reason to change the zone into Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 1:00 - WAT 1920 Apr 25 2:00 - CAT For the province of Kisangani, formerly Stanleyville, le Corre gives a transition from GMT +1 to GMT + 2 on 1935 Jun 14. But as this agrees with Lubumbashi after 1970, I do not expect the creation of another backzone entry for that. This task will be left for my private pre-1970 TZ extensions.

2 1

(no subject)
by Dennis Dau Feb. 24, 2022

Feb. 24, 2022

Take Russia off the time zones for now sanctioned by the United States of America for starting war yesterday with our alias

1 0

Brisbane's lord mayor calls for referendum on Queensland DST
by Gilmore Davidson Feb. 22, 2022

Feb. 22, 2022

https://www.theguardian.com/australia-news/2022/feb/22/queensland-daylight-… Thirty years after Queenslanders rejected daylight saving at the polls, > Brisbane lord mayor, Adrian Schrinner, is calling for a new referendum on > the divisive subject. > > [...] Queenslanders voted against permanently introducing daylight saving > time after a three-year trial back in 1992. Schrinner says most people > under the age of 48 and anyone who moved to the state in the last 30 years > hasn’t had a say on adjusting time zones. > > [...] Schrinner suggested a new referendum could be held at the same time > as the next state election in 2024. > > [...] The attorney general, Shannon Fentiman, responded to an > anti-daylight saving time petition to parliament in December, saying [it] > was “not currently” under consideration. > Cheers, Gil

1 0

(no subject)
by 이상준 Feb. 22, 2022

Feb. 22, 2022

-- 이상준1978.06.28

1 0

proposed change to Europe/Kaliningrad in 1945
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

Currently the zone Europe/Kaliningrad has Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 2:00 Poland EE%sT 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I wonder on which source this line is based: 2:00 Poland EE%sT 1946 Apr 7 It implies these time changes: 29 April 1945 from 2:00 to 3:00 like Poland DST 1 November 1945 from 3:00 back to 2:00 Russia took control of Königsberg/Kaliningrad in East Prussia on 10 April 1045. As a general rule, Russia imposed timezone 2:00 on occupied German territory in 1945, which is the same as German DST already in force from 2 April 1945. On 24 May 1945 Russia imposed double DST, making the effective time 3:00 east, until 24 Sept 1945, when it went back to 2:00 and then back to 1:00 (CET) on 18 Nov 1945. Now what happened in Königsberg? The Potsdam agreement of 2 August 1945 : (quote from Wikipedia) > The Conference has agreed in principle to the proposal of the Soviet > Government concerning the ultimate transfer to the Soviet Union of the > City of Koenigsberg and the area adjacent to it as described above > subject to expert examination of the actual frontier. Russia annexed the area on 17 October 1945, and integrated into the republic of Russia on 7 April 1946. Poland had no role to play in this matter. Regarding time regime, I would assume that the transition from 2:00 to 1:00 of 18 Nov 1945, for occupied Germany, did not happen in Kaliningrad. It was already annexed. It remained at 2:00 until 7 April 1946, when it was integrated and went to Moscow time. This transition on 7 April 1946 is also found in Shanks. Shanks does not have the double DST from 24 May to 24 September 1945, but I think he is wrong there. Why should the Russians have treated East Prussia from the rest of the occupied German territory in May 1945. That would make the zone table like this ( I marked the difference in red) Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 1:00 CEST 1945 May 24 2:00 1:00 2:00 CEMT 1945 Sep 24 3:00 1:00 1:00 CEST 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I have tried to simplify Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 SovietZone CE%sT 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET but get an error: can't determine time zone abbreviation to use just after until time at this line in tzdata.zi 1 So CE%sT 1945 O 17 This is why I made the changes implied by rule SovietZone explicit

2 2

Maryland permanent DST
by Arthur David Olson Feb. 21, 2022

Feb. 21, 2022

A permanent-DST bill has been approved by the Maryland House of Delegates on a third-and-final 108-24 vote; it now goes to the state senate. Text of the bill is available at... https://mgaleg.maryland.gov/2022RS/bills/hb/hb0126T.pdf …and status of the bill at... https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0126 There are contigencies: (1) enacting of a similar act by Delaware, the District of Columbia, Pennsylvania, Virginia, and West Virginia; and (2) 15 U.S.C. § 260a being amended to allow the states or a state, individually, to observe a year–round standard time that is consistent with Eastern Daylight Time Alas, if the contingencies are met there may be short lead time before a change: Section 1 of this Act shall take effect on the earlier of the second Sunday of March or the first Sunday of November after the [contigencies have been met]… Alas further, the senate (unlike the house) has returned to in-person hearings; written communications can be sent. One suggestion I’ve thought of making is to change “the earlier of” to “the later of” for kick-in; that would buy at least a few guaranteed months of lead time. I’d welcome any better suggestions; I’d also welcome any Marylander with more political weight than I have (read: anyone) to weigh in. --ado

6 6

Issues about parts of Europe/Moscow in 1981/1982
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

I have the impression that some of the comments in the Russia section in file 'europe' have not been followed through in the actual zone tables. I refer to the lines beginning here # From Stepan Golosunov (2016-03-07): # 11. Regions-violators, 1981-1982. # Wikipedia refers to # http://maps.monetonos.ru/maps/raznoe/Old_Maps/Old_Maps/Articles/022/3_1981.… # http://besp.narod.ru/nauka_1981_3.htm ... until # 12. Udmurtia Also the Russian wikipedia page https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0… contains the sentence (in Google translation) > In the autumn of 1981, Arkhangelsk, Vologda, Yaroslavl, Ivanovo, > Vladimir, Ryazan, Lipetsk, Voronezh, Rostov-on-Don, Krasnodar and > regions to the east of those named (about 30 in total) parted ways > with Moscow time.However, the convenience of common time with Moscow > turned out to be decisive - in 1982, these regions again switched to > Moscow time. Shanks International atlas has similar information, and also the Russian book Zaitsev A., Kutalev D. A new astrologer's reference book. Coordinates of cities and time corrections, - The World of Urania, 2012 Russian: Зайцев А., Куталёв Д., Новый справочник астролога. Координаты городов и временные поправки To me it seems that an extra zone is needed, which starts with LMT util 1919, later follows Moscow since 1930, but deviates from it between 1 October 1981 until 1 April 1982. I suggest to call this zone Europe/Yaroslavl, because Yaroslavl with a population of 608'000 seems to be largest city in the deviating area.

3 4

(no subject)
by Lanny Dorn Feb. 13, 2022

Feb. 13, 2022

seigepopcorn(a)gmail.com--

1 0

TZ data base and code
by Jin Quan Shen Feb. 3, 2022

Feb. 3, 2022

Hi, I have download and compiled timezone code and data base from https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/ tzcode2018e.tar.gz<https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/tzcode2018…> tzdata2018e.tar.gz<https://opensource.apple.com/source/TimeZoneData/TimeZoneData-88/tzdata2018…> Ran tzselect, zdump, zic however unable to execute successfully. What are causes and any suggestion? [cid:17778879-34f0-4bb4-99a5-6e7c0e5ff4ee] Regards, JinQuan Seagate Internal

2 4

[PROPOSED] Improve doc for some source files
by Paul Eggert Jan. 27, 2022

Jan. 27, 2022

* theory.html: Mention zone.tab and improve description of 'backward' and 'etcetera'. The goal of this change is to describe existing practice, and to allay concerns that names listed in 'backward' are going away. --- theory.html | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-) diff --git a/theory.html b/theory.html index 5a05f4b..28cc88e 100644 --- a/theory.html +++ b/theory.html @@ -296,7 +296,7 @@ in decreasing order of importance: </li> <li> If a name is changed, put its old spelling in the - '<code>backward</code>' file. + '<code>backward</code>' file as a link to the new spelling. This means old spellings will continue to work. Ordinarily a name change should occur only in the rare case when a location's consensus English-language spelling changes; for example, @@ -348,22 +348,37 @@ timestamps correctly and it increased maintenance burden. </ul> -The file '<code>zone1970.tab</code>' lists geographical locations used +The file <code>zone1970.tab</code> lists geographical locations used to name timezones. It is intended to be an exhaustive list of names for geographic regions as described above; this is a subset of the timezones in the data. -Although a '<code>zone1970.tab</code>' location's +Although a <code>zone1970.tab</code> location's <a href="https://en.wikipedia.org/wiki/Longitude">longitude</a> corresponds to its <a href="https://en.wikipedia.org/wiki/Local_mean_time">local mean time (<abbr>LMT</abbr>)</a> offset with one hour for every 15° east longitude, this relationship is not exact. +The backward-compatibility file <code>zone.tab</code> is similar +but conforms to the older-version guidelines related to <abbr>ISO</abbr> 3166-1; +it lists only one country code per entry and unlike <code>zone1970.tab</code> +it can list names defined in <code>backward</code>. -Excluding '<code>backward</code>' should not affect the other data. -If '<code>backward</code>' is excluded, excluding -'<code>etcetera</code>' should not affect the remaining data. +The database defines each timezone name to be a zone, or a link to a zone. +The source file <code>backward</code> defines links for backward +compatibility; it does not define zones. +Although <code>backward</code> was originally designed to be optional, +nowadays distributions typically use it +and no great weight should be attached to whether a link +is defined in <code>backward</code> or in some other file. +The source file <code>etcetera</code> defines names that may be useful +on platforms that do not support POSIX-style <code>TZ</code> strings; +no other source file other than <code>backward</code> +contains links to its zones. +One of <code>etcetera</code>'s names is <code>GMT</code>, +used by functions like <code>gmtime</code> to obtain leap +second information on platforms that support leap seconds. </section> -- 2.32.0

2 1

[PATCH 1/2] I18nize zdump a bit better
by Paul Eggert Jan. 26, 2022

Jan. 26, 2022

* zdump.c (sumsize, show): Translate diagnostics that were mistakenly untranslated. --- zdump.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/zdump.c b/zdump.c index be8ac30..dc3dca8 100644 --- a/zdump.c +++ b/zdump.c @@ -146,7 +146,7 @@ sumsize(size_t a, size_t b) { size_t sum = a + b; if (sum < a) { - fprintf(stderr, "%s: size overflow\n", progname); + fprintf(stderr, _("%s: size overflow\n"), progname); exit(EXIT_FAILURE); } return sum; @@ -813,7 +813,7 @@ show(timezone_t tz, char *zone, time_t t, bool v) gmtmp = my_gmtime_r(&t, &gmtm); if (gmtmp == NULL) { printf(tformat(), t); - printf(" (gmtime failed)"); + printf(_(" (gmtime failed)")); } else { dumptime(gmtmp); printf(" UT"); @@ -823,7 +823,7 @@ show(timezone_t tz, char *zone, time_t t, bool v) tmp = my_localtime_rz(tz, &t, &tm); if (tmp == NULL) { printf(tformat(), t); - printf(" (localtime failed)"); + printf(_(" (localtime failed)")); } else { dumptime(tmp); if (*abbr(tmp) != '\0') -- 2.34.1

1 1

[PROPOSED] Simplify recent zdump port
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

* zdump.c (tformat): Simplify by using default promotions. --- zdump.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/zdump.c b/zdump.c index 79ff1fd..be8ac30 100644 --- a/zdump.c +++ b/zdump.c @@ -1148,12 +1148,8 @@ tformat(void) /* C11-style _Generic is more likely to return the correct format when distinct types have the same size. */ char const *fmt = - _Generic((time_t) 0, - signed char: "%d", short: "%d", int: "%d", - long: "%ld", long long: "%lld", - char: CHAR_MAX <= INT_MAX ? "%d" : "%u", - unsigned char: UCHAR_MAX <= INT_MAX ? "%d" : "%u", - unsigned short: USHRT_MAX <= INT_MAX ? "%d" : "%u", + _Generic(+ (time_t) 0, + int: "%d", long: "%ld", long long: "%lld", unsigned: "%u", unsigned long: "%lu", unsigned long long: "%llu", default: NULL); -- 2.34.1

1 0

[PATCH] zdump ports better to odd C11 platforms
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

* zdump.c (HAVE_GENERIC): Define if not already defined, with the same definiens as private.h. (tformat): Prefer _Generic if it works, as this is more reliable than guessing via sizeof. --- zdump.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) diff --git a/zdump.c b/zdump.c index f08afbd..79ff1fd 100644 --- a/zdump.c +++ b/zdump.c @@ -56,6 +56,21 @@ */ enum { SECSPER400YEARS_FITS = SECSPERLYEAR <= INTMAX_MAX / 400 }; +#if !defined HAVE_GENERIC && defined __has_extension +# if __has_extension(c_generic_selections) +# define HAVE_GENERIC 1 +# else +# define HAVE_GENERIC 0 +# endif +#endif +/* _Generic is buggy in pre-4.9 GCC. */ +#if !defined HAVE_GENERIC && defined __GNUC__ +# define HAVE_GENERIC (4 < __GNUC__ + (9 <= __GNUC_MINOR__)) +#endif +#ifndef HAVE_GENERIC +# define HAVE_GENERIC (201112 <= __STDC_VERSION__) +#endif + #if HAVE_GETTEXT #include <locale.h> /* for setlocale */ #endif /* HAVE_GETTEXT */ @@ -1123,12 +1138,33 @@ abbr(struct tm const *tmp) /* ** The code below can fail on certain theoretical systems; -** it works on all known real-world systems as of 2004-12-30. +** it works on all known real-world systems as of 2021-01-25. */ static const char * tformat(void) { +#if HAVE_GENERIC + /* C11-style _Generic is more likely to return the correct + format when distinct types have the same size. */ + char const *fmt = + _Generic((time_t) 0, + signed char: "%d", short: "%d", int: "%d", + long: "%ld", long long: "%lld", + char: CHAR_MAX <= INT_MAX ? "%d" : "%u", + unsigned char: UCHAR_MAX <= INT_MAX ? "%d" : "%u", + unsigned short: USHRT_MAX <= INT_MAX ? "%d" : "%u", + unsigned: "%u", unsigned long: "%lu", + unsigned long long: "%llu", + default: NULL); + if (fmt) + return fmt; + fmt = _Generic((time_t) 0, + intmax_t: "%"PRIdMAX, uintmax_t: "%"PRIuMAX, + default: NULL); + if (fmt) + return fmt; +#endif if (0 > (time_t) -1) { /* signed */ if (sizeof(time_t) == sizeof(intmax_t)) return "%"PRIdMAX; -- 2.34.1

1 0

Wrong zdump output in timezone-2021e
by Danilo Spinella Jan. 25, 2022

Jan. 25, 2022

Hi everyone! I have encountered a strange behaviour in zdump in the latest version of timezone (timezone-2021e). Previous output of version timezone-2021a: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Current output with timezone-2021e: # zdump Europe/Copenhagen -v -c 2022,2023 | grep isdst Europe/Copenhagen -67768040609743820 = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen -67768040609740801 = Thu Jan 1 00:50:19 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Thu Jan 1 00:00:00 -2147481748 UT = Thu Jan 1 00:50:20 -2147481748 LMT isdst=0 gmtoff=3020 Europe/Copenhagen Sun Mar 27 00:59:59 2022 UT = Sun Mar 27 01:59:59 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 03:00:00 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 00:59:59 2022 UT = Sun Oct 30 02:59:59 2022 CEST isdst=1 gmtoff=7200 Europe/Copenhagen Sun Oct 30 01:00:00 2022 UT = Sun Oct 30 02:00:00 2022 CET isdst=0 gmtoff=3600 Europe/Copenhagen Wed Dec 31 22:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 CET isdst=0 gmtoff=3600 I consider this a bug due to the strange values printed by zdump. I have tested zdump in different distributions and they are all affected. Can you please confirm? -- Best Regards, Danilo Spinella

2 1

Re: [tz] Unexpected footer in Africa/Casablanca
by Paul Eggert Jan. 25, 2022

Jan. 25, 2022

On 1/10/22 08:55, Almaz Mingaleev wrote: > I was investigating generated TZif files and the generated footer for > Africa/Casablanca is "XXX-2<+01>-1,0/0,J365/23". Is that expected? > Effectively it behaves like GMT+1, but SAVE is -1:00 even though it is > 1:00 in rearguard.zi. How do I instruct zic to generate plain "<+01>-1" > or skip it at all? One fix is to change ziguard.awk to generate a rearguard-format .zi file that has a more-natural transition for Morocco in May 2087. ("More- natural" from the rearguard viewpoint that is; it's more-awkward from a real-world viewpoint.) Proposed patch attached; it causes the string to be "<+01>-1" for rearguard format too. Thanks for reporting the glitch. > I believe I am doing something wrong, as in MacOs it is empty and > "<+01>-1" in Linux, but I can't figure out what command options I should > specify in zic. It's "<+01>-1" on GNU/Linux platforms like Ubuntu and Fedora that use the default format. These distros are not using rearguard-format TZif files and so don't have rearguard issues there. I'm not sure why it's empty in macOS. macOS 12.1's 'zic --version' reports "zic: @(#)zic.c 8.22" which corresponds to tzcode2010m, so perhaps it's merely because macOS is stuck on a tzcode version that is so old that you can't easily tell that macOS is using rearguard format. (macOS's zdump doesn't seem to work past the year 2038, and Apple should upgrade well before that year rolls around.) While we're on the subject, what is Android's current state of support for negative DST and for timestamps past 2038? On the GNU/Linux side, I expect most distros support both - the stragglers being old-fashioned 32-bit x86 and ARM distros, where 64-bit timestamps weren't supported until Linux 5.6 (2020-03-29) and glibc 2.34 (2021-08-02), and even now many apps haven't been updated yet.

2 3

The State of Palestine has adopted the first part of the specification for its time zone
by heba.hamad＠mtit.gov.ps Jan. 24, 2022

Jan. 24, 2022

Dear Sir, Hope this email finds you well and wishing you a joyful new year . We would like to inform you that The State of Palestine has adopted the first part of the specification for its time zone. Kindly refer to the attachment below, which includes the specification and please provide me with any comments or notes you have regarding this specification. Ps: Please provide me with any comments you have. Sincerely Yours, Eng.Heba Hamad MTIT -Palestine Sent from Mail for Windows

5 7

[YBA] TLD make using mawk causes malloc failure
by Jonathan Ben Avraham Jan. 19, 2022

Jan. 19, 2022

Dear colleagues, I noticed that on all tz versions up to 2021e running make in the top-level directory results in a malloc failure on Debian 10 which uses the mawk alternate for awk: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o difftime.o difftime.c rm -f libtz.a ar -rc libtz.a localtime.o asctime.o difftime.o strftime.o : libtz.a awk -v DATAFORM=`expr main.zi : '$.*$.zi'` -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out malloc(): unsorted double linked list corrupted Aborted make: *** [Makefile:612: main.zi] Error 134 This can be corrected by installing gawk and running update-alternatives --config awk to select gawk as the awk alternate. I verified that the make completes without error using either GNU Awk 4.1.4, or GNU Awk 4.2.1. I did not see any warning about this in any of the NEW or README files, which is unfortunate as I spent several hours of my employers time understanding the problem and I suspect that others have seen this already. I suggest adding an INSTALL readme to say which environments are known to work and if there are specific know issues such as mawk. Best regards, - yba -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}-------- Jonathan Ben-Avraham ("yba") ----------ooO--U--Ooo------------{= mailto:yba@tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

3 3

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Doug Ewell Jan. 15, 2022

Jan. 15, 2022

heba.hamad at mtit.gov.ps wrote: > We would like to inform you that The State of Palestine has adopted > the first part of the specification for its time zone. and linked a document which states in part: > Names normally have the form AREA/LOCATION, where AREA is a continent > or ocean, and LOCATION is a specific location within the area. > > The State of Palestine is the Palestine Time Zone owner, It has the > sole right to set, modify and register the Standard Time Zone; Name / > Database / DST. The Time Zone Database includes two zones related to Palestine, with the identifiers "Asia/Gaza" and "Asia/Hebron". These zones differ for (recent) historical reasons, because the rules for summer time (daylight saving time) varied during the period from 2008 to 2012. The file "asia" in the TZDB has comments which explain the exceptions for Gaza. By stating: > Palestine will use Palestine Standard Time (PSST), and Palestine > daylight time (PSDT). the PSI document appears to signal that the entire State of Palestine will observe a single changeover date and time, and will no longer observe different changeover dates in Gaza. However, for historical reasons involving the 2008–2012 daylight time discrepancies, both zones will continue to be reflected in TZDB. The TZDB administrators will retain the right to keep the identifiers "Asia/Gaza" and "Asia/Hebron", or to change them according to rules that they and the larger community have established. Governments or other bodies do not determine these identifiers, and cannot unilaterally claim the right to do so. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

1 0

No leap second on 2022-06-30
by Tim Parenti Jan. 11, 2022

Jan. 11, 2022

Per IERS, Bulletin C 63 (2022-01-05) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.63 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Wed, 5 Jan 2022 at 10:43 Subject: Bulletin C number 63 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, 05 January 2022 Bulletin C 63 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2022. 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

1 0

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Paul Eggert Jan. 5, 2022

Jan. 5, 2022

On 1/4/22 09:12, Eliot Lear via tz wrote: > The TZ update process here has no formal recognition of governments (any governments). Still, statements from governments, however they reach this group, tend to carry a lot of weight. Quite true. In the past we've given a lot of weight to official government documents, and we welcome future cooperation in this area as this will streamline communication. (All too often for many countries in the past, we've had to rely on third parties or the popular press to forward their governments' information to us, which has resulted in inaccuracies and delays in updating the database.) From the timekeeping point of view, the most important thing is to know the UTC offsets and the rules for when daylight saving time starts and stops in Palestine, and for technical reasons it's best to have this nailed down well in advance - preferably at least a year before rules change. Currently for Palestine, tzdb lists standard time of UTC+02, and it says daylight saving time starts at 00:00 on the first Saturday on or after March 24, and ends at 01:00 on the first Friday on or after October 23. Unfortunately, as far as I know these daylight saving time rules are not official, in that there's no official Palestinian government document listing these rules for future years; however, tzdb must put *something* in the database and that's the best guess we've come up with. If the government could publish an official document stating what the rules are for future years, we'd be happy to adjust tzdb to match that. Of lesser importance is the English-language abbreviation used for standard and daylight saving time in Palestine. (This is less important because most timekeeping applications do not rely on these abbreviations, as they are inherently ambiguous and somewhat deprecated anyway.) Here, tzdb attempts to follow common practice, and it currently uses the same longstanding abbreviations for time in Palestine that it uses for Cyprus, Egypt, Jordan, Lebanon, and Syria - namely "EET" and "EEDT" (short for "Eastern European Time" and "Eastern European Summer Time"). I am unaware of any English-language use of the abbreviations "PSST" and "PSDT" to refer to civil timekeeping in this area. However, if these abbreviations become popular in common practice we should change tzdb to incorporate them.

2 2

Re: [tz] The State of Palestine has adopted the first part of thespecification for its time zone
by Sanjeev Gupta Jan. 4, 2022

Jan. 4, 2022

On Tue, Jan 4, 2022 at 7:24 PM <heba.hamad(a)mtit.gov.ps> wrote: > What is meant in general is that the State of Palestine (the Palestinian > government) is the only authorized one to address the international > bodies, including IANA, to request any amendment, update, registration, > or anything else related to the subject, > That may be hard to enforce. I am in Singapore, so what happens if I write to this list with information on the time in Hebron, or whether Gaza and Ramallah have the same DST date or not? I would be unauthorised to address IANA and request an update. or to publish any official decisions regarding the time Zone of the State > of Palestine. > Of course. That is unobjectionable. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1

[PATCH] Allow complication with tcc
by Arthur Williams Dec. 31, 2021

Dec. 31, 2021

In zic.c, some multi-line strings were surrounded in parenthesis which prevented tcc from parsing it. Maybe this is a complier bug, but don't think we gain anything by having the paren so just removed them. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 1ab636be..867c8d18 100644 --- a/zic.c +++ b/zic.c @@ -990,9 +990,9 @@ random_dirent(char const **name, char **namealloc) char const *src = *name; char *dst = *namealloc; static char const prefix[] = ".zic"; - static char const alphabet[] = ("abcdefghijklmnopqrstuvwxyz" + static char const alphabet[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" - "0123456789"); + "0123456789"; enum { prefixlen = sizeof prefix - 1, alphabetlen = sizeof alphabet - 1 }; int suffixlen = 6; char const *lastslash = strrchr(src, '/'); -- 2.34.1

2 1

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson Dec. 15, 2021

Dec. 15, 2021

A bit of necroposting from my August 2020 email (quoted in full below): > We should take the time to write up a good lengthy explanation of > the issues ("boilerplate"), because this a really important issue of > concern to many people in the world and the project has indeed > thought about it pretty carefully. Dismissing the inquiries because > they are repetitive makes it seem like we haven't, and that > unnecessarily upsets [people]. Has anyone done any work on this, or given thought to it? Serhii Trykoza (hopefully cc'd)'s github PR from the last hour (https://github.com/eggert/tz/pull/35, copied far below) raises the issue again. Please note that the tz project does not use github PRs for issue tracking or commit management, so the PR will likely be closed in short order, which is not an indication of merit. Speaking of boilerplates, I want to again suggest that if this is going to continue to be the project policy, there should be a github pull-request template that makes it clear pull requests are not considered appropriate. Also, when you create a pull request on github now, it reports, "Be sure to review the contributing guidelines." with a hyperlink to https://github.com/eggert/tz/blob/228a93f759cd5f2b0cca9e05eeee3d7cdea07ebf/…. It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]"), and the fact that the it's a plain text file (rather than CONTRIBUTING.md in markdown) makes it feel pretty unfriendly in the github world. Convertinf the file to markdown and making the "please don't use github pull requests" the first thing, rather than the last thing, would help to get the point across. (Indeed, perhaps that should be the *only* thing in the file that github links to.) -- jhawk(a)alum.mit.edu John Hawkinson John Hawkinson <jhawk(a)alum.mit.edu> wrote on Sat, 15 Aug 2020 at 18:52:58 EDT in <20200815225258.GA62055(a)alum.mit.edu>: > Date: Sat, 15 Aug 2020 18:52:58 -0400 > From: John Hawkinson <jhawk(a)alum.mit.edu> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Victor Perov <vic.gald(a)gmail.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv > Message-ID: <20200815225258.GA62055(a)alum.mit.edu> > In-Reply-To: <eggert/tz/pull/27/c673663957(a)github.com> > <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu> > > I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. > > We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. > > Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. > > In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). > There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. > > > Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 > at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > > > Thanks for bringing that to the mailing list (if I could shut off GitHub > > pull requests I would). > > Although you cannot do so, we can handle them a little bit better. > Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… > > You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") > > For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. > > https://github.com/eggert/tz/pulls?q=kiev > > Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. > > -- > jhawk(a)alum.mit.edu > John Hawkinson Serhii Trykoza <notifications(a)github.com> wrote on Mon, 6 Dec 2021 at 08:17:35 EST in <eggert/tz/pull/35(a)github.com>: > Date: Mon, 06 Dec 2021 05:17:35 -0800 > From: Serhii Trykoza <notifications(a)github.com> > To: eggert/tz <tz(a)noreply.github.com> > Cc: Subscribed <subscribed(a)noreply.github.com> > Subject: [eggert/tz] KyivNotKiev (PR #35) > Reply-To: eggert/tz > <reply+AAJWHPTK2DO6A5B34PZOC3N7XHXG7EVBNHHD7Z4WBI(a)reply.github.com> > Message-ID: <eggert/tz/pull/35(a)github.com> > X-GitHub-Sender: strikoza > > In September 2020, the English Wikipedia switched from using Kiev to Kyiv. > > https://en.wikipedia.org/wiki/KyivNotKiev > You can view, comment on, or merge this pull request online at: > > https://github.com/eggert/tz/pull/35 > > -- Commit Summary -- > > * KyivNotKiev - In September 2020, the English Wikipedia switched from using Kiev to Kyiv - https://en.wikipedia.org/wiki/KyivNotKiev > > -- File Changes -- > > M .gitignore (2) > M europe (4) > M theory.html (2) > M zone.tab (2) > M zone1970.tab (2) > > -- Patch Links -- > > https://github.com/eggert/tz/pull/35.patch > https://github.com/eggert/tz/pull/35.diff > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/eggert/tz/pull/35

4 9

[PATCH] Fix "el ds" typo in man pages
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

This fixes a typo that I introduced in 2014 when fixing glitches with '-' and italics in man pages. The typo is visible only when using traditional troff (as opposed to groff-compatible processors). --- date.1 | 2 +- newctime.3 | 2 +- newstrftime.3 | 2 +- newtzset.3 | 2 +- time2posix.3 | 2 +- tzfile.5 | 2 +- tzselect.8 | 2 +- zdump.8 | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/date.1 b/date.1 index 432cab1..1ecd63a 100644 --- a/date.1 +++ b/date.1 @@ -5,7 +5,7 @@ date \- show and set date and time .if n .nh .if n .na .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B date [ .B \*-u diff --git a/newctime.3 b/newctime.3 index cc56e2c..1b1790f 100644 --- a/newctime.3 +++ b/newctime.3 @@ -4,7 +4,7 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" diff --git a/newstrftime.3 b/newstrftime.3 index 887aba5..d68bc33 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -41,7 +41,7 @@ strftime \- format date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B "size_t strftime(char *restrict buf, size_t maxsize," diff --git a/newtzset.3 b/newtzset.3 index 05aa350..8aaa0ff 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -4,7 +4,7 @@ tzset \- initialize time conversion information .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B timezone_t tzalloc(char const *TZ); diff --git a/time2posix.3 b/time2posix.3 index fbb5766..2ea7edc 100644 --- a/time2posix.3 +++ b/time2posix.3 @@ -4,7 +4,7 @@ time2posix, posix2time \- convert seconds since the Epoch .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B time_t time2posix(time_t t); diff --git a/tzfile.5 b/tzfile.5 index e2f11b4..550b31d 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -10,7 +10,7 @@ tzfile \- timezone information \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like diff --git a/tzselect.8 b/tzselect.8 index a1ec8d0..69514e2 100644 --- a/tzselect.8 +++ b/tzselect.8 @@ -3,7 +3,7 @@ tzselect \- select a timezone .SH SYNOPSIS .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B tzselect [ .B \*-c diff --git a/zdump.8 b/zdump.8 index a5e2042..131a6cb 100644 --- a/zdump.8 +++ b/zdump.8 @@ -17,7 +17,7 @@ zdump \- timezone dumper \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The .B zdump program prints the current time in each -- 2.32.0

1 0

[PROPOSED] Fix Y2242 bug in tzdb tarball generation
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

Use pax format so that ‘make tarballs’ will still work after the year 2242. Without this patch, a far-future ‘make tarballs’ would fail for the same reason the following fails now with GNU tar: $ touch -d 2242-03-16T12:56:32Z future $ tar --format=ustar -cf tar future tar: value 8589934592 out of time_t range 0..8589934591 tar: Exiting with failure status due to previous errors This patch doesn’t change the tarball format for today’s releases since we don’t use any features requiring pax format, which means the tarballs stick to the ustar subset of pax. Although this issue was exposed by the recent switch to ustar format, the Y2242 bug has been present since the tzdb project began, due to historical tar format expiring in 2242 and to POSIX and GNU coming up with incompatible extensions to deal with this expiration. * Makefile (GNUTARFLAGS): Switch from --format=ustar to --format=pax --pax-option='delete=atime,delete=ctime'. * NEWS: Update description of tarball format change. --- Makefile | 3 ++- NEWS | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index d30227a..23dcc14 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ +GNUTARFLAGS= --format=pax --pax-option='delete=atime,delete=ctime' \ + --numeric-owner --owner=0 --group=0 \ --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ diff --git a/NEWS b/NEWS index edb9a1d..1106ef6 100644 --- a/NEWS +++ b/NEWS @@ -26,9 +26,12 @@ Unreleased, experimental changes instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead - of " ". For details about ustar format, please see + of " ". The two formats are planned to diverge more significantly + for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar + format becomes obsolete and the tarballs switch to pax format, an + extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, - <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Changes affecting documentation and commentary -- 2.33.1

2 1

[PATCH 1/4] Simplify tzselect by omitting old Bash workaround
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

* tzselect.ksh (doselect): Omit Bash 1.14.7 workaround that I wrote in September 1996, as Bash 1.14.7 hasn’t been supported for years and surely should not be used anyway for security reasons. Bash 2.0 came out in December 1996. --- tzselect.ksh | 8 -------- 1 file changed, 8 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 18fce27..832cf75 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -101,14 +101,6 @@ then esac done || exit } - - # Work around a bug in bash 1.14.7 and earlier, where $PS3 is sent to stdout. - case $BASH_VERSION in - [01].*) - case `echo 1 | (select x in x; do break; done) 2>/dev/null` in - ?*) PS3= - esac - esac ' else doselect() { -- 2.32.0

1 3

Anniversary
by Arthur David Olson Dec. 13, 2021

Dec. 13, 2021

Discussion at an online meeting today made me realize that, alas, we missed the recent 35th anniversary of the start of the time zone mailing list. Put 2026-11-25 on your calendars now.-) https://mm.icann.org/pipermail/tz/1986-November/008946.html @dashdashado

5 5

[PROPOSED] Distribute tarballs in ustar rather than gnu form
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

It recently came to my attention that tzdb tarballs are not generated in standard POSIX ustar format, but instead use a trivially different but nonstandard format. Fix this by switching to the standard format. * Makefile (GNUTARFLAGS): Add --format=ustar. * NEWS: Document the change. --- Makefile | 3 ++- NEWS | 10 ++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c89c1be..fd312d9 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --numeric-owner --owner=0 --group=0 --mode=go+u,go-w --sort=name +GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ + --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ else :; \ diff --git a/NEWS b/NEWS index 572a161..edb9a1d 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,16 @@ Unreleased, experimental changes reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. + Changes to build procedure + + Distribution tarballs now use standard POSIX.1-1988 ustar format + instead of GNU format. Although the formats are almost identical + for these tarballs, ustar headers' magic fields contain "ustar" + instead of "ustar ", and their version fields contain "00" instead + of " ". For details about ustar format, please see + "pax - portable archive interchange", IEEE Std 1003.1-2017, + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + Changes affecting documentation and commentary Rename CONTRIBUTING to CONTRIBUTING.md and use Markdown format. -- 2.32.0

1 0

.UA uses both kiev.ua and kyiv.ua, sebastopol.ua, uzhgorod.ua
by Brian Inglis Dec. 11, 2021

Dec. 11, 2021

...and other spellings for backward compatibility and convenience e.g. odessa.ua, sebastopol.ua with sevastopol.ua reserved, uzhgorod.ua (no mention of uzhhorod.ua even as reserved); from: https://hostmaster.ua/2ld/ referenced by the Public Suffix List package. Headings translated: Public domains second level =========================== Thematic domains ---------------- com.ua in.ua org.ua net.ua Specialty domains ----------------- edu.ua gov.ua Geographical domains -------------------- cherkassy.ua cherkasy.ua ck.ua chernigov.ua chernihiv.ua cn.ua chernovtsy.ua chernivtsi.ua cv.ua crimea.ua dnepropetrovsk.ua dnipropetrovsk.ua dp.ua donetsk.ua dn.ua ivano-frankivsk.ua if.ua kharkov.ua kh.ua kharkiv.ua kherson.ua ks.ua khmelnitskiy.ua km.ua kiev.ua kyiv.ua kirovograd.ua kr.ua lugansk.ua lg.ua lutsk.ua lt.ua volyn.ua lviv.ua nikolaev.ua mk.ua odessa.ua od.ua odesa.ua poltava.ua pl.ua rovno.ua rivne.ua rv.ua sebastopol.ua sumy.ua sm.ua ternopil.ua te.ua uzhgorod.ua uz.ua vinnica.ua vn.ua yalta.ua zaporizhzhe.ua zp.ua zhitomir.ua zt.ua Reserved domain names --------------------- cr.ua khmelnytskyi.ua kropyvnytskyi.ua krym.ua kv.ua lv.ua mykolaiv.ua sb.ua sevastopol.ua sicheslav.ua vinnytsia.ua zaporizhzhia.ua zhytomyr.ua Technological domains --------------------- admin.ua ipv6.ua ns.ua ua.ua www.ua xn--mqa.ua dnssec.ua rdap.ua epp1.ua epp2.ua This documents that proposed alternative English spellings may be neither as common nor the issue as settled as the trolls claim. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

1 0

Israel DST: Proposed Change of Start of DST
by Ephraim Silverberg Dec. 5, 2021

Dec. 5, 2021

The Minister of Interior, Ayelet Shaked, is proposing to change the Time Law so that DST will start in Israel at 2 a.m. on the *Friday *before the *second *Sunday of March. DST starts, according to the current law, at 2 a.m. on the Friday before the *last* Sunday in March. The proposed change has yet to be brought before the Knesset. I will endeavour to update the list if the proposed change receives Knesset approval.

2 2

America/SaoPaulo TZ still observing DST
by William Renan Santos (DHL Supply Chain) Dec. 4, 2021

Dec. 4, 2021

Hi, In Brazil the DST was revoked few years ago by government, but looks like the systems are still considering the DST change. I ran the tzupdater using latest file of tzdata and the systems are still considering 1 hour ahead in Sao Paulo. Could you please help me to review and point where in the tzdata file the DST for Brazil was removed? Thanks! William Santos LATAM - IT Products Sr Systems Analyst DHL Supply Chain Estrada da Cruz Grande, 1700 Louveira - SP ZipCode: 13290-000 Brazil Telephone: +55 19 3848 9377 william.r.santos(a)dhl.com<mailto:william.r.santos@dhl.com> www.dhl.com/supplychain<http://www.dhl.com/supplychain> DHL Supply Chain - Excellence. Simply delivered. [top_em]

3 2

Proposal: Sections for different kinds of backward links
by Stephen Colebourne Nov. 18, 2021

Nov. 18, 2021

I have taken a stab at splitting the `backward` file into sections. This is based on repeated observations made by multiple people that the file represents different kinds of Link. https://github.com/eggert/tz/pull/33 The sections I'm suggesting are: CROSS-ISO - These link across an ISO-3166 boundary EXCESS - These were added despite the locations having the same timekeeping since 1970 RENAMED - These are simple aliases/renames OBSOLETE - These are the most obsolete form of IDs FIXED - These are alternate names for fixed offsets I don't expect this PR to be merged as is - There will probably need to be some consideration as to the correct split, and as to whether each ID is in the correct section. The approach I've used is commented sections with stable section names. Alternate approaches to this problem are possible. For example, a new file could be created for each section. That seems to be more disruptive than the proposed approach. Note that in order for this change to be useful, the section names need to be considered part of the source file API, and maintained over time. thanks Stephen

5 16

Re: [tz] tz Digest, Vol 122, Issue 22
by nadir altinbas Nov. 14, 2021

Nov. 14, 2021

@ Comment; Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) May I remind to Alan Mintz ;On the "en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population" list shows that Turkey is in Asia, One of the region where is called as Marmara region is in Europe . Turkey is in both of Asia and Europe. Coordinates for Turkey as follows; ------------------------------------------- Latitude: 38° 57' 26.43" N Longitude: 35° 14' 26.67" E ------------------------------------------ also in GPS DD coordinate; 38.9573415 35.240741 ----------------------------------------- Nadir Altinbas nadiraltinbas(a)yahoo.com n.altinbas On Sunday, November 14, 2021, 05:27:55 PM GMT+3, tz-request(a)iana.org <tz-request(a)iana.org> wrote: Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..." Today's Topics: 1. Re: Time(Winter-summer) setting discussions in Turkey and research about it (nadir altinbas) 2. Re: Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Nov 2021 15:36:25 +0000 (UTC) From: nadir altinbas <nadiraltinbas(a)yahoo.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <2020539311.1385787.1636817785458(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Ok ! Paul, Thanks,wikipedia correction explanation was better. Nadir Altinbas n.altinbas On Saturday, November 13, 2021, 11:15:33 AM GMT+3, Paul Eggert <eggert(a)cs.ucla.edu> wrote: Thanks for the heads-up. If Turkey actually changes its time zones or daylight-saving rules please let us know. I hope they give us plenty of warning (such as a year or more); otherwise, their cell phones and/or computers will likely be off. One minor point. The text says "Saatlerini de?i?tirmeyen en b?y?k ?lkeler ?in, Hindistan ve Japonya" which Google translates as "The largest countries that do not change their clocks are China, India and Japan." Using the Wikipedia list of countries by population[1], the ten most populous countries that do not observe daylight saving time are China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, Japan, and Ethiopia, in that order. [1] https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… ------------------------------ Message: 2 Date: Sat, 13 Nov 2021 10:48:15 -0800 From: Alan Mintz <alan.mintz(a)gmail.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org>, nadir altinbas <nadiraltinbas(a)yahoo.com> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <CAMLM5-Vkqs_k7HkGy+MPwWGcjAUzRXhu4OOkAdFywvy-Ppj5rw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Sat, Nov 13, 2021 at 12:15 AM Paul Eggert via tz <tz(a)iana.org> wrote: > ... Using the Wikipedia list of countries by population[1], the ten > most populous countries that do not observe daylight saving time are > China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, > Japan, and Ethiopia, in that order. > > [1] > > https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… > Kind of a misleading statistic, though, since Indonesia straddles the equator and much of Brazil, Nigeria, and Ethiopia are within 15 degrees latitude, making DST unnecessary for them. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Time(Winter-summer) setting discussions in Turkey and research about it
by nadir altinbas Nov. 13, 2021

Nov. 13, 2021

Thank You Paul! Resending e -mail message as plain Text as follows.Amendment e -mail; GMT+2.30 adviced by Turkeys Electrical Engineers Society (TMMOB-EMO) for eficiently enery usage in the country, on the news dealing with conflict while settings winter and summer time through organization. here is the link about news as Turkish; (www.emo.org.tr/genel/bizden_detay.php?kod=136372&tipi=5&sube=0) There also mentioned a research by ITU (Istanbul technical University research about time arrangement. These are just discussions and advice not officially anouncment. nadiraltinbas(a)yahoo.com Nadir Altinbas n.altinbas

3 3

Tİme zone discussions in Turkey and research about it
by nadir altinbas Nov. 12, 2021

Nov. 12, 2021

For GMT +2.30 adviced from Turkey's Electrical Engineers Society (TMMOB-EMO) reported on Social mediato efficient energy usage in Turkey. news here on the link as follows;EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | | | | | | | | | EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | This research is not official now.It may be considered future plan nadiraltinbas(a)yahoo.com n.altinbas

1 0

Pre-1970 data
by Stephen Colebourne Nov. 12, 2021

Nov. 12, 2021

How can this project successfully handle pre-1970 data? Why have I focussed so much on IDs and their value to tzdb? Intro ------- In previous threads I've focussed on IDs, and laid out different ways to describe the groups of IDs we have. For now, lets focus solely on the two main groups - region IDs, which represent abstract regions where clocks have been the same since 1970 - non-region IDs, which represent locations where tzdb has, at some point, added an ID The key observation is that the segregation between these two groups of IDs *did not exist* until around 2014. It was only in 2018 that the ISO country rule was removed. It has only been since 2014 or so that IDs have been merged. What tzdb previously offered was a set of IDs, based on a simple rule - "ID as needed for post-1970 data, with at least one per ISO country". Full history was available for each of these (whether accurate or not). What has happened since is a split, where no split previously existed. A split which favours some locations over others. The recent mailing list debates merely represent the cumulation of this favouritism. The irony is that the merges are being done in the name of equity and fairness, when the outcome has actually been the exact opposite - picking favourites, and denigrating everywhere else. That the approach to picking favourites is according to a standardised largest city rule isn't really that relevant here - it is the outcome that is unfair, not the process. If region IDs were of different appearance (eg. numeric or textually different) then the issues would not have arisen. The mistake was taking a fully functional and fully integral set of IDs, and bifurcating it into two groups. The split was actually a huge change in the policy of tzdb, which has been added drip by drip, rather than something that was ever fully appreciated up front. FWIW, it is clear to me that there is an aspect of imposing a US-centric timezone system on other parts of the world. The recent tzdb approach of focussing entirely on timezone regions makes perfect sense for the US, where region boundaries do not follow state lines, and ordinary members of the public need to be aware of whether they are in US/Mountain or US/Central. This simply isn't the timezone model in many other parts of the world. In places like Europe and Asia, the timezone is driven primarily by the country you live in - an ordinary member of the public in Iceland is never going to associate with some abstract timezone region stretching down the Atlantic that is not named, not legally defined and is little more than a random outcome based on tzdb's choice of 1970. Even in somewhere like Norway, an ordinary member of the public will understand that although they follow CET, their timezone is actually driven by their Government in Oslo. The brilliance of the original rule - "ID as needed for post-1970 data, with at least one per ISO country" - was that it seamlessly handled *both* models of timezone in one unified set of IDs. Removal of the ISO country part has completely destabilised that balance. As a constraint to this thread, tzdb really needs to offer one standard view of data, not command line flags that allow different views. If downstream projects end up with different views of the data, it makes tzdb a much less reliable source. (tzdb can be packaged in different ways on the same machine, for example it is undesirable for Postgres' internal tzdb and the OS tzdb to diverge for the same version). Given this, what needs to be nailed down is what is the default data set that tzdb publishes - there isn't really much point in talking about compile time flags, or that the contents of backzone could be used by someone. Lets look at seven options for pre-1970 data: Pre-1970 data for regions only ----------------------------------------- 1) Pre-1970 data for regions only - Despite looking identical to other IDs, region IDs are treated as special/favoured - Pre-1970 data for non-region IDs is of no importance whatsoever, thus most get pre-1970 data from another country/continent - The split between region and non-region locations is fully completed - the US-centric timezone model is dominant - An end user in Iceland is supposed to use Africa/Abidjan, Europe/Reykjavik is treated as a historical mistake of tzdb kept around only for backwards compatibility Pre-1970 data for most IDs ------------------------------------ 2) Pre-1970 data for each ID meeting the rule "ID as needed for post-1970 data, with at least one per ISO country" - The split between region and non-region locations is healed - High quality data from places like Iceland and Norway is retained, but low quality data from elsewhere is restored - The pre-1970 data is simply viewed as the best available data for the each location which can be improved over time - Most end-users in Iceland would expect tzdb to provide pre-1970 data from Iceland, not the Ivory Coast 3) Pre-1970 data for for all IDs that currently exist except true aliases - This is very similar to #2, but would include something like Montreal which was effectively mistakenly added to tzdb - This doesn't seem as desirable as #2 4) Pre-1970 data for any ID where the pre-1970 data is high quality - Subjective on quality, which doesn't seem like a great idea - It does avoid bringing bad quality data back into the main tzdb distribution - On balance, #2 has fewer places for debate to arise 5) Pre-1970 data for all IDs that currently exist except true aliases, plus a *new* set of IDs representing regions - As per #2, but adding IDs like "Region/12345" or "Region/Berlin" - Regions should contain post-1970 data only, as the region is by definition only meaningful post-1970 - It is not entirely clear what this solves over just going with #2 - This option is connected to Russ' proposals [1], although he suggests a bigger split between timekeeping data and ID naming - Perhaps it makes sense if the new region IDs were internal and not normally seen by end users? Remove pre-1970 data from general use ------------------------------------------------------- 6) No pre-1970 data whatsoever, all IDs are post-1970 only - Project policy is that tzdb is focussed on post-1970 data only - Paul repeatedly tells us that pre-1970 data is unreliable, and people shouldn't use it - Pre-1970 data would not be deleted, but would not be available in most downstreams - The split between region and non-region locations is effectively healed - End users lose access to pre-1970 data, which is particularly notable in some locations where that data is reliable, eg London - It is unknown at this point what the user impact is of removing pre-1970 data from major financial/business centres (no major location has yet been merged) 7) No existing IDs get pre-1970 data, but a *new* set of IDs are created containing it - As per #5, the existing IDs get no pre-1970 data and the split between region and non-region locations is healed - New IDs, such as "Historic/Europe/London" or "Historic/Africa/Abidjan" get created for each of the main IDs - The historic IDs include pre-1970 data, the standard IDs do not - There is a mechanical transformation between the historic and non-historic IDs - Whether downstreams do or do not include the historic IDs is their choice, potentially based on available space - The data provided by the standard non-historic IDs remains the same whether the downstream includes the historic IDs or not (a Good Thing) - Users have to deliberately opt-in to get pre-1970 data, which might make them think about the accuracy issue Notes -------- - I'm not discussing adding new IDs simply to represent locations whose clocks differ only before 1970. I don't personally think that is a job for tzdb, and even if it is, it is a job for a different thread. - I'm not discussing what value is returned prior to 1970 when pre-1970 data is removed. That would be a job for a different thread. - Link vs Zone is not important for this discussion. Summary ------------- After a few weeks of thinking, these are the options I've come up with. Feel free to suggest another option or variant if you think I've missed anything obvious. I believe that was a disaster that the brilliant "ID as needed for post-1970 data, with at least one per ISO country" rule was removed. It has created needless division, bifurcating a unified set of ID into region and non-region IDs and creating backwards compatibility issues in the data of many locations. IMO, there are two basic models of timezones in the world, and moving tzdb from one that supported both to one that only supports the US-centric model is simply a mistake that needs correcting. As such, my preference would be to adopt option 2. Option 6 or 7 could work, and might be the best choices if we had a clean slate or if there was some hidden pressure that the list is unaware of to remove pre-1970 data, but they are risky options given we do not know the impact on end-users in major financial/business centres. Stephen [1] https://mm.icann.org/pipermail/tz/2021-September/030518.html

23 59

The link-name, America/Virgin, is linked to two zones in 'backzone'
by Yan-Jie Wang Nov. 12, 2021

Nov. 12, 2021

A link-name (the second column of the Link line) in a file should be unique. However, 'America/Virgin' is linked to two zones (America/Port_of_Spain and America/St_Thomas) in 'backzone'. The error is in the latest commit as well as in the archive tzdata2021e.tar.gz. The link to the file: https://github.com/eggert/tz/blob/6c15079/backzone Yan-Jie Wang

2 1

Re: [tz] What are the interfaces to the TZDB?
by Brian Park Nov. 10, 2021

Nov. 10, 2021

(Replying back to the list with permission) On Tue, Nov 9, 2021 at 11:45 AM Eliot Lear <lear(a)lear.ch> wrote: > On 09.11.21 20:38, Brian Park wrote: > > Is the TZDB project intended to support only POSIX systems? > > It's a fair question. Before we say, “no”, I would like to understand > what sort systems use the database that themselves are *NOT* POSIX > compliant. But also, as Paul pointed out, the binary format itself is > standardized at the IETF, the sponsor of this shindig. > > We could go up the stack, but before we do so, we should be clear on our > reasons as to why we are doing so. And so when you say: > > My downstream usage does not have a file system, or even an operating > system. For me, the API into the TZDB project are the raw files, but I > understand that my usage is unusual. > > Would you mind being a bit more specific? Are you printing a book? ;-) > Not that primitive... My libraries run on bare-metal, embedded microcontrollers, with no operating system. My first version is in C++, supporting all Zones and Links in about 36kB of flash (8-bit controllers) to 44kB of flash (32-bit controllers), without using 64-bit integers. I have another version in Python that I hope to convert to MicroPython soon. I'm hoping to write another version in Go lang, which will be converted into TinyGo. Brian

2 1

Re: [tz] Pre-1970 data
by dpatte Nov. 5, 2021

Nov. 5, 2021

I was be contributing a longer message on this whole subject within a few days, but I want to state upfront that country/city is insufficient in many countries for a fully expandable location database.Off the top of my head, I can think of three different Richmonds in Canada. One in Quebec, one in Ontario, and one in BC. I know there are many Springfields in many USA states, and let's not even talk about the potential USA/Columbus.The key of a database should be unique and recognizable. For many countries, multiple levels of government are the only way to properly differentiate cities.Canada/British_Columbia/Richmond would be more appropriate.This allows the pre-1970 db to be both infinitely expandable, as well as user friendly to the point of being fully obvious to all users.Sent from my Galaxy -------- Original message --------From: Brian Park via tz <tz(a)iana.org> Date: 2021-11-05 11:27 (GMT-05:00) To: Philip Paeps <philip(a)trouble.is> Cc: Stephen Colebourne <scolebourne(a)joda.org>, Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Pre-1970 data On Thu, Nov 4, 2021 at 10:11 PM Philip Paeps <philip(a)trouble.is> wrote:On 2021-11-05 12:17:34 (+0800), Brian Park via tz wrote: > I get the impression that this debate is caused by the existence of 2 > different schools of thought: [...] > > I want to suggest that it may be possible for these 2 views to > coexist. They de facto coexist right now. The overwhelming majority of the data are descriptive. Only recent efforts have made some of the post-1970 data appear more prescriptive.They coexist in an ad hoc manner right now, and that seems to be one of the causes for the contention. I am suggesting that we formalize the separation, so that both groups are happier. > We > could create a new file, e.g. call it 'countryzone', which contains a > set > of Links organized in a hierarchical tree by country, pointing to the > Core > zones. I strongly believe we should continue to carefully avoid attempting to group data by country. [I would even avoid using the word "country" wherever possible.]Can you explain why? Because it will cause arguments about disputed places? I think only a small minority of places around the world are disputed. By separating these ISO-country timezones into a 'countryzone' file, perhaps we can confine the debate into a smaller section of the TZDB. We could create duplicate entries (i.e. Country1/City, Country2/City), or create a pseudo-country called "Disputed" (i.e. Disputed/City). The point is, we can create policies that govern these disputed regions.Could we move 'countryzone' into a separate project? Probably, but some amount of initial coordination and refactoring would be required to resolve conflicting zone identifiers.Overall, I feel like the TZDB data should lean a bit more towards matching how end-users think about timezones in the real world (Prescriptive), and lean slightly less on treating timezones as a clustering problem (Descriptive). But I can see pros and cons of both approaches. Which is why I am suggesting ways to make the 2 approaches interoperate better. > For the pre-1970 data, it is my understanding that the 'backzone' file > contains Zone records which should replace ONLY the LinkMerged records > found in the other files. I propose that all LinkMerged records be > extracted into a separate file (let's call it 'mergedzone') so that > there > is a clear symmetry between 'backzone' and 'mergedzone', which allows > them > to be substituted for each other. The dependency diagram looks > something > like this: As I've suggested before in another thread, I think we should consider undoing the split into backzone. I really liked Stephen's phrasing earlier in this thread: acceptably accurate, not outrageously wrong. We started moving data to backzone to limit the scope of 'active' maintenance to post-1970 data. That artificial split led us towards a more prescriptive worldview. It seems clear that prescriptive simply does not work for a real world with people on it.I think Paul Eggert has made it clear that he does not want to maintain this data. My proposed refactoring of this info into the 'backzone' / 'mergedzone' pair makes it easy for downstream libraries to add back the 'backzone' data if they want. The 'make PACKRATDATA=backzone' hack does not help downstream libraries which do not use TZif or the Makefile. > If there is any chance that this will result in being able to type > "Canada/Toronto" instead of "America/Toronto", that would resolve an > annoyance that has lasted some 30-35 years. In this context, America refers to the landmass, not to the political entity occupying a large chunk of it. [Canada/Eastern etc moved to backward around 1993, as far as I can tell.]Virtual no one in the world thinks of "America" as referring to all of "North America" and "South America".Brian

2 1

Ref: Tz on social media
by nadir altinbas Nov. 4, 2021

Nov. 4, 2021

is it possible to add 'news' from TZ Coordiation web site share button to social media such as; Linkedin,FaceBook(meta),Instagram,Twitteretc.... There may be occur an anouncment to publicize for sharing via social media? Nadir Altinbas Estanbul /TR, 2021 Nov,2 nadiraltinbas(a)yahoo.com n.altinbas

2 2

event of interest: Future of Europe debates – The end of DST: how can it be placed back to the European agenda?
by BASTIAN Michelle Oct. 28, 2021

Oct. 28, 2021

Hi all, I was just at events for the Barcelona Time Use initiative time use week 2021 and the panel on changing DST in Europe was very interesting and I thought some of you might want to take a look. It is free to sign up and you can access recordings of all the events including the one on time zones/DST. Description and link below. Loved that there was lots of talk about there being no problem having many more time zones in Europe as ‘our computers handle all of that for us now’. https://timeuseweek.beplanet.tv/en/ Future of Europe debates – The end of DST: how can it be placed back to the European agenda? In 2019, the European Parliament agreed to end the biannual clock change. Nevertheless, the Member States have not been able to achieve an agreement on which time zone has to be adopted. This debate explores how can we place back the debate on the European and Member States agenda. Representative of European Parliament Pending to confirm Maria Nikolopoulou European social and economic council Ticia Luengo International Association for Natural Time Till Roenneberg World Federation of Societies for Chronobiology Best, Michelle. --- Dr Michelle Bastian Mid-Career Fellow, Independent Social Research Foundation (Project info<https://www.isrf.org/fellows-projects/michelle-bastian/>) Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

3 2

Re: [tz] tzcode2021e: uninitialized variable in localtime.c
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

On 10/22/21 07:49, Christos Zoulas wrote: > My linter reports "prevcorr" is uninitialized in the if statement > below the comment that starts "To avoid other botches". Thanks for mentioning that. This prompted me to find an obscure bug in localtime that would cause it to access an uninitialized local variable (which is undefined behavior) in cases involving 32-bit time_t code reading malformed 64-bit data. I installed the attached patch to fix the bug, and I hope this also pacifies your linter.

2 1

[PROPOSED] Be more generous when dealing with v1 data
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

* NEWS: Mention this. * localtime.c (tzloadbody): In version 2 and later files, do not attempt to validate the version 1 header and data block; instead, ignore them except for the purpose of skipping over them, as per a recommendation in RFC 8536 section 4. Also, when the TZif file is version 1 and we break out near the end of the loop, do so only after altering nread and memmoving any later data; this avoids having later code attempt to parse the version 1 header as if it were a TZ string. --- NEWS | 6 +++++ localtime.c | 71 +++++++++++++++++++++++++++++++---------------------- 2 files changed, 47 insertions(+), 30 deletions(-) diff --git a/NEWS b/NEWS index d4a9823..0f684f7 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,12 @@ Unreleased, experimental changes Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) + When reading a version 2 or later TZif file, the TZif reader now + validates the version 1 header and data block only enough to skip + over them, as recommended by RFC 8536 section 4. Also, the TZif + reader no longer mistakenly attempts to parse a version 1 TZIf + file header as a TZ string. + Release 2021e - 2021-10-21 18:41:00 -0700 diff --git a/localtime.c b/localtime.c index 6d736b2..39ef6e3 100644 --- a/localtime.c +++ b/localtime.c @@ -434,35 +434,45 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (close(fid) < 0) return errno; for (stored = 4; stored <= 8; stored *= 2) { - int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); - int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); - int_fast64_t prevtr = -1; - int_fast32_t prevcorr; - int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); - int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); - int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); - int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); - char const *p = up->buf + tzheadsize; - /* Although tzfile(5) currently requires typecnt to be nonzero, - support future formats that may allow zero typecnt - in files that have a TZ string and no transitions. */ - if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS - && 0 <= typecnt && typecnt < TZ_MAX_TYPES - && 0 <= timecnt && timecnt < TZ_MAX_TIMES - && 0 <= charcnt && charcnt < TZ_MAX_CHARS - && (ttisstdcnt == typecnt || ttisstdcnt == 0) - && (ttisutcnt == typecnt || ttisutcnt == 0))) - return EINVAL; - if (nread - < (tzheadsize /* struct tzhead */ - + timecnt * stored /* ats */ + char version = up->tzhead.tzh_version[0]; + bool skip_datablock = stored == 4 && version; + int_fast32_t datablock_size; + int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); + int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); + int_fast64_t prevtr = -1; + int_fast32_t prevcorr; + int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); + int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); + int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); + int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); + char const *p = up->buf + tzheadsize; + /* Although tzfile(5) currently requires typecnt to be nonzero, + support future formats that may allow zero typecnt + in files that have a TZ string and no transitions. */ + if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS + && 0 <= typecnt && typecnt < TZ_MAX_TYPES + && 0 <= timecnt && timecnt < TZ_MAX_TIMES + && 0 <= charcnt && charcnt < TZ_MAX_CHARS + && 0 <= ttisstdcnt && ttisstdcnt < TZ_MAX_TYPES + && 0 <= ttisutcnt && ttisutcnt < TZ_MAX_TYPES)) + return EINVAL; + datablock_size + = (timecnt * stored /* ats */ + timecnt /* types */ + typecnt * 6 /* ttinfos */ + charcnt /* chars */ + leapcnt * (stored + 4) /* lsinfos */ + ttisstdcnt /* ttisstds */ - + ttisutcnt)) /* ttisuts */ + + ttisutcnt); /* ttisuts */ + if (nread < tzheadsize + datablock_size) + return EINVAL; + if (skip_datablock) + p += datablock_size; + else { + if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) + && (ttisutcnt == typecnt || ttisutcnt == 0))) return EINVAL; + sp->leapcnt = leapcnt; sp->timecnt = timecnt; sp->typecnt = typecnt; @@ -578,13 +588,14 @@ tzloadbody(char const *name, struct state *sp, bool doextend, ttisp->tt_ttisut = *p++; } } - /* - ** If this is an old file, we're done. - */ - if (up->tzhead.tzh_version[0] == '\0') - break; - nread -= p - up->buf; - memmove(up->buf, p, nread); + } + + nread -= p - up->buf; + memmove(up->buf, p, nread); + + /* If this is an old file, we're done. */ + if (!version) + break; } if (doextend && nread > 2 && up->buf[0] == '\n' && up->buf[nread - 1] == '\n' && -- 2.31.1

1 0

Extra transition type is generated by zic with -r specified
by Almaz Mingaleev Oct. 26, 2021

Oct. 26, 2021

I’ve tried to generate a TZif file with transitions up to 1 Jan 2100 using zic with -r and “-b fat”. However, an extra transition type is generated for many (all?) time zones. That type’s UTC offset is zero and it is used only for the last transition in the 64-bit section. What I did: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data ./zic -b fat -r /@4102444800 -d ./data rearguard.zi Below is an investigation for Australia/Lord_Howe (I don’t think choice matters here). I couldn’t find a way to force zdump to print transitions for a given TZif file. Instead, please see human-readable dumps from the TZif from our internal tools immediately below and raw byte information at the bottom if you’d prefer to work with that. These are local time transition types for Australia/Lord_Howe: Types gmtOffset (seconds),isDst,ttisgmt,ttisstd,[gmtOffset ISO],[DST?] 38180,0,,,PT10H36M20S,STD 0,0,,,PT0S,STD <- this is odd 36000,0,,,PT10H,STD 41400,1,,,PT11H30M,DST 37800,0,,,PT10H30M,STD 39600,1,,,PT11H,DST Transitions: transition,type,[UTC time],[Type offset],[Type isDST] … 4063275000,5,2098-10-04T15:30:00Z,PT11H,DST 4078998000,4,2099-04-04T15:00:00Z,PT10H30M,STD 4094724600,5,2099-10-03T15:30:00Z,PT11H,DST 4102444800,1,2100-01-01T00:00:00Z,PT0S,STD <- this is odd So, after the upper bound specified in -r, the transitions say that GMT is used. As I’d expect, the 32-bit transitions are not affected when the upper bound in -r is after 2038. However, with -r /@1634833073 the 32-bit section also has 6 transition types and the last transition sets offset to 0. Is that a bug or is there a reason for such behaviour? Thanks, Almaz Byte manipulations: typecnt is 5 in 32-bit section: xxd -seek 36(4+1+15+4*4) -len 4 data/Australia/Lord_Howe 64-bit section starts at offset 674. timecnt is 0xF0(=240) in 64-bit section: xxd -seek 706(674 + 20 + 3 * 4) -len 4 data/Australia/Lord_Howe typecnt is 6 in 64-bit section: xxd -seek 710(706 + 4) -len 4 data/Australia/Lord_Howe So, 64-bit header has one extra transition type. Let’s check how it is used and what that transition is: 2638 = 674 + 44 + 240 * 8 xxd -seek 2638 -len 240 -c 1 data/Australia/Lord_Howe prints transition types: 00000b38: 05 . 00000b39: 04 . 00000b3a: 05 . 00000b3b: 04 . 00000b3c: 05 . 00000b3d: 01 . Transition type is changing from 4 to 5, but the last one is 1. xxd -seek 2878 -len 36 -c 6 data/Australia/Lord_Howe prints local time type records: 00000b3e: 0000 9524 0004 ...$.. 00000b44: 0000 0000 0000 ...... <- the last transition type 00000b4a: 0000 8ca0 0008 ...... 00000b50: 0000 a1b8 010d ...... 00000b56: 0000 93a8 0013 ...... 00000b5c: 0000 9ab0 0119 ...... Which means that 1st type’s offset is 0 and that the last rule for Lord Howe is actually GMT.

2 4