- tz - lists.iana.org

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Steve Allen April 26, 2021

April 26, 2021

On Mon 2021-04-26T17:17:13+0100 Tony Finch via tz hath writ: > My aim back then was to sketch what might be a reasonable way to bridge > between pre-atomic time and UTC, for code that can only support an integer > offset between UTC and TAI. If your code supports rubber seconds then it > should probably use the USNO table that records the rate and phase offsets > between 1962 and 1972. (I don't know another source of that table, nor > where you can get a copy while maia.usno.navy.mil is down.) Keep in mind that the USNO numbers only apply to time signals broadcast in the US, and before 1968 they ignore the many microseconds of offset between NBS and USNO. Germany did not start to broadcast the old UTC until the late 1960s, until 1974-01-01 broadcast both old UTC and SAT, and stopped providing old UTC as of 1970-04-01 because it had been deemed illegal. Soviet and Chinese time signals never used the old UTC. Sussing out the particulars for individual cases of national time signals needs finding remnants of the high-acid paper that each national time service used for bulletins issued to its users, and/or diving through the BIH Bulletin Horaire and Circular D to pull out the received timing of each official broadcast. It is much simpler to ignore the 50 to 200 ms jumps that were put into old UTC and say that before 1972 all available sources of civil time provided UT (nevermind the particular flavor, nobody set their clock that accurately) and after 1972 UTC with leap seconds. For civil time I do not see any advantage in a model with greater complexity than just plain UT as the basis time scale before 1972-01-01. This is adequate for any IANA tz library. For precise time no general model applies. Each precise timestamp must be meticulously referenced to the particulars of the clocks that were used to obtain it. No available clocks were using TAI before 1972-01-01, and this does not belong in any IANA tz library. Constructing a model that supposes it is possible to do better is akin to writing The Silmarillion. Look at the BIH plots of the accuracy of clocks https://www.ucolick.org/~sla/leapsecs/BHsHn05p142.html millisecond agreement between different national authorities was not achieved until 1960 during the UK/US experiment that became old UTC. > * TAI is a retrospective timescale; it isn't defined in the future. TAI also cannot be defined prior to mid 1955, and it was not generally availble for use by any system until 1972-01-01 when broadcast time signals began to be based on TAI. The BIPM will never tolerate TAI becoming part of an international agreement. The best that can be hoped for in a new international agreement on time is one (or more) new TAI-like uniform scale which will be offset by some integer number of seconds from TAI. The reason we use UTC is because it is what is in the current international agreement. Everybody involved in the technical aspects eschewed the use of UTC for their systems from before 1972-01-01. Look at the ATSC agreement for a technically-competent time scale. They chose GPS time because it is practically available. ATSC was not bound by international bureaucratic requirements, so they could make that choice. Because it is ultimately controlled by USNO GPS system time will never become part of an international agreement. On Mon 2021-04-26T12:42:19-0400 John Sauter via tz hath writ: > In looking at historical estimates of the rotation of the Earth based > on astronomical observations of occulations and eclipses, I found that > the values of UT1 are reliabe only since 1825. (Nevertheless, my table > of proleptic leap seconds goes back to the year -2000.) Morrison, L. V.; Stephenson, F. R.; Hohenkerk, C. Y.; Zawilski, M. DOI: 10.1098/rspa.2020.0776 Bibliographic Code: 2021RSPSA.47700776M Proceedings of the Royal Society A, Volume 477, Issue 2246, id.20200776 all tabulated at http://astro.ukho.gov.uk/nao/lvm/ That is the place to look, and it will continue to be so for the lifetime of the authors. But what is it mean to ask reliable? That is very much the question given that prior to "reliable" everybody's clock was set to local apparent time. What exactly is the question that is trying to be answered by an algorithm like this? Ultimately it is necessary to model two kinds of time: 1) earth rotation time (which before the 20th century differed by a second or more depending on who was setting the clock) because that is a subdivision of internationally agreed calendar days 2) uniform time (which becomes possible to interpret as atomic time beginning in 1955). -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Do not assume bytes have 8 bits
by Paul Eggert April 26, 2021

April 26, 2021

* zic.c (convert, convert64): Mask bytes with 0xff before storing them, for portability to machines where bytes have more than 8 bits. Although this is surely only of theoretical interest, we might as well be portable. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 88b1531..77a5698 100644 --- a/zic.c +++ b/zic.c @@ -1927,7 +1927,7 @@ convert(uint_fast32_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 24; i < 4; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void @@ -1938,7 +1938,7 @@ convert64(uint_fast64_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 56; i < 8; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void -- 2.27.0

4 5

[PATCH] Fix potential integer overflow in differ_by_repeat
by Paul Eggert April 26, 2021

April 26, 2021

* localtime.c (differ_by_repeat): Remove, since the subtraction t1 - t0 could in theory overflow in 64-bit TZif data. (tzloadbody): Redo to avoid integer overflow. * private.h (SECSPERREPEAT_BITS): Remove; no longer used. --- localtime.c | 30 ++++++++++++++---------------- private.h | 3 +-- 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/localtime.c b/localtime.c index 9dd496d..9840b89 100644 --- a/localtime.c +++ b/localtime.c @@ -334,14 +334,6 @@ scrub_abbrs(struct state *sp) } } -static bool -differ_by_repeat(const time_t t1, const time_t t0) -{ - if (TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) - return 0; - return t1 - t0 == SECSPERREPEAT; -} - /* Input buffer for data read from a compiled tz file. */ union input_buffer { /* The first part of the buffer, interpreted as a header. */ @@ -660,20 +652,26 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (sp->typecnt == 0) return EINVAL; if (sp->timecnt > 1) { + if (sp->ats[0] <= TIME_T_MAX - SECSPERREPEAT) { + time_t repeatat = sp->ats[0] + SECSPERREPEAT; + int repeattype = sp->types[0]; for (i = 1; i < sp->timecnt; ++i) - if (typesequiv(sp, sp->types[i], sp->types[0]) && - differ_by_repeat(sp->ats[i], sp->ats[0])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goback = true; break; - } + } + } + if (TIME_T_MIN + SECSPERREPEAT <= sp->ats[sp->timecnt - 1]) { + time_t repeatat = sp->ats[sp->timecnt - 1] - SECSPERREPEAT; + int repeattype = sp->types[sp->timecnt - 1]; for (i = sp->timecnt - 2; i >= 0; --i) - if (typesequiv(sp, sp->types[sp->timecnt - 1], - sp->types[i]) && - differ_by_repeat(sp->ats[sp->timecnt - 1], - sp->ats[i])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goahead = true; break; - } + } + } } /* Infer sp->defaulttype from the data. Although this default diff --git a/private.h b/private.h index cee3b11..340a354 100644 --- a/private.h +++ b/private.h @@ -642,7 +642,7 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TIME_T_MAX_NO_PADDING MAXVAL(time_t, TYPE_BIT(time_t)) /* The extreme time values. These are macros, not constants, so that - any portability problem occur only when compiling .c files that use + any portability problems occur only when compiling .c files that use the macros, which is safer for applications that need only zdump and zic. This implementation assumes no padding if time_t is signed and either the compiler lacks support for _Generic or time_t is not one @@ -727,7 +727,6 @@ char *ctime_r(time_t const *, char *); #define YEARSPERREPEAT 400 /* years before a Gregorian repeat */ #define DAYSPERREPEAT ((int_fast32_t) 400 * 365 + 100 - 4 + 1) #define SECSPERREPEAT ((int_fast64_t) DAYSPERREPEAT * SECSPERDAY) -#define SECSPERREPEAT_BITS 34 /* ceil(log2(SECSPERREPEAT)) */ #define AVGSECSPERYEAR (SECSPERREPEAT / YEARSPERREPEAT) #define TM_SUNDAY 0 -- 2.27.0

1 0

[PROPOSED 1/2] Do not assume unsigned->signed conversion style
by Paul Eggert April 23, 2021

April 23, 2021

* localtime.c (detzcode64): Use int_fast64_t, not uint_fast64_t, for local variable, to avoid an implementation-defined conversion when the variable’s value is returned. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c88b6e..9dd496d 100644 --- a/localtime.c +++ b/localtime.c @@ -237,7 +237,7 @@ detzcode(const char *const codep) static int_fast64_t detzcode64(const char *const codep) { - register uint_fast64_t result; + register int_fast64_t result; register int i; int_fast64_t one = 1; int_fast64_t halfmaxval = one << (64 - 2); -- 2.27.0

1 1

[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

[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