February 2021 - tz - lists.iana.org

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson March 18, 2022

March 18, 2022

I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > Thanks for bringing that to the mailing list (if I could shut off GitHub > pull requests I would). Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. https://github.com/eggert/tz/pulls?q=kiev Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. -- jhawk(a)alum.mit.edu John Hawkinson

10 13

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

Oct. 5, 2021

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

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

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

zdump man page misleading?
by Martin Burnicki Feb. 26, 2021

Feb. 26, 2021

Hi, the zdump.8.txt file generated from the current github code says: -c [loyear,]hiyear ... Cutoffs are at the start of each year, where the lower-bound timestamp is *exclusive* and the upper is *inclusive*; for example, -c 1970,2070 selects transitions after 1970-01-01 00:00:00 UTC and on or before 2070-01-01 00:00:00 UTC. The default cutoff is -500,2500. and $ ./zdump -V -c 2021,2022 Europe/Berlin Europe/Berlin Sun Mar 28 00:59:59 2021 UT = Sun Mar 28 01:59:59 .. Europe/Berlin Sun Mar 28 01:00:00 2021 UT = Sun Mar 28 03:00:00 .. Europe/Berlin Sun Oct 31 00:59:59 2021 UT = Sun Oct 31 02:59:59 .. Europe/Berlin Sun Oct 31 01:00:00 2021 UT = Sun Oct 31 02:00:00 .. (lines shorted to avoid line-wrapping) So the lower year is *inclusive* and the upper year is *exclusive*, and from my understanding these words should be swapped in the text of the man page. Or am I missing something? If I'm correct, should I provide a patch or pull request for the git repo? Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy

3 3

time zones only ?
by William Karlsson Feb. 25, 2021

Feb. 25, 2021

Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ? -- // Karlsson

3 2

New IANA-timezone support date/time library
by Kerry Shetline Feb. 24, 2021

Feb. 24, 2021

I’ve just finished an extensive update of a JavaScript/TypeScript date/time library that I’d previously used only for my own astronomy website, skyviewcafe.com <http://skyviewcafe.com/>. I’ve done enough updates to this library now that it may be of interest to many other software developers, especially if they want to handle the odd edge cases that exist in timezone handling, like 47-hour days and missing days and the like. One unique features is that it's possible for users to get live updates of the tz database, which usually don’t become available to applications without, at the very least, restarting an application, if not rebooting one’s computer. Libraries in this category are hardly unique, but one of the most popular libraries, Moment.js, is being phased out, so this seemed to be to be a good time to introduce a new one. Among the (possible) unique features, you can do things like find the specific moments of DST transitions and other transitions, like UTC offset changes, and get descriptions of these changes, like this: new DateTime('2021-11-07', 'America/New_York').getDiscontinuityDuringDay() → { start: '02:00:00', end: '01:00:00', delta: -3600000 } // fall back! // As soon as it’s midnight on the 30th, it’s instantly midnight on the 31st, erasing 24 hours:<br> new DateTime('2011-12-30', 'Pacific/Apia').getDiscontinuityDuringDay()) → { start: '00:00:00', end: '24:00:00', delta: 86400000 } // As soon as it’s midnight on the 31th, turn back to 1AM on the 30th, adding 23 hours to the day:<br> new DateTime('1969-09-30', 'Pacific/Kwajalein').getDiscontinuityDuringDay() → { start: '24:00:00', end: '01:00:00', delta: -82800000 } My updated library can be found here: https://www.npmjs.com/package/@tubular/time <https://www.npmjs.com/package/@tubular/time> Besides the IANA timezone support, this library also features the ability to handle variable switch-over from the Julian to the Gregorian calendar, which can be of helpful to those handling historical dates.

8 9

Re: [tz] Gratuitous optimization
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

Thanks, I installed your performance fix via the attached proposed patch. The performance bug seems to have been introduced by my commit 30364485a6fdc0333f48905db387e07abb70bac1 (2013-09-08) "Improve the support for perpetual DST" which first appeared in tzdb 2013e.

1 0

Re: [tz] New IANA-timezone support date/time library
by Kerry Shetline Feb. 23, 2021

Feb. 23, 2021

On 2021-02-22, at 14:25, Paul Gilmartin <PaulGBoulder(a)AIM.com> wrote: > But the "Help" link (<https://skyviewcafe.com/help/>) fails with 404. The “Help” link is working now, so I’m not sure what the issue was at the time you clicked on it. > I don't know whether you've followed the "Kiev"/"Kyiv" debate on tz(a)iana.org. > But I was curious what skyviewcafe.com does about it. I read a little of that, but haven’t followed it. At least the pronunciation of Kyiv isn’t an issue! ;) My geographic data base finds the Ukrainian capital by either spelling, so that’s not a problem. I’m not sure if showing “Europe/Kyiv” in my interface would be confusing or not, since that’s not the existing IANA name for the associated timezone. Users are generally expected to click “Find”, and find cities by name, thus getting longitude, latitude, and timezone automatically without fussing with a manual selection, so the IANA names aren’t quite so important. I also intend to update my manual interface to make timezone selections by standard UTC offset, and then a list of zones in that offset, as the default way to make a manual timezone selection, with region/zone being a secondary option. > I tried to enter > "50°25'N 30°31'E". I learned: > o It's tedious to enter such coordinates digit-by-digit. > o I found no way to refresh the page with the coordinates entered. It’s definitely tedious compared to just looking up a city and getting lat/long automatically. But if one wants to enter info manually, I’m curious what you’d prefer as a means of input. The manual entry field also supports rolling digits up and down, which is a fun way to explore how the sky changes as you change latitude and longitude. > Tz, trying to pivot away from the debate, says that internal directory > and filenames should not be obvious to users. Thus, applications should > not show me "America", "Denver", or "Kiev”. I hadn’t really thought of those names like “America/New_York” as file names, but as names for timezones as abstract timezone entities. In fact, there is no “America/New_York” file in the tzdb. There’s a file named “northamerica”, and inside that file, a zone entry named "America/New_York”. Perhaps that’s still something a bit too rawly technical to be considered user-friendly, however. -Kerrt

3 2

[PATCH 1/5] Don't cite Howse where no longer used
by Paul Eggert Feb. 23, 2021

Feb. 23, 2021

--- africa | 3 --- asia | 3 --- 2 files changed, 6 deletions(-) diff --git a/africa b/africa index 28168cf..fca9af7 100644 --- a/africa +++ b/africa @@ -30,9 +30,6 @@ # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94. # https://www.jstor.org/stable/1774359 # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # European-style abbreviations are commonly used along the Mediterranean. # For sub-Saharan Africa abbreviations were less standardized. # Previous editions of this database used WAT, CAT, SAT, and EAT diff --git a/asia b/asia index ed94413..ac7def8 100644 --- a/asia +++ b/asia @@ -34,9 +34,6 @@ # Byalokoz EL. New Counting of Time in Russia since July 1, 1919. # (See the 'europe' file for a fuller citation.) # -# A reliable and entertaining source about time zones is -# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). -# # The following alphabetic abbreviations appear in these tables # (corrections are welcome): # std dst -- 2.27.0

2 6

Some time zone history (2)
by P Chan Feb. 21, 2021

Feb. 21, 2021

Bahamas There were two periods of DST observed in 1941-1945: 1941-05-01 midnight to 1944-12-31 and 1945-02-01 to 1945-10-17 midnight. War Time Order 1942 [1942-05-01] and War Time (No. 2) Order 1942 [1942-09-29] Appendix to the Statutes of 7 George VI. and the Year 1942. p 34, 43 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA34 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA3-PA43 War Time Order 1943 [1943-03-31] and War Time Order 1944 [1943-12-29] Appendix to the Statutes of 8 George VI. and the Year 1943. p 9-10, 28-29 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA9 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA4-PA28 War Time Order 1945 [1945-01-31] and the Order which revoke War Time Order 1945 [1945-10-16] Appendix to the Statutes of 9 George VI. and the Year 1945. p 160, 247-248 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA160 https://books.google.com/books?id=5rlNAQAAIAAJ&pg=RA6-PA247 ---------- Guyana 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. The Official Gazette of British Guiana. (New Series.) Vol. XL. July to December, 1915, p 1547 https://books.google.com/books?id=5-5CAQAAMAAJ&pg=SA1-PA547 Interpretation and general clauses (Amendment) Act 1975 (Act No. 27 of 1975) [1975-07-31] https://parliament.gov.gy/documents/acts/10923-act_no._27_of_1975_-_interpr… Interpretation and general clauses (Amendment) Act 1992 (Act No. 6 of 1992) [1992-04-18] https://parliament.gov.gy/documents/acts/5885-6_of_1992_interpretation_and_… Circular No. 10/1992 dated 1992-03-30 https://dps.gov.gy/wp-content/uploads/2018/12/1992-03-20-Circular-010.pdf ---------- Nigeria On 1914-01-01, standard time of GMT+0:30 was adopted for the unified Nigeria. Colonial Reports - Annual. No. 878. Nigeria. Report for 1914. (April 1916), p 27 https://libsysdigi.library.illinois.edu/ilharvest/Africana/Books2011-05/306… Interpretation Ordinance, 1914 (No. 4 of 1914) [1914-10-01] https://books.google.com.hk/books?id=mm5CAQAAMAAJ&pg=PA172 In 1919, standard time was changed to GMT+1. Interpretation Ordinance (Cap 2) The Laws of Nigeria, Containing the Ordinances of Nigeria, in Force on the 1st Day of January, 1923, Vol.I p 5-18 https://books.google.com.hk/books?id=BOMrAQAAMAAJ&pg=PA16 For the standard time used in Lagos before 1914, the Interpretation Ordinance of Southern Nigeria, 1908 revised edition defined “Time” to mean Greenwich time. That section was originated from Proclamation No. 11 of 1905 of the Protectorate of Southern Nigeria. But the Colony of Lagos was not merged into Southern Nigeria until May 1906. Moreover, the 1906 Report of Southern Nigeria says “all laws in force in any part of the territory prior to the commencement of the new system of government shall continue in force until further provision is made by the local legislature.” Lloyd's Register of Shipping (1915) says “Hitherto the time observed in Lagos was the local mean time. On 1st January, 1914, standard time for the whole of Nigeria was introduced … Lagos time has been advanced about 16 minutes accordingly.” Therefore it is possible that no standard time was adopted in Lagos until 1914. Interpretation Ordinance (Cap 2) Laws of the Colony of Southern Nigeria : being the schedule to the Statute laws revision ordinance, 1908, Vol.I, p 3-11 https://babel.hathitrust.org/cgi/pt?id=mdp.35112105426037&view=1up&seq=61 Colonial Reports - Annual. No. 554. Southern Nigeria. Report for 1906. (February 1908), p 43 https://libsysdigi.library.illinois.edu/ilharvest/Africana/Books2011-05/306… Lloyd's Register of Shipping. 1915-16. Vol. II.-Appendix. ,p 655 https://books.google.com/books?id=b_ROAQAAIAAJ&pg=PA655 ---------- Seychelles Standard Time was adopted on 1907-01-01. Standard Time Ordinance (Chapter 237) The Laws of Seychelles in Force on the 31st December, 1971, Vol. 6, p 571 https://books.google.com/books?id=efE-AQAAIAAJ&pg=PA571 ---------- Turks and Caicos Islands Standard Time Declaration Order 2015 (L.N. 15/2015) http://online.fliphtml5.com/fizd/czin/#p=2 Standard Time Declaration Order 2017 (L.N. 31/2017) http://online.fliphtml5.com/fizd/dmcu/#p=2 ---------- Vanuatu DST was observed in 1973/1974. The spring forward in 1984 should be on Sep 23. Joint Daylight Saving Regulation No 59 of 1973 New Hebrides Condominium Gazette No 336. December 1973 http://www.paclii.org/vu/other/VUNHGovGaz//1973/11.pdf#page=15 Joint Daylight Saving (Repeal) Regulation No 10 of 1974 New Hebrides Condominium Gazette No 336. March 1974 http://www.paclii.org/vu/other/VUNHGovGaz//1974/3.pdf#page=11 Summer Time Act No. 35 of 1982 [1983-09-01] http://www.paclii.org/vu/other/VUGovGaz/1982/32.pdf#page=48 Summer Time Act (Cap 157) Laws of the Republic of Vanuatu Revised Edition 1988 http://www.paclii.org/cgi-bin/sinodisp/vu/legis/consol_act1988/sta147/sta14… Summer Time (Amendment) Act No. 6 of 1991 [1991-11-11] http://www.paclii.org/vu/legis/num_act/sta1991227/ Summer Time (Repeal) Act No. 4 of 1993 [1993-05-03] http://www.paclii.org/vu/other/VUGovGaz/1993/15.pdf#page=59

4 11

[PATCH] Fixups for today’s patches
by Paul Eggert Feb. 18, 2021

Feb. 18, 2021

* NEWS: Mention the recent all-year DST change. * zic.c (stringzone): Fix sign bug. --- NEWS | 7 +++++++ zic.c | 2 +- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index af5dd9f..f3c94ed 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,13 @@ Unreleased, experimental changes last time transition disagreed with the TZ string, contrary to Internet RFC 8563 section 3.3. + zic now generates a POSIX-conforming TZ string for TZif files + where all-year DST is predicted for the indefinite future. + For example, for all-year Eastern Daylight Time, zic now generates + "XXX3EDT4,0/0,J365/23" where it previously generated + "EST5EDT,0/0,J365/25" or "". (Thanks to Michael Deckers for + noting the possibility of POSIX conformance.) + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/zic.c b/zic.c index 4893a32..b91cb6c 100644 --- a/zic.c +++ b/zic.c @@ -2519,7 +2519,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) Fake a timezone with negative DST. */ stdzp = &zstr[0]; dstzp = &zstr[1]; - zstr[0].z_stdoff = zp->z_stdoff - 2 * save; + zstr[0].z_stdoff = zp->z_stdoff + 2 * save; zstr[0].z_format = "XXX"; /* Any 3 letters will do. */ zstr[0].z_format_specifier = 0; zstr[1].z_stdoff = zstr[0].z_stdoff; -- 2.27.0

1 0

[PATCH 1/4] Avoid use of local statics
by Paul Eggert Feb. 18, 2021

Feb. 18, 2021

* zic.c (inrule, inzsub, writezone): Avoid use of static when auto will do. This can help GCC catch uninitialized-variable errors. --- zic.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/zic.c b/zic.c index 51977b2..8653fb0 100644 --- a/zic.c +++ b/zic.c @@ -1341,7 +1341,7 @@ getsave(char *field, bool *isdst) static void inrule(char **fields, int nfields) { - static struct rule r; + struct rule r; if (nfields != RULE_FIELDS) { error(_("wrong number of fields on Rule line")); @@ -1418,7 +1418,7 @@ inzsub(char **fields, int nfields, bool iscont) { register char * cp; char * cp1; - static struct zone z; + struct zone z; register int i_stdoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; @@ -1868,8 +1868,6 @@ writezone(const char *const name, const char *const string, char version, register FILE * fp; register ptrdiff_t i, j; register int pass; - static const struct tzhead tzh0; - static struct tzhead tzh; bool dir_checked = false; zic_t one = 1; zic_t y2038_boundary = one << 31; @@ -2000,6 +1998,7 @@ writezone(const char *const name, const char *const string, char version, for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; + struct tzhead tzh; int currenttype, thisdefaulttype; bool locut, hicut; zic_t lo; @@ -2168,7 +2167,7 @@ writezone(const char *const name, const char *const string, char version, thistimelim = thistimei; } #define DO(field) fwrite(tzh.field, sizeof tzh.field, 1, fp) - tzh = tzh0; + memset(&tzh, 0, sizeof tzh); memcpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = version; convert(utcnt, tzh.tzh_ttisutcnt); -- 2.27.0

1 3

State of Palestine Time zone - need to update
by heba hamad Feb. 14, 2021

Feb. 14, 2021

Dear Sir/Madam, In reference to your recent response at 25 Oct,2020 regarding State of Palestine's request to correct the 'Time Zone Database', we would like to confirm that 'TZ' related to the State of Palestine is as follows: PS State of Palestine Asia/East Jerusalem UTC +2:00 Also, we would like to inform you that the State of Palestine comprises of the West Bank, including East Jerusalem and Gaza, all of which are integral parts of the State of Palestine, thus, as one territorial unit all areas belong to the same time zone. We would like to also emphasize that East Jerusalem is an integral part of the West Bank as stipulated under international law and by numerous international resolutions. Therefore, we urge you to adopt the official name and correct your data base. Best Regards, Heba Hamad 11 Feb,2021

22 35

[PATCH 1/2] Remove unused C macros
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

Also, pacify ‘gcc -Wunused-macros’, which was employed to find these unused macros. * localtime.c (NETBSD_INSPIRED_EXTERN): Define only if STD_INSPIRED is defined. * private.h (sys_time) [!TZ_TIME_T]: Inspect LOCALTIME_IMPLEMENTATION. * zdump.c (MAX_STRING_LENGTH): * zic.c (PRIdZIC): Remove these macros, which are no longer used. --- localtime.c | 16 ++++++++-------- private.h | 7 ++++--- zdump.c | 4 ---- zic.c | 1 - 4 files changed, 12 insertions(+), 16 deletions(-) diff --git a/localtime.c b/localtime.c index d3e406b..82a3b70 100644 --- a/localtime.c +++ b/localtime.c @@ -28,14 +28,6 @@ static int lock(void) { return 0; } static void unlock(void) { } #endif -/* NETBSD_INSPIRED_EXTERN functions are exported to callers if - NETBSD_INSPIRED is defined, and are private otherwise. */ -#if NETBSD_INSPIRED -# define NETBSD_INSPIRED_EXTERN -#else -# define NETBSD_INSPIRED_EXTERN static -#endif - #ifndef TZ_ABBR_MAX_LEN #define TZ_ABBR_MAX_LEN 16 #endif /* !defined TZ_ABBR_MAX_LEN */ @@ -2247,6 +2239,14 @@ leapcorr(struct state const *sp, time_t t) #ifdef STD_INSPIRED +/* NETBSD_INSPIRED_EXTERN functions are exported to callers if + NETBSD_INSPIRED is defined, and are private otherwise. */ +# if NETBSD_INSPIRED +# define NETBSD_INSPIRED_EXTERN +# else +# define NETBSD_INSPIRED_EXTERN static +# endif + /* ** IEEE Std 1003.1 (POSIX) says that 536457599 ** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which diff --git a/private.h b/private.h index 9efcd78..a919e4f 100644 --- a/private.h +++ b/private.h @@ -418,10 +418,11 @@ typedef unsigned long uintmax_t; # define TZ_TIME_T 0 #endif -#if TZ_TIME_T -# ifdef LOCALTIME_IMPLEMENTATION +#if defined LOCALTIME_IMPLEMENTATION && TZ_TIME_T static time_t sys_time(time_t *x) { return time(x); } -# endif +#endif + +#if TZ_TIME_T typedef time_tz tz_time_t; diff --git a/zdump.c b/zdump.c index b532fe3..57e363e 100644 --- a/zdump.c +++ b/zdump.c @@ -42,10 +42,6 @@ #define ZDUMP_HI_YEAR 2500 #endif /* !defined ZDUMP_HI_YEAR */ -#ifndef MAX_STRING_LENGTH -#define MAX_STRING_LENGTH 1024 -#endif /* !defined MAX_STRING_LENGTH */ - #define SECSPERNYEAR (SECSPERDAY * DAYSPERNYEAR) #define SECSPERLYEAR (SECSPERNYEAR + SECSPERDAY) #define SECSPER400YEARS (SECSPERNYEAR * (intmax_t) (300 + 3) \ diff --git a/zic.c b/zic.c index b37cdc9..51977b2 100644 --- a/zic.c +++ b/zic.c @@ -21,7 +21,6 @@ typedef int_fast64_t zic_t; #define ZIC_MIN INT_FAST64_MIN #define ZIC_MAX INT_FAST64_MAX -#define PRIdZIC PRIdFAST64 #define SCNdZIC SCNdFAST64 #ifndef ZIC_MAX_ABBR_LEN_WO_WARN -- 2.27.0

1 1

[PATCH] Clarify GCC pacification in previous fix
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

* zic.c (outzone): Make it clear that prevktime is initialized only to pacify GCC. --- zic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zic.c b/zic.c index a864bc4..b37cdc9 100644 --- a/zic.c +++ b/zic.c @@ -2715,7 +2715,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) for (i = 0; i < zonecount; ++i) { struct rule *prevrp = NULL; - zic_t prevktime = min_time; + zic_t prevktime; + INITIALIZE(prevktime); /* ** A guess that may well be corrected later. */ -- 2.27.0

1 0

[PATCH] Fix bug in last time type of Asia/Gaza etc.
by Paul Eggert Feb. 13, 2021

Feb. 13, 2021

* zic.c (outzone): When avoiding bloat due to transitions deducible from the TZ string, don’t eliminate transitions that are before any lower-bound cutoff established by -r. All but the last of these transitions will be discarded later by limitrange, and the last transition is needed so that the dummy time type after the TZif file’s last transition agrees with the TZ string as required by Internet RFC 8536 section 3.3. This problem can be observed in tzdb 2021a if you run the command ‘zic -r@2145916800 asia’: the output file Asia/Gaza’s only time transition, which is at the specified time 2038-01-01 00:00:00 UTC, has an associated time type that specifies +03 with DST, rather than the correct +02 without DST. --- NEWS | 6 ++++++ zic.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index b9d5777..a22e8ff 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,12 @@ Unreleased, experimental changes Portugal observed DST in 1950. (Thanks to Alois Treindl.) + Changes to code + + Fix bug in zic -r; in some cases, the dummy time type after the + last time transition disagreed with the TZ string, contrary to + Internet RFC 8563 section 3.3. + Release 2021a - 2021-01-24 10:54:57 -0800 diff --git a/zic.c b/zic.c index a902b34..a864bc4 100644 --- a/zic.c +++ b/zic.c @@ -2715,6 +2715,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) for (i = 0; i < zonecount; ++i) { struct rule *prevrp = NULL; + zic_t prevktime = min_time; /* ** A guess that may well be corrected later. */ @@ -2851,7 +2852,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) rp->r_isdst, rp->r_save, false); offset = oadd(zp->z_stdoff, rp->r_save); if (!want_bloat() && !useuntil && !do_extend - && prevrp + && prevrp && lo_time <= prevktime && rp->r_hiyear == ZIC_MAX && prevrp->r_hiyear == ZIC_MAX) break; @@ -2865,6 +2866,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) lastatmax = timecnt; addtt(ktime, type); prevrp = rp; + prevktime = ktime; } } if (usestart) { -- 2.27.0

1 0

Replying to government officials
by John Hawkinson Feb. 12, 2021

Feb. 12, 2021

I wonder if we should have some kind of understanding of when it is appropriate for the general members of the list to respond to emails from government officials, versus deferring that task to the project coordinators. (I have thought this was a concern for some time, but multiple recent messages have amplified it in my mind.) -- jhawk(a)alum.mit.edu John Hawkinson

2 1

DST existed in Portugal 1950
by Alois Treindl Feb. 10, 2021

Feb. 10, 2021

TZ claims that in 1950 there was no DST in Portugal, zone Europe/Lisbon. While it was continuously applied between 1916 and 1965. The sources quoted in file europe are poor, it is only Whitman versus Shanks/Pottenger. I have research online law collection for Portugal at https://dre.pt/ and searched for 'hora de verão'. The results are sparse, but what I find on legal texts does not indicate any interruption of the 1916 law for the year 1950. This Wikipedia page shows a list https://pt.wikipedia.org/wiki/Lista_de_per%C3%ADodos_em_que_vigorou_o_hor%C… and mentions the Decreto-Lei nº 37048 for 1949-1965. That law says 'first Sunday in April to first Sunday in October. No exception for 1950. Here is a list from the Lisbon astronomical observatory, which says the same thing. http://oal.ul.pt/documentos/2018/01/hl1911a2018.pdf/ I suggest that the rules for Europe/Lisbon should be updated accordingly.

3 6

Request for change to the tz database
by Nadia Kobyliak Feb. 9, 2021

Feb. 9, 2021

Dear Arthur and Paul, I would like to draw your attention to one of the names of the UTC+2 time zone: Europe/Kiev . And suggest changing it to Europe/Kyiv. This name is derived from the name of Ukrainian capital “Київ”. Its official transliteration(1) is “Kyiv” and not “Kiev”. The transliteration “Kyiv” was approved by the Tenth United Nations Conference on Standardization of Geographical Names(2). This is a warranty of the campaign KyivNotKiev launched by Ministry of Foreign Affairs of Ukraine(3). This is a very important issue for Ukrainians in establishing our national identity in times of an armed conflict and hybrid war by propaganda and misinformation. “To appreciate the significance of the “Kyiv vs. Kiev” debate, one must first step back and view it in terms of the deep-rooted national identity crisis caused by centuries of Tsarist and Soviet russification.” (4) It would make a huge difference if you considered this suggestion! And please let me know, if there is something else I should do to substantiate this proposal. References: 1. According to the rules approved by Governmental decree from 27 January 2010 №55: https://www.kmu.gov.ua/npas/243262567 This particular example could be found there. 2. Resolution X/9. Romanization of Ukrainian geographical names could be found in the Report of the Conference: https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CO… Document approved by the resolution: “Romanization System in Ukraine” https://unstats.un.org/unsd/geoinfo/UNGEGN/docs/10th-uncsgn-docs/econf/E_CO… 1. It may also be interesting for you to find out more about the movement on Wikipedia page: https://en.wikipedia.org/wiki/KyivNotKiev 2. An article on this matter in English could be found on Atlantic Council web-site: https://www.atlanticcouncil.org/blogs/ukrainealert/kyiv-not-kiev-why-spelli… Kind regards, Nadia Kobyliak [Изображение выглядит как знак Автоматически созданное описание] Nadia Kobyliak Senior project manager SOEs and Corporate Governance reform ________________________________ cell.: +38 097 642 35 29 12/2 Hrushevskoho str. me.gov.ua<http://www.me.gov.ua/> kobyliak.nadia(a)gmail.com<mailto:kobyliak.nadia@gmail.com> 01008 Kyiv Twitter<http://twitter.com/mineconomdev> NKobyliak(a)me.gov.ua<mailto:NKobyliak@me.gov.ua> Ukraine Facebook<http://facebook.com/mineconomdev>

17 33

Re: [tz] Request for change to the tz database
by Hal Murray Feb. 8, 2021

Feb. 8, 2021

tim(a)timtimeonline.com said: > Yes, and as the proposal moves forward, we could provide the IANA moderators > with updated boilerplate as necessary. I'd expect the boilerplate to be a pointer to a FAQ entry. I think a note on the page about the list would be helpful and friendly. https://mm.icann.org/mailman/listinfo/tz -- These are my opinions. I hate spam.

1 0

Re: [tz] South Sudan to change time zone?
by Paul Eggert Feb. 8, 2021

Feb. 8, 2021

On 2/7/21 10:16 AM, Hayo Schmidt wrote: > you created a new > edge case by defining 00:00 of a day and then shifting back the date by > one day (and 23 hours forward). This sort of edge case is not new to Africa/Juba. For example, it occurred on 2020-03-22 at 00:00 in America/Asuncion, and is scheduled to occur again on 2021-03-28 at 00:00 at the same location. > A datum could have been created when reaching the first time exactly > 00:00:00.000. This is modeled in tzdb by the clock ticking 23:59:59.999999999 (as many 9s as you like) followed by 23:00:00.000000000 (the same number of 0s). That is, all the timestamps from 23:00:00.000000000 through 23:59:59.999999999 occur twice, but 00:00:00.000000000 the next day occurs only once. In this sense, there's no difference between a transition at 24:00, and one at 02:00. You can seem more details by running the command "zdump -v Africa/Juba".

1 0

Fwd: Timezone issue
by Yaroslav Bilko Feb. 5, 2021

Feb. 5, 2021

Hi, hope you're doing great! I've noticed some libraries use quite an irrelevant name for the capital of Ukraine: "Timezone: Europe/Kiev". And it comes from TZDB. C'mon lads, everybody in the whole civilized world knows that Kiev is wrong but you use it for some reason (only bloody russians talk like this and without any permission from our country (ukrainians), they push that name just because they want conquer our country and erase ukrainnian culture and you help them to achieve this goal!), the only one official name of this city is Kyiv! Yes, many people say "Kiev" even in Ukraine, but their number is getting down very fast. People start to figure it out. And the most important thing - they use it in non-public conversations. In all public places all information must be written Ukrainian (sometimes dubbing with English and that's it). It is protected by the law ( https://zakon.rada.gov.ua/laws/show/2704-19#Text) All Latin transliteration of our cities written in this law: https://zakon.rada.gov.ua/laws/show/z0957-14#Text [image: image.png] No Kiev as you can see. Only Kyiv. Soviet name "Kiev" disappeared 30 years ago. There's no need to exhume this corpse from the grave. Ukraine started a official campaign ( https://mfa.gov.ua/news/67521-correctua-mzs-ukrajini-zvertajetysya-do-svitu… ) some time ago to show other countries and mass media that Kyiv is only one true name. Even Google accepted it and maps show the correct name. That hit me and my friends and colleagues right in a heart! We hope you find some time to fix this little typo, but this is little only for first look! Hope for your care.

4 5

Names of Areas
by Andrea Boyle Feb. 3, 2021

Feb. 3, 2021

Hello, I am writing to you to request a small but significant change to the area options that are currently listed in the database. Recently I used software that uses the database for the area and location information and I was initially very puzzled when trying to find Canada. America was there but no other country in the North or South American continents. After a little research I realized that the database has America represent both. The trouble I have is that America is also a well used name for the United States and represents the name of a country rather than the two continents. I will be honest that it definitely rubbed the wrong way to have to choose America to find a city in Canada and I would also bet that outside of the US it would not be intuitive to choose America when looking for other countries within North and South America. To that end, I think it would be a great improvement to update the area to "Americas" or "the Americas" so that it was much clearer that it represents more than just one country. Thank you -- Andrea Boyle

3 2

(Near) UNIX epoch in the wild
by Arthur David Olson Feb. 1, 2021

Feb. 1, 2021

Today at the Paul S. Sarbanes Silver Spring (Maryland) Transit Center. https://twitter.com/dashdashado/status/1356321947005628418 @dashdashado

2 1