March 2021 - tz - lists.iana.org

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

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

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

Oct. 5, 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

Historical fix for Tonga
by Tim Parenti Sept. 14, 2021

Sept. 14, 2021

First, a quick clerical patch: 0001, attached, fixes the placement of a comment which got shuffled around in the lead-up to publishing the changes for South Sudan in 2021a. Patch 0003 relates to Tonga, and comes from some of the links P Chan shared to 1957–1963 editions of The Air Almanac: https://mm.icann.org/pipermail/tz/2021-February/029866.html On Thu, 25 Feb 2021 at 03:43, P Chan <legco(a)outlook.com> wrote: > 1960 Nov (1962.1-4) > https://books.google.com/books?id=bVgtWM6kPZUC&pg=SL1-PA20 > 1961 Mar (1962.5-8) > https://books.google.com/books?id=W2nItAul4g0C&pg=SL1-PA20 When looking around at how this data was presented for other regions, I noticed on the preceding pages (listing "Places Fast on GMT", i.e., east of Greenwich) in some of the earlier editions provided that Tonga was listed at GMT+12:20. The peculiar offset stuck out, and I quickly noticed that some of the later editions of the same tables had it at GMT+13. A quick bisection puts the changeover, as far as The Air Almanac contemporaneously reckoned it, between November 1960 and March 1961. Previously, our data had Tonga transitioning to UT+13 in 1941 based on a quotation from a 1997 news article. Although this differs from what the Almanac suggests by some 20 years, the article does mention a change coincident with the New Year, and that Tāufaʻāhau Tupou IV was Crown Prince at the time. As his predecessor and mother, Queen Sālote Tupou III, reigned from 1918-04-05 to 1965-12-16, a possible transition of 1961-01-01 still jives with the gist of the article, even if the specific year was perhaps wrong or just misprinted. For what it's worth, our commentary already noted that Shanks & Pottenger had put the transition even later, at 1968-10-01. Although of course we don't know how they arrived at that date, given that they did, 1961 seems rather less out-of-place than it otherwise might. The attached patch 0003 makes this adjustment, while more fully documenting and comparing the conflicting sources. Thanks again to P Chan for pointing us to these resources. I wasn't expecting to get a "bonus" correction out of it, but one never knows quite what will catch the eye… -- Tim Parenti

3 3

[PATCH 1/8] * tzfile.5: Fix prefix/suffix typo (thanks to Ian Abbott).
by Paul Eggert Sept. 14, 2021

Sept. 14, 2021

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index b4952d5..ec78689 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -134,7 +134,7 @@ bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the .B tt_desigidx values mentioned above. -The byte strings can overlap if one is a prefix of the other. +The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified. .IP * .B tzh_leapcnt -- 2.27.0

2 8

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

April 2, 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

Relation between Time Zone Abbreviation and Offset in Asia
by Evgheni Antropov March 30, 2021

March 30, 2021

Dear Tzdata Maintainers, Is it historically appeared in Asia, that several Locations have Offset only instead of Time Zone Abbreviation? I mean next location: Bangkok<https://www.timeanddate.com/time/zone/thailand/bangkok> from Thailand<https://www.timeanddate.com/time/zone/thailand> which is related with Vientiane<https://www.timeanddate.com/time/zone/laos/vientiane> from Laos<https://www.timeanddate.com/time/zone/laos> and Phnom Penh<https://www.timeanddate.com/time/zone/cambodia/phnom-penh> from Cambodia<https://www.timeanddate.com/time/zone/cambodia> - all of them is in Indochina Time<https://www.timeanddate.com/time/zones/ict>, but in repository for file asia they have only offset: https://github.com/eggert/tz/blob/main/asia#L3823 I don't know is it issue or typo, cause I didn't find any info when this Abbreviation was added https://en.wikipedia.org/wiki/UTC%2B07:00 For our customers, I added this step before compiling tzdata sources: # set Asia/Bangkok for Thailand to use name instead of digits in timezone, affecting on Asia/Vientiane for Laos and Asia/Phnom_Penh for Cambodia sed -i -e '/# Thailand/,/Vientiane/s/+07/ICT/' $(pwd)/asia but maybe it doesn't require and you will add corresponding changes in the main source code. BTW, during my investigation, I observed that several time zones have same behavior, ex.: Tajikistan<timeanddate.com/time/zone/tajikistan> - Asia/Dushanbe<https://www.timeanddate.com/time/zone/tajikistan/dushanbe> - TJT - Tajikistan Time<https://www.timeanddate.com/time/zones/tjt> https://github.com/eggert/tz/blob/main/asia#L3817 Turkmenistan<https://www.timeanddate.com/time/zone/turkmenistan> - Asia/Ashgabat<https://www.timeanddate.com/time/zone/turkmenistan/ashgabat> - TMT - Turkmenistan Time<https://www.timeanddate.com/time/zones/tmt> https://github.com/eggert/tz/blob/main/asia#L3834 United Arab Emirates<https://www.timeanddate.com/time/zone/united-arab-emirates> - Asia/Dubai<https://www.timeanddate.com/time/zone/united-arab-emirates/dubai> - GST - Gulf Standard Time<https://www.timeanddate.com/time/zones/gst> https://github.com/eggert/tz/blob/main/asia#L3839 Uzbekistan - Asia/Samarkand | Asia/Tashkent - UZT - Uzbekistan Time<https://www.timeanddate.com/time/zones/uzt> https://github.com/eggert/tz/blob/main/asia#L3851 Vietnam - Asia/Ho_Chi_Minh - ICT - Indochina Time<https://www.timeanddate.com/time/zones/ict> https://github.com/eggert/tz/blob/main/asia#L3920 Sri Lanka - Asia/Colombo - IST - India Standard Time<https://www.timeanddate.com/time/zones/ist> https://github.com/eggert/tz/blob/main/asia#L3645 Singapore - Asia/Singapore - SGT - Singapore Time<https://www.timeanddate.com/time/zones/sgt> https://github.com/eggert/tz/blob/main/asia#L3581 Saudi Arabia - Asia/Riyadh - AST - Arabia Standard Time<https://www.timeanddate.com/time/zones/ast-arabia> https://github.com/eggert/tz/blob/main/asia#L3565 Qatar - Asia/Qatar - AST - Arabia Standard Time<https://www.timeanddate.com/time/zones/ast-arabia> https://github.com/eggert/tz/blob/main/asia#L3518 Please give me explanation of this, is it correct to use Offset instead of Abbreviation or it will be fixed in future? Best regards, [cid:image001.jpg@01D72579.B94CFD20] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>

2 1

[PATCH] Update Crimea country codes in line with UN A/RES/73/263
by Dimitri John Ledkov March 27, 2021

March 27, 2021

"the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, temporarily occupied by the Russian Federation" is the preffered way to refer to the Crimean Peninsula as called upon by the A/RES/73/263 point 11. [1] Unfortunately there is no two letter country code to state precisely that. For internet & computer users however whenever any locale & location is derived from the zone.tab & zone1970.tab file formats results in most appropriate UX with a temporary RU country code. [1] https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 Note, that it is best read in conjuction with resolutions from previous and subsequent sessions. I.e. https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/68/262 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/71/205 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/72/190 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/194 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/73/263 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/74/17 https://www.un.org/en/ga/search/view_doc.asp?symbol=A/RES/75/29 Signed-off-by: Dimitri John Ledkov <xnox(a)ubuntu.com> --- Users from the Crimean Pensinsula are reporting issues when using computer systems. Many pieces of software derive and display location/country based on the zone.tab file format which doesn't reflect the widely internationally acknowledged (as ratified by UN general assembly resolutions) temporary occupation of the pensinsula by the Russian Federation. Currently, the currency in use is rubles; telephone country codes switch to +7, with old ones defunct; MasterCard/Visa networks replaced by MIR network; car license plates are issues with Russian area codes; local government *.gov.ua websites are defunct, replaced with *.gov.ru, e.g. https://sev.gov.ua/ => https://sev.gov.ru/; and so on. As this issue is causing distress to the users of the Internet, I hope that this proposed temporary updated could be included in the tzdata update. zone.tab | 8 ++++---- zone1970.tab | 6 ++++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/zone.tab b/zone.tab index 14fceb9..35e2493 100644 --- a/zone.tab +++ b/zone.tab @@ -331,10 +331,10 @@ RO +4426+02606 Europe/Bucharest RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# The obsolescent zone.tab format cannot represent Europe/Simferopol well. -# Put it in RU section and list as UA. See "territorial claims" above. -# Programs should use zone1970.tab instead; see above. -UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan diff --git a/zone1970.tab b/zone1970.tab index ddb2321..d699388 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -288,8 +288,10 @@ RO +4426+02606 Europe/Bucharest RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area -# Mention RU and UA alphabetically. See "territorial claims" above. -RU,UA +4457+03406 Europe/Simferopol Crimea +# "the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, +# temporarily occupied by the Russian Federation" +# Temporarily list as RU. See "territorial claims" above. +RU +4457+03406 Europe/Simferopol Crimea RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan -- 2.27.0

3 5

time zone history for the Cook Islands - Christmas Day Act 1899
by wtz＠worldtimezone.com March 25, 2021

March 25, 2021

Cook Islands changed its date from the west (Asia, New Zealand, Australia) side to the east (American) side on Christmas day 1899. In 1899 the Cook Islands celebrated Christmas twice to correct the calendar. According to the old books, missionaries were unaware of the International Date line, when they came from Sydney. Thus the Cook Islands were one day ahead. ".... The Christmas Day Act was designed to change the time to that of Tahiti and all other civilised places east of the 180th degree of longitude: it is a measure that has been strongly opposed by the Maoris on previous occasions ..." (Lieut-Colonel Gudgeon, 14 Sep, 1899) See references below: Discoverers of the Cook Islands and the Names They Gave (Victoria University of Wellington) Christmas Day Act 1899 http://nzetc.victoria.ac.nz/tm/scholarly/tei-KloDisc-t1-body-d18.html (page 60) PACIFIC ISLANDS. PROCEEDINGS OF THE BRITISH RESIDENT, RAROTONGA. (National Library of New Zealand) Appendix to the Journals of the House of Representatives, 1900 https://atojs.natlib.govt.nz/cgi-bin/atojs?a=d&d=AJHR1900-I.2.1.2.3 (page 20) I guess, Zone Pacific/Rarotonga was +13:20:56 before Christmas 1899 and on Christmas Day 1899 time zone has been changed to -10:39:04 (text Christmas Day Act 1899 on our web site): https://www.worldtimezone.com/dst_news/dst_news_cook-islands01.html (or Christmas Day Act 1899 screenshot): https://www.worldtimezone.com/images/1899-cook-island.gif Regards, Alexander Krivenyshev, https://www.worldtimezone.com

4 5

Palestine summer time 2021
by Sharef Mustafa March 24, 2021

March 24, 2021

Hi, Palestine to start summer time on Sat Mar 27th after midnight as per cabinet announcement "وأقر مجلس الوزراء بدء التوقيت الصيفي في دولة فلسطين، بتقديم عقارب الساعة 60 دقيقة، اعتبارا من منتصف ليل الجمعة/ السبت الموافق 27-3-2021" "The Council of Ministers approved the start of daylight saving time in the State of Palestine, by presenting the clock at 60 minutes, starting at midnight Friday / Saturday 27-3-2021 " https://www.facebook.com/PMO.Palestine/posts/4198242146875242 https://www.maannews.net/news/2035719.html BR

3 2

[PROPOSED] Fix ‘make check_time_t_alternatives’
by Paul Eggert March 24, 2021

March 24, 2021

* zic.c (EPOCH_LOCAL, EPOCH_OFFSET, time_tz): #undef, so that zic uses the system ‘time’ function instead of relying on any replacement. That way, zic doesn’t depend on localtime.c. This fixes a problem introduced in 2021-02-23T07:03:07Z!eggert@cs.ucla.edu when zic.c started using the ‘time’ function to generate crude random numbers. --- zic.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/zic.c b/zic.c index 6c38bd7..d1e9a97 100644 --- a/zic.c +++ b/zic.c @@ -5,6 +5,12 @@ ** 2006-07-17 by Arthur David Olson. */ +/* Use the system 'time' function, instead of any private replacement. + This avoids creating an unnecessary dependency on localtime.c. */ +#undef EPOCH_LOCAL +#undef EPOCH_OFFSET +#undef time_tz + #include "version.h" #include "private.h" #include "tzfile.h" -- 2.27.0

1 0

[PATCH] Restore simpler delta_nonneg code.
by Paul Eggert March 24, 2021

March 24, 2021

* zdump.c (delta_nonneg): Undo previous change to this area that inadvertently installed an unnecessary ‘if’. --- zdump.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/zdump.c b/zdump.c index e1db329..918d09c 100644 --- a/zdump.c +++ b/zdump.c @@ -716,16 +716,10 @@ hunt(timezone_t tz, char *name, time_t lot, struct tm *lotmp, time_t hit, static intmax_t delta_nonneg(struct tm *newp, struct tm *oldp) { - register intmax_t result; - register int tmy; - - result = 0; - tmy = oldp->tm_year; - if (newp->tm_year - tmy > YEARSPERREPEAT) { - intmax_t cycles = (newp->tm_year - tmy) / YEARSPERREPEAT; - result = cycles * (YEARSPERREPEAT * DAYSPERNYEAR + 100 - 4 + 1); - tmy += cycles * YEARSPERREPEAT; - } + intmax_t oldy = oldp->tm_year; + int cycles = (newp->tm_year - oldy) / YEARSPERREPEAT; + intmax_t sec = SECSPERREPEAT, result = cycles * sec; + int tmy = oldp->tm_year + cycles * YEARSPERREPEAT; for ( ; tmy < newp->tm_year; ++tmy) result += DAYSPERNYEAR + isleap_sum(tmy, TM_YEAR_BASE); result += newp->tm_yday - oldp->tm_yday; -- 2.27.0

1 0

zoneinfo generating issues
by 汪蒙蒙（木之） March 17, 2021

March 17, 2021

Hi: Recently, I wanted to write a program to watch the change of timezone database. I got newest version from this address: https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz. I used zic (version: zic (tzcode) 2020c, system: CentOS Linux release 7.6.1810 (Core)) to generate the zoneinfo. I pick up some zones with local timeto calculate utc time to verify the changes using both the new and currently used version tzdata, here is diff: zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way. Here was what do: # mkdir zoneinfo # cd tzdata2021a # zic -d ../zoneinfo -L ./leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory I was wondering if you could provide me some help. I really appreciate your reply. Sincerely, wangmm

11 27

Should tzfile.5 list the time zone designations field more explicitly?
by Ian Abbott March 17, 2021

March 17, 2021

The description of the local time types entries mentions the array of time zone abbreviation bytes in passing, but that probably deserves its own list item. On skimming over the man page, it looks like the local time type entries are immediately followed by the leap-second correction records. -- -=( Ian Abbott <abbotti(a)mev.co.uk> || MEV Ltd. is a company )=- -=( registered in England & Wales. Regd. number: 02862268. )=- -=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=- -=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-

2 2

[PROPOSED] Improve coverage of version 4 interoperability
by Paul Eggert March 17, 2021

March 17, 2021

* tzfile.5: Mention problems with version 3-only readers and version 4 files, and update other interoperability coverage. --- tzfile.5 | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 8ee6cfb..b4952d5 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -243,10 +243,13 @@ Readers that only understand Version 1 must ignore any data that extends beyond the calculated end of the version 1 data block. .PP -Writers should generate a version 3 file if +Other than version 1, writers should generate +the lowest version number needed by a file's data. +For example, a writer should generate a version 3 file +if the file does not contain a truncated leap second table +and so does not use version 4 features, but TZ string extensions are necessary to accurately -model transition times. -Otherwise, version 2 files should be generated. +model transition times so the file does need version 3 features. .PP The sequence of time changes defined by the version 1 header and data block should be a contiguous subsequence @@ -269,7 +272,7 @@ and This is for compatibility with POSIX requirements for time zone abbreviations. .PP -When reading a version 2 or 3 file, readers +When reading a version 2+ file, readers should ignore the version 1 header and data block except for the purpose of skipping over them. .PP @@ -328,6 +331,10 @@ for the next time zone east, e.g., .q "AST4" for permanent Atlantic Standard Time (\-04). .IP * +Some readers designed for earlier versions reject version 4 files, +because they require complete leap second tables that do not record +expiration dates. +.IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. As a partial workaround, a writer can output more transitions -- 2.27.0

1 0

[PATCH 1/7] localtime.c is less finicky about leap seconds
by Paul Eggert March 17, 2021

March 17, 2021

* localtime.c (tzloadbody): Do not reject a TZif file merely because its leap second table contains adjacent entries with equal corrections, or contains a first entry with a correction value other than +1 or -1. * NEWS: Mention this. --- NEWS | 5 +++++ localtime.c | 13 ++++++++++--- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 0de05f3..d8676e6 100644 --- a/NEWS +++ b/NEWS @@ -39,6 +39,11 @@ Unreleased, experimental changes seconds error than with an hour error, so zic -L no longer truncates output in this way. + The TZif reader now allows the leap second table to begin with a + correction other than -1 or +1, and to contain adjacent + transitions with equal corrections. This supports possible + future extensions to the TZif format. + Fix bug that caused 'localtime' etc. to crash when TZ was set to a all-year DST string like "EST5EDT4,0/0,J365/25" that does not conform to POSIX but does conform to Internet RFC 8536. diff --git a/localtime.c b/localtime.c index 6627ff2..a086d4d 100644 --- a/localtime.c +++ b/localtime.c @@ -445,7 +445,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); int_fast64_t prevtr = 0; - int_fast32_t prevcorr = 0; + 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); @@ -542,9 +542,16 @@ tzloadbody(char const *name, struct state *sp, bool doextend, and UTC months are at least 28 days long (minus 1 second for a negative leap second). Each leap second's correction must differ from the previous one's by 1 - second. */ + second or less, except that the first correction can be + any value; these requirements are more generous than + RFC 8536, to allow future RFC extensions. */ if (tr - prevtr < 28 * SECSPERDAY - 1 - || (corr != prevcorr - 1 && corr != prevcorr + 1)) + || ((timecnt == 0 || sp->ats[0] < tr) + && ! (i == 0 + || (prevcorr < corr + ? corr == prevcorr + 1 + : (corr == prevcorr + || corr == prevcorr - 1))))) return EINVAL; sp->lsis[leapcnt].ls_trans = prevtr = tr; sp->lsis[leapcnt].ls_corr = prevcorr = corr; -- 2.27.0

2 7

changing "master" to "main" in tzdb development repository
by Paul Eggert March 17, 2021

March 17, 2021

Because the word "master" has negative connotations in English, I renamed the "master" branch to "main" in the tzdb development repository <https://github.com/eggert/tz>. This follows in the wake of GitHub's October change that makes the default branch "main" rather than "master", and GitHub's followup changes in January that made renaming relatively painless - for example, web requests for "master" are now redirected to "main" automatically <https://github.com/github/renaming/>. This renaming by GitHub is part of a broader change within the Git software ecosystem <https://sfconservancy.org/news/2020/jun/23/gitbranchname/>. This change affects neither past nor future releases of tzdb. It affects only the small number of direct accesses to the development repository for commits between releases. The idea is that on balance the small inconvenience for developers is outweighed by the advantage in reducing insensitivity overall. If you are a developer with a local clone of the tzdb repository, please adjust to this change by running the following shell commands: $ git branch -m master main $ git fetch origin $ git branch -u origin/main main I've done this for my own local clone of the repository. To document this change for tzdb newcomers, I installed the attached patch to the CONTRIBUTING file just before renaming the branch.

8 8

Troubles with zone Asia/Gaza after tzdata2020b release
by Evgheni Antropov March 15, 2021

March 15, 2021

Dear tzdata maintainers, I have found that after tzdata2020b release something has gone wrong with Asia/Gaza timezone, which is related to Palestine. For checking I used this information https://www.timeanddate.com/worldclock/palestine/gaza and for DST at 2019: https://www.timeanddate.com/time/change/palestine/gaza?year=2019 for DST at 2020: https://www.timeanddate.com/time/change/palestine/gaza?year=2020 for DST at 2021: https://www.timeanddate.com/time/change/palestine/gaza?year=2021 I compiled all last release of tzdata from 2019c to 2021a and was comparing them with Ubuntu packages for 2020b on groovy (20.10) and 2021a on bionic (18.04). If several changes in the date of DST for different years can be related with last applied laws of DST in Palestine (described here http://mm.icann.org/pipermail/tz/2020-October/029376.html) but broken timezone output in letters or numbers is speaking about any error in the this time zone code. Can you investigate this too ? On screenshot you can see all my investigation: [cid:image002.png@01D70EDB.BE0D5350] Also I share all commands and listing for your execution itself: [root@Router8:~]# ls -la /etc/localtime lrwxrwxrwx 1 root root 35 Mar 4 2021 /etc/localtime -> /usr/share/zoneinfo/posix/Asia/Gaza [root@Router8:~]# ls -la /usr/share/zoneinfo/posix/Asia/Gaza* lrwxrwxrwx 1 root root 41 Mar 27 01:00 /usr/share/zoneinfo/posix/Asia/Gaza -> /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 22 09:34 /usr/share/zoneinfo/posix/Asia/Gaza.2019c -rw-r--r-- 1 root root 2316 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020a -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020b -rw-r--r-- 1 root root 1166 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020c -rw-r--r-- 1 root root 1195 Oct 30 2020 /usr/share/zoneinfo/posix/Asia/Gaza.2020d -rw-r--r-- 1 root root 1213 Mar 1 2021 /usr/share/zoneinfo/posix/Asia/Gaza.2021a -rw-r--r-- 1 root root 2316 Oct 19 2020 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b -rw-r--r-- 1 root root 2459 Jan 27 2021 /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a [root@Router8:~]# date +"%Y%m%d %T" -s "20190328 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20190328 23:59:55 Thu Mar 28 23:59:59 2019 +0200 EET Fri Mar 29 01:00:01 2019 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020a' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2020c /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2020c' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0000 Fri Mar 27 00:00:01 2020 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2020b' [root@Router8:~]# date +"%Y%m%d %T" -s "20200326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20200326 23:59:55 Thu Mar 26 23:59:59 2020 +0200 EET Fri Mar 27 01:00:01 2020 +0300 EEST [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0000 Sat Mar 27 00:00:01 2021 +0000 [root@Router8:~]# ln -sfv /usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a /usr/share/zoneinfo/posix/Asia/Gaza '/usr/share/zoneinfo/posix/Asia/Gaza' -> '/usr/share/zoneinfo/posix/Asia/Gaza.ubuntu.2021a' [root@Router8:~]# date +"%Y%m%d %T" -s "20210326 23:59:55" ; sleep 4; date +%c%t%z%t%Z; sleep 2 ; date +%c%t%z%t%Z 20210326 23:59:55 Fri Mar 26 23:59:59 2021 +0200 EET Sat Mar 27 01:00:01 2021 +0300 EEST Best regards, [cid:image001.jpg@01D70EC7.959CF010] Evgheni Antropov Software R&D Engineer +373 22 404 665 www.addgrup.com<http://www.addgrup.com/>

4 12

Re: [tz] [PROPOSED] Fix Sierra Leone typo for 1957
by REMI ACIEN March 11, 2021

March 11, 2021

For Sierra Leone : -0:53:00 - FMT 1913 Jun # Freetown Mean Time. Envoyé depuis mon appareil Galaxy

2 1

Re: [tz] Some time zone history (4) (P Chan)
by Yandex.ru March 9, 2021

March 9, 2021

On Wed, Mar 03, 2021 at 04:22:48PM +0000, P Chan via tz wrote: > Russia > … > The 1922 transition in Moscow seems to be wrong. The 1922 transition in Moscow is true, that confirmed by law: +1h on 15.02.1922 at 23:00 Msk https://www.lawmix.ru/zakonodatelstvo/2575961 -1h on 30.09.1922 at 24:00 Msk https://www.lawmix.ru/zakonodatelstvo/2575587

1 0

Some time zone history (4)
by P Chan March 8, 2021

March 8, 2021

Russia Before 14 February 1918, Julian calendar was used in Russia. Therefore for the 1917 transitions in tz, 1 July should be 14 July and 28 December should be 10 January 1918. Decrees for the 1917 forward transition: http://docs.historyrussia.org/ru/nodes/33879#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/33986#mode/inspect/page/4/zoom/4 http://docs.historyrussia.org/ru/nodes/34925#mode/inspect/page/3/zoom/4 In 1920, there were four transitions, the dates were the same as 1921. http://docs.historyrussia.org/ru/nodes/16730#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/16813#mode/inspect/page/1/zoom/4 http://docs.historyrussia.org/ru/nodes/21879#mode/inspect/page/1/zoom/4 The 1922 transition in Moscow seems to be wrong. Instead, there should be a transition in 1924. http://www.libussr.ru/doc_ussr/ussr_1984.htm You may also refer to a section on the Russian Wikipedia. https://ru.wikipedia.org/wiki/%D0%92%D1%80%D0%B5%D0%BC%D1%8F_%D0%B2_%D0%A0%… ----- Tanzania Standard time of GMT+2:30 was adopted on 1913-10-01, then GMT+3 at midnight of 1925-05-16, GMT+2:45 on 1937-01-01 and GMT+3 on 1942-08-01. Popular Astronomy: A Review of Astronomy and Allied Sciences, Volume 22, p 328 https://books.google.com/books?id=yVFGAQAAMAAJ&pg=PA328 General Notice No. 335 of 1925, 1905-05-13, Tanganyika Gazette, Vol. VI No.20, 1925-05-15, p 175 Interpretation (Standard Time) Order in Council, 1929 (Government Notice No. 11), 1929-01-21, Supplement to the Tanganyika Territory Gazette, Vol. X, No.5, 1929-01-25, p 9 Interpretation (Standard Time) Order, 1936 (Government Notice No. 159), 1936-10-13, Ibid., Vol. XVII, No. 56, 1936-11-06, p 270 Interpretation (Standard Time) Order, 1942 (Government Notice No. 259), 1942-07-15, Ibid., Vol. XXIII, No. 36, 1942-07-24,p 296 https://1drv.ms/u/s!AgX5Bc6Y-VsIi2-tBj4iXt90KNrV?e=8yoy29 ----- Uganda At some point after 1905-11-08, Uganda time was 30 minutes behind Mombasa Mean Time. At some point before 1908-04-25, GMT+2:30 was adopted as the standard time. In 1937 and 1942, new standard times in Uganda were adopted simultaneously in Kenya and Tanganyika. Notice. Uganda Official Time., 1905-11-08, The Official Gazette of the East Africa and Uganda Protectorates, 1905-12-01, p 392 https://books.google.com/books?id=FsRZ7PcucTEC&pg=RA1-PA392 "Local Time.", East African Standard, Mombasa Times and Uganda Argus, 1907-11-23, p 16 http://ddsnext.crl.edu/titles/31664#?c=0&m=260&s=0&cv=15&r=0&xywh=1130%2C24… "Standard Time.",Ibid., 1908-04-25, p 17 http://ddsnext.crl.edu/titles/31664#?c=0&m=282&s=0&cv=16&r=0&xywh=3187%2C18… General Notice No. 601 of 1936, 1936-11-03, Official Gazette of the Uganda Protectorate, Vol. XXIX, No.25, 1936-11-16, p 385 General Notice No. 213 of 1942, 1942-07-11, The Uganda Gazette, Vol. XXXV, No. 14, 1942-07-15, p 102 https://1drv.ms/u/s!AgX5Bc6Y-VsIi3O5OxfZRvN46GWA?e=EbwRAe ----- Zimbabwe Standard time of GMT+2 was adopted in 1899-08-01. Before that, GMT+2:30 was used in Salisbury. The Bulawayo Chronicle, 1899-07-08, p 5 Government Notice No. 160 of 1899, 1899-07-20, The British South Africa Company Government Gazette, 1899-07-21, p 199 https://1drv.ms/u/s!AgX5Bc6Y-VsIi3Ruk-lLkymGZBUN?e=bJnSaL ----- Israel For the fallback transition in 1980, it could be either at 24:00 or 24:00s. sources with 24:00s: Maariv⁩, 1980-09-09, p 1 https://www.nli.org.il/en/newspapers/mar/1980/09/09/01/article/7 Davar,⁩ 1980-09-10, p 2 and 10 https://www.nli.org.il/en/newspapers/dav/1980/09/10/01/article/14 https://www.nli.org.il/en/newspapers/dav/1980/09/10/01/article/114.2 The Jerusalem Post, 1980-09-10, p 18 https://search.proquest.com/docview/918197263 source with 24:00: Maariv, 1980-09-10, p 12 https://www.nli.org.il/en/newspapers/mar/1980/09/10/01/article/83 sources with "midnight": Al-Ittihad⁩, 1980-09-12, p 8 https://www.nli.org.il/en/newspapers/?a=d&d=alittihad19800912-01&dliv=userc… The Jerusalem Post, 1980-09-10, p 1 and 1980-09-14, p 1 https://search.proquest.com/docview/918209000 https://search.proquest.com/docview/918188423 For the fallback transition in 1984, it should be at 24:00. Maariv, 1984-08-24, p 1 https://www.nli.org.il/en/newspapers/mar/1984/08/24/01/article/6 Al-Ittihad⁩, 1984-08-26, p 2 https://www.nli.org.il/en/newspapers/?a=d&d=alittihad19840826-01&dliv=userc… The Jerusalem Post, 1984-08-21, p 4 and 1984-08-24, p 1 https://search.proquest.com/docview/924823083 https://search.proquest.com/docview/924051659 The Jerusalem Post images: https://1drv.ms/u/s!AgX5Bc6Y-VsIjBGvgWp_o9PZfHyu?e=VmSRwW ------ Cyprus Before independence, DST was observed in 1940-1945 and 1948 List of Summer Time Orders: http://www.cylaw.org/cgi-bin/sinocgi.pl?title=summer+time&searchoption=1&di… An article on the government website said that DST in Cyprus was first implemented in 1976. https://cyineu.pio.gov.cy/%CE%B5%CF%80%CE%B9%CE%BA%CE%B1%CE%B9%CF%81%CF%8C%… List of decrees for DST since 1976: http://www.cylaw.org/cgi-bin/sinocgi.pl?title=%C8%E5%F1%E9%ED%DE%F2+%BF%F1%… Apparently, no decree was issued for DST in 1975 and 1977-1979. http://www.cylaw.org/KDP/1975.html http://www.cylaw.org/KDP/1977.html http://www.cylaw.org/KDP/1978.html http://www.cylaw.org/KDP/1979.html For other years, the rules in tz mostly match with the degrees, except: 1. spring forward transitions in 1994-1997 were at 00:01 instead of 00:00. 2. fallback transitions in 1996 and 1997 were at 24:00 of the last Saturday of October (or 00:00 of the last Sunday of October) instead of September. 3. EU rules were first used for the spring forward transition in 1998 instead of September 1998. The Sovereign Base Areas of Akrotiri and Dhekelia has similar DST rules as Cyprus. List of Summer Time Orders of the Sovereign Base Areas: 1976: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1980: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1981: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1982: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1983: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1984: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1985: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1986: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1987: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1988: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1989: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1990: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1991: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1992: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1993: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1994: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1995: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1996: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1997: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… 1998: https://sbaadministration.org/home/legislation/01_02_09_06_PIs/01_02_09_06_… (EU rules have been adopted since 1998) These orders were not publicly listed, some were searchable by search engine, the others were found by brute-force. Apparently, no order was issued for DST before 1976 and 1977-1979. These orders mostly correspond to the decrees of Cyprus, except the transition times were in GMT, which was not stated in the decrees of Cyprus prior to 1998. Also, spring forward transition in 1994 was 00:00 (GMT) instead of 00:01. ------ Shanghai Standard time of GMT+8 was adopted by the French concession at noon on 1903-01-01, before that GMT+8:05:56.7 (Shanghai mean time) was used. "A New Time for the New Year", The North China Herald and Supreme Court & Counsular Gazette, 1902-12-31, p 1383 https://search.proquest.com/docview/1369511715/ The Straits Times, 1903-01-09, p 5 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1903… Newspaper sources for DST observed in 1919 and 1940-1949: (These are taken from "全国报刊索引" https://www.cnbksy.com/ and "中國近代報刊" https://www.dhcdb.com.tw/SP/) https://1drv.ms/u/s!AgX5Bc6Y-VsIjBV8vf4qIDkPyE_7?e=LUQyIy The China Press 1919-04-13, p 26 1919-09-28, p 1 1940-05-31, p 1 1941-03-15, p 10 1941-11-02, p 2 1946-05-15, p 5 1946-10-01, p 2 1947-04-15, p 1 1947-09-21, p 5 1948-04-30, p 9 1948-09-30, p 1 1949-05-01, p 5 The North-China Daily News 1940-10-13, p 6 1949-06-01, p 1 The Shanghai Sunday Times 1942-02-01, p 4 The Shanghai Times 1942-10-23, p 5 Shun Pao (申報) 1945-08-28, p 2 The spring forward transitions in 1941 and 1942 should be at 24:00, the fallback transition in 1945 should be at 00:00. Actually these can also be deduced from Li Yu's article: footnote 29: 《沪市继续推行日光节约运动，自本月十五日午夜实行》，《申报》1941年3月12日，第7版。 footnote 34: 《日光节约时间昨夜开始》，《申报》1942年2月1日，第3版。 the sentence before footnote 37:"...宣布本年9月1日零时起结束'日光节约时间'" The communist city government ended DST at 00:00 on 1949-06-01. The rules for Shanghai and Taipei in 1946-1949 are the same. Maybe they can be merged. ------ Malaysia and Singapore Some of the sources mentioned in Aslaksen's webpage about Singapore time: Government Notification No. 1000, 1900-09-06, Straits Settlements Government Gazette, 1900-09-07, p 1933 https://eservice.nlb.gov.sg/data2/BookSG/publish/f/fe38abfe-bfbb-46f2-b977-… Government Notification No. 201, 1904-02-22, Ibid., 1904-02-26, p 300 https://eservice.nlb.gov.sg/data2/BookSG/publish/d/df4b34d6-7388-4c84-9b33-… Daylight Saving Ordinance, 1932 (No. 21 of 1932), Ibid., 1932-12-23, p 2623 https://eservice.nlb.gov.sg/data2/BookSG/publish/1/1d7e5694-43e5-46b2-b050-… Government Notification No. 2367, 1933-12-04, Ibid., 1933-12-15, p 2706 https://eservice.nlb.gov.sg/data2/BookSG/publish/9/91e94bfb-1e92-4451-badc-… Government Notification No. 2371, 1934-10-08, Ibid., 1934-10-19, p 2954 https://eservice.nlb.gov.sg/data2/BookSG/publish/d/d9d45030-bb72-4d5c-8a7e-… Daylight Saving (Amendment) Ordinance, 1935 (No. 5 of 1935), Ibid., 1935-03-08, p 488 https://eservice.nlb.gov.sg/data2/BookSG/publish/e/e16c3415-b038-48c8-90c2-… Daylight Saving Ordinance (Chapter 170), The laws of the Straits Settlements Edition of 1936, Vol VI, p 694 https://eservice.nlb.gov.sg/data2/BookSG/publish/b/b8f6f919-b64d-4ac5-ab10-… Daylight Saving (Amendment) Ordinance, 1941 (No. 33 of 1941), Supplement to the laws of the Straits Settlements, 1942, Vol I, p 223 https://eservice.nlb.gov.sg/data2/BookSG/publish/6/6f963fc2-9708-41c5-b7b2-… Daylight Saving Ordinance (Chapter 266), The laws of the Colony of Singapore Edition of 1955, Vol VII, p 319 https://eservice.nlb.gov.sg/data2/BookSG/publish/5/57ab953e-f062-40ea-aeda-… Interpretation and General Clauses Ordinance (Chapter 2), Ibid., Vol I, pp 17-38 https://eservice.nlb.gov.sg/data2/BookSG/publish/9/91034b99-bb5f-4ec6-b371-… Singapore Standard Time Notification (G.N. No. S 392/1981) https://sso.agc.gov.sg/SL/IA1965-N1/Historical/19920325?DocDate=20000831&Va… Malaysian Standard Time Act 1981 (Act 261) http://www.commonlii.org/my/legis/consol_act/msta1981223/ Other sources: "Malaya Finished With 'Tokyo Time'", The Straits Times, 1945-09-07, p 1 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1945… Statute Law Revision Bill (Bill No. 36/1970) https://sso.agc.gov.sg/Bills-Supp/36-1970/Published/19700728?DocDate=197007… With regard to Aslaksen and tz, the 1935 Ordinance, which made the Daylight Saving Ordinance permanent, was commenced on 1935-03-08. During WWII, Kuala Lumpur was occupied by Japanese a month earlier than Singapore. Kuching was also occupied earlier in December 1941. Therefore it is unlikely that they switched to GMT+9 on the same day. The Daylight Saving Ordinance was repealed by the Statute Law Revision Act 1970 (No. 48 of 1970). The 1981/1982 transition took place at 16:00 GMT on 1981-12-31. (This was actually mentioned by Mok Ly Yng but the entry has remained uncorrected since 2003.) Some of the sources for Sarawak: Order No. VIII, 1926, 1926-02-11 The Sarawak Government Gazette, 1926-02-16, Vol.19 No.433, p 54 https://books.google.com.hk/books?id=VKbL-mOu1F8C&pg=PA54 Notification No. 429, 1930-06-30 Ibid., 1930-07-01, Vol.23 No. 552, p 248 https://books.google.com/books?id=B5saIO8yLL0C&pg=RA4-PA14 Notification No. 436, 1931-06-24 Ibid., 1931-07-01, Vol.24 No. 579 p.193 https://books.google.com/books?id=YqvrMnxJHAYC&pg=RA16-PP3 Notification No. 798, 1931-12-03 Ibid., 1932-01-02, Vol.24 No. 591, p 356 https://books.google.com/books?id=YqvrMnxJHAYC&pg=RA30-PA10 Notification No. 1274, 1940-09-06 Ibid., 1940-09-16, Vol.33 No.38, p 701 https://books.google.com/books?id=HDU3vTSR4UYC&pg=PA701 Defence (Standard Time (revocation)) Regulations, 1946 Ibid., Vol. 1 No.4, 1946-08-16, p 48 https://books.google.com/books?id=pWd9qBTe4gYC&pg=PA48 Standard Time Ordinance, 1946 (No. 2 of 1946) Ibid., Vol. 1 No.20, 1946-12-16, p 232 https://books.google.com/books?id=pWd9qBTe4gYC&pg=PA232 Standard Time Regulations, 1950 Colony of Sarawak Supplement to the Government Gazette, Sup. No. 6, 1950-04-17, p 50 https://books.google.com/books?id=GelAgpgyMpUC&pg=RA1-PA50 Standard Time (Amendment) Ordinance, 1950 (No. 2 of 1950) Ibid., Sup. No. 12, 1950-05-30, p 91 https://books.google.com/books?id=GelAgpgyMpUC&pg=RA1-PA91 "Sarawak Standard Time", The Sarawak Gazette, 1926-03-01, p 55 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1370908367.pdf#pag… "Mainly About Nothing", Ibid., 1929-12-02, p 213 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1399273124.pdf#pag… "Time in Sarawak", Ibid, 1932-10-01, p 168 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1399277620.pdf#pag… "Sarawak Chronology", Ibid, 1961-07-31, p 131 https://www.pustaka-sarawak.com/gazette/gazette_uploaded/1403144292.pdf#pag… "Summer Time in Sarawak" ,The Straits Times, 1932-09-29, p 19 https://eresources.nlb.gov.sg/newspapers/Digitised/Article/straitstimes1932… The Sarawak Government Gazette, 1929 https://books.google.com/books?id=wmtR6OfLitQC The Sarawak Government Gazette, 1941 https://books.google.com/books?id=sTOu9S62f9IC Standard time of GMT+7:30 was adopted in Sarawak on 1926-03-01. DST was officially observed in 1930-1939, GMT+7:50 was used from September to December. The 1933 transition in tz should be an error. According to some sources, DST was also observed in 1929, but the details are unclear. It was not mentioned in the Government Gazette issues published in 1929. According to the Defence (Standard Time (revocation)) Regulations, 1946, the Defence (Standard Time) Regulations, 1941 suspended the 1926 Order. But the text of the 1941 Regulations is unknown. The 1941 issues of Government Gazette on Google Books are only up to 1941-12-09. Therefore it is likely that those regulations were publish after that day. The 1946 Regulations reinstated the 1926 Order but did not affect the clock. The time zone being used during 1945-1946 is unclear. Standard time of GMT+8 has been adopted since 1950-05-01. "NBorneo" do not seem to be an appropriate name for the rules for Sarawak (Asia/Kuching). Since "North Borneo" usually refers to the territory which is now Sabah.

2 1

Temporal - ECMAScript built-in JS Library for dates/times/timezones/calendars in progress
by Jase Williams March 8, 2021

March 8, 2021

Hi I'm one of the TC39 (EcmaScript) delegates. As a heads up to anyone interested, we're creating a new built-in module in JavaScript (to hopefully replace Date()) called Temporal. This new, rich API includes: - First-class support for all time zones, including DST-safe arithmetic - Strongly-typed objects for dates, times, date/time values, year/month values, month/year values, "zoned" date/time values, and durations - Immutability for all Temporal objects - String serialization and interoperability via standardized formats - Compliance with industry standards like ISO 8601, RFC 3339, and RFC5545 (iCalendar) - Full support for non-Gregorian calendars Feel free to play around with it and offer feedback on the repo. The repository is here: https://github.com/tc39/proposal-temporal Documentation here: https://tc39.es/proposal-temporal/docs/index.html Polyfill here: https://github.com/tc39/proposal-temporal/tree/main/polyfill EcmaScript spec: https://tc39.es/proposal-temporal/ It's currently Stage 2 which means it's under review, but there's hope to see this implemented in Browsers/NodeJS soon. For consideration in tz-link.html. Feel free to adjust wording Project: https://github.com/tc39/proposal-temporal NPM: https://www.npmjs.com/package/proposal-temporal Thanks Jason Williams

6 5

[PROPOSED] Omit some no-longer-live packages
by Paul Eggert March 4, 2021

March 4, 2021

* tz-link.html: Remove pointers to some software packages that no longer seem live: ZoneInfo.Java, Time Zone Master, VelaTerra. --- tz-link.html | 12 ------------ 1 file changed, 12 deletions(-) diff --git a/tz-link.html b/tz-link.html index af8885f..e7570a2 100644 --- a/tz-link.html +++ b/tz-link.html @@ -580,9 +580,6 @@ the Apache License.</li> library that translates between <abbr>UT</abbr> and civil time and can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> -<li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> -is a <abbr>TZif</abbr> file reader written in Java. -It is freely available under the <abbr>LGPL</abbr>.</li> <li><a href="https://github.com/derickr/timelib">Timelib</a> is a C library that reads <abbr>TZif</abbr> files and converts timestamps from one time zone or format to another. @@ -667,15 +664,6 @@ href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent <code><abbr>tz</abbr></code> database in a Java-specific format.</li> -<li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone -Master</a> is a Microsoft Windows clock program that can automatically -download, compile and use <code><abbr>tz</abbr></code> releases. -The Basic version is free.</li> -<li><a -href="http://veladg.com/velaterra.html">VelaTerra</a> is -a macOS program. Its developers -<a href="http://veladg.com/tzoffer.html">offer free -licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> </ul> </section> -- 2.27.0

1 0

Eighth Continent Zealandia/Te Riu-a-Maui
by Brian Inglis March 3, 2021

March 3, 2021

Australians appear to agree that New Zealand is situated on its own (largely submerged) continental crust, along with nearby island groups, so we may have to consider a future split: https://www.bbc.com/future/article/20210205-the-last-secrets-of-the-worlds-… https://www.gns.cri.nz/static/unclos/images/unclosbook_print.pdf https://en.wikipedia.org/wiki/Zealandia#Political_divisions -- 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.]

3 2