October 2020 - tz - lists.iana.org

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

March 19, 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

Italy April 1944 discrepancy between comment and data
by Alois Treindl Oct. 6, 2021

Oct. 6, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

FW: [Ext] The TZ Coordination
by Naela Sarras April 3, 2021

April 3, 2021

Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf <afaf(a)anrt.ma> Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras <naela.sarras(a)iana.org> Cc: BENLEMLIH Hamida <benlemlih(a)anrt.ma> Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg@01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

9 16

[PROPOSED] Port 'make rearguard_tarballs' to Solaris 10
by Paul Eggert Oct. 28, 2020

Oct. 28, 2020

* Makefile (tarballs, etc.): Export AWK to submake, for Solaris 10 which needs something like 'make AWK=nawk rearguard_tarballs'. (.KEEP_STATE): Remove. .KEEP_STATE is a Solaris 'make' feature that breaks 'make rearguard_tarballs' because it causes submakes to mistakenly consider files to be out-of-date. As .KEEP_STATE is not specified by POSIX and is ignored by GNU 'make' it should not be needed. --- Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Makefile b/Makefile index a0b6aeb..5064a19 100644 --- a/Makefile +++ b/Makefile @@ -1012,7 +1012,7 @@ tarballs rearguard_tarballs traditional_tarballs \ signatures rearguard_signatures traditional_signatures: \ version set-timestamps.out rearguard.zi VERSION=`cat version` && \ - $(MAKE) VERSION="$$VERSION" $@_version + $(MAKE) AWK='$(AWK)' VERSION="$$VERSION" $@_version # These *_version rules are intended for use if VERSION is set by some # other means. Ordinarily these rules are used only by the above @@ -1110,8 +1110,6 @@ strftime.o: private.h tzfile.h zdump.o: version.h zic.o: private.h tzfile.h version.h -.KEEP_STATE: - .PHONY: ALL INSTALL all .PHONY: check check_time_t_alternatives .PHONY: check_web check_zishrink -- 2.25.1

1 0

Israel DST
by P Chan Oct. 28, 2020

Oct. 28, 2020

Here is a full list of the orders related to the DST in Mandatory Palestine/Israel in 1940-2004.

4 5

Yukon and the zone.tab file
by Chris Walton Oct. 27, 2020

Oct. 27, 2020

The two Yukon entries in the zone.tab file still have descriptions with the name "Pacific": CA +6043-13503 America/Whitehorse *Pacific* - Yukon (east) CA +6404-13925 America/Dawson *Pacific* - Yukon (west) Please consider changing the descriptions to something like this: CA +6043-13503 America/Whitehorse *MST* - Yukon (east) CA +6404-13925 America/Dawson *MST* - Yukon (west) Thank you. -chris

2 1

State of Palestine Time zone - need to update
by heba.hamad＠mtit.gov.ps Oct. 26, 2020

Oct. 26, 2020

,Dear Sir.I’m Heba Hamad .I have been appointed as a focal point by the Ministry of telecommunication and information technology (state of Palestine) to communicate with you I’m contacting you in regard to the time zone data base the field related to the state of Palestine. I checked the published data regarding the time zones related to Palestine and noticed that it’s not accurate, and hence I would like to ask for an update to the time zone data base related to Palestine to be as follow PS State of Palestine Asia/AlQuds UTC +2:00 :Instead of the following data PS State of Palestine Asia/Gaza UTC +2:00 PS State of Palestine Asia/Hebron UTC +2:00 .Kindly advise if any documents, information or procedures are needed from our side ,Best Regards

3 2

My public key via GitHub and WKD for verifying tzdb distributions
by Paul Eggert Oct. 26, 2020

Oct. 26, 2020

Recently users have had trouble verifying tzdb releases because they could not obtain the GPG public key that I use to sign the releases. These problems stem from the denial-of-service attacks on public keyservers last year, combined with my extending the expiration of my longstanding public key, which had been due to expire in August. The expiration-date extension had problems propagating to public keyservers that use the traditional method of key distribution. To try to help ameliorate this problem I recently did two things. First, I uploaded my public key to the development repository on GitHub. You can now use <https://github.com/eggert/tz/tags> to verify every tzdb release starting with 2012e. (Older releases are not tagged, as discussed in the 2013f NEWS entry.) Second, at my suggestion the UCLA Computer Science Department has added WKD support to cs.ucla.edu, and you can now verify my key independently via WKD. See an example below for how to do this. In the longer term, the IANA have been working on a way to have IANA authorities sign distributions, and eventually we hope to have something implemented along those lines. Thanks to Phil Pennock for his suggestions and help in improving the process of verifying tzdb distributions. PS. For more about last year's denial-of-service attacks and the use of WKD instead of traditional public keyservers, please see: Osborne C. PGP SKS key network poisoned by unknown hackers. ZDNet. 2019-07-04. https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/ Koch W. OpenPGP Web Key Directory. Active Internet-Draft. 2020-05-26. https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ What is a Web Key Directory? GnuPG e.V. 2020-07-06. https://wiki.gnupg.org/WKD PPS. Here is one way to verify a key via WKD, using the 'gpg' shell command. You'll need a recent-enough GnuPG: version 2.1.23 (2017-08-23) or later should suffice. $ gpg --auto-key-locate wkd --locate-keys eggert(a)cs.ucla.edu gpg: key ED97E90E62AA7E34: public key "Paul Eggert <eggert(a)cs.ucla.edu>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found pub rsa4096 2010-09-03 [SC] [expires: 2021-08-31] 7E3792A9D8ACF7D633BC1588ED97E90E62AA7E34 uid [ unknown] Paul Eggert <eggert(a)cs.ucla.edu> sub rsa4096 2010-09-03 [E] [expires: 2021-08-31]

1 0

Re: [tz] tz leap-seconds.list
by Paul Eggert Oct. 26, 2020

Oct. 26, 2020

On 10/25/20 10:45 AM, Kristin Minchev wrote: > The [leap-seconds.list] file itself doesn't have any license information > (nor NIST's). Under current US law a file that contains no license information normally defaults to being copyrighted with no license granted. The NIST is an arm of the US government, though, so under US law its publications are public domain so we don't have to worry about redistributing the NIST file even though it contains no license info. I just now searched for the top ten "leap-seconds.list" hits on Google. The #1, #3, #4, #6, #7 and #9 hits were about the NIST file, and of these all but #9 were about the tzdb copy of the NIST file (#9 was unclear). The #5 and #10 hits were about the IERS file. (#2 and #8 were false matches.) So even though the IERS file is published by the primary source for leap seconds, licensing issues have prevented the IERS file from being the most popular in practice. We've attempted to contact the IERS multiple times to get its file's license clarified, but haven't made much progress. > And most of the data comes from IERS anyway. That's fine: under US law, data cannot be copyrighted. There was a court case about this; see <https://www.eff.org/press/releases/eff-wins-protection-time-zone-database>. I installed the attached patch to the tzdb development repository to try to explain this all a bit better, without getting too long-winded about it.

1 0

Time in Kenya
by P Chan Oct. 25, 2020

Oct. 25, 2020

The standard time of GMT+2:30 was adopted in the East Africa Protectorate on 1 May 1908. https://books.google.com/books?id=e-cAC-sjPSEC&pg=PA274 At midnight on 30 June 1928 the clocks throughout Kenya was put forward half an hour by the Alteration of Time Ordinance, 1928. https://gazettes.africa/archive/ke/1928/ke-government-gazette-dated-1928-05… https://books.google.com/books?id=2S0S6os32ZUC&pg=PA813 The 1928 ordinance was repeal by the Alteration of Time (repeal) Ordinance, 1929 and the time was restored to GMT+2:30 at midnight on 4 January 1930. https://books.google.com/books?id=_g18jIZQlwwC&pg=PA2701 The Alteration of Time Ordinance, 1936 changed the time to GMT+2:45 and repealed the previous ordinance at midnight on 31 December 1936 . https://books.google.com/books?id=K7j41z0aC5wC&pg=PA705 The Defence (Amendment of Laws No. 120) Regulations changed the time to GMT+3 at midnight on 31 July 1942. https://books.google.com/books?hl=zh-TW&id=c_E-AQAAIAAJ&pg=PA331 The provision of the 1936 ordinance was not repealed and was later incorporated in the Interpretation and General Clauses Ordinance in 1948. Although it was overridden by the 1942 regulations. https://dds.crl.edu/item/217517 (p.101) In 1950, the Interpretation and General Clauses Ordinance was amended to adopt GMT+3 permanently as the 1942 regulations were due to expire on 10 December. https://books.google.com/books?id=jvR8mUDAwR0C&pg=PA787 https://books.google.com/books?id=-_dQAQAAMAAJ&pg=PA294

3 2