- tz - lists.iana.org

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

[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

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

March 3, 2021

Correction: > British Guiana/Guyana adopted GMT-4 on 1911-08-01, GMT-3:75 on 1915-03-01, GMT-3 on 1975-08-01 and GMT-4 on 1992-03-29. GMT-3:75 should be GMT-3:45 --------- Most of the documents below were obtained from British Online Archives and LLMC Digital. ---------- Barbados https://1drv.ms/u/s!AgX5Bc6Y-VsIi3ioucfhJMcNlHr_?e=wjYyQa Definition of Time Act, 1911 (1911-7) [1911-08-28] Defence (Daylight Saving) Regulations, 1942, 1942-04-13 Defence (Daylight Saving) (Repeal) Regulations, 1942, 1942-08-22 Defence (Daylight Saving) Regulations, 1943, 1943-04-16 Defence (Daylight Saving) (Repeal) Regulations, 1943, 1943-09-01 Defence (Daylight Saving) Regulations, 1944, 1944-03-21 Defence (Daylight Saving) (Repeal) Regulations, 1944, 1944-04-30 Standard time of GMT-4 was adopted in 1911. DST was observed in 1942-44. The transitions were: 1942-04-19 05:00 GMT 1942-08-31 06:00 GMT 1943-05-02 05:00 GMT 1943-09-05 06:00 GMT 1944-04-09 05:00 GMT 1944-09-10 06:00 GMT --------- Gambia https://1drv.ms/f/s!AgX5Bc6Y-VsIi0MbGvyuIXGge6Iq Interpretation Ordinance, 1914 (No. 12 of 1914) [1914-09-29] Interpretation Ordinance, 1933 (No. 10 of 1933) [1933-03-31] Notice No. 5 of 1942, Colony of the Gambia Government Gazette, Vol. LIX, No.2, 1942-01-15, p 2 Interpretation (Amendment) Ordinance, 1946 (No. 3 of 1946) [1946-07-15] Standard time of GMT-1 was adopted on 1933-04-01. On 1942-02-01, GMT was adopted as a war time measure. This was made permanent in 1946. --------- Malawi https://1drv.ms/f/s!AgX5Bc6Y-VsIi0sbGvyuIXGge6Iq Interpretation and General Clauses Ordinance, 1911 (No. 12 of 1911) [1911-07-24] Notice No. 124 of 1914, 1914-06-30, The Nyasaland Government Gazette, Vol. XXI, No. 8, 1914-06-30, p 122 Interpretation and General Clauses (Amendment) Ordinance, 1925 (No. 3 of 1925) [1925-04-02] In 1911, Zomba mean time was adopted as the legal time of Nysaland. In 1914, Zomba mean time switched from GMT+2:21:10 to GMT+2:21. On 1925-07-01, GMT+2 was adopted. ---------- Nigeria https://1drv.ms/f/s!AgX5Bc6Y-VsIi0cbGvyuIXGge6Iq Government notices for the transition in 1905 and 1908. Government Notice No. 427 of 1905, 1905-06-17, Government Gazette. Colony of Lagos, No. 32, 1905, 1905-06-21, p 395 Government Notice No. 742 of 1908, 1908-06-24, Government Gazette. Colony of Southern Nigeria, No. 44, Vol. 3, 1905-06-24, p 869 ---------- Sierra Leone https://1drv.ms/f/s!AgX5Bc6Y-VsIi1EbGvyuIXGge6Iq Government Notice No. 121 of 1913 , 1913-06-06, Sierra Leone Royal Gazette, Vol. XLIV, No. 1384, 1913-06-14, p 347 Alteration of Time Ordinance, 1932 (No. 34 of 1932) [1932-12-01] Alteration of Time (Amendment) Ordinance, 1938 (No. 25 of 1938) [1938-11-24] Defence Regulations (No. 9), 1939 (Regulations No. 9 of 1939),1939-09-05 Defence Regulations (No. 11), 1939 (Regulations No. 11 of 1939), 1939-09-27 Defence (Amendment) (No.17) Regulations, 1941 (Public Notice No.157 of 1941), 1914-12-04 Alteration of Time (Amendment) Ordinance, 1946 (No. 2 of 1946) [1946-02-07] Standard time of GMT-1 was adopted on 1913-07-01. Twenty minutes of DST was introduce in 1932 and was suspended in 1939. In 1941, GMT was adopted by Defence Regulations. This was made permanent in 1946. For DST in 1957-62, I have looked through the gazettes from 1957 to 1961 but could not find any laws or notices related to DST. Also, the Local Time Ordinance (Cap 2, 1960 Revised Edition) <https://books.google.com/books?id=B-U-AQAAIAAJ&pg=PA18> does not contain any provisions related to DST. Proposed Rules: # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule SL 1932 only - Dec 1 0:00 0:20 -0040 Rule SL 1933 1938 - Mar 31 24:00 0 -01 Rule SL 1933 1939 - Aug 31 24:00 0:20 -0040 Rule SL 1939 only - May 31 24:00 0 -01 Rule SL 1939 only - Sep 5 0:00 0 -01 Zone Africa/Freetown -0:53:00 - LMT 1882 -0:53:00 - FMT 1913 Jul 1 # Freetown Mean Time -1:00 SL %s 1941 Dec 6 24:00 0:00 - GMT

2 5

Re: [tz] tz Digest, Vol 114, Issue 4
by Alan Lehotsky March 2, 2021

March 2, 2021

I can confirm that there can be funny behavior on 32 bit O/S if zic runs without -b fat Sent from my iPhone > On Mar 2, 2021, at 10:08, tz-request(a)iana.org wrote: > > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Troubles with zone Asia/Gaza after tzdata2020b release > (Evgheni Antropov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 2 Mar 2021 08:49:33 +0000 > From: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Tim Parenti > <tim(a)timtimeonline.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b > release > Message-ID: <5b8eea9809f34e658c6529708744c1ad(a)addgrup.com> > Content-Type: text/plain; charset="us-ascii" > > Dear Paul and Tim, > Thank you for attention to this issue. > > We're using tzdata on the our embedded devices with ARMv7 Processor rev 2 (v7l), which has vanilla kernel > [root@Router8:~]# uname -a > Linux Router8 4.4.19-gdb0b54cdad #49 PREEMPT Mon Sep 30 15:10:54 EEST 2019 armv7l GNU/Linux > > Whole filesystem was compiled using Yocto Project 1.5 (poky-dora-10.0.0) https://old.yoctoproject.org/releases-yocto-version/yocto-project-15-dora > > Tzdata was compiling on Ubuntu 18.04 without any additional flags and cross-compilers, just simple make install > #!/bin/sh > make clean > > #For compiling source extract tzdata and tzcode in one directory and run: > make TOPDIR=$(pwd)/binaries install > > with additional changes related with requests from our several customers, which are not effecting on the this file. > > In attachment you can see whole listing of compilation. > > Best regards, > > > Evgheni Antropov > Software R&D Engineer > +373 22 404 665 > www.addgrup.com<http://www.addgrup.com> > > > -----Original Message----- > From: Paul Eggert <eggert(a)cs.ucla.edu> > Sent: Tuesday, March 2, 2021 01:59 > To: Tim Parenti <tim(a)timtimeonline.com> > Cc: Evgheni Antropov <Evgheni.Antropov(a)addgrup.com>; Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Troubles with zone Asia/Gaza after tzdata2020b release > >> On 3/1/21 1:19 PM, Tim Parenti via tz wrote: >> Why is the system you're >> testing only looking at the (legacy) 32-bit data in the v1 data block, >> and not using the 64-bit data in the v2+ data block? Please let us >> know more about the system you're running > > Another possibility is that Evgheni is using a stripped down library that ignores both data blocks, and uses only the TZ string at the end. > Such a library does not conform to Internet RFC 8536 but might be suitable for stripped down devices such as a router. For Asia/Gaza, the TZ string is TZ='EET-2EEST,M3.4.4/48,M10.4.4/49', where the "48" and "49" rely on the extension specified in Internet RFC 8536 section 3.3.1 and scheduled to appear in a future POSIX release. If Evgheni's library doesn't support that extension then that's the problem. > > Yet another possibility is that Evgheni's library simply ignores the TZ string. '-b slim' relies on the TZ string even for current timestamps, whereas '-b fat' fills out entries through 2038. However, if this were the issue I expect it would happen for timezones other than Asia/Gaza. > >> Please let us know more >> about the system you're running > > Yes, that'd be helpful. >

1 0