September 2019 - tz - lists.iana.org

Italy April 1944 discrepancy between comment and data
by Alois Treindl 05 Oct '21

05 Oct '21

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

An update on AP style on Kyiv
by John Hawkinson 20 Nov '19

20 Nov '19

I apologize for stirring the pot by contributing to one of our longer-running topics of late, however: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv -- jhawk(a)alum.mit.edu John Hawkinson Date: Wed, 14 Aug 2019 14:08:09 -0000 From: "The Definitive Source: <author>" Subject: An update on AP style on Kyiv X-RSS-Feed: https://blog.ap.org/feed.rss X-RSS-ID: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv X-RSS-URL: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv X-RSS-TAGS: Kyiv,Kiev,Ukraine,AP Style,AP Stylebook,Announcements,featured,Definitive-Source We are making a significant change in our style for the Ukrainian capital city Kiev. It will henceforth be written in text, captions and datelines as Kyiv. URL: https://blog.ap.org/announcements/an-update-on-ap-style-on-kyiv

14 26

Morocco Time must stay at GMT+1
by Naoufal Semlali 30 Sep '19

30 Sep '19

Good Morning, I want to inform you that Morocco is not concerned by the transition to the winter time which will take place in Europe on the night of Saturday, October 26 to Sunday, October 27, 2019. Morocco's schedule must stay on GMT+1 The schedule change take place only before and after the month of Ramadan. Best Regards De : Naoufal Semlali Envoyé : jeudi 18 avril 2019 08:27 À : 'Paul Eggert' <eggert(a)cs.ucla.edu> Cc : Time zone mailing list <tz(a)iana.org>; Maamar Abdelkader <A.MAAMAR(a)iam.ma> Objet : RE: Will Morocco switch from +01 to +00 during Ramadan next year? Hello, The predictions below seem to be correct based on the latest official declarations of the Moroccan government. Of course, if there will be any change, we will keep you informed. Thanks. Semlali -----Message d'origine----- De : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Envoyé : mercredi 17 avril 2019 19:04 À : Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> Cc : Time zone mailing list <tz(a)iana.org<mailto:tz@iana.org>>; Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>> Objet : Re: Will Morocco switch from +01 to +00 during Ramadan next year? On 4/17/19 12:24 AM, Naoufal Semlali wrote: > > Please confirm also that the switch to GMT+1 on Sunday, June 9th 2019 > at 2 am is already implemented in the tzdata. > Yes, I checked that too. For what it's worth, here are the tzdata 2018h-and-later predictions for Africa/Casablanca through the year 2037. The columns are the date, the hour just after the transition, the UTC offset just after the transition, and (optionally) 1 if (negative) DST is in effect. These predictions could well be wrong: if you have better info please let us know. 2019-05-05 02 +00 1 2019-06-09 03 +01 2020-04-19 02 +00 1 2020-05-24 03 +01 2021-04-11 02 +00 1 2021-05-16 03 +01 2022-03-27 02 +00 1 2022-05-08 03 +01 2023-03-19 02 +00 1 2023-04-23 03 +01 2024-03-10 02 +00 1 2024-04-14 03 +01 2025-02-23 02 +00 1 2025-04-06 03 +01 2026-02-15 02 +00 1 2026-03-22 03 +01 2027-02-07 02 +00 1 2027-03-14 03 +01 2028-01-23 02 +00 1 2028-02-27 03 +01 2029-01-14 02 +00 1 2029-02-18 03 +01 2029-12-30 02 +00 1 2030-02-10 03 +01 2030-12-22 02 +00 1 2031-01-26 03 +01 2031-12-14 02 +00 1 2032-01-18 03 +01 2032-11-28 02 +00 1 2033-01-09 03 +01 2033-11-20 02 +00 1 2033-12-25 03 +01 2034-11-05 02 +00 1 2034-12-17 03 +01 2035-10-28 02 +00 1 2035-12-02 03 +01 2036-10-19 02 +00 1 2036-11-23 03 +01 2037-10-04 02 +00 1 2037-11-15 03 +01 ________________________________ [Description : cid:image002.jpg@01CC9EE4.44A57D10]Eco – geste: privilégiez la sauvegarde électronique, si nécessaire imprimez en recto-verso ________________________________ Ce message et toutes les pièces jointes sont adressés à l'attention exclusive de leurs destinataires et sont strictement confidentiels. Si vous le recevez par erreur, merci de le détruire après en avoir informé l'expéditeur sans délai. Toute divulgation, copie ou usage par une personne autre que son destinataire sont interdits. Maroc Telecom décline toute responsabilité pour toute altération, déformation ou falsification subie par le message au cours de sa transmission. Retrouvez toutes les informations de Maroc Telecom sur www.iam.ma<http://www.iam.ma> . ________________________________ This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete the material from any computer after having informed the sender. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited. Maroc Telecom accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about Maroc Telecom on www.iam.ma .

2 1

zoneinfo version?
by Paul Gilmartin 29 Sep '19

29 Sep '19

Just curious: On a Linux system logs tell me that zoneinfo was recently updated to 2019c. Good. On a MacOS system the zoneinfo is older than 2019c. But which is it? When I grep through the installed zoneinfo I find no strings that seem to identify the version. Is this information available somehow? Thanks, gil

5 8

Tzdata for Texas
by Ron Sparks 16 Sep '19

16 Sep '19

I have been using tzdata in one form or another for 3 decades and have always been puzzled why Dallas or Houston Texas were never listed as an alias to America/Chicago. Dallas-Fort Worth is currently the 4th largest city in America and Houston is 5th. Is there some particular reason for these omissions? Or is it just that no one ever volunteered to do the work to get them added? Additionally I have never seen El Paso Texas listed even though it is the one spot in Texas that is in the Mountain Time Zone. I know that Chicago has been the Central Time Zone marker as far back as I can remember (at least 1970). Thanks, Ron Sparks

4 3

Turkey rules
by Zoidiasoft Technologies 12 Sep '19

12 Sep '19

Hi, Just wondering how to interpret the following: Rule Turkey 1977 1978 - Apr Sun>=1 2:00 1:00 S Rule Turkey 1977 1978 - Oct Sun>=15 2:00 0 - Rule Turkey 1978 only - Jun 29 0:00 0 - The problem is with 1978 which seems to have two end dates for DST. Knowing this country has Ramadan, did I miss a rule for standard time onset at the start of Ramadan in 1978? Sincerely, Curtis Manwaring

2 1

Re: [tz] [PROPOSED] Mention RFC 8633 on leap smearing
by Hal Murray 11 Sep '19

11 Sep '19

tz(a)iana.org said: > I see that RFC 8633 cautions against public-facing servers' using leap > smearing, and NTP clients' using a mixture of smeared and unsmeared. I > suppose the same should apply to quasi-NTP UT1 servers such as: Correct, but the nature of the errors is different from smearing servers. There are many smearing servers. There is no way in the protocol to tell if you are talking to a server that will smear when a leap second comes along. The whole point of them is to trick innocent clients into avoiding leaps. If you use a UT1 server, the error will likely be visible right away. If you happen to catch it near the zero crossing, it will soon drift off. There aren't many UT1 servers. You are very unlikely to use one by accident. I don't think it's worth cluttering up TZ info with a warning about UT1 servers. It might be useful as an example of a more general warning. -- These are my opinions. I hate spam.

1 0

[tz-announce] 2019c release of tz code and data available
by Paul Eggert 11 Sep '19

11 Sep '19

The 2019c release of the tz code and data is available. It reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Briefly: Fiji observes DST from 2019-11-10 to 2020-01-12. Norfolk Island starts observing Australian-style DST. Changes to future timestamps Fiji's next DST transitions will be 2019-11-10 and 2020-01-12 instead of 2019-11-03 and 2020-01-19. (Thanks to Raymond Kumar.) Adjust future guesses accordingly. Norfolk Island will observe Australian-style DST starting in spring 2019. The first transition is on 2019-10-06. (Thanks to Kyle Czech and Michael Deckers.) Changes to past timestamps Many corrections to time in Turkey from 1940 through 1985. (Thanks to Oya Vulaş via Alois Treindl, and to Kıvanç Yazan.) The Norfolk Island 1975-03-02 transition was at 02:00 standard time, not 02:00 DST. (Thanks to Michael Deckers.) South Korea observed DST from 1948 through 1951. Although this info was supposed to appear in release 2014j, a typo inadvertently suppressed the change. (Thanks to Alois Treindl.) Detroit observed DST in 1967 and 1968 following the US DST rules, except that its 1967 DST began on June 14 at 00:01. (Thanks to Alois Treindl for pointing out that the old data entries were probably wrong.) Fix several errors in pre-1970 transitions in Perry County, IN. (Thanks to Alois Triendl for pointing out the 1967/9 errors.) Edmonton did not observe DST in 1967 or 1969. In 1946 Vancouver ended DST on 09-29 not 10-13, and Vienna ended DST on 10-07 not 10-06. In 1945 Königsberg (now Kaliningrad) switched from +01/+02 to +02/+03 on 04-10 not 01-01, and its +02/+03 is abbreviated EET/EEST, not CET/CEST. (Thanks to Alois Triendl.) In 1946 Königsberg switched to +03 on 04-07 not 01-01. In 1946 Louisville switched from CST to CDT on 04-28 at 00:01, not 01-01 at 00:00. (Thanks to Alois Treindl and Michael Deckers.) Also, it switched from CST to CDT on 1950-04-30, not 1947-04-27. The 1892-05-01 transition in Brussels was at 00:17:30, not at noon. (Thanks to Michael Deckers.) Changes to past time zone abbreviations and DST flags Hong Kong Winter Time, observed from 1941-10-01 to 1941-12-25, is now flagged as DST and is abbreviated HKWT not HKT. Changes to code leapseconds.awk now relies only on its input data, rather than also relying on its comments. (Inspired by code from Dennis Ferguson and Chris Woodbury.) The code now defends against CRLFs in leap-seconds.list. (Thanks to Brian Inglis and Chris Woodbury.) Changes to documentation and commentary theory.html discusses leap seconds. (Thanks to Steve Summit.) Nashville's newspapers dueled about the time of day in the 1950s. (Thanks to John Seigenthaler.) Liechtenstein observed Swiss DST in 1941/2. (Thanks to Alois Treindl.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2019c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2019c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2019c.tar.lz As usual, links to the latest release files are here: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 765984a9356b01bf1c629fb474c5cee8b6ba2c70 dated 2019-09-11 08:59:48 -0700 and tagged '2019c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 61ef36385f501c338c263081486de0d1fccd454b86f8777b0dbad4ea3f21bbde059d0a91c23e207b167ed013127d3db8b7528f0188814a8b44d1f946b19d9b8b tzcode2019c.tar.gz 2921cbb2fd44a6b8f7f2ed42c13fbae28195aa5c2eeefa70396bc97cdbaad679c6cc3c143da82cca5b0279065c02389e9af536904288c12886bf345baa8c6565 tzdata2019c.tar.gz cc76c25a55868d61e8500293d1ee3cadb0055987fc81ad0ed08add548e1c6a19cd2a10f4c4313827e4ab46bd2fbf16607519b4db92930ebaaa87062fa4c8b55d tzdb-2019c.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl15Gt8ACgkQ7ZfpDmKq fjQc4xAAgd+mFqVxnuM3sbzyd4/bv7Fp9/lKjY9A4P+/K2ihOYYztYvMntwVWcRf mQPOfnoHgYw3lFb+uUiqiC2N3UCLz7Yj7PTVmikOUmOZP9Fd9rLz4fSM1LiQztGa ocvpWo0kxth4gbxFMWaoa2N4sXCHe561z/McP+7DItziIvOA5VfY8CYdTQC/KOnX 9U1Ih/wO+xUdJEcdseQSwsF6iLtd3dPKKSOZVkxro2xPYlDiXv07XdUnnF4BN8cG /himcxLaQc5z4g1ZvLMZCg1lHEY6KbtiCjU7oZKQsFe7DyFgAn/wMaOmYHieGwlF Pbgfkv/BzstZtUCxkZE1UKqlN5jTLbxBCLJGO6CIenGh5LIyc4sHiXumhPCwhpUV CU68etDsRwkTWmgRhDrXgRawtxVF/PsfAp3Zdtp/KKhsegy/jin9JUwlcs9AL4Rs udHIXUlcSUz3n4UR4YFBwoxTbbQ7aDCe++W+U8hHfRwzYTWYLKxyVhyb/2hp6gaL Dr+iJbnfwi3jsfCG1cVYnicmHDchpcK40G2Y9YAFZ8BX8LdikOvbfFj55yKHT4Ym kgtlQgjDyuKmmwdF7Eolz8HuKSm14FOTYEuOxToPgQK783kMrZuOVXyiQlJZJ9Oe XgJNDYTmmIyydehwK2Av8MYtDv3xA/SDfLAJp6bZGw1QzBcwkCU= =GNwR -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl15Gt8ACgkQ7ZfpDmKq fjQJIQ//d285K+JrdfrQdhWCps5cQkxylPUyCvuBLEW7fI/hbyyWDL5Mh0KF1goT 9eboGFxenHsNGpEpyEp9DGPc17PmA4lck0gQ7Uz3dZ/AkmZ+mFipHKlxk8SDDNEV WssSqdKEi8ZkKznVRrfQt2RAHeNHy2xofKmhkVn3dOCOMzp4RCC/eet+gqDVCXmT jN+sLRpWJq66fn/Ap3lpAvXVHb5aw/fLb1VsncD5L6JppGdCvdPpEGo4Hx4LgmVt pxQE0zACGSQzC49P6UsHPP0kiQDCAvDheyKQsnnWR4ii2elOrcQncKXaSla+CCqQ dBClTx52fCTUWzmFHI/aTRz01jOomKa5bK1QSgmIZK4dg56oC6zj9740ingcSrt3 Q5+hQp5KeXjab/jqgZhWbuWG90Yho8v8WLP9Pde8CYma+UyKzIPsD7KdVqHzGylK PYkeyfgR3GuaxOYnseg+xr68OEYXK36PAGspiJkdGklRZ0eoEPNm1PpQSm+mVORP LOWgvR6+kz1AFM9Qr0hZph1YfiFp4P3X/fbwweW+uHmSAyiXiXTvDlOhBJ4Od2mG J8WWgMzXOK6MP+vbKSVXysFX6GTXkaP4c9Ou9B9OQkF5PGK6294so6dcVJ9Aw7ot ZWyzyEdkUX3gyHjsaLbS4TexBu8Y46IPoL+42FbBdO61Aj2QhBA= =EFVW -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl15GuAACgkQ7ZfpDmKq fjTNTRAAqcpsGc0/UXv/GlTcSZ1EYlBYyX5tDRe+3nWh6x0F1XfSiEmQ9YW/VgNW WgziP6TFxBF442qKPA4XvP6HY7iLaL4/7XbZjjW2P7xVvv/T/xOzr4dWUp2X+ubi lpJ22a2p3C+jGFHgN8zt5F8wpM8/hT2h6oZEbiddK0mcv/kQFRw6Qh7ThRtEcxgO EO3DW7jo57cG5O0E3+7175BEvX1rthPuVTqE+sEY53G6PNuQhViEzH4SYcyJYx7T il5d9cGthMjeMelmnMYLtJoWyrJ8krVVxIAlESjZCtFTsACKL4l0PEMSMqQyCwZ2 94jQoYWcsrwVYwzJ+f/hm87e5flfqdL/V81zRNNG8n2Zj9fJYNI1MLcJkxbI3Qi0 iP0aeyohw+mXY5UyY4Pg7e4DiWQK2vTGKffsgp5kSN4TowGcWDbkOMHQPqpXcihg uJmKT7m4tgDewTLVDPMO7ypYbpXmdbTWAvKJsZgKqcxHu35x98YvdAxK3qQPVWH/ WWeBXr0qFu6UqrpQD6uXqmgV7cKeST/vK+eyWdZv7hr7gABLdp66/i/VUlb/WPRQ 4U5rrXj7aUAB66SpPzlYHXlOsT2i3O5XsD4H2mUytpnIk/vEE5BYeG3OkVO8jKVt oEB4do+jdAdRlG+DUXXqnCvxrTkNOp0/ZS6gt3iIfGyyMdAJSmQ= =ysDP -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, this release's data entries can be turned into a rearguard-format tarball that does not use these features. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

[PROPOSED] Mention RFC 8633 on leap smearing
by Paul Eggert 11 Sep '19

11 Sep '19

* tz-link.html: Cite RFC 8633 on leap smearing, and update some URLs. --- tz-link.html | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/tz-link.html b/tz-link.html index 41d8894..e34ea20 100644 --- a/tz-link.html +++ b/tz-link.html @@ -302,7 +302,7 @@ These are listed roughly in ascending order of complexity and fanciness. time and zones.</li> <li><a href="https://www.timejones.com">TimeJones.com</a>, <a href="https://timezoneconverterapp.com">Time Zone Converter</a> and -<a href="https://worldclock.com">The World Clock</a> +<a href="https://www.worldclock.com">The World Clock</a> are time zone converters.</li> <li><a href="https://twiki.org/cgi-bin/xtra/tzdatepick.html">Date and Time Gateway</a> @@ -312,7 +312,7 @@ href="http://www.convertit.com/Go/ConvertIt/World_Time/Current_Time.ASP">Current Time in 1000 Places</a> uses descriptions of the values.</li> <li><a href="https://timezoneconverterapp.com/">Time Zone Converter</a> uses a pulldown menu.</li> -<li><a href="http://home.kpn.nl/vanadovv/time/TZworld.html">Complete +<li><a href="https://home.kpn.nl/vanadovv/time/TZworld.html">Complete timezone information for all countries</a> displays tables of DST rules. <li><a href="https://www.timeanddate.com/worldclock/">The World Clock – Worldwide</a> lets you sort zone names and convert times.</li> @@ -395,9 +395,9 @@ transition in the <code><abbr>tz</abbr></code> database.</li> <li>The <a href="https://howardhinnant.github.io/date/tz.html">Time Zone Database Parser</a> is a <a href="https://en.wikipedia.org/wiki/C%2B%2B">C++</a> parser and -runtime library that is <a -href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0355r4.html">moving -forward</a> for inclusion in +runtime library with API <a +href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">adopted +into the draft standard</a> for <a href="https://en.wikipedia.org/wiki/C++20">C++20</a>, the next iteration of the C++ standard. It is freely available under the @@ -749,7 +749,7 @@ coordinates?</a>" discusses other geolocation possibilities.</li> <li><a href="http://statoids.com/statoids.html">Administrative Divisions of Countries ("Statoids")</a> lists political subdivision data related to time zones.</li> -<li><a href="http://home.kpn.nl/vanadovv/time/Multizones.html">Time +<li><a href="https://home.kpn.nl/vanadovv/time/Multizones.html">Time zone boundaries for multizone countries</a> summarizes legal boundaries between time zones within countries.</li> <li><a href="http://manifold.net/info/freestuff.shtml">Manifold Software @@ -963,7 +963,12 @@ sixty seconds. This approach works with the default <code><abbr>tz</abbr></code> "<code>posix</code>" configuration, is <a href="http://bk1.ntp.org/ntp-stable/README.leapsmear">supported</a> by the <abbr>NTP</abbr> reference implementation, and is used by major -cloud service providers.</li> +cloud service providers. However, according to +<a href="https://tools.ietf.org/html/rfc8633#section-3.7.1">§3.7.1 of +Network Time Protocol Best Current Practices</a> +(Internet <abbr>RFC</abbr> 8633), leap smearing is not suitable for +applications requiring accurate UTC or civil time, +and is intended for use only in single, well-controlled environments.</li> <li>The <a href="https://pairlist6.pair.net/mailman/listinfo/leapsecs">Leap Second Discussion List</a> covers <a -- 2.17.1

2 1

[PROPOSED] * leapseconds.awk: Fix Y285, 428, 681 thinko in comment.
by Paul Eggert 10 Sep '19

10 Sep '19

--- leapseconds.awk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/leapseconds.awk b/leapseconds.awk index 86072ce..1fe5012 100755 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -12,7 +12,7 @@ # timestamps this program should be good until the year 285,428,681 # (the year 1900 plus 2**53 seconds). By then leap seconds will be # long obsolete, as the Earth will likely slow down so much that -# there will less than 23 hours in a day and so some other scheme +# there will be more than 25 hours per day and so some other scheme # will be needed. BEGIN { -- 2.17.1

1 0

Re: [tz] [PROPOSED] Improve leapseconds support
by Chris Woodbury 10 Sep '19

10 Sep '19

The following has been kicking around my "Handling_Leapseconds directory for more than a year. It is a complete replacement for the current "leapseconds.awk". It uses the NTP timestamp *data* rather than the *comments* at the end of each leap-second datum from the leap-seconds.list file. I found it again today and finished the changes needed to use Dennis' sstamp_to_ymdhMs() AWK function. I've incorporated some AT&T UNIX programming style changes (which I learned back in the dark ages), too. I'm sure Paul will re-arrange it whichever way he wants before (or even if) it makes it into the TZ distribution. # -=*< This file is in the public domain !! >*=- # Generate zic LEAP commands from an NIST format 'leap-seconds.list'. BEGIN { print "# This file is in the public domain\n" print "# Allowance for leap-seconds added to each time zone file.\n" print "# This script generates zic \"Leap\" directives from public-domain data" print "# in the NIST format leap-seconds.list file (originally created for the" print "# Network Time Protocol (NTP) daemon by Judah Levine). Find it at:\n" print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>" print "# -or- <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>\n" print "# For more info about the leap-seconds.list file, please see:\n" print "# The NTP Timescale and Leap Seconds by Prof. David L. Mills." print "# <https://www.eecis.udel.edu/~mills/leap.html>.\n" print "# The rules for leap-seconds are specified in Annex 1 (Time scales) of:\n" print "# \"Standard-frequency and time-signal emissions\"" print "# International Telecommunication Union -" print "# Radiocommunication Sector Recommendation (ITU-R) TF.460-6 (02/2002)\n" print "# <https://www.itu.int/rec/R-REC-TF.460-6-200202-I/>\n" print "# which is incorporated by reference in the [ITU] Radio Regulations.\n" print "# The International Earth Rotation and Reference Systems Service (IERS)" print "# periodically uses leap seconds to keep UTC to within 0.9 s of UT1" print "# (which is a proxy for the earth's angular orientation in space)" print "# and publishes leap-second data in a copyrighted file" print "# <https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat>." print "# USNO also has a comprehensive uncopyrighted list of leap-seconds at:" print "# <ftp://199.211.133.23/ser7/leapsec.dat> (AKA maia.usno.navy.mil)" print "# Also see: Coordinated Universal Time and the leap second by Judah Levine" print "# URSI Radio Sci Bull. 2016;89(4):30-6. doi:10.23919/URSIRSB.2016.7909995" print "# <https://ieeexplore.ieee.org/document/7909995>.\n" print "# There were no leap-seconds before 1972, as no official mechanism existed" print "# accounting for the discrepancy between atomic time (TAI) and UT1." print "# All leap-seconds are Stationary (S) at the given UTC time.\n" print "# The correction (+ or -) is made at the given time, so lines" print "# will typically look like:\n" print "# Leap YEAR MON DAY 23:59:60 + S" print "# - or -" print "# Leap YEAR MON DAY 23:59:59 - S\n" monthabbr[ 1] = "Jan" ; monthabbr[ 2] = "Feb" ; monthabbr[ 3] = "Mar" monthabbr[ 4] = "Apr" ; monthabbr[ 5] = "May" ; monthabbr[ 6] = "Jun" monthabbr[ 7] = "Jul" ; monthabbr[ 8] = "Aug" ; monthabbr[ 9] = "Sep" monthabbr[10] = "Oct" ; monthabbr[11] = "Nov" ; monthabbr[12] = "Dec" # In case the input has CRLF form a la NIST RS = "\r?\n" old_TAI_minus_UTC = int( 0 ) # This variable should be initialize !! sstamp_init() # Init function } # Note: maintaining case, spacing or punctuation can # not be depended upon when humans are involved... /^#[ \t]*[Uu]pdated through[ \t:]*/ || /^#[ \t]*[Ff]ile expires on[ \t:]*/ { last_lines = last_lines $0 "\n" } /^#[$][ \t]/ { updated = strtonum( $2 ) } # Save update NTP timestamp /^#[@][ \t]/ { expires = strtonum( $2 ) } # Save expiry NTP timestamp /^[ \t]*#/ { next } { NTP_timestamp = int( $1 ) # NTP epoch timestamp TAI_minus_UTC = int( $2 ) # delta T if ( old_TAI_minus_UTC ) { if ( old_TAI_minus_UTC < TAI_minus_UTC ) { sign = "23:59:60\t+" } else { sign = "23:59:59\t-" } sstamp_to_ymdhMs( NTP_timestamp - 1, ss_NTP ) # Note minus one !! printf "Leap\t%d\t%s\t%d\t%s\tS\n", ss_y, monthabbr[ ss_m ], ss_d, sign } old_TAI_minus_UTC = TAI_minus_UTC } END { # The difference between the NTP and POSIX epochs is 70 years # (including 17 leap days), each 24 hours of 60 minutes of 60 # seconds each. epoch_minus_NTP = ((1970 - 1900) * 365 + 17) * 24 * 60 * 60 print "" print "# POSIX timestamps for the data in this file:" sstamp_to_ymdhMs( updated, ss_NTP ) printf "# Updated: %s (%02d %s %d)\n", ( updated - epoch_minus_NTP ), ss_d, monthabbr[ ss_m ], ss_y sstamp_to_ymdhMs( expires, ss_NTP ) printf "# Expires: %s (%02d %s %d)\n", ( expires - epoch_minus_NTP ), ss_d, monthabbr[ ss_m ], ss_y printf "\n%s", last_lines } # Contributed by # # Dennis Ferguson <dennis.c.ferguson(a)gmail.com> on Sun, 14 Oct 2018 21:56:57 -0700 # # sstamp_to_ymdhMs() - convert (NTP, POSIX) seconds stamp to date and time # # Call as: # # sstamp_to_ymdhMs( sstamp, epoch_days ) # # where: # # sstamp - is a seconds timestamp, e.g. POSIX or NTP # epoch_days - is the timestamp epoch in (proleptic Gregorian) days since # 1 Mar 1600. ss_NTP is appropriate for a NTP sstamp, ss_POSIX # for a Unix sstamp. # # On return the following variables are set based on sstamp: # # ss_y - calendar year for the sstamp (e.g. 2016) # ss_m - month of the year (1-January to 12-December) # ss_d - day of the month # ss_h - hour (0-23) # ss_M - minute (0-59) # ss_s - second (0-59) # ss_w - day of week (0-Sunday to 6-Saturday) # # The function # # sstamp_init() # # should be called prior to using sstamp_to_ymdhMs(). # # The calendar computation part of this starts with a count of days since # March 1, 1600 (in a proleptic Gregorian calendar) and computes a ymd # date with days of the month numbered 0-30, months (March-February) numbered # 0-11 and years which run from March-February. The last four lines of code # in the function convert the date to a conventional day of month (1-31), # month (1-12, January-December) and Gregorian year. # # In the alternate calendar a year starts at March 1 and ends after the last # day of February. A quad-year starts on March 1 of a year evenly divisible # by 4 and ends after the last day of February 4 years later. A century # starts on and ends before March 1 in a year evenly divisible by 100 # (i.e. 1600, 1900, 2100). A quad-century starts on and ends before March 1 # in years divisible by 400 (1600, 2000, 2400). Given this the magic constants # used here are: # # days per year = 365 # days per quad-year = 1461 = (365 * 4) + 1 # days per century = 36524 = (1461 * 25) - 1 # days per quad-century = 146097 = (36524 * 4) + 1 # weekday (0-Sunday 6-Saturday) of first day of quad-century = 3 (Wednesday) # # Note that while the number of days in a quad-century is a constant the # number of days in each of the other time periods can vary by 1. In all # these cases, however, the variation is in the last day of the time period # (there might or might not be a February 29) where it is easy to deal with. # # The three standard day_epochs are: # # ss_MJD = 94493 # ss_NTP = 109513 # ss_POSIX = 135080 function sstamp_init(){ ss_mon_days[ 1] = 31 ss_mon_days[ 2] = 61 ss_mon_days[ 3] = 92 ss_mon_days[ 4] = 122 ss_mon_days[ 5] = 153 ss_mon_days[ 6] = 184 ss_mon_days[ 7] = 214 ss_mon_days[ 8] = 245 ss_mon_days[ 9] = 275 ss_mon_days[10] = 306 ss_mon_days[11] = 337 ss_NTP = 109513 ss_POSIX = 135080 } function sstamp_to_ymdhMs( sstamp, epoch_days, ss_qcent, ss_cent, ss_qyr, ss_yr ){ ss_s = sstamp % 86400 # isolate hms ss_h = int( ss_s / 3600 ) ss_s %= 3600 ss_M = int( ss_s / 60 ) ss_s %= 60 ss_d = int( sstamp / 86400 ) + epoch_days # select epoch ss_qcent = int( ss_d / 146097 ) ss_y = 1600 + ss_qcent * 400 ss_d -= ss_qcent * 146097 ss_w = ( ss_d + 3 ) % 7 ss_cent = int( ss_d / 36524 ) if (ss_cent == 4) { ss_cent = 3 } ss_d -= ss_cent * 36524 ss_y += ss_cent * 100 ss_qyr = int( ss_d / 1461 ) ss_y += ss_qyr * 4 ss_d -= ss_qyr * 1461 ss_yr = int(ss_d / 365) if ( ss_yr == 4 ) { ss_yr = 3 } ss_d -= ss_yr * 365 ss_y += ss_yr for ( ss_m = 11 ; ss_m > 0 ; ss_m-- ){ if( ss_d >= ss_mon_days[ss_m] ){ ss_d -= ss_mon_days[ss_m] ; break ; } } # convert to conventional calendar ss_d += 1; if (ss_m > 9) { ss_m -= 9 ; ss_y++ } else { ss_m += 3 } }

3 3

Add ISO Phonetic and Letter Time Zone Links to etcetera
by Brian Inglis 09 Sep '19

09 Sep '19

Suggest adding ISO Phonetic and Letter time zone names, used in military and other organizations, in the Etc directory, linked to the existing Etc/GMT[-/+n] time zones, created from the etcetera data file, as shown in the attached file (suffixed .txt for reader convenience). If there are any concerns about adding them into Etc, they could be added to a new ISO, Letter, Phonetic, Mil, Military, or other directory. Note that Etc/Zulu is already created as a Link from Etc/UTC, the names India and Quebec do not already exist in any directories, while America/Lima (Peru) already exists. -- 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.

3 2

Time zone abbreviations
by Elena Sharovar 07 Sep '19

07 Sep '19

Hi Iana Team, where can I find some explanation why in 2017a format changed from AST to +03? and the same happened in a lot of timezones (letter abbreviations changed to +03, +02, etc.) // 2016j Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 3:00 -* AST* // 2017a Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 3:00 - *+03* Thanks & Regards, Elena.

5 5

Central America Time Zone?
by Rodolfo Quesada Zumbado 07 Sep '19

07 Sep '19

Hello, I have one question/proposal. Recently I ran into a problem because my calendar shows the "America/Costa_Rica" time zone appointments as "Central Time", which seems to be the designation so far. However at the moment, I checked several sources about the current "Central Time" and it is currently UTC-05:00, whereas in "America/Costa_Rica" it is UTC-06:00. Here in Costa Rica we don't use the customary North American time zones (Pacific, Mountain, Central, Eastern), we just call it "the local time", as is the rest of Central America. We are very small countries so those designations doesn't make sense. I can drive from the Pacific coast to Caribbean/Atlantic coast through the mountains and the central valley in a few hours! :-) What would be the procedure to suggest an standardized "Central America" time zone? I just checked the tz database, and it shows America/Costa_Rica as designated with C%sT. Should it come from the local governmental science/tech departments? Is this related to ISO or other international organization? I have seen that Microsoft uses a "TZID=Central America Standard Time" which is more culturally sensitive and appropriate than using the other designations. Thanks for your time. -- Ing. Rodolfo Quesada Zumbado http://www.roqz.net roqz(a)roqz.net

2 1

end of DST in occupied France October 1944
by Alois Treindl 07 Sep '19

07 Sep '19

This is just a question to some well informed readers of this mailing list. Liberated France ended daylight saving time on 8 October 1944, 01:00, as represented in zone Europe/Paris. Eastern parts of France were still occupied by the German army at that time, and Germany ended DST in 1944 on 2 October 1922, 02:00s = 03:00, as represented in TZ by Europe/Berlin, rule C-Eur. For occupied France however, Shanks claims the end of DST on 3 Oct 1944 03:00. For all other countries in Europe on German time at that moment, Shanks holds that DST ended 2 October, like in Germany itself. I cannot find a source supporting Shanks' claim for the deviation in France. Does anyone have information supporting Shanks' claim?

3 5

Typo fixes
by Tim Parenti 02 Sep '19

02 Sep '19

Attached are a couple small typo fixes to recent commentary. -- Tim Parenti

1 0

[PATCH] * southamerica: Modernize Magallanes comments.
by Paul Eggert 01 Sep '19

01 Sep '19

--- southamerica | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/southamerica b/southamerica index 397a2cc..9b679c6 100644 --- a/southamerica +++ b/southamerica @@ -1230,14 +1230,8 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # From Juan Correa (2016-12-04): # Magallanes region ... will keep DST (UTC -3) all year round.... # http://www.soychile.cl/Santiago/Sociedad/2016/12/04/433428/Bachelet-firmo-e… -# # From Deborah Goldsmith (2017-01-19): # http://www.diariooficial.interior.gob.cl/publicaciones/2017/01/17/41660/01/… -# From Paul Eggert (2017-01-19): -# The above says the Magallanes change expires 2019-05-11 at 24:00, -# so in theory, they will revert to -04/-03 after that, which means -# they will switch from -03 to -04 one hour after Santiago does that day. -# For now, assume that they will not revert. # From Juan Correa (2018-08-13): # As of moments ago, the Ministry of Energy in Chile has announced the new @@ -1258,6 +1252,11 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # So we extend the new rules on Saturdays at 24:00 mainland time indefinitely. # From Juan Correa (2019-02-04): # http://www.diariooficial.interior.gob.cl/publicaciones/2018/11/23/42212/01/… +# From Paul Eggert (2019-09-01): +# The above says the Magallanes exception expires 2022-04-02 at 24:00, +# so in theory, they will revert to -04/-03 after that. +# For now, assume that they will not revert, +# since they have extended the expiration date once already. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1927 1931 - Sep 1 0:00 1:00 - -- 2.21.0

1 0