July 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] [IANA #1173666] Time zone change - Yukon Canada
by Andrew.Smith＠gov.yk.ca 30 Sep '20

30 Sep '20

Good day. I work for the Government of Yukon in Canada. We are in the process of revising our definition of time to be permanently on UTC -7, no longer observing a twice-annual time change. I was on the hunt for authoritative standards related to time, and saw the IANA come up as caretaker of the time zone database, which appears to be relied on for software and systems. I am contacting you to see if there is any process beyond notification to making this adjustment in your TZ database, and perhaps to know if there are other agencies that should be aware of what Yukon is planning. From what I see now, TZ database names "America/Dawson", "America/Whitehorse" and "Canada/Yukon" would be affected by this change. Our regulation is not yet complete, so it is not law at this time and I am not looking for immediate change. We are aiming for finalization here by November 1, 2020. Hope to hear from you soon. Andrew Andrew G. Smith Intergovernmental Relations Executive Council Office Government of Yukon C: 867-335-6008 -----Original Message----- From: Amanda Baber via RT <iana-questions(a)iana.org> Sent: July 2, 2020 3:48 PM To: Andrew.Smith <Andrew.Smith(a)gov.yk.ca> Subject: [IANA #1173666] Time zone change - Yukon Canada Dear Andrew, Thank you for contacting us. IANA hosts the Time Zone Database, but the database is managed by the Time Zone Coordinator in conjunction with a mailing list. You can find find mailing list information here: https://www.iana.org/time-zones This document should have or point to much of the information you're looking for: https://data.iana.org/time-zones/tz-link.html As is noted at the link above, "If your government plans to change its time zone boundaries or daylight saving rules, inform tz(a)iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%… for examples." Best regards, Amanda Baber Lead IANA Services Specialist On Thu Jul 02 22:20:44 2020, Andrew.Smith(a)gov.yk.ca wrote: > Good day. > > I work for the Government of Yukon in Canada. We are in the process of > revising our definition of time to be permanently on UTC -7, no longer > observing a twice-annual time change. > I was on the hunt for authoritative standards related to time, and saw > the IANA come up as caretaker of the time zone database, which appears > to be relied on for software and systems. I started with ISO 8601, but > couldn't see the full text to know if there are time zone standards > there. I am contacting you to see your TZ database is a widely adopted > and authoritative as it seems, to see if there is any process to > making this adjustment in your TZ database, and perhaps to know if > there are other agencies that should be aware of what Yukon is > planning. > From what I see now, TZ database names "America/Dawson", > "America/Whitehorse" and "Canada/Yukon" would be affected by this > change. > > Our regulation is not yet complete, so it is not law at this time and > I am not looking for immediate change. We are aiming for finalization > here by November 1, 2020. > Hope to hear from you soon. > > Andrew > > > [cid:image003.png@01D65084.40C16690] > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > C 867-335-6008 | Yukon.ca

10 23

tz database update on a publication & thank-you.
by Andrew Lyon 03 Aug '20

03 Aug '20

Several months ago I posted queries about the tz database to this discussion list as I investigated a series of errors triggered in software used to order and report clinical laboratory tests in our hospital network. Our main software system uses universal time for date& time of birth a recently added peripheral system (based on Android OS, and Java Joda-time that relies on the tz database) that triggered the peripheral system to freeze every few weeks. Investigation revealed that there were 10 years (between 1935 and 1945) in the America/Regina tz time zone data where the transition to daylight saving time occurred at midnight on spring transition dates. If our hospital (which is in the America/Regina time zone) encountered patients born on one of those spring daylight savings time transitions dates 1935-1945, the system froze, because the hour of birth was usually unknown and was assigned to midnight local time by default, and midnight local time on those dates does not map back to universal time. A software patch was quickly developed by the software provider and this susceptibility is now avoided. I understand now that this type of situation is well known to members of this group. I want to pass on a 'thank-you' to the tz database community for their helpful messages as this case was investigated. A description of this investigation was published today in the Journal of Applied Laboratory Medicine: "No Lab Tests" When You Are Born in The Twilight Zone: A Clinical Informatics Case Report. [ https://pubmed.ncbi.nlm.nih.gov/32728691/ | https://pubmed.ncbi.nlm.nih.gov/32728691/ ] best wishes, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan, SK, Canada

8 8

[PATCH] Update Bahrain as per article in The National
by Paul Eggert 25 Jul '20

25 Jul '20

* backzone (Asia/Bahrain): Adjust transitions before 1944 to match Ashleigh Stewart’s article in today’s The National (Abu Dhabi). --- backzone | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/backzone b/backzone index 91fa21d..7cf026d 100644 --- a/backzone +++ b/backzone @@ -459,7 +459,22 @@ Zone Asia/Aden 2:59:54 - LMT 1950 3:00 - +03 # Bahrain -Zone Asia/Bahrain 3:22:20 - LMT 1920 # Manamah +# +# From Paul Eggert (2020-07-22): +# Most of this data comes from: +# Stewart A. Why Gulf Standard Time is far from standard: the fascinating story +# behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. +# https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… +# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# others at +0323. Reginald George Alban, a British political agent based in +# Manama, worked to standardize this, and from 1941-07-20 Bahrain was at +# +0330. However, BOAC asked that clocks be moved to gain more light at day's +# end, so Bahrain switched to +04 on 1944-01-01. +# +# We don't know when companies chose +0330 or +0323 before 1940; for now +# assume that there was no real standard in Bahrain before 1941-07-20. +Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah + 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun 3:00 - +03 -- 2.17.1

4 4

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

[PROPOSED] * backzone: More commentary re 1940s Bahrain.
by Paul Eggert 23 Jul '20

23 Jul '20

--- backzone | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 7cf026d..f2684b4 100644 --- a/backzone +++ b/backzone @@ -460,19 +460,31 @@ Zone Asia/Aden 2:59:54 - LMT 1950 # Bahrain # -# From Paul Eggert (2020-07-22): +# From Paul Eggert (2020-07-23): # Most of this data comes from: # Stewart A. Why Gulf Standard Time is far from standard: the fascinating story # behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. # https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… -# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# Stewart writes that before 1941 some companies in Bahrain were at +0330 and # others at +0323. Reginald George Alban, a British political agent based in # Manama, worked to standardize this, and from 1941-07-20 Bahrain was at # +0330. However, BOAC asked that clocks be moved to gain more light at day's # end, so Bahrain switched to +04 on 1944-01-01. # -# We don't know when companies chose +0330 or +0323 before 1940; for now -# assume that there was no real standard in Bahrain before 1941-07-20. +# Re the 1941 transition, Stewart privately sent me this citation: +# "File 16/53 Enquiries Re: Calculation of Local Time", British Library: India +# Office Records and Private Papers, IOR/R/15/2/1564, in Qatar Digital Library +# https://www.qdl.qa/archive/81055/vdc_100000000282.0x00012b +# It says there was no real standard in Bahrain before 1941-07-20. +# +0330 was used by steamers of the British India Co, by Petroleum Concessions +# and by Cable & Wireless; +0323 was used by the Eastern Bank Ltd, BOAC, and +# Bahrein Petroleum (Bapco), and California Arabian Standard Oil Co (Casoc) +# adopted DST effective 1941-05-24. Alban suggested adopting DST, R.B. Coomb +# of C&W countersuggested +0330, and although C.A. Rodstrom of Casoc (formerly +# of Bapco) stated that Bahrain had formerly used +0330 before Bapco arrived +# but Bapco switched to +0323 because of "constant confusion", the consensus +# was +0330. The government adopted +0330 in 1941-07-20 and companies seem to +# have switched by 08-01. No time of day was given for the 1940s transitions. Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun -- 2.17.1

1 0