June 2020 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl 05 Oct '21

05 Oct '21

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 02 Apr '21

02 Apr '21

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

DST changes in Hungary (full historical revision)
by Nyáry Géza 12 Oct '20

12 Oct '20

Dear Paul! I examined it all of the Hungary daylight saving time changes. More differences I found what I repaired and I prepared it it source file, which I attach to this letter. I used Library Hungarica online database as a source, where from scanned contemporary ministerial decrees, instructions, newspapers and from other documents it was possible to find the time of the changes concerning the years. https://library.hungaricana.hu I checked the modified changes many times and I considered it right. If it's possible, I ask the exchange the attached modified Hungarian section in global database! Thank you very much! Bets regards, Géza Nyáry

5 11

Removing systemv, pacificnew, Rule TYPEs, zic -y
by Tim Parenti 04 Oct '20

04 Oct '20

I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti

3 3

Updating zic.c to further match Link line field names
by Tim Parenti 03 Oct '20

03 Oct '20

In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti

1 1

Re: [tz] Fwd: DST changes in Hungary (full historical revision)
by Paul Eggert 25 Jul '20

25 Jul '20

Thanks for those corrections. I installed the attached patch to the development database on GitHub. It's not exactly what you emailed me, but it should generate equivalent transitions. It'd help if we could list citations for the transitions; are URLs available for each decree etc. that you consulted? We could add them as comments. Thanks again.

9 33

Tim Parenti as backup TZ Coordinator?
by Paul Eggert 09 Jul '20

09 Jul '20

Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week.

12 13

North Vietnam 1970 to 1975 - Asia/Hanoi belongs into main file
by Alois Treindl 02 Jul '20

02 Jul '20

(Corrected subject line) The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

6 14

Re: [tz] Mirmalek on Martian timekeeping
by Paul Eggert 30 Jun '20

30 Jun '20

On 6/30/20 2:00 AM, BASTIAN Michelle wrote: > I wondered if you had come across this ethnography of mars working time https://brill.com/view/journals/kron/8/2/article-p159_7.xml?language=en No, I wasn't familiar with Mirmalek's work. I see she turned it into a book published in March. Thanks for the heads-up. I updated theory.html's discussion of Martian timekeeping based on the info you sent, and installed the attached patch. This patch also changes some tenses in the text, as the Mars Exploration Rover mission's second rover bit the dust in 2018 (literally: communications cut off during a planetwide dust storm).

1 0

re SPDX, I'll do the work, if you'll use the tag
by Mark Atwood 30 Jun '20

30 Jun '20

I was tagged in to this list because of the discussion about SPDX license tagging. I sit on the SPDX committee (which doesn't mean much, it's similar to an IETF WG, in that anyone who joins the list, joins the calls, and then does needed work is "on the committee"). It may be useful to have an SPDX tag for the TZ database data files. The SPDX makes nearly zero legal assessment about a license. Applying an SPDX tag to an existing project is intended to document reality in a machine readable way, it is not intended to change reality. Having an SPDX tag is mostly for the benefit of systems and companies who are trying to be scrupulously correct when complying with open source licenses. When the SPDX evaluates a license, the things looked for are "does/will it have real users?", "does it have a stable enough text that the matching tools can correctly identify it?", and "is it for content intended for mostly uncontrolled distribution?". We very much do not get into all the arguments about "is this well defined in europe", "is this a license or a public domain declaration", "is copyright even appropriate", "copyleft is theft", etc etc etc. We don't practice law, and we don't want to dictate policy, we just id licenses for people who just want to know they are doing the right thing when using your files, and make suggestions for projects that want to write a policy about it. Looking at the TZ database history, it has a very long history with lots of contributors, its mostly just a collection of facts, it appears to be a public domain declaration, that started out kind of adhoc. Using one of the existing PD declarations in the SPDX database would not be appropriate, because of the need to get the past contributors to assent, lots of work for no value. What does make sense is creating a new tag, something like "TZ-PD". Then you can start putting "# SDPX-License-Identifier: TZ-PD" in your database text source file, and make life easier for a bunch of people who just want to do the right thing with your data. To repeat, adding that SPDX license tag of a new identifer to id an existing stable in the field declaration, like this, does not change any legal obligations or expose anyone to any new legal risks. It's just a machine readable way of saying what's already been said about the copyright status of the TZ database. So, I'm willing to volunteer to do that lift for the TZ community, if you are willing to use the resulting id tag. What say you? ..m Mark Atwood <mark.atwood(a)gmail.com> https://keybase.io/fallenpegasus +1-206-604-2198

4 3