September 2019 - tz - lists.iana.org

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

An update on AP style on Kyiv
by John Hawkinson Nov. 20, 2019

Nov. 20, 2019

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 Sept. 30, 2019

Sept. 30, 2019

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 Sept. 29, 2019

Sept. 29, 2019

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 Sept. 16, 2019

Sept. 16, 2019

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 Sept. 12, 2019

Sept. 12, 2019

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 Sept. 11, 2019

Sept. 11, 2019

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 Sept. 11, 2019

Sept. 11, 2019

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 Sept. 11, 2019

Sept. 11, 2019

* 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 Sept. 10, 2019

Sept. 10, 2019

--- 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