- tz - lists.iana.org

[PROPOSED 1/2] * SECURITY: New file.
by Paul Eggert April 20, 2021

April 20, 2021

--- SECURITY | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 SECURITY diff --git a/SECURITY b/SECURITY new file mode 100644 index 0000000..40128bc --- /dev/null +++ b/SECURITY @@ -0,0 +1,15 @@ +Please report any sensitive security-related bugs via email to the +tzdb designated coordinators, currently Paul Eggert +<eggert(a)cs.ucla.edu> and Tim Parenti <tim(a)timtimeonline.com>. +Put "tzdb security" at the start of your email's subject line. +We prefer communications to be in English. + +You should receive a response within a week. If not, please follow up +via email to make sure we received your original message. + +If we confirm the bug, we plan to notify affected third-party services +or software that we know about, prepare an advisory, commit fixes to +the main development branch as quickly as is practical, and finally +publish the advisory on tz(a)iana.org. As with all tzdb contributions, +we give credit to security contributors unless they wish to remain +anonymous. -- 2.27.0

1 1

Wisconsin daylight savings 1957
by TJ April 17, 2021

April 17, 2021

Hey everyone, I was doing some digging and found the following referendum in 1957 for Wisconsin. - https://ballotpedia.org/Wisconsin_Daylight_Saving_Time,_Question_1_(April_1… The text of the measure that passed was: "Shall section 175.095 (2) of the statutes, which proposes a statewide daylight saving time of one hour per day from the last Sunday in April to the last Sunday in September in each year be law beginning with the last Sunday in April 1957?" However, the 1947 ballot to use daylight savings was defeated: https://ballotpedia.org/Wisconsin_Daylight_Saving_Time_Referendum,_Question… In the tz db for North America, it looks like Wisconsin is using America/Chicago which has a few rules for the time period in question: Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S It appears to me that Wisconsin might need some modification? Is this the correct mailing list for this discussion? Thanks, TJ

3 3

Ref: What time is it: managing time in the internet
by Brian Inglis April 17, 2021

April 17, 2021

"What time is it: managing time in the internet", p37–44, July 2019, "Proceedings of the Applied Networking Research Workshop" https://dl.acm.org/doi/10.1145/3340301.3341125 "investigation of how current local time is reported accurately by devices connected to the internet", analysis of tzdb and updates, "proposals for enhancing TZDB management and reducing vulnerabilities in the system." -- 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.]

2 2

Terminology: “Central European Summer Time” vs “Europe/Berlin”
by Michael[tm] Smith April 15, 2021

April 15, 2021

In the time zone taxonomy, if the term for “Europe/Berlin” is clearly “time zone”, and “GMT+2” is precisely a “timezone offset”, is there a term (other than “time zone”) for what “Central European Summer Time” is — either an authoritative/ normative term, or else at least a best-practice term that’s commonly used? The context is, I’m updating some of the MDN documentation related to JavaScript methods and properties for dealing with dates, including these articles: * https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/… * https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/… And in particular, I’m working on trying to describe the timeZoneName property, in the context of the following behavior: Consider the following code: TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', \ { timeZoneName: 'short' }).formatToParts())" When you run that, what you get back is this: [ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'GMT+2' } ] So part of what I want to explain in the MDN articles is: When you specify “timeZoneName: 'short'”, what you get back as the value for the 'timeZoneName' field in the output is actually a time zone *offset* — not a time zone. But along with that, I need to deal with describing this case: TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', { timeZoneName: 'long' }).formatToParts())" When you run that, what you get back is this: [ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'Central European Summer Time' } ] That’s the particular thing I’m struggling with — that is, when you specify “timeZoneName: 'long'”, what do I call the 'Central European Summer Time' that you get back in the output? Something like “a localized long name for the associated time zone offset” is the best I’ve been able to come up with. But I’ve been hoping there might be some authoritative term for it that I’ve not managed to find yet. And I realize there’s no “Central European Summer Time” in the zoneinfo data itself — and so implementations get that by doing some kind of lookup against (I guess) CLDR. So I guess it’s expected that the documentation for the IANA timezone database itself doesn’t have a term for it. And I guess it’s also unsurprising that CLDR seems to just use the term “time zone” to refer to it — since CLDR doesn’t need to bee more precise and since because CLDR doesn’t need to do anything with the actual canonical time zone names such as Europe/Berlin, it doesn’t have the problem of distinguishing between what a time zone is and what time zone offset is. But from what I’ve seen in issues and questions reported by developers at MDN and Stack Overflow, probably the single biggest source of chronic frustration that developers have when dealing with date-related methods and properties in programming languages comes down to a fundamental misunderstanding of what a time zone is, and how it differs from time zone offset. So I’ve admired what Matt Johnson-Pint has done at Stack Overflow in answering many questions — and in putting the https://stackoverflow.com/tags/timezone/info and https://stackoverflow.com/tags/timezone-offset/info pages together — to provide developers with the kind of clarity they need to solve their problems. And so what I’m hoping to do with my MDN changes is to bring similar clarity to developers through MDN. And so also that’s why it seems important to get the terminology right at MDN when explaining to developers exactly what “Central European Summer Time” is. –Mike -- Michael[tm] Smith https://people.w3.org/mike

6 10

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

News article about EU DST
by Matt Johnson-Pint April 1, 2021

April 1, 2021

Good article from Bloomberg about how the pandemic has put the EU's plans to stop daylight saving time on hold. https://www.bloomberg.com/news/articles/2021-03-11/will-daylight-saving-tim… (It covers a bit about the recent US bill as well.) It also links to a humorous bit about time in Iceland from 2009 that may be worthy of our tz-art.html page: https://www.youtube.com/watch?v=q5q77MQzU2Q Cheers! -Matt

1 0

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