- tz - lists.iana.org

Palestine end of summer time 2019
by Sharef Mustafa Oct. 18, 2019

Oct. 18, 2019

Hi, Palestine summer time will end on midnight Oct 26th 2019 by delaying the clock by 60 minutes as per Palestinian cabinet decision published on the official website. http://www.palestinecabinet.gov.ps/website/ar/ViewDetails?ID=43948 As usual the announcement was not specific on the exact time, however the announcement indicated: بدء العمل بالتوقيت الشتوي في فلسطين، وذلك بتأخير عقارب الساعة ستين دقيقة، اعتباراً من منتصف ليلة جمعة/سبت الموافق 26/10/2019 Google Translate: Start of winter time in Palestine, with a delay of 60 minutes, starting from midnight Friday/ Saturday 26/10/2019 it's safe to assume 01:00 as the time to return clock by 60 minutes. <http://www.palestinecabinet.gov.ps/website/ar/ViewDetails?ID=43948> this affects Asia/Gaza & Asia/Hebron time zones. Thanks. Sharef Mustafa

3 2

[PROPOSED] Rename asctime symbols if required in private.h
by Roland Young Oct. 15, 2019

Oct. 15, 2019

When libtz.a is built using -DRESERVE_STD_EXT_IDS (but not in other cases where TZ_TIME_T is defined) the asctime and asctime_r symbols need renaming. Note: if my assumption about "other cases" is wrong, the preprocessor guards in this patch should be omitted. --- private.h | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 1ead147..112a58c 100644 --- a/private.h +++ b/private.h @@ -409,6 +409,12 @@ static time_t sys_time(time_t *x) { return time(x); } typedef time_tz tz_time_t; +#if RESERVE_STD_EXT_IDS +# undef asctime +# define asctime tz_asctime +# undef asctime_r +# define asctime_r tz_asctime_r +#endif # undef ctime # define ctime tz_ctime # undef ctime_r @@ -478,6 +484,10 @@ typedef time_tz tz_time_t; # define altzone tz_altzone # endif +#if RESERVE_STD_EXT_IDS +char *asctime(struct tm const *timeptr); +char *asctime_r(struct tm const *restrict, char *restrict); +#endif char *ctime(time_t const *); char *ctime_r(time_t const *, char *); double difftime(time_t, time_t) ATTRIBUTE_CONST; @@ -494,7 +504,7 @@ struct tm *localtime_r(time_t const *restrict, struct tm *restrict); time_t mktime(struct tm *); time_t time(time_t *); void tzset(void); -#endif +#endif /* defined TZ_TIME_T */ #if !HAVE_DECL_ASCTIME_R && !defined asctime_r extern char *asctime_r(struct tm const *restrict, char *restrict); -- 2.7.4

2 1

Why does libtz.a contain asctime.o but not strftime.o ?
by Roland Young Oct. 11, 2019

Oct. 11, 2019

I am planning to use the NetBSD inspired functions localtime_rz and mktime_z in a user-space program. I notice that I can avoid clashes with symbols in the system libraries by defining RESERVE_STD_EXT_IDS, and have tried building as follows: make TOPDIR=$MY_TZ CFLAGS="-DRESERVE_STD_EXT_IDS -DTHREAD_SAFE -pthread" install I notice that the resulting libtz.a contains an unresolved external reference to tz_strftime. This appears to be because the Makefile includes asctime.o in LIBOBJS but does not include strftime.o on which it should depend (and does depend when the external symbols are prefixed with 'tz_') This will not affect my use case - our program will not use tz_asctime or tz_asctime_r - and I suspect that very few users of the tz code will be tripped up by it, given that the tz executables will be built correctly and anyone with a use case like mine has got to make their own header file to use libtz.a, but nonetheless... Should this be corrected, or is there a rationale which I have missed and which could be noted in a Makefile comment? --- Roland Young ITRS Group Ltd, London

2 1

Kyiv not Kiev
by caRo_Ot Oct. 11, 2019

Oct. 11, 2019

Hello! Please rename my capital from Kiev to Kyiv (as it is native name since V centuary). https://www.google.com/search?&q=kyiv

2 1

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. 13, 2019

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

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

Re: [tz] [PROPOSED] Improve leapseconds support
by Chris Woodbury Sept. 11, 2019

Sept. 11, 2019

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

Sept. 9, 2019

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

Sept. 7, 2019

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

Sept. 7, 2019

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

Sept. 7, 2019

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

Sept. 2, 2019

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

1 0

[PATCH] * southamerica: Modernize Magallanes comments.
by Paul Eggert Sept. 1, 2019

Sept. 1, 2019

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

Re: [tz] Turkey Rules 1978 - 1983 may need revision
by Paul Eggert Aug. 29, 2019

Aug. 29, 2019

Michael H Deckers wrote: > There may be some typos in the proposed change: Thanks for checking it so carefully. Alois Treindl also noted the 1940 typo. I installed the attached.

1 0

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Re: [tz] question regarding Europe/Brussels in 1914
by Stijn “Adhemar” Vandamme Aug. 28, 2019

Aug. 28, 2019

A reliable source for the history of the timezone offset in Brussels is the Royal Observatory of Belgium. Dutch: <https://www.astro.oma.be/GENERAL/INFO/nli001a.html> French: <https://www.astro.oma.be/GENERAL/INFO/fri001a.html> The text at the beginning translates: > *The time in Belgium* > > Until 1 May 1892 the local (mean) time was used, usually the one of a > large town nearby. > > The law of 28 April 1892 (in effect from 1 May 1892) determined the legal > time in Belgium to be GMT, later UT, now standardized to coordinated > universal time (UTC). The table indicates which correction is required > for the period following the indicated date. The text before the bottom table translates: > In the period 1914-1918 the following arrangement was in force *in > occupied territory*. In the other areas only UTC was used (correction > +0h). The exact moment of the hour change depended on the advance or > withdrawal of the occupation army. The bottom table mentions 8 November 1914 as the start of the imposed use of the +1h offset in occupied territory (including Brussels), without specifying the exact time of that start. The start of summer time in 1916 is mentioned as 30 April 1916 23h UTC which is 1 May 1916 0h (UTC+1) becoming 1h (UTC+2) local time. — Adhemar

2 1

Europe/Brussels on 1892-05-01
by Michael H Deckers Aug. 28, 2019

Aug. 28, 2019

The exposition in the web page [https://www.bestor.be/wiki/index.php/Voyager_dans_le_temps._L%E2%80%99intro…] gives several contemporary sources from which one can conclude that the switch in Europe/Brussels on 1892-05-01 was from 00:17:30 to 00:00:00, and not from 12:00:00 to 11:42:30 as is currently contained in tzdb. It is true that mean time at the Royal Observatory was determined to be UT + 17 min + 29 s at the time, and that the observatory delivered Brussels time every morning at 06:00, but this does not mean that Brussels time was UT + 17 min + 29 s because the observatory had recently moved to Uccle (see [Ernest Pasquier: "L’unification des heures", page 306] as referenced in the web page above). The text in tzdb LMT before 1892 was 0:17:30, according to the official journal of Belgium: Moniteur Belge, Samedi 30 Avril 1892, N.121. is probably incorrect as regards the "according to". The text of the 1892 law is reprinted in [Laurent Delatte: "C'était dans Ciel et Terre il y a cent ans". Ciel et Terre vol 108 p 113..116. 1992.], online at [http://articles.adsabs.harvard.edu/cgi-bin/article_queryform?bibcode=1992C%…] on page 115, and it does not contain any offsets from UT. And it hardly could contain offsets because every larger town in Belgium had its own railway time, and civil time outside the stations often differed, as described by the articles by Ernest Pasquier referenced in the web page. Anyway, the actual time step taken was 17 min + 30 s, and time jumped from 00:17:30 to 00:00:00. This is described in the circular issued by the administration of railways and quoted in [Gazette de Charleroi of 1892-04-30, "Réglez vos pendules" page 1..2], and linked to in the BEstor web page. Michael Deckers.

2 1

Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Kyle Czech Aug. 28, 2019

Aug. 28, 2019

Please be advised that there will be a time zone change for Norfolk Island as of October 6, 2019. The Ordinance for the time zone change was passed in December last year https://www.legislation.gov.au/Details/F2018L01702 and will come into effect October 6, 2019. Please note the below in regards to change of time observed: daylight saving period means: (a) a period starting at 2 am on the first Sunday in October in each year and ending at 2 am on the first Sunday in the following April; or (b) if the Minister declares a different period under section 4A of this Ordinance-that period. daylight saving time means the time prescribed by section 7 of this Ordinance. standard time means the time prescribed by section 6 of this Ordinance. Further information is available here: https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… If you have any questions please let me know. Thank you, Kyle Kyle Czech [http://portals/entr/business-services/communications-and-media/publishing-a…, Local Government and Assets Norfolk Island and Mainland Territories Branch, Territories Division Department of Infrastructure, Transport, Cities and Regional Development t 0011 6723 23315 w www.infrastructure.gov.au<http://www.infrastructure.gov.au/> --------------------------------------------------------------------- Disclaimer This message has been issued by the Department of Infrastructure, Regional Development and Cities. The information transmitted is for the use of the intended recipient only and may contain confidential and/or legally privileged material. Any review, re-transmission, disclosure, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may result in severe penalties. If you have received this e-mail in error, please notify the Department on (02) 6274-7111 and delete all copies of this transmission together with any attachments. ---------------------------------------------------------------------

5 10

Re: [tz] tz Digest, Vol 95, Issue 8
by Kıvanç Yazan Aug. 28, 2019

Aug. 28, 2019

Hi! Here's some "resmi gazete" links for those years. http://www.resmigazete.gov.tr/arsiv/14539.pdf (page 24) 1973-06-03 01:00 -> 02:00 1973-11-04 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/14829.pdf (page 1) 1974-03-31 02:00 -> 03:00 1974-11-03 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15161.pdf (page 1) 1975-03-22 02:00 -> 03:00 1975-11-02 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15535_1.pdf (page 1) 1976-03-21 02:00 -> 03:00 1976-10-31 02:00 -> 01:00 http://www.resmigazete.gov.tr/arsiv/15778.pdf (page 5) 1977-04-03 02:00 -> 03:00 1977-10-16 02:00 -> 01:00 1978-04-02 02:00 -> 03:00 (not applied, see below) 1978-10-15 02:00 -> 01:00 (not applied, see below) 1979-04-01 02:00 -> 03:00 (not applied, see below) 1979-10-14 02:00 -> 01:00 (not applied, see below) http://www.resmigazete.gov.tr/arsiv/16245.pdf (page 17) This cancels the previous decision, and repeats it only for 1978. 1978-04-02 02:00 -> 03:00 1978-10-15 02:00 -> 01:00 (not applied due to standard TZ change below) http://www.resmigazete.gov.tr/arsiv/16331.pdf (page 3) This decision changes the default longitude for Turkish time zone from 30 degrees East to 45 degrees East. This means a standard TZ change, from +2 to +3. This is published & applied on 1978-06-29. At that time, Turkey was already on summer time (already on 45E). Hence, this new law just meant an "continuous summer time". Note that this was reversed in a few years. http://www.resmigazete.gov.tr/arsiv/18119_1.pdf (page 1) 1983-07-31 02:00 -> 03:00 (note that this jumps TZ to +4) 1983-10-02 02:00 -> 01:00 (back to +3) http://www.resmigazete.gov.tr/arsiv/18561.pdf (page 1 and 34) At this time, Turkey is still on +3 with no spring-forward on early 1984. This decision is published on 10/31/1984. Page 1 declares the decision of reverting the "default longitude change". So the standard time should go back to +3 (30E). And page 34 explains when that will happen: 1984-11-01 02:00 -> 01:00 You can think of this as "end of continuous summer time, change of standard time zone". http://www.resmigazete.gov.tr/arsiv/18713.pdf (page 1) 1985-04-20 01:00 -> 02:00 1985-09-28 02:00 -> 01:00 >From 1986 on, you can see my previous comments here: https://github.com/eggert/tz/blob/master/europe#L3671 Thanks, Kivanc Yazan

5 7

TZData file error
by Leonardo Menezes Aug. 26, 2019

Aug. 26, 2019

Hello, I am trying to update the time but is being displayed an error in the file (attachment). The file used was tzdata2019b Could you help me please? Thank you, *Leonardo Menezes* (13) 98211-5615

4 3

oral history contribution to the time zone history of Cambodia
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

TZ has this information in file backzone # From Paul Eggert (2014-10-11): # See Asia/Ho_Chi_Minh for the source for most of this data. Also, guess # (1) Cambodia reverted to UT +07 on 1945-09-02, when Vietnam did, and # (2) they also reverted to +07 on 1953-11-09, the date of independence. # These guesses are probably wrong but they're better than guessing no # transitions there. Zone Asia/Phnom_Penh 6:59:40 - LMT 1906 Jul 1 7:06:30 - PLMT 1911 May 1 7:00 - +07 1942 Dec 31 23:00 8:00 - +08 1945 Mar 14 23:00 9:00 - +09 1945 Sep 2 7:00 - +07 1947 Apr 1 8:00 - +08 1953 Nov 9 7:00 - +07 A good friend of mine born in 1951 in Phnom Pen is the adoptive daughter of late Cambodian ruler Prince Sihanouk. Being very interested in astrology, this friend of course much engaged in knowing the correct time zone for her birth. The information above would set it at 8h east of GMT for 1947 - 1953. My friend writes (and I have bolded the essential phrase): According to my father xxxx, during the French protectorate, Cambodia’s legal time was that of Hanoi. [..] My [adoptive] father Sihanouk confirmed the above in 2011 when I drafted my essay on King Sihanouk. I needed to ask him many questions, including details regarding our time zone, especially 5-6 August 1951. [...] King Sihanouk said that, during the Japanese occupation, starting with what historians refer to as “le coup de force du 9 mars 1945”, Cambodia, like the entire French Indochina, used Tokyo time zone. After Japan surrendered, 2 September 1945, Cambodia fell under French rule again and adopted Hanoi time zone again. *However, on 7 January 1946, Sihanouk and Tioulong managed to obtain a status of “internal autonomy” from the government of Charles de Gaulle. Although many fields remained under the administration of the French (customs, taxes, justice, defence, foreign affairs, etc.), the Cambodian administration was responsible for religious matters and traditional celebrations, which included our calendar and time. The time zone was GMT + 7 and _no_ DST was applied.* After Sihanouk and Tioulong achieved full independence, on 9 November 1953, GMT + 7 was maintained. -- end quote ket In view of this, I would tend to eliminate the line 8:00 - +08 1953 Nov 9 Of course, it is here like in many other cases the question what TZ wants to represent: offical time maintained by the colonial administration, or 'time on the ground' used by the local population for their own records, like a royal birth event. I do not expect action by Paul Eggert, as this is only backzone data.Still. I consider it worthwile to be recorded in the TZ mailing ist history.

3 4

Question regarding zone Asia/Seoul DST rules 1948-1951
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

For South Korea, TZ has rules covering the years 1948 - 1988, and the text comments confirm that they were applied in 1948. Rule ROK 1948 only - Jun 1 0:00 1:00 D Rule ROK 1948 only - Sep 12 24:00 0 S Rule ROK 1949 only - Apr 3 0:00 1:00 D Rule ROK 1949 1951 - Sep Sat>=7 24:00 0 S Rule ROK 1950 only - Apr 1 0:00 1:00 D Rule ROK 1951 only - May 6 0:00 1:00 D Rule ROK 1955 only - May 5 0:00 1:00 D Rule ROK 1955 only - Sep 8 24:00 0 S Rule ROK 1956 only - May 20 0:00 1:00 D Rule ROK 1956 only - Sep 29 24:00 0 S Rule ROK 1957 1960 - May Sun>=1 0:00 1:00 D Rule ROK 1957 1960 - Sep Sat>=17 24:00 0 S Rule ROK 1987 1988 - May Sun>=8 2:00 1:00 D Rule ROK 1987 1988 - Oct Sun>=8 3:00 0 S But the zone data apply only rules from 1954 onwards while those for 1948-51 are ignored. Why is this so? This may be an error made in 2014, when the ROK rules for 1948-1959 were added, but it was forgotten to enter ROK into the 1954 line. Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1 8:30 - KST 1912 Jan 1 9:00 - JST 1945 Sep 8 9:00 - KST 1954 Mar 21 8:30 ROK K%sT 1961 Aug 10 9:00 ROK K%sT

2 1

error in zone America/Kentucky/Louisville 1946
by Alois Treindl Aug. 26, 2019

Aug. 26, 2019

I have to report an error in zone America/Kentucky/Louisville zdump gives zdump -V -c 1945,1950 America/Kentucky/Louisville America/Kentucky/Louisville Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 17:59:59 1945 CWT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 18:00:00 1945 CPT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Sep 30 06:59:59 1945 UT = Sun Sep 30 01:59:59 1945 CPT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Sep 30 07:00:00 1945 UT = Sun Sep 30 01:00:00 1945 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Tue Jan 1 05:59:59 1946 UT = Mon Dec 31 23:59:59 1945 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Tue Jan 1 06:00:00 1946 UT = Tue Jan 1 01:00:00 1946 CDT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Jun 2 06:59:59 1946 UT = Sun Jun 2 01:59:59 1946 CDT isdst=1 gmtoff=-18000 America/Kentucky/Louisville Sun Jun 2 07:00:00 1946 UT = Sun Jun 2 01:00:00 1946 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Sun Apr 27 07:59:59 1947 UT = Sun Apr 27 01:59:59 1947 CST isdst=0 gmtoff=-21600 America/Kentucky/Louisville Sun Apr 27 08:00:00 1947 UT = Sun Apr 27 03:00:00 1947 CDT isdst=1 gmtoff=-18000 with a strange transition CST to CDT on 1 January 1946. I have searched Louisville newspaper archives and find no report of such a clock change around New Year 1946. I find however the begin of CDT for 28 April 1946, and the switch back to CST on 2 June 1946. Shanks also has the transition on 28 April 1946. The cause I thnk is the strange formulation of Louisville rules # This also includes Clark, Floyd, and Harrison counties in Indiana. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Louisville 1921 only - May 1 2:00 1:00 D Rule Louisville 1921 only - Sep 1 2:00 0 S Rule Louisville 1941 1961 - Apr lastSun 2:00 1:00 D Rule Louisville 1941 only - Sep lastSun 2:00 0 S Rule Louisville 1946 only - Jun 2 2:00 0 S Rule Louisville 1950 1955 - Sep lastSun 2:00 0 S Rule Louisville 1956 1960 - Oct lastSun 2:00 0 S # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Kentucky/Louisville -5:43:02 - LMT 1883 Nov 18 12:16:58 -6:00 US C%sT 1921 -6:00 Louisville C%sT 1942 -6:00 US C%sT 1946 -6:00 Louisville C%sT 1961 Jul 23 2:00 -5:00 - EST 1968 -5:00 US E%sT 1974 Jan 6 2:00 -6:00 1:00 CDT 1974 Oct 27 2:00 -5:00 US E%sT I attach a newspaper article describing the swith on 28 April.

3 3

Fiji DST 2019/2020
by Raymond Kumar Aug. 26, 2019

Aug. 26, 2019

Hi Paul There is a DST time change in Fiji island from November 10th 2019 The attached order states: Members of the public are advised to move their clocks one hour ahead at 2am on Sunday November 10th. The daylight saving period will end at 3am on Sunday January 12, 2020. Can a new tzdata be generated for Fiji Island. RuleFiji2014max-NovSun>=12:001:00- RuleFiji2015max-JanSun>=133:000- Thanks Raymond Kumar Head of Billing & Products +6797015315 ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

3 3

Re: [tz] [Tzdist-bis] [calsify] tzdist and IANA
by Daniel Migault Aug. 23, 2019

Aug. 23, 2019

adding the tz mailing in the discussion Yours, Daniel On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki < martin.burnicki(a)burnicki.net> wrote: > Eliot Lear wrote: > > > >> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki(a)burnicki.net> > wrote: > >> > >> Hi all, > >> > >> Eliot Lear wrote: > >>> Hi everyone, > >>> > >>> While the IANA does a great job at servicing our assigned number needs > >>> and delivering the TZ database to developers, they is not set up, nor > do > >>> they have *any* experience, to handle the load that end clients could > >>> place on them. Moreover, they are in no position to support millions > of > >>> people if something goes wrong. And make no mistake: something will go > >>> wrong. I would be okay with a limited tzdist service for those who are > >>> going to be distributing the data themselves, but the order of > receivers > >>> should be on 100s not millions. > >> > >> Wouldn't it be nice to have an infrastructure similar to what the NTP > >> pool provides for time synchronization? > > > > > > I guess I would want to see commitment from those who provide TZ service > to their customers today to go to such a new service before investing a lot > of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the > others want to use it? I also realize that ICANN is well positioned to > fund this sort of thing, but it is not clear to me that it is right for > them to do so. There has to be a real need, and those who really need it > perhaps should foot the bill. > > > > I'm working at Meinberg > https://www.meinbergglobal.com/ > > and we are manufacturing NTP/PTP servers, beside related time > synchronization stuff. > > In the past, whenever governments as of Egypt, Morocco, etc. decided to > start or end DST just a couple of days before this really happens we get > support requests from industries, telecommunication companies, etc., > asking if our time servers could fix the problem to update the TZ data > quickly enough. > > We always have to tell them they need to wait until a new TZ DB has been > released, and then hope that their OS maintainers (Microsoft, Apple, > Linux distros, etc.) pick up the new TZ DB version and provide a > software/firmware update just to provide the latest changes quickly. > > Providing these updates also requires quite some effort for the > maintainers, and it would be much easier for them if this kind of > information could be updated automatically, which should also be faster > than with manual intervention required. > > TZ data must not be requested from a server as often as the current > time, so I think that even if the data size is larger than an NTP packet > the overall load compared to NTP will not be much higher than for a > server that provides NTP services, and if I remember correctly then data > only needs to be transferred if changes have become available. > > So I think this type of service and its advantages just need to be made > more public, to let the OS maintainers learn that they have less work > with rolling out and deploying software updates if they just use TZDIST. > > I'd expect that a TZDIST pool could be operated by volunteers, just like > the NTP pool. > > Martin > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis(a)ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis >

14 20

Java 1.8 update with new DST changes in Brazil?
by Jared Brunson Aug. 22, 2019

Aug. 22, 2019

Will there be an update to Java 1.8 with the new Brazil DST changes? Reference: https://www.timeanddate.com/news/time/brazil-scraps-dst.html The following page hasn't been updated yet. https://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html This is very important for our software product that relies heavily on Java. Thanks, Jared Brunson PSE Symantec DLP

2 1

question regarding Europe/Brussels in 1914
by Alois Treindl Aug. 22, 2019

Aug. 22, 2019

TZ zone Europe/Brussels has a transition from WET to CET on 8 November 1914: 0:00 - WET 1914 Nov 8 1:00 - CET 1916 May 1 0:00 What is the source for this information? Shanks, Henri le Corre "Regime horaires pour l'Europe et l'Afrique' and Gabriel "Trait de l'heute dans le monde' have all 4 August 1914, which was the begin of the German invasion. It seems unlikely that the whole country switched to German time at the begin of the invasion, and therefore I do not trust these three sources. Brussels was occupied by the Germans on 20 August 1914.

2 1

leap second theory
by scs＠eskimo.com Aug. 20, 2019

Aug. 20, 2019

I was trying to point someone to a reference describing how the "right" zones can be used to enable a system to handle leap seconds more correctly, but I discovered that this isn't really documented anywhere. (There's Steve Allen's page at https://www.ucolick.org/~sla/leapsecs/right+gps.html , of course, but that describes a distinct variant of the scheme.) Would it make sense to add something like the attached patch to theory.html?

8 15

file asia needs Link for Asia/Hanoi
by Alois Treindl Aug. 16, 2019

Aug. 16, 2019

I think file asia should have a line Link Asia/Bangkok Asia/Hanoi If this is absent, and file backzone is not compiled, no binary file for Hanoi gets created. This breaks all references to it. For all other zones in backzone, a Link line exists so that a binary file is always created.

2 2

Fwd: Turkey timezone 1940/41
by Alois Treindl Aug. 15, 2019

Aug. 15, 2019

The claim that Turkey had double daylight time in 1940/41 as was published in http://www.astrolojidergisi.com/yazsaati.htm has now been retracted. I had insisted on a double check, because the wording in official documents is often unclear and ambiguous. > Von: Barış İlhan <barisilhan(a)superonline.com> > Datum: 15. August 2019 um 12:30:13 MESZ > An: "'Alois Treindl'" <alois(a)astro.ch> > Betreff: Aw:⁨ Turkey timezone change October 1978⁩ > > Dear Alois, > > I got in touch with the researcher, she said she made a correction for 1941 for one day, after she searched the newspapers. She came to the conclution that a sentence was written wrong in the official legal gazette. > So the final list is this for 1941; > > 01.07.1940 saat 00.00 > > 06.10.1940 saat 00.00 > 1 hour > 01.12.1940 saat 00.00 > - > 21.09.1941 saat 00.00 > 1 hour > 01.04.1942 saat 00.00 > 08.10.1945 saat 00.00 > > 1 hour > > The Milliye gazete archive will not be helpful, because that newspaper was founded in 1950. > > Best, > Baris > > From: Alois Treindl [mailto:alois@astro.ch] > Sent: Thursday, August 15, 2019 12:15 PM > To: Barış İlhan <barisilhan(a)superonline.com> > Subject: Re: Turkey timezone change October 1978 > > > > On 14.08.19 23:30, Barış İlhan wrote: > It looks complicated but actually it is clear. > In 1941 the government first announced 1 hour, and the next day 1 hour more. At the second announcement it says first announcement is still valid, so it makes 2 hours. > > Best, > Baris > > > Sorry, but we need to see this reports in public newspapers, both at the beginning and at the end of the period in question > > Newspapers do say things like 'clock shifts backward one hour' at the end of daylight saving time. In that case, around 21 September 1941, the newspapers must have mentioned a clock shift by two hours. > > The paper archive http://gazetearsivi.milliyet.com.tr/ is accessible for free and is searchable. My problem is that I cannot read Turkish. > > We do not trust the wording of formal government announcements. They have been unclear at other occasions, for example in 1978.

1 0

Re: [tz] Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Paul Eggert Aug. 14, 2019

Aug. 14, 2019

Michael H Deckers wrote: > F2018L01702 is just the diff for the revised > version of Norfolk Island Standard Time Ordinance 2015 > at [https://www.legislation.gov.au/Details/F2019C00010/Download] > > They seem to invalidate the diff after it has been > applied by Legislation Act -- it is probably not idempotent. Thanks for the clarification. I installed the attached patch to the development version on GitHub to implement the change to tzdb, and something like this should appear in the next release. This change assumes that the fall-back transition on 2020-04-05 will occur at 02:00 standard time (03:00 local time), not at 02:00 local time, as this is common practice in Australia.

1 0

Re: [tz] Norfolk Island, Daylight Saving Time (DST) 6/10/19-05/04/20 [SEC=UNCLASSIFIED]
by Stijn “Adhemar” Vandamme Aug. 14, 2019

Aug. 14, 2019

Paul Eggert wrote: > I just visited <https://www.legislation.gov.au/Details/F2018L01702> and found > that it says that F2018L01702 is "No longer in force". The web page details > say that F2018L01702 was registered 2018-12-07, tabled 2019-02-12, and > repealed 2019-08-02 by Division 1 of Part 3 of Chapter 3 of the Legislation > Act 2003, which contains a bunch of legal mumbo jumbo that I don't understand. F2018L01702 ("Norfolk Island Standard Time Amendment (Daylight Saving) Ordinance 2018") amends F2019C00010 ("Norfolk Island Standard Time Ordinance 2015"); and <https://www.legislation.gov.au/Details/F2019C00010> says that F2019C00010 is still in force, with the amendments in question included in the latest version. I guess C2019C00084 ("Legislation Act 2003"), Chapter 3, Part 3, Division 1 contains the legislative logic along the lines of "Once the amendment (diff) has been applied in the original text, the modifying text can fall out of force automatically." -- Adhemar

1 0

Call for evidence on UK adoption of EU summer time abolition
by Joseph Myers Aug. 5, 2019

Aug. 5, 2019

The House of Lords EU Internal Market Sub-Committee has published a call for written evidence on UK adoption of EU abolition of seasonal time changes. https://www.parliament.uk/business/committees/committees-a-z/lords-select/e… https://www.parliament.uk/documents/lords-committees/eu-internal-market-sub… -- Joseph S. Myers jsm(a)polyomino.org.uk

2 1

Fwd: Bulletin C number 58
by Chris Woodbury July 29, 2019

July 29, 2019

On Sat Jul 27 14:21:34 UTC 2019, Paul Eggert <eggert at cs.ucla.edu> wrote: >Thanks, I installed that into the development version on GitHub. > >I see that the updated file has a space at the end of the '#@ 3802291200' line >that encodes the expiration (2020-06-28 00:00:00 UTC). I assume this was >inadvertent. It doesn't break tzcode (which ignores that line), but the format >of the line is not documented anywhere that I can see. I dropped Judah Levine a >line about this. > Back in the dark ages, when I first started writing C code, it was said that the ultimate documentations was the code. In the NTP daemon, there is a subroutine leapsec_load() in which is the following: while (get_line(func, farg, linebuf, sizeof(linebuf))) { cp = linebuf; if (*cp == '#') { cp++; if (*cp == '@') { cp = skipws(cp+1); pt->head.expire = strtouv64(cp, &ep, 10); ... strtouv64() is an NTP native subroutine (found in libntp/vint64ops.c) which reads numeric data in a specified base (in this case 10). It skips "whitespace" (so the call to skipws() is superfluous), and then converts the digits, one at a time, to numeric in that base. It quits conversion when whatever it's pointing at isn't a digit in the selected base and returns the number and "ep", a pointer to where it stopped parsing. This allows for comments and/or additional data. So, a space instead of a line terminator or say, a comment such as "\t# 28 Jun 2020", after the expiration NTP timestamp is an acceptable field termination. Anyone who cares to can reference the "standard" implementation of the NTP code found at: <http://www.ntp.org/downloads.html> The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server...

6 6

CRLF terminated leap-seconds.list fix
by Chris Woodbury July 29, 2019

July 29, 2019

NIST has yet again generated a leap-seconds.list file with CRLF line terminations. If the file is transferred in FTP binary mode and used, it breaks leapseconds.awk. Using int( ) around the last column variable eliminates this problem. Therefore, I propose the attached patch.

3 3

Re: [tz] Fwd: Bulletin C number 58
by Pierpaolo Bernardi July 27, 2019

July 27, 2019

Il giorno 27 luglio 2019, alle ore 05:17, David Patte <dpatte(a)relativedata.com> ha scritto: >For my products I use an algorithm (Meeus; Astronomical Algorithms 1998) to 'predict' deltaT into the future. Does anyone have a good source for a more recent algorithm that takes into account IERS values since 1998? This page may be a start: https://eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html

3 2

Fwd: Bulletin C number 58
by Kurt Roeckx July 27, 2019

July 27, 2019

8 11

NIST leap-seconds.list is finally here
by Chris Woodbury July 26, 2019

July 26, 2019

There is now an updated for July 2019 "leap-seconds.list" file at NIST. Both the Boulder and Greenbelt FTP sites have the new file. Attached find a patch (as follows). $ git diff leap-seconds.list diff --git a/leap-seconds.list b/leap-seconds.list index fd3d192..a1bc5a7 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C57 -# File expires on: 28 December 2019 +# Updated through IERS Bulletin C58 +# File expires on: 28 June 2020 # -#@ 3786480000 +#@ 3802291200 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a +#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30

1 0

Re: [tz] [Tzdist-bis] tzdist and IANA
by Paul Eggert July 25, 2019

July 25, 2019

Here are some other thoughts about any potential IANA effort in this area: * As others have mentioned, the effort should address authentication of the timezone data. It would be helpful to have a real authentication expert in on this, since we want something simple and scalable and workable downstream (see below). * Each tzdb release comes with a version number like "2019b", development commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers often make minor changes to the data, and some append a suffix to the version number to indicate this. The mechanism for publishing this number is specified only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort would do something more specific. Downstream modifications will complicate data authentication. * Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab that contain vague geographical information associated with each tzdb entry. (In some cases this vagueness is intentional, to avoid running into political disputes.) These files are not covered by TZDIST but some POSIX-style clients use them. How should metadata like this be addressed? * Each tzdb release has an auxiliary data file 'leapseconds' that is widely used by clients running NTP and related software. TZDIST has a "leapseconds" action that conveys the information in a different format, and we would need to make sure that this all hooks up correctly. * It'd be helpful to support not only TZDIST, but also a reasonably simple protocol, presumably based on HTTPS transfer of the data since HTTPS is widely supported. This could be used by platforms that don't support TZDIST, or that need auxiliary metadata that is outside the scope of TZDIST. For example, many NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap seconds data format.

2 1

[PROPOSED] Mention IANA Updater, tzdbgen, ZIUpdater
by Paul Eggert July 25, 2019

July 25, 2019

* tz-link.html: Add linkjs for IANA Updater, tzdbgen, and ZIUpdater. Mention ‘make reaguard_tarballs’ too. --- tz-link.html | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/tz-link.html b/tz-link.html index 234c04e..a037972 100644 --- a/tz-link.html +++ b/tz-link.html @@ -268,7 +268,8 @@ For further information about updates, please see <a href="https://tools.ietf.org/html/rfc6557">Procedures for Maintaining the Time Zone Database</a> (Internet <abbr title="Request For Comments">RFC</abbr> 6557). More detail can be -found in <a href="theory.html">Theory and pragmatics of the tz code and data</a>. +found in <a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a>. <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> displays changes between recent <code><abbr>tzdb</abbr></code> versions. </p> @@ -361,6 +362,11 @@ title="JavaScript Object Notation">JSON</abbr></a> format.</li> <section> <h2 id="compilers">Other <code><abbr>tz</abbr></code> compilers</h2> +<p>Although some of these do not fully support +<code><abbr>tz</abbr></code> data, in recent <code><abbr>tzdb</abbr></code> +distributions you can generally work around compatibility problems by +running the command <code>make rearguard_tarballs</code> and compiling +from the resulting tarballs instead.</p> <ul> <li><a href="https://sourceforge.net/projects/vzic/">Vzic</a> is a <a href="https://en.wikipedia.org/wiki/C_%28programming_language%29">C</a> @@ -408,7 +414,7 @@ into an <abbr>ICU</abbr>-specific format. <abbr>BSD</abbr>-style license.</li> <li>The <a href="https://github.com/lau/tzdata">Tzdata</a> package for the <a href="https://elixir-lang.org">Elixir</a> language downloads -and compiles tz source and exposes <abbr +and compiles <code><abbr>tz</abbr></code> source and exposes <abbr title="Application Program Interface">API</abbr>s for use. It is freely available under the <abbr>MIT</abbr> license.</li> <li>Java-based compilers and libraries include: @@ -429,6 +435,11 @@ and time <abbr>API</abbr></a> contains a class Java 8 <code>java.time</code>, which its users should migrate to once they can assume Java 8 or later. It is available under the <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License</a>.</li> +<li><a href="https://bell-sw.com/pages/iana-updater/">IANA Updater</a>, +<a href="https://github.com/akashche/tzdbgen">tzdbgen</a>, and <a +href="https://www.azul.com/products/open-source-tools/ziupdater-time-zone-tool/">ZIUpdater</a> +are other alternatives to TZUpdater. IANA Updater's license is unclear; +the others are licensed under the <abbr>GPL</abbr>.</li> <li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and time library for Android</a> and <a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, @@ -1040,7 +1051,8 @@ is called "<abbr>GMT</abbr>".</li> <section> <h2 id="see-also">See also</h2> <ul> -<li><a href="theory.html">Theory and pragmatics of the tz code and data</a></li> +<li><a href="theory.html">Theory and pragmatics of the +<code><abbr>tz</abbr></code> code and data</a></li> <li><a href="tz-art.html">Time and the Arts</a></li> </ul> </section> -- 2.17.1

1 0

probable correction to Europe/Kaliningrad 1945
by Alois Treindl July 25, 2019

July 25, 2019

3 3

error in zone Erope/Vienna 1946
by Alois Treindl July 25, 2019

July 25, 2019

2 1

Error in zone America/Edmonton 1967, no DST
by Alois Treindl July 25, 2019

July 25, 2019

2 2

Error in America/Vancouver for 1946
by Alois Treindl July 25, 2019

July 25, 2019

3 7

Indian Time zone history and choice of Kolkata as reference location
by Alois Treindl July 24, 2019

July 24, 2019

3 3

tzdata2019b failing to be parsed
by Ian Kaebery July 22, 2019

July 22, 2019

Hello, I’m having trouble with the TZUpdater tool. I’m using the latest version to try and update my timezone definitions to either the ‘latest' package, or the ‘2019b' package, retreived from the IANA website. Both are failing on an entry with Japan using a time of 25:00. I’ve read inconsistent comments on the internet stating a number of things - that this was fixed in the 2018 version, or that there is a script you can run to patch the line, or that there’s an unofficial version (rearguard?) available - but since this is for work I’d prefer to use an unmodified and up-to-date (>2018) version directly from IANA’s website. Do you know if there is any official package I can use for the 2019b definitions that would work with the TZUpdater tool? Thanks very much, Ian

4 4

time zone history Nagorno-Karabakh
by Alois Treindl July 21, 2019

July 21, 2019

Nagorno-Karabakh is an 'Armenian enclave' inside Azerbaijan, which seceded from Azerbaijan in the 1990s, and has some kind of unclear status of autonomy since a ceasefire agreement in 1994. See https://en.wikipedia.org/wiki/Nagorno-Karabakh and https://en.wikipedia.org/wiki/Nagorno-Karabakh_Autonomous_Oblast Azerbaijan and Armenia have different time zone rules, represented in TZ by Asia/Baku and Asia/Yerevan. Has anyone researched the time zone and DST rules in Nagorno-Karabakh? If the time zone rules followed locally differ from Azerbaijan, the situation there justifies the creation of a separate TZ zone. The zone exists now since 25 years with rather high political stability.

3 2

Brazil might stick with daylight saving after all
by Paul Eggert July 21, 2019

July 21, 2019

Our reward for pushing out tzdb 2019b to publish Brazil's DST abolition months early, is that Brazilian President Bolsonaro is now threatening to change his mind and not abolish DST after all. On Thursday, Bolsonaro signaled that possibility as follows: “A minha caneta Bic está à disposição de vocês, qualquer decreto pode ser modificado. A gente entra em contato com a assessoria de assuntos jurídicos e estuda. Se for o caso, a gente altera o decreto para atender o bem-estar da população, sem extrapolar os limites da lei.” Google Translate renders this as: “My Bic pen is at your disposal, any decree can be modified. We get in touch with legal counsel and study. If this is the case, we amend the decree to meet the welfare of the population, without extrapolating the limits of the law.” Reference: Ernesto M. Bolsonaro sinaliza que pode voltar com horário de verão. Correio Braziliense. 2019-07-18. https://www.correiobraziliense.com.br/app/noticia/politica/2019/07/18/inter…

1 0

Dubious coding in tzcode 2019b
by Tom Lane July 20, 2019

July 20, 2019

Some compilers in the Postgres buildfarm are unhappy[1] about this coding in 2019b's zic.c: register ptrdiff_t thistimei, thistimecnt, thistimelim; bool locut, hicut; ... thistimecnt = - locut - hicut; I think they have a point: at best this code is seriously opaque, and at worst it's unportable. I can't even figure out whether this is assuming that bool promotes to signed or unsigned int; and even if whichever choice that is supported by the C99 spec, what will happen in environments where "bool" does not mean the C99 type, but rather signed or unsigned char? (For my immediate purposes, that includes every released branch of Postgres :-(.) I think this would be a lot better if it were written as some if-tests that just consider locut and hicut as boolean values, without any assumptions about how bool converts to integer. If we must have such assumptions, please write them as explicit casts. While the compilers aren't whining about it, this line a bit further down seems like equally bad style to me: convert(locut + thistimecnt + hicut, tzh.tzh_timecnt); This also seems like it's making dubious assumptions about how signed and possibly-unsigned values will mix. regards, tom lane [1] https://www.postgresql.org/message-id/20190719035347.GJ1859@paquier.xyz

4 5

[PROPOSED] HKWT observed in late 1941 in Hong Kong
by Paul Eggert July 12, 2019

July 12, 2019

* NEWS: Mention this. * asia (Asia/Hong_Kong): Treat the period from 1941-10-01 to 1941-12-25 as 30-minute DST rather than as standard time. * theory.html (Time zone abbreviations): Add HKWT. --- NEWS | 5 +++++ asia | 19 ++++++++++++++----- theory.html | 2 +- 3 files changed, 20 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 65c67a2..e2ebe32 100644 --- a/NEWS +++ b/NEWS @@ -12,6 +12,11 @@ Unreleased, experimental changes Fix several errors in pre-1970 transitions in Perry County, IN. (Thanks to Alois Triendl for pointing out the 1967/9 errors.) + 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 commentary Nashville's newspapers dueled about the time of day in the 1950s. diff --git a/asia b/asia index 348e2b5..47a0b25 100644 --- a/asia +++ b/asia @@ -8,7 +8,7 @@ # tz(a)iana.org for general use in the future). For more, please see # the file CONTRIBUTING in the tz distribution. -# From Paul Eggert (2018-06-19): +# From Paul Eggert (2019-07-11): # # Unless otherwise specified, the source for data through 1990 is: # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th edition), @@ -47,13 +47,13 @@ # 7:00 WIB west Indonesia (Waktu Indonesia Barat) # 8:00 WITA central Indonesia (Waktu Indonesia Tengah) # 8:00 CST China -# 8:00 PST PDT* Philippine Standard Time +# 8:00 HKT HKST Hong Kong (HKWT* for Winter Time in late 1941) +# 8:00 PST PDT* Philippines # 8:30 KST KDT Korea when at +0830 # 9:00 WIT east Indonesia (Waktu Indonesia Timur) # 9:00 JST JDT Japan # 9:00 KST KDT Korea when at +09 -# 9:30 ACST Australian Central Standard Time -# *I invented the abbreviation PDT; see "Philippines" below. +# *I invented the abbreviations HKWT and PDT; see below. # Otherwise, these tables typically use numeric abbreviations like +03 # and +0330 for integer hour and minute UT offsets. Although earlier # editions invented alphabetic time zone abbreviations for every @@ -653,6 +653,15 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 # * 1941-09-30, Hong Kong Daily Press, Winter Time Warning. # https://i.imgur.com/dge4kFJ.png +# From Paul Eggert (2019-07-11): +# "Hong Kong winter time" is considered to be daylight saving. +# "Hong Kong had adopted daylight saving on June 15 as a wartime measure, +# clocks moving forward one hour until October 1, when they would be put back +# by just half an hour for 'Hong Kong Winter time', so that daylight saving +# operated year round." -- Low Z. The longest day: when wartime Hong Kong +# introduced daylight saving. South China Morning Post. 2019-06-28. +# https://www.scmp.com/magazines/post-magazine/short-reads/article/3016281/lo… + # From P Chan (2018-12-31): # * According to the Hong Kong Daylight-Saving Regulations, 1941, the # 1941 spring-forward transition was at 03:00. @@ -754,7 +763,7 @@ Rule HK 1979 only - Oct 21 3:30 0 - Zone Asia/Hong_Kong 7:36:42 - LMT 1904 Oct 30 0:36:42 8:00 - HKT 1941 Jun 15 3:00 8:00 1:00 HKST 1941 Oct 1 4:00 - 8:30 - HKT 1941 Dec 25 + 8:00 0:30 HKWT 1941 Dec 25 9:00 - JST 1945 Nov 18 2:00 8:00 HK HK%sT diff --git a/theory.html b/theory.html index e0b3233..1e7df4a 100644 --- a/theory.html +++ b/theory.html @@ -428,7 +428,7 @@ in decreasing order of importance: EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, - HKT/HKST Hong Kong, + HKT/HKST/HKWT Hong Kong, IST India, IST/GMT Irish, IST/IDT/IDDT Israel, -- 2.17.1

1 0

Re: [tz] zone America/Indiana/Tell_city 1967 - 1969
by Paul Eggert July 11, 2019

July 11, 2019

Michael H Deckers wrote: > -Rule Perry 1960 only - Oct lastSun 2:00 0 S Thanks for catching that typo; I installed the attached.

1 0

USNO steps gingerly into the daylight saving mess
by Paul Eggert July 10, 2019

July 10, 2019

Last month the US Naval Observatory's Astronomical Applications Department published a web page that displays daylight saving starting and ending dates for US rules since 1967. A web page lets you enter a year like 1967 and the response will tell you start and end dates for that year. There is also an API that returns the data in a JSON format. Only US federal rules are supported, and only years from 1967 through 9999. See: https://aa.usno.navy.mil/data/docs/daylight_time.php

1 0

zone America/Indiana/Tell_city 1967 - 1969
by Alois Treindl July 10, 2019

July 10, 2019

I am afraid I have to challenge the entry Zone America/Indiana/Tell_City -5:47:03 - LMT 1883 Nov 18 12:12:57 -6:00 US C%sT 1946 -6:00 Perry C%sT 1964 Apr 26 2:00 -5:00 - EST 1969 -5:00 US E%sT 1971 -5:00 - EST 2006 Apr 2 2:00 -6:00 US C%sT It conflicts with Shanks for 1967-169, and therefore I checked newspaper archives. The Indianapolis News, Friday 27 October 1967 states that Perry County returned to CST. It went again to EST on 27 April 1969, as documented by the Indianapolis star of Saturday 26 April. (second screenshot attached)

2 1

VTIMEZONEs and Outlook
by Ken Murchison July 10, 2019

July 10, 2019

All, Sorry for the off-topic post, but I'm fishing. I'm one of the maintainers of vzic, a utility to convert IANA tzdata into iCalendar VTIMEZONE components. In the process of tweaking the tool to handle recent tzdata changes and to generate more correct/compact VTIMEZONEs in "pure" mode, I managed to break the generation of Outlook-compatible VTIMEZONEs. Does anyone know what parts of the iCalendar/VTIMEZONE spec that Outlook doesn't properly handle and/or know what the requirements are to be compatible with Outlook? -- Ken Murchison Cyrus Development Team Fastmail US LLC

4 4

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 8, 2019

July 8, 2019

>On Mon Jul 8 11:16:42 UTC 2019,Tony Finch dot at dotat.at wrote: > >The main problem that I can see is 3 out of the 7 navy.mil DNS servers say >that usno.navy.mil does not exist, so it's a matter of luck whether you'll >be able to contact it or not. > >Tony. Great detective work, Tony! After a little "digging" of my own, I discovered it's even worse than that. There are no public facing "authoritative" DNS servers for Navy.MIL (or USNO.Navy.MIL as all of them are unreachable). The Navy.MIL DNS servers have *no authoritative data* for USNO; they all appear to be caching secondary servers. The give away is that the TTLs decrements between "dig" runs. (Possibly "slit horizon" DNS servers that internally referencing their other half. There's no way to tell from this side.) This also means that the primary server listed in the SOA is not the real primary. There must be hidden primary and secondary DNS server somewhere as the servers we can actually see have cached RR (resource records). Someone hasn't thought out all of the implications of what they're doing. When I was looking, only two of seven Navy.MIL DNS servers returning NXDOMAIN for USNO.Navy.MIL. These were ns1.csd.disa.mil, the purported Navy.MIL primary DNS server (with no authoritative SOA RR) and updciftr01.csd.disa.mil. I could not reach *any* of the USNO.Navy.MIL DNS servers, period (The Naval Oceanographic Portal. (NoP) is up as I was able to FTP to Tycho and MAIA. I'm going to have to add Psyche.USNO.Navy.MIL to my /etc/hosts it seems (when I can figure out its IP address)). I must agree that a guaranteed 28% failure rate for USNO.Navy.MIL DNS lookups is unacceptable. The USNO SOA points to hostmaster(a)usno.navy.mil and none of the hosts in that MX RR are reachable. Does anyone have the 'phone number of a responsible person at USNO proper? The Petty Officer who answered the 'phone at the main number was less than helpful... (I hesitate to call Jeff Prillaman about this issue.)

1 0

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 8, 2019

July 8, 2019

Brian et al, DoD sites are subject to frequent attack from the Internet. One of their defense strategies is to "go turtle"". Sometimes they're not there at all but, more often, they isolate just portion of their "space". (TRACERT ends in never-neverland.) I have discovered that, when this happens, the Navy.Mil and USNO.Navy.Mil DNS servers are often not reachable. As a result, while USNO sites are actually available though the Naval Oceanographic Portal (NoP) (point of presence (PoP) in Portsmouth, VA), their DNS entries are not. I, personally, solved part of this problem by adding the USNO sites I use to /etc/host (or its Windows equivalent, %WINDIR%\System32\drivers\etc\hosts). These are: 199.211.133.23 maia.usno.navy.mil 199.211.133.93 aa.usno.navy.mil 199.211.133.239 tycho.usno.navy.mil # Charon is a USNO.Navy.Mil DNS server on the NOP 199.211.133.5 charon.usno.navy.mil charon.nofs.navy.mil 192.68.148.66 charon.nofs.navy.mil 192.68.148.80 toshi.nofs.navy.mil MAIA also has backup servers for their data at NASA Goldstone Space Flight Center (cddis.gsfc.nasa.gov) and, as Brian mentioned, toshi.nofs.navy.mil. (At this instant, MAIA and Toshi are unavailable via HTTP but FTP is just fine (with /etc/host entries). If one is running a local DNS server, adding a pointer to USNO.Navy.Mil with a Charon.USNO.Navy.Mil NS RR might help the cause... Since I've done these things (particularly the /etc/hosts entries), I rarely have problems reaching USNO sites. Also, sometimes, DoD restrict themselves to Secure DNS. As I've got (some of) the certificate information installed, I may not have problems where others might. Lastly, occasionally I can't reach MAIA via HTTP but FTP works just fine. (I've just change my references to ser7.dat to FTP for that reason.) (Pardon my edits to the following. No words were removed...) > On Sat Jul 6 16:12:26 UTC 2019, Brian Inglis Brian.Inglis at SystematicSw.ab.ca wrote: >>On 2019-07-05 15:55, Chris Woodbury via tz wrote: >> # This NTP leap-second file was created with data obtained from >> # the United States Naval Observatory (USNO) MAIA FTP server. >> # >> # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> >> ... >> # See: http://maia.usno.navy.mil/ser7/ser7.txt > > Seems to be some DNS resolver and network blocking, possibly only > outside the US, to maia.usno.navy.mil ; interactive web browser access > and Naval Oceanography Portal to tycho.usno.navy.mil and aa.usno.navy.mil > mostly work, but web browser ftp access does not, and non web browser > resolution and access do not, e.g. host or wget; however everything resolves > and is accessible form the browser and command line from toshi.nofs.navy.mil. > Some other previous reports back this up, but there were no followups to say > whether issues were temporary and cleared up, or persisted and were permanent. > > It may be possible that lookups or accesses may be rate limited to deter > intrusions, or entries may have expired because they may be offline for July 4 > thru the weekend, or sites may be blocked due to lack of monitoring staff or > funding for non-defense services.

3 3

Re: [tz] DST in Detroit 1967
by Paul Eggert July 7, 2019

July 7, 2019

Alois Treindl wrote: > So whether it was DST or not, at the time given in the article light cannot have > started to fail That depends on what the article's author Bill Dow meant by "fail". In a burning city, light could "fail" well before astronomical sunset. > You say in your comment that you have seen "multiple reports that (Shanks DST > data) is incorrect." > > I am curious what those other reports might be. Sorry, I don't remember the details. As I vaguely recall, the situation in Michigan was chaotic. The state rebelled against the federal daylight-saving law, some counties rebelled against the state, cases went to the state supreme court which may have (temporarily?) suspended the state's suspension of DST, and I don't know of any reliable catalog of what actually happened that year in Detroit. Perhaps someone could spring the money and read all the stories in the Detroit Free Press and Detroit News archives related to daylight saving time that year. I expect there would be dozens of stories to wade through. Let's hope the competing newspapers in Detroit didn't follow the model of Nashville in the previous decade. That Nashville story is so entertaining that it should be promoted from our email archive to the northamerica comments. Proposed patch attached.

1 1

Blocked USNO sites was: Updated Public Domain leapseconds.list
by Chris Woodbury July 6, 2019

July 6, 2019

For reasons I can not fathom, I did not check on all the links in the leap-seconds.list I just submitted to the list. As a result, I failed to notice that the link to IERS Bulletin A was incorrect. The proper link is: # <ftp://maia.usno.navy.mil/ser7/ser7.dat> ^^^ Also available via HTTP. Note: the FTP and HTTP versions *have different timestamps* (and therefore are most likely separate files in different file structures). Otherwise, the files are identical. (This is why I've got alias cp='cp --preserve=timestamps' in my run commands....) Also, I managed to include a dot (.) at the end of a link in my first Bulletin C number 58 message. The proper URL for the directory in which to find the IERS leap-seconds.list file is: <ftp://hpiers.obspm.fr/iers/bul/bulc/ntp/> "leap-seconds.list" is a symbolic link. Its "real" name is "leap-seconds.3771235866" (4 Jul 2019 15:31:06 CEST) One may also use HTTP or HTTPS protocols to get there. Sorry about that.

1 0

Updated Public Domain leapseconds.list
by Chris Woodbury July 6, 2019

July 6, 2019

# -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> # Updated using information from IERS Bulletin C 58 (4 Jul 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # Bulletin C 58 did not announce a new leap-second. # The last leap-second occurred on 1 Jan 2017 (3692217600). # # -=<*>=- # # This file is not produced by a national metrology laboratory. # It *is* created using data from one: # # United States Naval Observatory (USNO) # IERS Rapid Service/Prediction Center for Earth Orientation # 3450 Massachusetts Ave NW, Washington, DC 20392 # # It should be noted that anyone with proper information can # generate an NTP leap-seconds.list file. # # This file's generation was originally necessitated by a U.S. # government shutdown and the resulting lack of an NIST or USNO # generated file until late in January 2019. # # -=<*>=- # # The Network Time Protocol (NTP) keeps time in Coordinated # Universal Time (UTC). UTC is a time scale based upon # Standard International (SI) seconds and derived from Temps # Atomique International (TAI). UTC is the basis for legal # time since 1 Jan 1972 0h. # # [Le] Bureau International des Poids et Mesures (BIPM) tracks # TAI, UT1, TE and UTC uses a weighted ensemble of 420+ atomic # clocks at over 80+ national metrology laboratories worldwide # to track time and Very-Long-Baseline Interferometry (VLBI) # for precision millisecond pulsars timing and to track Earth's # orientation in space. The origin of TAI has been agreed # officially to coincide with UT1 on 1 January 1958 0h. # # For further information, read BIPM monograph "Time Scales" # found at: # # <https://www.bipm.org/... # utils/common/pdf/monographies-misc/Monographie1994-1.pdf> # # And "Coordinated Universal Time" at: # # <https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf> # # And, lastly: # # "Atomic Time Scales for Dynamical Astronomy" pp.51-56 # # "How Can Millisecond Pulsars Improve the Long-Term Stability # of Atomic Time Scales?", pp.57-60: # # Proceedings of the 6th European Frequency and Time Forum # (17-19 March 1992) # # <http://www.eftf.org/proceedings/proceedingsEFTF1992.pdf> # # -=<*>=- # # Leap seconds are an official correction to UTC to keep it # within 0.9 seconds of UT1; yet another time standard # based upon the orientation of the earth in space (and the # basis of legal time until 1972). IERS Bulletin A keeps # track of and predicts the value of UT1-UTC. # # See: http://maia.usno.navy.mil/ser7/ser7.txt # # The data kept in "leap-seconds.list" are used by the # Network Time Protocol daemon (NTPd) to determine when to # apply leap seconds to Coordinated Universal Time (UTC). # "leap-seconds.list" is a symbolic link to the actual # file name, leap-seconds.xxxxxxxxxx, where xxxxxxxxxx # is derived from the NTP update timestamp (below). # # Theoretically, a leap second may be positive or negative. # Realistically, negative leap seconds are unlikely to occur. # # All timestamps in this leap seconds file are encoded using the # NTP epoch. These timestamps represent the number of seconds # since 1 Jan 1900 0:00:00. This is Modified Julian Date (MJD) # 15020 and Julian Date 2415020.5. There will be an unsigned # 32-bit overflow to the second NTP era in 2036 (07 Feb 2036 # 06:28:16 UTC to be precise). # # A leap second datum consists of an NTP timestamp and the # number of seconds difference between TAI and UTC (e.g. # currently TAI-UTC is 37). UTC was established (at # midnight) on 1 Jan 1972 0h with TAI-UTC started at 10. # There was no mechanism prior to that time defining when # to apply leap seconds. # # Note: the first datum in the leap-seconds.list file is # *not* a leap-second; it denotes the definition of the # UTC timescale. # # Leap-seconds rules are establish in: # # International Telecommunications Union-Recommendation (ITU-R) # 460-6 (Standard-frequency and Time-Signal Emissions), # Annex 1 (Time scales), Section 2 (Leap-Seconds). # # Note: Version 460-6 of the Recommendation is incorporated # by reference in the [ITU] Radio Regulations. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # Section 2.3: Delegates leap-second timing/dissemination to the # International Earth Rotation and Reference System Service (IERS), # (in its role as inheritor of Bureau International de l'Heure (BIH)). # # NTP Leap second files have an update time (#$). This is often # the UTC zero (0) hour time of the day when the leap second file # is built. [I am of the opinion] it should be updated whenever # a new IERS Bulletin C is issued. CCW] # #$ 3771187200 # # Leap second data have a lifetime. Traditionally, this ends on # the twenty-eighth (28) day of the month six months after the # period of time described in the latest IERS Bulletin C. This # is the expiry time (#@). # # File expires on: 28 Jun 2020 # #@ 3802291200 # # Leap second files have a hash, as define in NIST's FIPS 180 # Secure Hash Standard (SHS), current revision 4 (FIPS 180-4). # # FIPS Publications: <http://csrc.nist.gov/publications/fips/> # Direct Link: <http://dx.doi.org/10.6028/NIST.FIPS.180-4> # # It is based on an SHA[1] digest, created using the data # portions of the file including leap second data and the update # and expiry timestamps. All "white space" and comments are # ignored in the computation thereof. The 160-bit SHA[1] # digest polynomial are encoded in five hexadecimal grouping at # the end of the file (#h). The hash itself is NOT included in # the SHA[1]. It can also be calculated using GNU sha1sum which # generates the same 160-bit digest, given the same data, in # forty hexadecimal characters. # # Additionally, there may be an "#SHA256" digest record. If # present, it is a FIPS-180 SHA256 digest that includes the # same records as "#h" plus the comment Day, Month and Year # included in each NTP leap-second record (thus making it # possible to *verify* those comments as well as the file time- # stamps, and NTP leap-second data. # # NTP delta #timestamp T Date of Change # 2272060800 10 # 1 Jan 1972 (MJD 41317) 2287785600 11 # 1 Jul 1972 (MJD 41499) 2303683200 12 # 1 Jan 1973 (MJD 41683) 2335219200 13 # 1 Jan 1974 (MJD 42048) 2366755200 14 # 1 Jan 1975 (MJD 42413) 2398291200 15 # 1 Jan 1976 (MJD 42778) 2429913600 16 # 1 Jan 1977 (MJD 43144) 2461449600 17 # 1 Jan 1978 (MJD 43509) 2492985600 18 # 1 Jan 1979 (MJD 43874) 2524521600 19 # 1 Jan 1980 (MJD 44239) 2571782400 20 # 1 Jul 1981 (MJD 44786) 2603318400 21 # 1 Jul 1982 (MJD 45151) 2634854400 22 # 1 Jul 1983 (MJD 45516) 2698012800 23 # 1 Jul 1985 (MJD 46247) 2776982400 24 # 1 Jan 1988 (MJD 47161) 2840140800 25 # 1 Jan 1990 (MJD 47892) 2871676800 26 # 1 Jan 1991 (MJD 48257) 2918937600 27 # 1 Jul 1992 (MJD 48804) 2950473600 28 # 1 Jul 1993 (MJD 49169) 2982009600 29 # 1 Jul 1994 (MJD 49534) 3029443200 30 # 1 Jan 1996 (MJD 50083) 3076704000 31 # 1 Jul 1997 (MJD 50630) 3124137600 32 # 1 Jan 1999 (MJD 51179) 3345062400 33 # 1 Jan 2006 (MJD 53736) 3439756800 34 # 1 Jan 2009 (MJD 54832) 3550089600 35 # 1 Jul 2012 (MJD 56109) 3644697600 36 # 1 Jul 2015 (MJD 57204) 3692217600 37 # 1 Jan 2017 (MJD 57754) # #SHA256: 128f9463dc3828a1c7a611a4017bc311aabdfbe4c33fd8278a63bed7ef3ba0e2 #h bca6f457 5f358e20 a63e0aab a79ad3c3 c0a21083

3 3

Bulletin C number 58
by Chris Woodbury July 6, 2019

July 6, 2019

Christian Bizouard has struck again (and exactly a week earlier than I was expecting). No new leap-second. I predict (after a careful perusal of Bulletin A) that we will see one in July 2020. i.e.: 3802550400 38 # 1 Jul 2020 There is a new, IERS leap-seconds.3771235866 file at https://hpiers.obspm.fr/iers/bul/bulc/ntp. Dr. Levine and Jeff Prillaman will no doubt shortly generate NIST and USNO versions respectively. (Today is a federal holiday in the US.) For those who can't wait, I have attached another leap-seconds.list file, Eggert_leap-seconds.3771187200, which has a FIPS style SHA-256 digest that includes the erstwhile day, month and year from the comments. Happy (U.S.) Independence Day !!

2 1

Bug Moncton 1973? Where can I find old tzdata releases?
by Alois Treindl July 5, 2019

July 5, 2019

https://data.iana.org/time-zones/ seems to contain only tzdata releases from 2016 upwards. I need to look into pre-2005 ones. Where can I find them? The reason is that I am checking New Brunswick, Canada DST in 1973. The zone America/Moncton was introduced in 2007, to be able to represent an unusual clock time of 0:01 for DST onset. America/Moncton does not list DST for 1973. That is the only year between 1945 and 2020 that NB would not have DST. Nearby zones like Halifax or ST_Johns have 1973 DST, just like the rest of Canada? Is there a bug in America/Moncton ? Shanks has DST in 1973 for New Brunswick.

5 4

Re: [tz] tz Digest, Vol 94, Issue 6
by Andrii Nabok July 5, 2019

July 5, 2019

Dear Paul Eggert, I would like to draw your attention to the fact that the Kyiv time zone is officially defined in the Crimea. In this regard, I have the following statements: 1. This is not a political issue; 2. All projects on the Internet, regardless of their scope, must comply with international law. 3. The territory of Crimea is not a disputed territory. Crimea is an integral part of Ukraine. All countries in the world, except Russia (which started the war in Ukraine), consider Crimea to be part of Ukraine. 4. Also pay attention to the provisions of the BCP 175. *"Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry.". *Fake news on Russian sites - is not a consensus. Why is the Tzadat base contributing to Russian invaders and terrorists in conducting an information war against a civilized world? Also, we ask to answer the following questions: 1. On which basis were changes made in 2014? Based on the news on the site in the domain zone. Ru ??? 2. Will you change the time zone in Alaska, if after some time, Russian troops enter Alaska, take prisoner of official representatives of the US government and subsequently publish on all Russian sites the news that the Magadan time zone is set in Alaska??? Sincerely, Andrii Nabok чт, 4 лип. 2019 о 10:36 <tz-request(a)iana.org> пише: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Simferopol switch near 2014-03-30 (Paul.Koning(a)dell.com) > 2. Re: Simferopol switch near 2014-03-30 (Tim Parenti) > 3. Re: Simferopol switch near 2014-03-30 (Michael H Deckers) > 4. Re: Simferopol switch near 2014-03-30 (Paul Eggert) > 5. [PROPOSED] Cite Rec. ITU-R TF.460-6 for leap seconds (Paul Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 3 Jul 2019 13:27:29 +0000 > From: <Paul.Koning(a)dell.com> > To: <tz(a)iana.org> > Subject: Re: [tz] Simferopol switch near 2014-03-30 > Message-ID: <43E8DF99-A7A4-4879-9555-5E5DEC7CEC31(a)dell.com> > Content-Type: text/plain; charset="us-ascii" > > > > > On Jul 3, 2019, at 6:44 AM, Sergij Marchenko <makars(a)gmail.com> wrote: > > > > You can continue to live according to the rules imposed by russian > terrorists under the occupation regime of Putin Huylo. > > It's been explained many times already that the TZ project is a technical > one, not a political one, and the issue you raise is out of scope. > > Since you persist in bringing it up in spite of being corrected > repeatedly, it may be time to consider your mail to be spam and filter it > accordingly. > > paul > > > ------------------------------ > > Message: 2 > Date: Wed, 3 Jul 2019 09:33:36 -0400 > From: Tim Parenti <tim(a)timtimeonline.com> > To: Michael H Deckers <michael.h.deckers(a)googlemail.com> > Cc: Time Zone Mailing List <tz(a)iana.org> > Subject: Re: [tz] Simferopol switch near 2014-03-30 > Message-ID: > < > CAFpi07wuB0+X230MukZJGmVwFS2f8PBo5Fcua8CMaB-y+s4PJw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, 3 Jul 2019 at 04:43, Michael H Deckers via tz <tz(a)iana.org> wrote: > > > tzdb currently has the switch in Simferopol from > > 2014-03-30T02:00 to 04:00, following the announcement in > > [https://vz.ru/news/2014/3/17/677464.html] from 2014-03-17. > > > > But the clocks of the main station shown in the video at > > [https://www.rt.com/news/crimea-clocks-moscow-time-173/] > > advance from 22:00 to 00:00. If this is not a fake, the > > switch happened 4 hours earlier. > > > This apparent discrepancy in reporting was discussed contemporaneously > on-list and is already noted in commentary. > https://mm.icann.org/pipermail/tz/2014-March/020814.html > https://mm.icann.org/pipermail/tz/2014-March/020815.html > > Specifically: > > # Simferopol and Sevastopol reportedly changed their central town clocks > > # late the previous day, but this appears to have been ceremonial > > # and the discrepancies are small enough to not worry about. > > > As it so happens, the RT article you linked confirms that particular > perspective ? that the 22:00 transition was merely "ceremonial" and that > the 02:00 transition was official ? more clearly than we had identified at > the time. Quoting the article: > > ?the hands of the main railway station clock in the city of Simferopol > > jumped from 10 pm to 12 am on Saturday. [?] The ceremony follows the > > region?s formal joining the Russian Federation on March 21. Other > Crimeans, > > apart from Simferopol, the region?s capital, were expected to switch > their > > clocks at 2:00 am on Sunday, AFP reported. > > > It appears India's *Business Standard* also contemporaneously reported the > same, at > > https://www.business-standard.com/article/pti-stories/crimea-to-set-clocks-… > : > > ?a symbolic ceremony will be held to move the clocks forward at the railway > > station in the main city of Simferopol. The Black Sea peninsula's prime > > minister Sergei Aksyonov will oversee the switch at 10pm (midnight > Moscow, > > 2000 GMT). Europeans and ordinary Crimeans make the daylight savings > time > > switch at 2am tomorrow. > > > Since the zone is meant to represent the region as a whole, and not > necessarily one or two clocks in the town squares in the representative > city, this is why we settled on 2014-03-30 02:00 for the transition. > > -- > Tim Parenti >

2 3

[PROPOSED] Cite Rec. ITU-R TF.460-6 for leap seconds
by Paul Eggert July 4, 2019

July 4, 2019

(Inspired by patch proposed by Chris Woodbury.) * leapseconds.awk (BEGIN): * tz-link.html (Precision timekeeping): Add ITU-R citation. * leapseconds.awk (BEGIN): Drop mention of rolling leap seconds, as the ITU-R doesn’t mention them and this script doesn’t generate them. --- leapseconds.awk | 16 +++++++++------- tz-link.html | 4 ++++ 2 files changed, 13 insertions(+), 7 deletions(-) mode change 100644 => 100755 leapseconds.awk diff --git a/leapseconds.awk b/leapseconds.awk old mode 100644 new mode 100755 index 242e9d6..241da92 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -16,6 +16,11 @@ BEGIN { print "# The NTP Timescale and Leap Seconds" print "# <https://www.eecis.udel.edu/~mills/leap.html>." print "" + print "# The rules for leap seconds are specified in Annex 1 (Time scales) of:" + print "# Standard-frequency and time-signal emissions." + print "# International Telecommunication Union - Radiocommunication Sector" + print "# (ITU-R) Recommendation TF.460-6 (02/2002)" + print "# <https://www.itu.int/rec/R-REC-TF.460-6-200202-I/>." print "# The International Earth Rotation and Reference Systems Service" print "# periodically uses leap seconds to keep UTC to within 0.9 s of UT1" print "# (which measures the true angular orientation of the earth in space)" @@ -29,15 +34,12 @@ BEGIN { print "# accounting for the discrepancy between atomic time and the earth's rotation" print "# did not exist. The first (\"1 Jan 1972\") data line in leap-seconds.list" print "# does not denote a leap second; it denotes the start of the current definition" - print"# of UTC." + print "# of UTC." print "" print "# The correction (+ or -) is made at the given time, so lines" - print "# will typically look like:" - print "# Leap YEAR MON DAY 23:59:60 + R/S" - print "# or" - print "# Leap YEAR MON DAY 23:59:59 - R/S" - print "" - print "# If the leap second is Rolling (R) the given time is local time (unused here)." + print "# typically look like this:" + print "# Leap YEAR MON DAY 23:59:60 + S" + print "# A negative leap second's columns 5 and 6 would be '23:59:59' and '-'." monthabbr[ 1] = "Jan" monthabbr[ 2] = "Feb" diff --git a/tz-link.html b/tz-link.html index 85fc001..234c04e 100644 --- a/tz-link.html +++ b/tz-link.html @@ -929,6 +929,10 @@ scales used by each landed mission on Mars.</li> dedicated not only to leap seconds but to precise time and frequency in general. It covers the state of the art in amateur timekeeping, and how the art has progressed over the past few decades.</li> +<li>The rules for leap seconds are specified in Annex 1 (Time scales) of <a +href="https://www.itu.int/rec/R-REC-TF.460-6-200202-I/">Standard-frequency +and time-signal emissions</a>, International Telecommunication Union – +Radiocommunication Sector (ITU-R) Recommendation TF.460-6 (02/2002).</li> <li><a href="https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html"><abbr title="International Earth Rotation and Reference Systems Service">IERS</abbr> -- 2.17.1

3 7

Clarification on future direction of POSIXRULES and POSIX TZ specs?
by Tom Lane July 4, 2019

July 4, 2019

The 2019b announcement says that zic's -p feature is being deprecated with an eye to eventual removal. I am wondering what is the game plan there exactly, and in particular what is planned to happen in localtime.c. Will the code that tries to load the TZDEFRULES zone be removed? If so, will the behavior for transition-rule-less POSIX TZ specs be that it always falls back to the hard-wired TZDEFRULESTRING? Or are you planning to go further, say by rejecting such TZ specs entirely? (As far as I can see, doing that would be contrary to the POSIX spec --- although they don't say what the default rule should be, it's pretty clear syntactically that you can omit it.) Also, what sort of time scale might this happen on? regards, tom lane

2 1

Backzone entry for Europe/Vaduz
by Alois Treindl July 4, 2019

July 4, 2019

In the year 2013 I had contributed information that Swiss neighbor country Liechtenstein, represented by Europe/Vaduz in file backzone, did not have daylight saving time in 1941 and 1942, while Switzerland, represented by Europe/Zurich, did have it. A colleague sent me a follow-up question today, which cause me to reconsider the question. I was able to access the online archive of the Vaduz paper Vaterland for free - they offer a special summer deal. I could confirm frm the paper that Liechtenstein did in fact follow the same DST in 1941 and 1942 as Switzerland did. The entry Europe/Vaduz in the file backzone can be removed, so that the link Europe/Zurich Europe/Vaduz remains effective even for those who, like me, compile TZ with backzone included. I attach a few newspaper clippings, not translated.

3 4

Golan Heights and Quneitra
by Alois Treindl July 4, 2019

July 4, 2019

The Golan Heights are not represented by a zone in TZ. Since 1967 under control of Israel, they fall under Asia/Jerusalem, as all differences fall under the 1970 TZ cut-off. Having a zone in backzone would be good, though. There is however one town in the Golan Heights, Quneitra, which was returned from Isreal to Syria in 1974. There have been timezone differences in the years 1967 - 1974 between Israel and Syria. Therefore, Asia/Quneitra would merit its own zone, in my opinion. https://en.wikipedia.org/wiki/Quneitra list a population of 153 for the (destroyed) town itself and 4318 for is 'metropolitan' area.

2 1

Simferopol switch near 2014-03-30
by Michael H Deckers July 3, 2019

July 3, 2019

tzdb currently has the switch in Simferopol from 2014-03-30T02:00 to 04:00, following the announcement in [https://vz.ru/news/2014/3/17/677464.html] from 2014-03-17. But the clocks of the main station shown in the video at [https://www.rt.com/news/crimea-clocks-moscow-time-173/] advance from 22:00 to 00:00. If this is not a fake, the switch happened 4 hours earlier. Michael Deckers.

5 7

From Consulate General of Ukraine in San Francisco
by Consulate General of Ukraine in San Francisco July 2, 2019

July 2, 2019

З повагою/Best regards, Генеральне консульство України в Сан-Франциско/Consulate General of Ukraine in San Francisco 530 Bush Street, Suite 402, San Francisco, CA 94108 Tel: + 1 (415) 398 0240, Fax: +1 (415) 398 5039 http://san-francisco.mfa.gov.ua<http://san-francisco.mfa.gov.ua/> gc_uss(a)mfa.gov.ua<mailto:gc_uss@mfa.gov.ua>

2 1

[tz-announce] 2019b release of tz code and data available
by Paul Eggert July 2, 2019

July 2, 2019

The 2019b 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: Brazil no longer observes DST. 'zic -b slim' outputs smaller TZif files; please try it out. Palestine's 2019 spring-forward transition was on 03-29, not 03-30. Changes to future timestamps Brazil has canceled DST and will stay on standard time indefinitely. (Thanks to Steffen Thorsen, Marcus Diniz, and Daniel Soares de Oliveira.) Predictions for Morocco now go through 2087 instead of 2037, to work around a problem on newlib when using TZif files output by zic 2019a or earlier. (Problem reported by David Gauchard.) Changes to past and future timestamps Palestine's 2019 spring transition was 03-29 at 00:00, not 03-30 at 01:00. (Thanks to Sharef Mustafa and Even Scharning.) Guess future transitions to be March's last Friday at 00:00. Changes to past timestamps Hong Kong's 1941-06-15 spring-forward transition was at 03:00, not 03:30. Its 1945 transition from JST to HKT was on 11-18 at 02:00, not 09-15 at 00:00. In 1946 its spring-forward transition was on 04-21 at 00:00, not the previous day at 03:30. From 1946 through 1952 its fall-back transitions occurred at 04:30, not at 03:30. In 1947 its fall-back transition was on 11-30, not 12-30. (Thanks to P Chan.) Changes to past time zone abbreviations Italy's 1866 transition to Rome Mean Time was on December 12, not September 22. This affects only the time zone abbreviation for Europe/Rome between those dates. (Thanks to Stephen Trainor and Luigi Rosa.) Changes affecting metadata only Add info about the Crimea situation in zone1970.tab and zone.tab. (Problem reported by Serhii Demediuk.) Changes to code zic's new -b option supports a way to control data bloat and to test for year-2038 bugs in software that reads TZif files. 'zic -b fat' and 'zic -b slim' generate larger and smaller output; for example, changing from fat to slim shrinks the Europe/London file from 3648 to 1599 bytes, saving about 56%. Fat and slim files represent the same set of timestamps and use the same TZif format as documented in tzfile(5) and in Internet RFC 8536. Fat format attempts to work around bugs or incompatibilities in older software, notably software that mishandles 64-bit TZif data or uses obsolete TZ strings like "EET-2EEST" that lack DST rules. Slim format is more efficient and does not work around 64-bit bugs or obsolete TZ strings. Currently zic defaults to fat format unless you compile with -DZIC_BLOAT_DEFAULT=\"slim\"; this out-of-the-box default is intended to change in future releases as the buggy software often mishandles timestamps anyway. zic no longer treats a set of rules ending in 2037 specially. Previously, zic assumed that such a ruleset meant that future timestamps could not be predicted, and therefore omitted a POSIX-like TZ string in the TZif output. The old behavior is no longer needed for current tzdata, and caused problems with newlib when used with older tzdata (reported by David Gauchard). zic no longer generates some artifact transitions. For example, Europe/London no longer has a no-op transition in January 1996. Changes to build procedure tzdata.zi now assumes zic 2017c or later. This shrinks tzdata.zi by a percent or so. Changes to documentation and commentary The Makefile now documents the POSIXRULES macro as being obsolete, and similarly, zic's -p POSIXRULES option is now documented as being obsolete. Although the POSIXRULES feature still exists and works as before, in practice it is rarely used for its intended purpose, and it does not work either in the default reference implementation (for timestamps after 2037) or in common implementations such as GNU/Linux (for contemporary timestamps). Since POSIXRULES was designed primarily as a temporary transition facility for System V platforms that died off decades ago, it is being decommissioned rather than institutionalized. New info on Bonin Islands and Marcus (thanks to Wakaba and Phake Nick). Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2019b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2019b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2019b.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 23a01523a5d6a6ae2217df77b2a3f60e10a373d2 dated 2019-07-01 00:09:53 -0700 and tagged '2019b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: bcfb417fe3b7c39e702da0090291db0489744f733010ae183007fce5e441bfce885fb25ed11730cf7f363572e107d7ff0c4b38691bb99def2d8cf7017c05720f tzcode2019b.tar.gz c0104078d994e501d80a41bea31364b1390a75c2fbf42968a8343a090e2ac2eddbc58770ca470b192ea19dec89fcc634141a1de703ea2ffa0325176a64afe1fc tzdata2019b.tar.gz 98030b41258d21b6040fe95ecee4edd6bb9fa3775d89bebf69f460abad009eb47f053197ac755dc2d631b40fe31d4d3650493f139069b14ab3771e529cebcaea tzdb-2019b.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl0Zs9AACgkQ7ZfpDmKq fjQziw//UmsHJNgU9cwbxWUBNqqu6VqrllAgLEXXLbK0EhZGwQpYsrhW9h5LZrvS OVHUt7EorLaFB4rSkTr2DP6pSqAn7+i7pXVdETxHNmTcF85rbyLwt5Z4OrbMAaN2 f44BxVSOSO4C/A+wWN7JAhAC57fwj++bCvIZ82qlauV1BsBq0AiuURat5OP2ZA16 Wpz3749wy1N4xEtYaMRzBozWQ6mnyYxaCRZUTv2BhuVK8UbUrHZ8I8KkcqAYnOqL E0fTWSKQVRxciApFNWHEreIeeVonOom0DWWEL3dIQcx09IM0YtocpAXgWoyHzOic mU7ibcx0KrpzDW+6nf/owxe/dkUa+CbHgPDs9b5vTJUwJkSk8wrpr3tAPSjBeo9K WN+BvhxeZKihPU9DziWTs8jAzyVtnqGNesBhVi1zecY723Gk/oizdDQNxh9vLbYU VUP3kcc2IqEciJVeI6bDz2wSJVcCif3bFFosuF2fOpTzmpLx+WceYVw+y0NFMcTN euZ/D1AQK7opCshjoBKqbOMB6TvbjjCiEjQ/pkXKLwhYBWCtIPMblgo+33MrI4Eb r/3S+l4o6yDbxslZjn0kNoG6krrbb6F1IrjIfnd4t2PDoeYS2vE7rCi+qhrJNLEI 24ZxbaZgnt4JvAec+5cy9ZnTOzZs7IhDSiMbm40IB0v2zVFT+rQ= =6vQV -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl0Zs9AACgkQ7ZfpDmKq fjT55Q/9G4BmEDL48wU0slZCAFNMqbvNfizL2MTNHC6Yv60gwdQCl7CgQk+zE+1W b4ir1Vm23eWWVdCjGGwjt4WWy+SlvnEKqjiZxTRFpkB5to8Zi5KNklGlUX0U9iUu vMCVKeIQMFLUr6sAqAk4lgJ2OUF1MNaj2kVwINxS+C8rCyr6wjn6FWWaxvbCO3+D 2Z8sZgCRBWxmckqX+4Nmv2YeCGuL1ZjVTz0flkWi/OduR+PjBe/9PN506PjeEht8 cqOjtRz/V4SEKfbv6rn8jqxDrl6xkrBxfiaF64smWgwSFcQ9yRrxCt2L35tARdal DAP/vb1PemUb0fJawYP/ZhiArk0fCRRZ+wleTZKsk65I4VsrffQ3rYe5ZtMYnUhO +UP+B7OkxNa0gARf+uFwYvrqZefg0HRq/INFqd3TCkza0wa7Rb3mQL9orCzUH7St XLrdhRJYWGcuepGBiTdO4+yPqXkK7k89W3ACo+HiVuRbMRo3Xf+38918kubns41l /itR/C/lSN+/ErokSh6VshelvOuMVcgoghTD7fDAtNaH9IgldEIF/Wf3m1Um+V9R sN646EvAazgkxw3hD1sEDxHxN7TIsxFvTaimVg+uwrX2b8Ok+tffomlalSXoOS8F zK/EyKROm8v2dSJUD0Hf+FvDqJm/Pre0ydKqsdahJYBxIStNnX8= =P/tF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl0Zs9IACgkQ7ZfpDmKq fjRlfQ//ev3hI5NxrAoJX8fpb9LAdReo7ZpADinVnNn47AyS0WYUtf6Afaav+lT+ FL+OU39VTJAeQ0zwVrH9JZr3Oy8mIl9mhAEPUsX4NxLw8P7QTdCHO84NmkrzpoM9 l9GEOkBoNTIE5YaM9IezKhMKJv/CyPXkRnx3UBAblgTaBkV0gqkoePPn4sVa0Arh 3Vn6H6AV6oQpC8WtH8yCxBuLXkddiVHFi3zbuM+3MHgFTb+8f/UwTopGUjsZOPoN z00rwFO+jVjdrm2700i1j1bTYGInIe3pIctwfutQfglIQSFK3nQADFYdlhfBLBJM H0NDCYF1z/LKtAWSycWpRhpqU2+25mX6Fldrfp1YhrSiJCrUQYOgQNXRSa32nY1T 5gc71UAe9rQNDRo5deSmOunKXWY5s6tZdxn7Q22FBFWwfrGmCqhR6mrB2dgEBvl8 isjoGxZO1iJYhlTvq7WyxOdnbjR4BLBF0eE8KB2S2F6srb/luPfCG6F9Ier5fYl7 N/NvH5FSeJHC1r2EWw+yy5bjaG5GkX6NP1+FBfw7prKtUNx48x8tpdy11FlULkCN J+zid9ySJBsnMRNL5p/egYbYGaptLGO8yAuKN3s3znaG/f9kh39u+xI1Fo9KFVBd +NvQYaMNYMgTi4qyCaMeCGxUUlJLN/WnjclJyl/ca84sUhpLXRI= =3v1i -----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

[PATCH] Allow the gpg2 binary name to be overridden by the environment.
by Matthew Donadio July 1, 2019

July 1, 2019

On some platforms, the gpg2 binary isn't actually called 'gpg2'; on OSX when you install GPG view Homebrew, it is just 'gpg'. This probably affects about three people on the planet, but noticed it when working on build scripts. --Matthew Donadio (matt(a)mxd120.com)

2 1

[PATCH] Revert Hong Kong 1952 fall-back transition date to Nov 2 (inadvertently changed during recent Hong Kong fixes)
by Brad Arndt June 29, 2019

June 29, 2019

* asia: Revert Hong Kong 1952 fall-back transition from October 26 to November 2nd --- asia | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/asia b/asia index c9b362d..2182455 100644 --- a/asia +++ b/asia @@ -741,7 +741,8 @@ Rule HK 1946 only - Dec 1 3:30s 0 - Rule HK 1947 only - Apr 13 3:30s 1:00 S Rule HK 1947 only - Nov 30 3:30s 0 - Rule HK 1948 only - May 2 3:30s 1:00 S -Rule HK 1948 1952 - Oct Sun>=25 3:30s 0 - +Rule HK 1948 1951 - Oct Sun>=25 3:30s 0 - +Rule HK 1952 only - Nov 2 3:30s 0 - Rule HK 1949 1953 - Apr Sun>=1 3:30 1:00 S Rule HK 1953 1964 - Oct Sun>=31 3:30 0 - Rule HK 1954 1964 - Mar Sun>=18 3:30 1:00 S -- 2.17.0.windows.1

3 2

compiling backzone file with zic - How to?
by Alois Treindl June 28, 2019

June 28, 2019

I am trying to compile the zonefiles with zic, and I want to include the backzone file. I expect that zoneinfo/Africa/Mbabane comes out differently from zoneinfo/Africa/Johannesburg because in backzone there is # Eswatini (formerly Swaziland) Zone Africa/Mbabane 2:04:24 - LMT 1903 Mar 2:00 - SAST (Swaziland did not observe South African DST in 1942-1944 and I want to see that respected in the binary zonefile Africa/Mbabane) while in file africa there is: # South Africa # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SA 1942 1943 - Sep Sun>=15 2:00 1:00 - Rule SA 1943 1944 - Mar Sun>=15 2:00 0 - Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 1:30 - SAST 1903 Mar 2:00 SA SAST Link Africa/Johannesburg Africa/Mbabane # Eswatini I use the command: ./zic -d ./tzdata/etc/zoneinfo africa antarctica asia australasia backward backzone etcetera europe factory northamerica pacificnew southamerica systemv and expect the information in 'backzone' to override the information in 'africa'. But it does not. These two files are generated but are binary identical. zoneinfo/Africa/Mbabane zoneinfo/Africa/Johannesburg What is the correct command line for zic so that information in backzone is considered? I have tried putting backzone at he begin or end of the list of files, but that made no difference in the binary output.

2 1

Re: [tz] Timezone in Autonomous Republic of Crimea and spelling of Kyiv
by Sergij Marchenko June 28, 2019

June 28, 2019

Thank you, Mr. Paul Eggert! -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

1 0

Summer Time Brazil 2019 - Information
by Walmir Tadeu Satyro June 27, 2019

June 27, 2019

Good Afternoon, I need to know if there is an update of TzUpdater for the Brazil region in 2019. Today we need to validate if there is or was something specific to update here in Brazil. We understand that this is usually time consuming ... It is a question of updating the product and in it is contemplated specific rules for each region not only Brazil As we did not have defined summer schedules there were no corrections issued by IANA regularly, they are valid internationally since it is the Java product. To check if there is a most recent Brazil update in case of summer time 2019 Best regards. [Ass_Everis_WTS] Esta mensagem, incluindo seus anexos, pode conter informa??es privilegiadas e/ou de car?ter confidencial, n?o podendo ser retransmitida sem autoriza??o do remetente. Se voc? n?o ? o destinat?rio ou pessoa autorizada para receb?-la, informamos que o seu uso, divulga??o, c?pia ou arquivamento s?o proibidos. Portanto, se voc? recebeu esta mensagem por engano, por favor nos informe respondendo imediatamente a este e-mail e delete o seu conte?do. This message, including its attachments, may contain privileged or confidential information, and it must not be fowarded without the express authorization of the sender. If you are not the intended recipient, we hereby inform you that the use, disclosure, copy or filing are forbidden. So, if you received this message as a mistake, please inform us by answering this e-mail and deleting its contents Questo messaggio, inclusi gli allegati, potrebbe contenere informazioni privilegiate e/o riservate, e non deve essere ritrasmesse senza l'autorizzazione del mittente. Se non siete il destinatario o la persona autorizzata a riceverlo, informiamo che il suo utilizzo, diffusione, copia o archiviazione sono proibite. Quindi, se avete ricevuto questo messaggio per errore, per cortesia ci informi rispondendo immediatamente a questa email e cancelli il suo contenuto

2 1

I: Brazil Won't Change Clocks in 2019
by DONATELLA SABELLICO June 27, 2019

June 27, 2019

Hi, we got We got this advice.. https://www.timeanddate.com/news/time/brazil-scraps-dst.html the latest 2019A iana table reports Rule Brazil 2018 max - Nov Sun>=1 0:00 1:00 - So we need a new level.. Do you know when the Timezone package will be released' thanks Da: DONATELLA SABELLICO Inviato: lunedì 27 maggio 2019 11:20 A: eggert(a)cs.ucla.edu Cc: Anawesha Khuntia <AnaweshaK(a)in.ibm.com>; Java Timezone Utility Support <JTZU(a)uk.ibm.com>; Sbriccoli's L3 only <sbriccolisl3only(a)hcl.com>; SILVANO LUTRI <silvano.lutri(a)hcl.com> Oggetto: Brazil Won't Change Clocks in 2019 Priorità: Alta Hi Paul sorry to disturb but.. We got this advice.. https://www.timeanddate.com/news/time/brazil-scraps-dst.html We are using Iana 2019A table. Basing on that it seems NO Nov 2019 changes are into them...but when the new IAN Dst olson will be released? Thanks. Da: DONATELLA SABELLICO Inviato: lunedì 8 ottobre 2018 17:39 A: Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>>; ALESSIO FIORAVANTI <alessio.fioravanti(a)hcl.com<mailto:alessio.fioravanti@hcl.com>> Cc: Anawesha Khuntia <AnaweshaK(a)in.ibm.com<mailto:AnaweshaK@in.ibm.com>>; Java Timezone Utility Support <JTZU(a)uk.ibm.com<mailto:JTZU@uk.ibm.com>>; Sbriccoli's L3 only <sbriccolisl3only(a)hcl.com<mailto:sbriccolisl3only@hcl.com>> Oggetto: Re: R: DST rBrazil 2018 changed again to Nov 18th ..When DST Olson table will be released? Hi jtuz is not our tool. We owned tws product. Well at this time we need to wait official approval from Brazil president. Thanks ________________________________ Da: Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Inviato: lunedì 8 ottobre 2018 17:25:46 A: DONATELLA SABELLICO; ALESSIO FIORAVANTI Cc: Anawesha Khuntia; Java Timezone Utility Support; Sbriccoli's L3 only Oggetto: Re: R: DST rBrazil 2018 changed again to Nov 18th ..When DST Olson table will be released? On 10/8/18 8:15 AM, DONATELLA SABELLICO wrote: > WAS/Java that means that we need also that JTUZ tool is refreshed with the new tables... > > So even if we update our packages with these "developer" dst olson table ... the Jtuz table will be not ....so the Jtuz tool will still not be updated. You can update the Java tables from whatever data you like. See: https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.orac… ::DISCLAIMER:: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

35 150

Minor clerical fixes
by Tim Parenti June 27, 2019

June 27, 2019

Mostly grammar and consistency around areas that have changed recently. See attached. -- Tim Parenti

2 1

Petition to abolish local time in Sommarøy, Norway
by Paul Eggert June 26, 2019

June 26, 2019

On Thursday, Kjell Ove Hveding, who lives in Sommarøy, Norway (latitude 70°N, population 321), formally petitioned his parliamentarian to abolish civil time in the town. Assuming this becomes law and common practice (which does not appear likely), I suppose we'd need to create a new entry for the region of Norway that switches to having no civil time whatsoever. (The tzdb convention for this is UTC with the abbreviation "-00".) The Gizmodo story about this quotes Hveding as saying: "You have to go to work, and even after work, the clock takes up your time. I have to do this, I have to do that. My experience is that [people] have forgotten how to be impulsive, to decide that the weather is good, the Sun is shining, I can just live." See: Mandelbaum RF. A Norwegian city wants to abolish time. Gizmodo. 2019-06-14 16:55 -04. https://gizmodo.com/a-norwegian-city-wants-to-get-rid-of-clocks-1835526377

6 7

Precise meaning of AT 25:00
by Stephen Colebourne June 26, 2019

June 26, 2019

The Tokyo rule now includes the value 25:00 in the AT column. Can someone confirm the exact meaning of the 25:00? Is it a) an extended local time-of-day b) the actual duration from midnight at the start of day While similar, there would be a difference between the two definitions if there was a second DST gap/overlap earlier in the day. eg. imagine the case where DST starts at 13:00 (with a gap to 14:00) and ends at 26:00. With (a) the AT column would hold 26:00, while with (b) the AT column would hold 25:00 I'm pretty sure it is (a), but wanted to double check before it gets baked into APIs Stephen

2 1

*Off top* A little respect ...
by Chris Woodbury June 26, 2019

June 26, 2019

On Tue Jun 25 13:34:37 UTC 2019, Sergij Marchenko makars at gmail.com wrote: > > What is the time zone here? This is not interesting to anyone. Actually, I disagree, that is *EXACTLY* what this list is about. It is a *technical list about timezones* and the IANA TZ software. Generally, I/we would rather politics did not rear its ugly head. However, there is a constant trickle of folks *WHO MISS THIS POINT ENTIRELY*. > The question is, to which country belongs the territory occupied by Putin Huilo. To you; perhaps. To this list, probably not. *County codes* kept by the TZ database are a secondary aspect of the zone. (Again: *NOT A LEGAL DOCUMENT*.) TZ keeps the country code only as a non-authoritative aspect of the data. Specifically, "the CC normally identifies the administrative hierarchy that currently effectively determines the the civil time". Again, we're talking about "reality on the ground". (Though Dr. Eggert did mention AQ (Antarctica) and Crimea being exceptions.) "zone.tab", one of the files listing CCs, explicitly states: 19: This table is intended as an aid for users to help them select timezones 20: appropriate for their practical needs. It is not intended to take or 21: endorse any position on legal or territorial claims. "zone1970.tab", the other file, says exactly the same thing starting on line 30. Both files explicitly refer to this disclaimer for the Europe/Simferopol entry. Last but not least, currently the CCs of Europe/Simferopol in ".zone.tab" and "zone1970.tab" are "UA" and "RU,UA" respectively. These seem apropos to me.

1 0

Daylight saving and heart attacks
by Arthur David Olson June 26, 2019

June 26, 2019

Belatedly...brought to my attention by reading Matt Parker's "Humble Pi," the youtube video "Does daylight saving kill people?" from September, 2018. https://www.youtube.com/watch?v=XZGs5Im9f8Q @dashdashado

7 10

*Off topic* A little respect ...
by Chris Woodbury June 25, 2019

June 25, 2019

> On Sun Jun 23 08:57:16 UTC 2019 Sergij Marchenko makars at gmail.com wrote: > > You write very beautifully, but the fact remains that once the Russians > occupy the Crimea, you immediately made changes, pleasing Putin ... Yes, I suppose that might have pleased Putin (if he ever became aware of it if only by the fact that his cellular telephone showed the correct local time) but ... it wasn't done to please or displease him or his cronies (and the fifth columnists 'phones are right, too.) It was, as has been explained, to reflect the technical "reality on the ground". I'm sorry if that displeased you but it is what it is. Being obstreperous isn't going to change anything (except by further expanding the misery). Making us out to be tools of injustice doesn't make it so. Note that the *country codes* that came into question have been patched reasonably expeditiously by Dr. Eggert. TZ will reflect reality as best it can under the circumstances with or without anyone's complete satisfaction. I *am* certain that no one is happy about all the death, destruction and heart wrenching circumstances from what has come to pass. My thoughts and prayers are with all the people who find themselves in such unfortunate conditions. Were it only within my power to change them....

6 5

Jeopardy! category on time zones 2019-05-28
by Tim Parenti June 25, 2019

June 25, 2019

Apparently there is a category on time zones on the US version of *Jeopardy!* tonight (Tuesday 28 May). I'll avoid any spoilers for now — due to the vagaries of US broadcast syndication and, well, time zones — for anyone stateside who might be as captivated by the performance of the current champion, James Holzhauer, as my friends. I'll try to send over the clues tomorrow. -- Tim Parenti

1 1

Timezone in Autonomous Republic of Crimea and spelling of Kyiv
by Oleksandr Ryzhenko June 23, 2019

June 23, 2019

*Dear Mr. Paul Eggert,* By this letter let me as the representative of Ukraine to ICANN's GAC inform you about the following. The State Agency for e-Governance of Ukraine is the national authority of Ukraine that is responsible for matters related to Internet governance, including those within the purview of ICANN. We have discovered mistakes in the Time Zone Database. In particular, the time zones, country code and coordinates for the part of Ukrainian territory, namely the Autonomous Republic of Crimea, the city of Simferopol, and Sevastopol, are determined incorrectly. As far as we are aware, the Zone Europe/Simferopol was changed to MSK on the grounds of Russian Federation citizen appeal (Mr. Alexander Krivenyshev). The appeal was filed after *Russian military intervention in Autonomous Republic of Crimea followed by the illegal annexation of the sovereign territory of Ukraine.* We would request your immediate attention that change of this specified time zone is *a gross violation of the rules of international law*, namely: - United Nations General Assembly Resolution 68/262, adopted on March 27, 2014 by the sixty-eighth session of the United Nations General Assembly in response to the Russian annexation of Crimea, entitled "Territorial integrity of Ukraine"; - United Nations General Assembly Resolutions 71/205, 72/190, 73/263: Situation of human rights in the Autonomous Republic of Crimea and the city of Sevastopol (Ukraine); - United Nations General Assembly Resolution 73/194: Problem of the militarization of the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, as well as parts of the Black Sea and the Sea of Azov. Taking into account the above, we urge you to resolve this situation by determining *EU EE%sT time for Zone Europe/Simferopol* in Time Zone Database and identify* UA* as a country code for *Europe/Simferopol.* At the same time, we draw your attention to the decision of The United States Board on Geographic Names. *English spelling of Ukraine’s capital has changed from Kiev to Kyiv* (source: https://www.kyivpost.com/world/kyiv-not-kiev-us-changes-spelling-of-ukraini…) In this regard, we ask you to update the spelling of Kyiv in all existing databases of your organization. ---------------------------------------------- *Sincerely,Oleksandr RyzhenkoHead of the State Agency for e-Governance of UkraineRepresentative of Ukraine to ICANN’s GAC *

9 12

*Off topic* A little respect ...
by Chris Woodbury June 23, 2019

June 23, 2019

To Oleksandr Ryzhenko, et al, and whom so ever might be listening: Firstly, that's Dr. Paul R. Eggert, PhD 1980 UCLA. He has been voluntarily contributing his time to this (and other) projects (and education) for over thirty years. I, for one, respect and value his contributions (even when I momentarily forget to do so). Secondly, telling us (and him) that such and such is a violation of "*international law*" (as tho they were an authority and someone was going to be dragged off to the The Hague) is a threat and an inappropriate response to the supposed provocation. Making such is a clear indication that there is a certain lack of understanding of what's really going on. (As an aside and for what it's worth: I commiserate with those worrying about the whole Kiev/Kyiv thing. It's a huge "can of worms" and technical but it ain't going to happen! If it were "fixed" this one time, a precedent would be set and similar "problems" would have to be "fixed". It would be never ending. Theresult being *technically unnecessary* database "churn". The stance that some-thing like this are internal labels is an interesting solution to a "problem". Also, thinking of them as a thing imposed over the barrel of a gun and wanting to "fix it" *right now*, where others might not, is just going to raise ones blood pressure. It will be changed sometime. The language or transliteration will change over time, or there will be new generation of tzdb volunteer maintainers (hint, hint) or, possibly, our own version of Vasili Arkhipov* will come along and find a solution. Remember, sometimes a "problem" is merely a matter of perspective. (I was also raised to appreciate an excellent quibble when I see one.)) (Also, I might be wrong, but one might consider that treating the TZ database as if it were a legal document could be a mistake.) Lastly, I personally would appreciate it if the folks "who have a bone to pick" would spend the same amount of time they spend so carefully crafting their e-mails*going over the content of the archives* before they actually send them. It also might be helpful to *consult a subject matter expert* while composing, too. It might just save some time for all of us. * An underappreciated man who saved the world. -

2 1

[PATCH] Fix ‘make check’ problems caused by recent changes
by Paul Eggert June 22, 2019

June 22, 2019

* Makefile: Fix stray non-ASCII chars in comments. (check_sorted): Omit tests that duplicate what checktab.awk does. Discovered when debugging checktab.awk. * checktab.awk: Don’t complain about special case for Crimea. --- Makefile | 10 ++-------- checktab.awk | 9 ++++++++- 2 files changed, 10 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index d305f68..6816d3b 100644 --- a/Makefile +++ b/Makefile @@ -36,7 +36,7 @@ DATAFORM= main LOCALTIME= GMT # The POSIXRULES macro controls interpretation of nonstandard and obsolete -# POSIX-like TZ settings like TZ=’EET-2EEST’ that lack DST transition rules. +# POSIX-like TZ settings like TZ='EET-2EEST' that lack DST transition rules. # In the reference implementation, if you want something other than Eastern # United States time as a template for handling these settings, you can # change the line below (after finding the timezone you want in the @@ -58,7 +58,7 @@ LOCALTIME= GMT # Nonempty POSIXRULES is obsolete and should not be relied on, because: # * It does not work correctly in popular implementations such as GNU/Linux. # * It does not work in the tzdb implementation for timestamps after 2037. -# * It is incompatible with ’zic -b slim’ if POSIXRULES specifies transitions +# * It is incompatible with 'zic -b slim' if POSIXRULES specifies transitions # at standard time or UT rather than at local time. # In short, software should avoid ruleless settings like TZ='EET-2EEST' # and so should not depend on the value of POSIXRULES. @@ -805,12 +805,6 @@ CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } check_sorted: backward backzone iso3166.tab zone.tab zone1970.tab $(AWK) '/^Link/ {print $$3}' backward | LC_ALL=C sort -cu $(AWK) '/^Zone/ {print $$2}' backzone | LC_ALL=C sort -cu - $(AWK) '/^[^#]/ {print $$1}' iso3166.tab | LC_ALL=C sort -cu - $(AWK) '/^[^#]/ {print $$1}' zone.tab | LC_ALL=C sort -c - $(AWK) '/^[^#]/ {print substr($$0, 1, 2)}' zone1970.tab | \ - LC_ALL=C sort -c - $(AWK) '/^[^#]/ $(CHECK_CC_LIST)' zone1970.tab | \ - LC_ALL=C sort -cu touch $@ check_links: checklinks.awk $(TDATA_TO_CHECK) tzdata.zi diff --git a/checktab.awk b/checktab.awk index 393ab19..ec145b5 100644 --- a/checktab.awk +++ b/checktab.awk @@ -63,12 +63,19 @@ BEGIN { coordinates = $2 tz = $3 comments = $4 - if (cc < cc0) { + + # Don't complain about a special case for Crimea in zone.tab. + # FIXME: zone.tab should be removed, since it is obsolete. + # Or at least put just "XX" in its country-code column. + if (cc < cc0 \ + && !(zone_table == "zone.tab" \ + && tz0 == "Europe/Simferopol")) { printf "%s:%d: country code '%s' is out of order\n", \ zone_table, zone_NR, cc >>"/dev/stderr" status = 1 } cc0 = cc + tz0 = tz tztab[tz] = 1 tz2comments[tz] = comments tz2NR[tz] = zone_NR -- 2.21.0

1 0

Re: [tz] Crimean timezones
by Sergij Marchenko June 21, 2019

June 21, 2019

Dear Paul, By making such a proposal to Mr. Demediuk you are in fact taking sides despite your alleged neutrality. Russia's claims to Crimea are not supported by anyone but Russia itself, perhaps barring a negligible amount of countries that have their own governments largely criticized as undemocratic. The vast majority of countries have openly condemned the annexation and Russian aggression and continue to recognize Crimea as a Ukrainian territory it is. A solution, which is more consistent with your view, exists. The patch could instead make the interface display the timezones in question as Russian to Russian users alone, while in the rest of the world they would be listed as Ukrainian. This practice, although controversial in the face of the international law, is a lesser violation of it than the current state of matter. By keeping things the way they are now you are sending the world a message. The message is that you are endorsing the aggressor, even though it may not appear to you as such. With a leaden heart we would accept the territory being assigned to different countries depending on a user's geolocation, provided that RU only shows up for Russian users and UA is the default configuration elsewhere, globally. Otherwise we would kindly ask you to drop the neutrality claims and make your open endorsement of Russian military aggression against Ukraine transparent. Kind regards. -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

3 2

Re: [tz] Crimean timezones
by Sergij Marchenko June 21, 2019

June 21, 2019

I'm using Fedora release 30 (Thirty) 5.1.11-300.fc30.x86_64 Here is a screenshot in the Gnome-3 environment: http://makar.homelinux.net/ftp/pub/exchange/20190621/Screenshot_20190620_14… When selecting the city Simferopol highlights the Russian Federation (and in fact, correctly - Ukraine) Here is a screenshot in KDE: http://makar.homelinux.net/ftp/pub/exchange/20190621/Screenshot_20190620_21… When choosing a city, Simferopol highlights Europe / Russia (and in fact, rightly, Europe / Ukraine) -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

1 0

Timezone in Autonomous Republic of Crimea and spelling of Kyiv
by Oleksandr Ryzhenko June 21, 2019

June 21, 2019

*Dear Mr. Paul Eggert,* By this letter let me as the representative of Ukraine to ICANN's GAC inform you about the following. The State Agency for e-Governance of Ukraine is the national authority of Ukraine that is responsible for matters related to Internet governance, including those within the purview of ICANN. We have discovered mistakes in the Time Zone Database. In particular, the time zones, country code and coordinates for the part of Ukrainian territory, namely the Autonomous Republic of Crimea, the city of Simferopol, and Sevastopol, are determined incorrectly. As far as we are aware, the Zone Europe/Simferopol was changed to MSK on the grounds of Russian Federation citizen appeal (Mr. Alexander Krivenyshev). The appeal was filed after Russian military intervention in Autonomous Republic of Crimea followed by the illegal annexation of the sovereign territory of Ukraine. We would request your immediate attention that change of this specified time zone is a gross *violation of the rules of international law*, namely: - United Nations General Assembly Resolution 68/262, adopted on March 27, 2014 by the sixty-eighth session of the United Nations General Assembly in response to the Russian annexation of Crimea, entitled "Territorial integrity of Ukraine"; - United Nations General Assembly Resolutions 71/205, 72/190, 73/263: Situation of human rights in the Autonomous Republic of Crimea and the city of Sevastopol (Ukraine); - United Nations General Assembly Resolution 73/194: Problem of the militarization of the Autonomous Republic of Crimea and the city of Sevastopol, Ukraine, as well as parts of the Black Sea and the Sea of Azov. Taking into account the above, we urge you to resolve this situation by determining *EU EE%sT *time for *Zone Europe/Simferopol *in Time Zone Database and identify *UA* as a country code for* Europe/Simferopol.* At the same time, we draw your attention to the decision of The United States Board on Geographic Names. *English spelling of Ukraine’s capital has changed* from Kiev to *Kyiv* (source: https://www.kyivpost.com/world/kyiv-not-kiev-us-changes-spelling-of-ukraini…) In this regard, we ask you to update the spelling of Kyiv in all existing databases of your organization. ---------------------------------------------- *Sincerely,Oleksandr RyzhenkoHead of the State Agency for e-Governance of UkraineRepresentative of Ukraine to ICANN’s GAC*

1 0

Crimean timezones
by Sergij Marchenko June 20, 2019

June 20, 2019

Dear Mr. Eggert, I am reaching out to you as to the IESG-designated TZ Coordinator, as you are listed here: https://www.iana.org/time-zones Let me preface my letter with assuring you that I am reaching out in good will. I live in Ukraine. As a longtime Linux user, I was disappointed to notice that in my timezone settings that one of Simferopol is being assigned to the Russian Federation. Apparently, my preferred desktop environment, along with several others, pulls this data from the project you maintain. The statement that Simferopol (or Sevastopol, or any other Crimean city, for that matter) is situated in Russia contradicts the official stance of the United States, Canada, the counties of the European Union, and many others. Suffice it to say, the international community never recognized Russia's claims to Crimea as valid and the so-called "referendum" as legally binding. The Unites States of America was also a signatory of the Budapest Memorandum on Security Assurances, which guarantees the territorial intergity of Ukraine. Let me add that the annexation of the Crimean peninsula in 2014 was only the first step of the Russian aggression against my country. The war in Donbas led by Russia is still ongoing and has costed dozens of thousands of Ukrainians their lives. As of 2016, the International Criminal Court officially recognized the war in Donbas as Russia's invasion of Ukraine. Russia and its allies has also put a lot of effort in spreading misinformation about the conflict, attempting to portray Ukraine as a far-right state and the Euromaidan protests as a coup. As an eyewitness to these events, I can assure you that it can not be further from truth, and, should you be interested, I can provide multiple sources that debunk this propaganda. Therefore, I humbly ask you to research this delicate matter. Once you have confirmed that pro-Russian sources are completely misinterpreting their far-from-innocuous role in the tragedy that shattered numerous families in my country, I hope that you will consider submitting corrections to your project and list all Crimean cities and respective timezones as Ukrainian. This would assure its compliance to the international standards, from both legal and moral viewpoint. I remain open to dialogue and would gladly answer any further questions you may happen to have. Looking forward to hearing from you, -- Best regards, Sergij Marchenko mailto:makars@gmail.com http://makar.homelinux.net Skype: makarsoft Viber/WhatsApp/Telegram/Signal: +380661877234

2 1

[PROPOSED 1/5] * tzfile.5: Typeset ‘-’ more carefully.
by Paul Eggert June 18, 2019

June 18, 2019

--- tzfile.5 | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index d13029c..69f8860 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -119,13 +119,13 @@ that follow the structure(s) in the file. The .I tt_utoff -value is never equal to -2**31, to let 32-bit clients negate it without +value is never equal to \-2**31, to let 32-bit clients negate it without overflow. Also, in realistic applications .I tt_utoff -is in the range [-89999, 93599] (i.e., more than -25 hours and less +is in the range [\-89999, 93599] (i.e., more than \-25 hours and less than 26 hours); this allows easy support by implementations that -already support the POSIX-required range [-24:59:59, 25:59:59]. +already support the POSIX-required range [\-24:59:59, 25:59:59]. .IP * .I tzh_leapcnt pairs of four-byte values, written in network byte order; @@ -204,7 +204,7 @@ For version-3-format timezone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in .BR newtzset (3). First, the hours part of its transition times may be signed and range from -\*-167 through 167 instead of the POSIX-required unsigned values +\-167 through 167 instead of the POSIX-required unsigned values from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference @@ -239,7 +239,7 @@ in the version 1 data block to save space. Time zone designations should consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, -.q "-", +.q "\*-", and .q "+". This is for compatibility with POSIX requirements for @@ -298,11 +298,11 @@ mishandled by version 2 readers. Some readers designed for version 2 do not support permanent daylight saving time, e.g., a TZ string .q "EST5EDT,0/0,J365/25" -denoting permanent Eastern Daylight Time (\*-04). +denoting permanent Eastern Daylight Time (\-04). As a partial workaround, a writer can substitute standard time for the next time zone east, e.g., .q "AST4" -for permanent Atlantic Standard Time (\*-04). +for permanent Atlantic Standard Time (\-04). .IP * Some readers ignore the footer, and instead predict future timestamps from the time type of the last transition. @@ -316,17 +316,17 @@ As a partial workaround, a writer can output a dummy (no-op) first transition at an early time. .IP * Some readers mishandle timestamps before the first -transition that has a timestamp not less than -2**31. +transition that has a timestamp not less than \-2**31. Readers that support only 32-bit timestamps are likely to be more prone to this problem, for example, when they process 64-bit transitions only some of which are representable in 32 bits. As a partial workaround, a writer can output a dummy -transition at timestamp \*-2**31. +transition at timestamp \-2**31. .IP * Some readers mishandle a transition if its timestamp has the minimum possible signed 64-bit value. -Timestamps less than \*-2**59 are not recommended. +Timestamps less than \-2**59 are not recommended. .IP * Some readers mishandle POSIX-style TZ strings that contain @@ -347,7 +347,7 @@ These characters are not recommended. Some readers may mishandle time zone abbreviations that contain fewer than 3 or more than 6 characters, or that contain ASCII characters other than alphanumerics, -.q "-", +.q "\*-", and .q "+". These abbreviations are not recommended. @@ -381,18 +381,18 @@ Readers that do not support negative timestamps are likely to be more prone to this problem. .IP * Some readers mishandle time zone abbreviations like -.q "-08" +.q "\*-08" that contain .q "+", -.q "-", +.q "\*-", or digits. .IP * Some readers mishandle UT offsets that are out of the -traditional range of \*-12 through +12 hours, and so do not +traditional range of \-12 through +12 hours, and so do not support locations like Kiritimati that are outside this range. .IP * -Some readers mishandle UT offsets in the range [\*-3599, \*-1] +Some readers mishandle UT offsets in the range [\-3599, \-1] seconds from UT, because they integer-divide the offset by 3600 to get 0 and then display the hour part as .q "+00". -- 2.21.0

1 4

[PROPOSED] Rename internal identifiers to match RFC 8536
by Paul Eggert June 18, 2019

June 18, 2019

Internet RFC 8536 uses names that differ a bit from the names historically used in tzdb. The RFC uses "utoff" instead of "gmtoff" for UT (GMT) offsets, and "desigidx" instead of "abbrind" for designator (abbreviation) indexes. Going forward it’s better to stick with the RFC terminology in internal identifiers. This change does not affect longstanding and standard APIs such as the tm_gmtoff member of struct tm or the string "gmtoff" in zdump output. * africa, antarctica, asia, australasia, backzone, europe, factory: * northamerica, pacificnew, southamerica, systemv, tz-how-to.html: * tzfile.5, zoneinfo2tdf.pl: Use UTOFF instead of GMTOFF in comments. * localtime.c (struct ttinfo): Rename tt_gmtoff to tt_utoff, tt_abbrind to tt_desigidx, tt_isgmt to tt_ttisut. * localtime.c (init_ttinfo, tzloadbody): Rename locals for consistency. * tzfile.h (struct tzhead): Rename tzh_ttisgmtcnt to tzh_ttisutcnt. * zic.c (struct rule): Rename r_todisgmt to r_todisut. (struct zone): Rename z_gmtoff to z_utoff. (ZF_UTOFF): Renamed from ZF_GMTOFF. (ZFC_UTOFF): Renamed from ZFC_GMTOFF. (utoffs): Renamed from gmtoffs. (desigidx): Renamed from abbrinds. (ttisuts): Renamed from ttisgmts. (inzsub, stringrule, outzone, addtype): Rename locals for consistency. --- africa | 42 ++++++------ antarctica | 14 ++-- asia | 90 ++++++++++++------------ australasia | 60 ++++++++-------- backzone | 2 +- europe | 80 +++++++++++----------- factory | 2 +- localtime.c | 91 +++++++++++++------------ northamerica | 100 +++++++++++++-------------- pacificnew | 2 +- southamerica | 34 +++++----- systemv | 2 +- tz-how-to.html | 12 ++-- tzfile.5 | 16 ++--- tzfile.h | 4 +- zic.c | 177 +++++++++++++++++++++++------------------------- zoneinfo2tdf.pl | 2 +- 17 files changed, 363 insertions(+), 367 deletions(-) diff --git a/africa b/africa index 07ef15d..068677d 100644 --- a/africa +++ b/africa @@ -89,7 +89,7 @@ Rule Algeria 1980 only - Apr 25 0:00 1:00 S Rule Algeria 1980 only - Oct 31 2:00 0 - # Shanks & Pottenger give 0:09:20 for Paris Mean Time; go with Howse's # more precise 0:09:21. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time 0:00 Algeria WE%sT 1940 Feb 25 2:00 @@ -124,7 +124,7 @@ Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 # For now, ignore that and follow the 1911-05-26 Portuguese decree # (see Europe/Lisbon). # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Atlantic/Cape_Verde -1:34:04 - LMT 1912 Jan 01 2:00u # Praia -2:00 - -02 1942 Sep -2:00 1:00 -01 1945 Oct 15 @@ -135,7 +135,7 @@ Zone Atlantic/Cape_Verde -1:34:04 - LMT 1912 Jan 01 2:00u # Praia # See Africa/Lagos. # Chad -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena 1:00 - WAT 1979 Oct 14 1:00 1:00 WAST 1980 Mar 8 @@ -151,7 +151,7 @@ Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena # See Africa/Lagos. # Côte d'Ivoire / Ivory Coast -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Abidjan -0:16:08 - LMT 1912 0:00 - GMT Link Africa/Abidjan Africa/Bamako # Mali @@ -356,7 +356,7 @@ Rule Egypt 2014 only - Jun 26 24:00 0 - Rule Egypt 2014 only - Jul 31 24:00 1:00 S Rule Egypt 2014 only - Sep lastThu 24:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Cairo 2:05:09 - LMT 1900 Oct 2:00 Egypt EE%sT @@ -414,7 +414,7 @@ Zone Africa/Cairo 2:05:09 - LMT 1900 Oct # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Ghana 1920 1942 - Sep 1 0:00 0:20 - Rule Ghana 1920 1942 - Dec 31 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Accra -0:00:52 - LMT 1918 0:00 Ghana GMT/+0020 @@ -428,13 +428,13 @@ Zone Africa/Accra -0:00:52 - LMT 1918 # evidently confusing the date of the Portuguese decree # (see Europe/Lisbon) with the date that it took effect. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Bissau -1:02:20 - LMT 1912 Jan 1 1:00u -1:00 - -01 1975 0:00 - GMT # Kenya -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Nairobi 2:27:16 - LMT 1928 Jul 3:00 - EAT 1930 2:30 - +0230 1940 @@ -469,7 +469,7 @@ Link Africa/Nairobi Indian/Mayotte # Use the abbreviation "MMT" before 1972, as the more-accurate numeric # abbreviation "-004430" would be one byte over the POSIX limit. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Monrovia -0:43:08 - LMT 1882 -0:43:08 - MMT 1919 Mar # Monrovia Mean Time -0:44:30 - MMT 1972 Jan 7 # approximately MMT @@ -519,7 +519,7 @@ Rule Libya 1997 only - Apr 4 0:00 1:00 S Rule Libya 1997 only - Oct 4 0:00 0 - Rule Libya 2013 only - Mar lastFri 1:00 1:00 S Rule Libya 2013 only - Oct lastFri 2:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Tripoli 0:52:44 - LMT 1920 1:00 Libya CE%sT 1959 2:00 - EET 1982 @@ -629,7 +629,7 @@ Rule Mauritius 1982 only - Oct 10 0:00 1:00 - Rule Mauritius 1983 only - Mar 21 0:00 0 - Rule Mauritius 2008 only - Oct lastSun 2:00 1:00 - Rule Mauritius 2009 only - Mar lastSun 2:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis 4:00 Mauritius +04/+05 # Agalega Is, Rodriguez @@ -1083,7 +1083,7 @@ Rule Morocco 2087 only - May 4 2:00 0 - # need to be extended, though quite possibly Morocco will change the # rules first. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco +00/+01 1984 Mar 16 1:00 - +01 1986 @@ -1113,7 +1113,7 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf # merely made it official? # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Maputo 2:10:20 - LMT 1903 Mar 2:00 - CAT Link Africa/Maputo Africa/Blantyre # Malawi @@ -1185,7 +1185,7 @@ Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 WAT #Rule Namibia 1995 2017 - Apr Sun>=1 2:00 0 WAT # End of rearguard section. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - +0130 1903 Mar 2:00 - SAST 1942 Sep 20 2:00 @@ -1206,7 +1206,7 @@ Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 # See Africa/Lagos. # Nigeria -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Lagos 0:13:36 - LMT 1919 Sep 1:00 - WAT Link Africa/Lagos Africa/Bangui # Central African Republic @@ -1220,7 +1220,7 @@ Link Africa/Lagos Africa/Niamey # Niger Link Africa/Lagos Africa/Porto-Novo # Benin # Réunion -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Reunion 3:41:52 - LMT 1911 Jun # Saint-Denis 4:00 - +04 # @@ -1280,7 +1280,7 @@ Zone Africa/Sao_Tome 0:26:56 - LMT 1884 # See Africa/Abidjan. # Seychelles -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Mahe 3:41:48 - LMT 1906 Jun # Victoria 4:00 - +04 # From Paul Eggert (2001-05-30): @@ -1300,7 +1300,7 @@ Zone Indian/Mahe 3:41:48 - LMT 1906 Jun # Victoria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SA 1942 1943 - Sep Sun>=15 2:00 1:00 - Rule SA 1943 1944 - Mar Sun>=15 2:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 1:30 - SAST 1903 Mar 2:00 SA SAST @@ -1335,14 +1335,14 @@ Rule Sudan 1970 only - May 1 0:00 1:00 S Rule Sudan 1970 1985 - Oct 15 0:00 0 - Rule Sudan 1971 only - Apr 30 0:00 1:00 S Rule Sudan 1972 1985 - Apr lastSun 0:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Khartoum 2:10:08 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT 2017 Nov 1 2:00 - CAT # South Sudan -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Juba 2:06:28 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT @@ -1448,7 +1448,7 @@ Rule Tunisia 2006 2008 - Oct lastSun 2:00s 0 - # Shanks & Pottenger give 0:09:20 for Paris Mean Time; go with Howse's # more precise 0:09:21. # Shanks & Pottenger say the 1911 switch was on Mar 9; go with Howse's Mar 11. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Africa/Tunis 0:40:44 - LMT 1881 May 12 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time 1:00 Tunisia CE%sT diff --git a/antarctica b/antarctica index 1dd9b00..edb74f3 100644 --- a/antarctica +++ b/antarctica @@ -13,7 +13,7 @@ # for information. # Unless otherwise specified, we have no time zone information. -# FORMAT is '-00' and GMTOFF is 0 for locations while uninhabited. +# FORMAT is '-00' and UTOFF is 0 for locations while uninhabited. # Argentina - year-round bases # Belgrano II, Confin Coast, -770227-0343737, since 1972-02-05 @@ -70,7 +70,7 @@ # Australian Antarctica Division informed us that Casey changed time # zone to UTC+11 in "the morning of 22nd October 2016". -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/Casey 0 - -00 1969 8:00 - +08 2009 Oct 18 2:00 11:00 - +11 2010 Mar 5 2:00 @@ -142,7 +142,7 @@ Zone Antarctica/Mawson 0 - -00 1954 Feb 13 # St Paul Island - near Amsterdam, uninhabited # fishing stations operated variously 1819/1931 # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Kerguelen 0 - -00 1950 # Port-aux-Français 5:00 - +05 # @@ -153,7 +153,7 @@ Zone Indian/Kerguelen 0 - -00 1950 # Port-aux-Français # Another base at Port-Martin, 50km east, began operation in 1947. # It was destroyed by fire on 1952-01-14. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/DumontDUrville 0 - -00 1947 10:00 - +10 1952 Jan 14 0 - -00 1956 Nov @@ -181,7 +181,7 @@ Zone Antarctica/DumontDUrville 0 - -00 1947 # Syowa station, which is the first antarctic station of Japan, # was established on 1957-01-29. Since Syowa station is still the main # station of Japan, it's appropriate for the principal location. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/Syowa 0 - -00 1957 Jan 29 3:00 - +03 # See: @@ -231,7 +231,7 @@ Rule Troll 2005 max - Mar lastSun 1:00u 2:00 +02 #Rule Troll 2004 max - Nov 7 1:00u 0:00 +00 # Remove the following line when uncommenting the above '#Rule' lines. Rule Troll 2004 max - Oct lastSun 1:00u 0:00 +00 -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/Troll 0 - -00 2005 Feb 12 0:00 Troll %s @@ -305,7 +305,7 @@ Zone Antarctica/Vostok 0 - -00 1957 Dec 16 # From Paul Eggert (2002-10-22) # <http://webexhibits.org/daylightsaving/g.html> says Rothera is -03 all year. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/Rothera 0 - -00 1976 Dec 1 -3:00 - -03 diff --git a/asia b/asia index e64f0c4..dee9405 100644 --- a/asia +++ b/asia @@ -84,7 +84,7 @@ Rule RussiaAsia 1985 2010 - Mar lastSun 2:00s 1:00 - Rule RussiaAsia 1996 2010 - Oct lastSun 2:00s 0 - # Afghanistan -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Kabul 4:36:48 - LMT 1890 4:00 - +04 1945 4:30 - +0430 @@ -117,7 +117,7 @@ Zone Asia/Kabul 4:36:48 - LMT 1890 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Armenia 2011 only - Mar lastSun 2:00s 1:00 - Rule Armenia 2011 only - Oct lastSun 2:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Yerevan 2:58:00 - LMT 1924 May 2 3:00 - +03 1957 Mar 4:00 RussiaAsia +04/+05 1991 Mar 31 2:00s @@ -143,7 +143,7 @@ Zone Asia/Yerevan 2:58:00 - LMT 1924 May 2 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Azer 1997 2015 - Mar lastSun 4:00 1:00 - Rule Azer 1997 2015 - Oct lastSun 5:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Baku 3:19:24 - LMT 1924 May 2 3:00 - +03 1957 Mar 4:00 RussiaAsia +04/+05 1991 Mar 31 2:00s @@ -231,7 +231,7 @@ Zone Asia/Baku 3:19:24 - LMT 1924 May 2 Rule Dhaka 2009 only - Jun 19 23:00 1:00 - Rule Dhaka 2009 only - Dec 31 24:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Dhaka 6:01:40 - LMT 1890 5:53:20 - HMT 1941 Oct # Howrah Mean Time? 6:30 - +0630 1942 May 15 @@ -241,7 +241,7 @@ Zone Asia/Dhaka 6:01:40 - LMT 1890 6:00 Dhaka +06/+07 # Bhutan -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Thimphu 5:58:36 - LMT 1947 Aug 15 # or Thimbu 5:30 - +0530 1987 Oct 6:00 - +06 @@ -252,13 +252,13 @@ Zone Asia/Thimphu 5:58:36 - LMT 1947 Aug 15 # or Thimbu # We have no information as to when standard time was introduced; # assume it occurred in 1907, the same year as Mauritius (which # then contained the Chagos Archipelago). -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Chagos 4:49:40 - LMT 1907 5:00 - +05 1996 6:00 - +06 # Brunei -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Brunei 7:39:40 - LMT 1926 Mar # Bandar Seri Begawan 7:30 - +0730 1933 8:00 - +08 @@ -273,7 +273,7 @@ Zone Asia/Brunei 7:39:40 - LMT 1926 Mar # Bandar Seri Begawan # of Greenwich." This refers to the period before Burma's transition to +0630, # a transition for which Shanks is the only source. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Yangon 6:24:47 - LMT 1880 # or Rangoon 6:24:47 - RMT 1920 # Rangoon local time 6:30 - +0630 1942 May @@ -561,7 +561,7 @@ Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # that the sort of users who prefer Asia/Urumqi now typically ignored the # +08 mandate back then. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Beijing time, used throughout China; represented by Shanghai. Zone Asia/Shanghai 8:05:43 - LMT 1901 8:00 Shang C%sT 1949 May 28 @@ -750,7 +750,7 @@ Rule HK 1965 1976 - Oct Sun>=16 3:30 0 - Rule HK 1973 only - Dec 30 3:30 1:00 S Rule HK 1979 only - May 13 3:30 1:00 S Rule HK 1979 only - Oct 21 3:30 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Hong_Kong 7:36:42 - LMT 1904 Oct 30 0:36:42 8:00 - HKT 1941 Jun 15 3:00 8:00 1:00 HKST 1941 Oct 1 4:00 @@ -879,7 +879,7 @@ Rule Taiwan 1974 1975 - Oct 1 0:00 0 S Rule Taiwan 1979 only - Jul 1 0:00 1:00 D Rule Taiwan 1979 only - Oct 1 0:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Taipei or Taibei or T'ai-pei Zone Asia/Taipei 8:06:00 - LMT 1896 Jan 1 8:00 - CST 1937 Oct 1 @@ -1017,7 +1017,7 @@ Rule Macau 1975 1976 - Apr Sun>=16 03:30 1:00 D Rule Macau 1979 only - May 13 03:30 1:00 D Rule Macau 1979 only - Oct Sun>=16 03:30 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Macau 7:34:10 - LMT 1904 Oct 30 8:00 - CST 1941 Dec 21 23:00 9:00 Macau +09/+10 1945 Sep 30 24:00 @@ -1056,7 +1056,7 @@ Rule Cyprus 1977 only - Sep 25 0:00 0 - Rule Cyprus 1978 only - Oct 2 0:00 0 - Rule Cyprus 1979 1997 - Sep lastSun 0:00 0 - Rule Cyprus 1981 1998 - Mar lastSun 0:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT @@ -1105,7 +1105,7 @@ Link Asia/Nicosia Europe/Nicosia # Byalokoz 1919 says Georgia was 2:59:11. # Go with Byalokoz. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Tbilisi 2:59:11 - LMT 1880 2:59:11 - TBMT 1924 May 2 # Tbilisi Mean Time 3:00 - +03 1957 Mar @@ -1142,7 +1142,7 @@ Zone Asia/Tbilisi 2:59:11 - LMT 1880 # which will be permanent, with no seasonal adjustment, will happen at # midnight on Saturday, September 16. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Dili 8:22:20 - LMT 1912 Jan 1 8:00 - +08 1942 Feb 21 23:00 9:00 - +09 1976 May 3 @@ -1208,7 +1208,7 @@ Zone Asia/Dili 8:22:20 - LMT 1912 Jan 1 # time for 1870-1941. Shanks is our only (and dubious) source for the # 1941-1945 data. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Kolkata 5:53:28 - LMT 1854 Jun 28 # Kolkata 5:53:20 - HMT 1870 # Howrah Mean Time? 5:21:10 - MMT 1906 Jan 1 # Madras local time @@ -1260,7 +1260,7 @@ Zone Asia/Kolkata 5:53:28 - LMT 1854 Jun 28 # Kolkata # WITA - +08 - Waktu Indonesia Tengah (Indonesia central time) # WIT - +09 - Waktu Indonesia Timur (Indonesia eastern time) # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Java, Sumatra Zone Asia/Jakarta 7:07:12 - LMT 1867 Aug 10 # Shanks & Pottenger say the next transition was at 1924 Jan 1 0:13, @@ -1532,7 +1532,7 @@ Rule Iran 2087 only - Sep 21 24:00 0 - Rule Iran 2088 max - Mar 20 24:00 1:00 - Rule Iran 2088 max - Sep 20 24:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Tehran 3:25:44 - LMT 1916 3:25:44 - TMT 1946 # Tehran Mean Time 3:30 - +0330 1977 Nov @@ -1577,7 +1577,7 @@ Rule Iraq 1986 1990 - Mar lastSun 1:00s 1:00 - # Rule Iraq 1991 2007 - Apr 1 3:00s 1:00 - Rule Iraq 1991 2007 - Oct 1 3:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Baghdad 2:57:40 - LMT 1890 2:57:36 - BMT 1918 # Baghdad Mean Time? 3:00 - +03 1982 May @@ -1806,7 +1806,7 @@ Rule Zion 2012 only - Sep 23 2:00 0 S Rule Zion 2013 max - Mar Fri>=23 2:00 1:00 D Rule Zion 2013 max - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Jerusalem 2:20:54 - LMT 1880 2:20:40 - JMT 1918 # Jerusalem Mean Time? 2:00 Zion I%sT @@ -1898,7 +1898,7 @@ Rule Japan 1950 1951 - May Sat>=1 24:00 1:00 D # Central Time (UT+9). The adoption began on Oct 1, 1937. # https://ja.wikisource.org/wiki/明治二十八年勅令第百六十七號標準時ニ關スル件中改正ノ件 -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Tokyo 9:18:59 - LMT 1887 Dec 31 15:00u 9:00 Japan J%sT # Since 1938, all Japanese possessions have been like Asia/Tokyo, @@ -2001,7 +2001,7 @@ Rule Jordan 2006 2011 - Oct lastFri 0:00s 0 - Rule Jordan 2013 only - Dec 20 0:00 0 - Rule Jordan 2014 max - Mar lastThu 24:00 1:00 S Rule Jordan 2014 max - Oct lastFri 0:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Amman 2:23:44 - LMT 1931 2:00 Jordan EE%sT @@ -2198,7 +2198,7 @@ Zone Asia/Amman 2:23:44 - LMT 1931 # UTC+6 to UTC+5 effective December 21st, 2018. The legal document is # located here: http://adilet.zan.kz/rus/docs/P1800000817 (russian language). -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # # Almaty (formerly Alma-Ata), representing most locations in Kazakhstan # This includes KZ-AKM, KZ-ALA, KZ-ALM, KZ-AST, KZ-BAY, KZ-VOS, KZ-ZHA, @@ -2300,7 +2300,7 @@ Rule Kyrgyz 1992 1996 - Apr Sun>=7 0:00s 1:00 - Rule Kyrgyz 1992 1996 - Sep lastSun 0:00 0 - Rule Kyrgyz 1997 2005 - Mar lastSun 2:30 1:00 - Rule Kyrgyz 1997 2004 - Oct lastSun 2:30 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Bishkek 4:58:24 - LMT 1924 May 2 5:00 - +05 1930 Jun 21 6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s @@ -2415,7 +2415,7 @@ Rule ROK 1987 1988 - Oct Sun>=8 3:00 0 S # The BBC reported that the transition was from 23:30 to 24:00 today. # https://www.bbc.com/news/world-asia-44010705 -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1 8:30 - KST 1912 Jan 1 9:00 - JST 1945 Sep 8 @@ -2464,7 +2464,7 @@ Rule Lebanon 1992 only - Oct 4 0:00 0 - Rule Lebanon 1993 max - Mar lastSun 0:00 1:00 S Rule Lebanon 1993 1998 - Sep lastSun 0:00 0 - Rule Lebanon 1999 max - Oct lastSun 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Beirut 2:22:00 - LMT 1880 2:00 Lebanon EE%sT @@ -2476,7 +2476,7 @@ Rule NBorneo 1935 1941 - Dec 14 0:00 0 - # peninsular Malaysia # taken from Mok Ly Yng (2003-10-30) # http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - +07 1933 Jan 1 @@ -2490,7 +2490,7 @@ Zone Asia/Kuala_Lumpur 6:46:46 - LMT 1901 Jan 1 # From Paul Eggert (2014-08-12): # The data entries here are mostly from Shanks & Pottenger, but the 1942, 1945 # and 1982 transition dates are from Mok Ly Yng. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Kuching 7:21:20 - LMT 1926 Mar 7:30 - +0730 1933 8:00 NBorneo +08/+0820 1942 Feb 16 @@ -2498,7 +2498,7 @@ Zone Asia/Kuching 7:21:20 - LMT 1926 Mar 8:00 - +08 # Maldives -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Maldives 4:54:00 - LMT 1880 # Malé 4:54:00 - MMT 1960 # Malé Mean Time 5:00 - +05 @@ -2641,7 +2641,7 @@ Rule Mongol 2002 2006 - Mar lastSat 2:00 1:00 - Rule Mongol 2015 2016 - Mar lastSat 2:00 1:00 - Rule Mongol 2015 2016 - Sep lastSat 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Hovd, a.k.a. Chovd, Dund-Us, Dzhargalant, Khovd, Jirgalanta Zone Asia/Hovd 6:06:36 - LMT 1905 Aug 6:00 - +06 1978 @@ -2659,7 +2659,7 @@ Zone Asia/Choibalsan 7:38:00 - LMT 1905 Aug 8:00 Mongol +08/+09 # Nepal -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Kathmandu 5:41:16 - LMT 1920 5:30 - +0530 1986 5:45 - +0545 @@ -2809,7 +2809,7 @@ Rule Pakistan 2008 only - Jun 1 0:00 1:00 S Rule Pakistan 2008 2009 - Nov 1 0:00 0 - Rule Pakistan 2009 only - Apr 15 0:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Karachi 4:28:12 - LMT 1907 5:30 - +0530 1942 Sep 5:30 1:00 +0630 1945 Oct 15 @@ -3145,7 +3145,7 @@ Rule Palestine 2016 2018 - Mar Sat>=24 1:00 1:00 S Rule Palestine 2016 max - Oct lastSat 1:00 0 - Rule Palestine 2019 max - Mar lastFri 0:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct 2:00 Zion EET/EEST 1948 May 15 2:00 EgyptAsia EE%sT 1967 Jun 5 @@ -3219,7 +3219,7 @@ Rule Phil 1954 only - Apr 12 0:00 1:00 D Rule Phil 1954 only - Jul 1 0:00 0 S Rule Phil 1978 only - Mar 22 0:00 1:00 D Rule Phil 1978 only - Sep 21 0:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31 8:04:00 - LMT 1899 May 11 8:00 Phil P%sT 1942 May @@ -3227,7 +3227,7 @@ Zone Asia/Manila -15:56:00 - LMT 1844 Dec 31 8:00 Phil P%sT # Qatar -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Qatar 3:26:08 - LMT 1920 # Al Dawhah / Doha 4:00 - +04 1972 Jun 3:00 - +03 @@ -3275,7 +3275,7 @@ Link Asia/Qatar Asia/Bahrain # the country. Presumably this is documenting airline time. Ignore this, # as it's before our 1970 cutoff. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 3:00 - +03 Link Asia/Riyadh Asia/Aden # Yemen @@ -3284,7 +3284,7 @@ Link Asia/Riyadh Asia/Kuwait # Singapore # taken from Mok Ly Yng (2003-10-30) # http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 6:55:25 - SMT 1905 Jun 1 # Singapore M.T. 7:00 - +07 1933 Jan 1 @@ -3348,7 +3348,7 @@ Zone Asia/Singapore 6:55:25 - LMT 1901 Jan 1 # even worse. For now, let's use a numeric abbreviation; we can # switch to "SLST" if it catches on. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Colombo 5:19:24 - LMT 1880 5:19:32 - MMT 1906 # Moratuwa Mean Time 5:30 - +0530 1942 Jan 5 @@ -3518,13 +3518,13 @@ Rule Syria 2010 2011 - Apr Fri>=1 0:00 1:00 S Rule Syria 2012 max - Mar lastFri 0:00 1:00 S Rule Syria 2009 max - Oct lastFri 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Damascus 2:25:12 - LMT 1920 # Dimashq 2:00 Syria EE%sT # Tajikistan # From Shanks & Pottenger. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 5:00 - +05 1930 Jun 21 6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s @@ -3532,7 +3532,7 @@ Zone Asia/Dushanbe 4:35:12 - LMT 1924 May 2 5:00 - +05 # Thailand -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Bangkok 6:42:04 - LMT 1880 6:42:04 - BMT 1920 Apr # Bangkok Mean Time 7:00 - +07 @@ -3541,7 +3541,7 @@ Link Asia/Bangkok Asia/Vientiane # Laos # Turkmenistan # From Shanks & Pottenger. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Ashgabat 3:53:32 - LMT 1924 May 2 # or Ashkhabad 4:00 - +04 1930 Jun 21 5:00 RussiaAsia +05/+06 1991 Mar 31 2:00 @@ -3549,14 +3549,14 @@ Zone Asia/Ashgabat 3:53:32 - LMT 1924 May 2 # or Ashkhabad 5:00 - +05 # United Arab Emirates -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Dubai 3:41:12 - LMT 1920 4:00 - +04 Link Asia/Dubai Asia/Muscat # Oman # Uzbekistan # Byalokoz 1919 says Uzbekistan was 4:27:53. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Samarkand 4:27:53 - LMT 1924 May 2 4:00 - +04 1930 Jun 21 5:00 - +05 1981 Apr 1 @@ -3622,7 +3622,7 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2 # Lê Thành Lân: "Lịch hai thế kỷ (1802-2010) và các lịch vĩnh cửu", # NXB Thuận Hoá, Huế, 1995. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Asia/Ho_Chi_Minh 7:06:40 - LMT 1906 Jul 1 7:06:30 - PLMT 1911 May 1 # Phù Liễn MT 7:00 - +07 1942 Dec 31 23:00 diff --git a/australasia b/australasia index eff74a4..b30e3f6 100644 --- a/australasia +++ b/australasia @@ -25,7 +25,7 @@ Rule Aus 1943 only - Oct 3 2:00 1:00 D # says W Australia didn't use DST in 1943/1944. Ignore Whitman's claim that # 1944/1945 was just like 1943/1944. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Northern Territory Zone Australia/Darwin 8:43:20 - LMT 1895 Feb 9:00 - ACST 1899 May @@ -102,7 +102,7 @@ Rule AS 2006 only - Apr 2 2:00s 0 S Rule AS 2007 only - Mar lastSun 2:00s 0 S Rule AS 2008 max - Apr Sun>=1 2:00s 0 S Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb 9:00 - ACST 1899 May 9:30 Aus AC%sT 1971 @@ -134,7 +134,7 @@ Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 D Rule AT 2006 only - Apr Sun>=1 2:00s 0 S Rule AT 2007 only - Mar lastSun 2:00s 0 S Rule AT 2008 max - Apr Sun>=1 2:00s 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Australia/Hobart 9:49:16 - LMT 1895 Sep 10:00 - AEST 1916 Oct 1 2:00 10:00 1:00 AEDT 1917 Feb @@ -162,7 +162,7 @@ Rule AV 2006 only - Apr Sun>=1 2:00s 0 S Rule AV 2007 only - Mar lastSun 2:00s 0 S Rule AV 2008 max - Apr Sun>=1 2:00s 0 S Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Australia/Melbourne 9:39:52 - LMT 1895 Feb 10:00 Aus AE%sT 1971 10:00 AV AE%sT @@ -185,7 +185,7 @@ Rule AN 2006 only - Apr Sun>=1 2:00s 0 S Rule AN 2007 only - Mar lastSun 2:00s 0 S Rule AN 2008 max - Apr Sun>=1 2:00s 0 S Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb 10:00 Aus AE%sT 1971 10:00 AN AE%sT @@ -256,14 +256,14 @@ Zone Antarctica/Macquarie 0 - -00 1899 Nov 11:00 - +11 # Christmas -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Christmas 7:02:52 - LMT 1895 Feb 7:00 - +07 # Cocos (Keeling) Is # These islands were ruled by the Ross family from about 1830 to 1978. # We don't know when standard time was introduced; for now, we guess 1900. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Indian/Cocos 6:27:40 - LMT 1900 6:30 - +0630 @@ -386,12 +386,12 @@ Rule Fiji 2012 2013 - Jan Sun>=18 3:00 0 - Rule Fiji 2014 only - Jan Sun>=18 2:00 0 - Rule Fiji 2014 max - Nov Sun>=1 2:00 1:00 - Rule Fiji 2015 max - Jan Sun>=13 3:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Fiji 11:55:44 - LMT 1915 Oct 26 # Suva 12:00 Fiji +12/+13 # French Polynesia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea -9:00 - -09 Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct @@ -434,7 +434,7 @@ Rule Guam 1977 only - Apr 24 2:00 1:00 D # http://documents.guam.gov/wp-content/uploads/E.O.-77-18-Guam-Standard-Time.… Rule Guam 1977 only - Aug 28 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Guam -14:21:00 - LMT 1844 Dec 31 9:39:00 - LMT 1901 # Agana 10:00 - GST 1941 Dec 10 # Guam @@ -444,7 +444,7 @@ Zone Pacific/Guam -14:21:00 - LMT 1844 Dec 31 Link Pacific/Guam Pacific/Saipan # N Mariana Is # Kiribati -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - +12 Zone Pacific/Enderbury -11:24:20 - LMT 1901 @@ -460,7 +460,7 @@ Zone Pacific/Kiritimati -10:29:20 - LMT 1901 # See Pacific/Guam. # Marshall Is -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Majuro 11:24:48 - LMT 1901 11:00 - +11 1914 Oct 9:00 - +09 1919 Feb 1 @@ -478,7 +478,7 @@ Zone Pacific/Kwajalein 11:09:20 - LMT 1901 12:00 - +12 # Micronesia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 10:07:08 - LMT 1901 10:00 - +10 1914 Oct @@ -506,7 +506,7 @@ Zone Pacific/Kosrae -13:08:04 - LMT 1844 Dec 31 11:00 - +11 # Nauru -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Nauru 11:07:40 - LMT 1921 Jan 15 # Uaobe 11:30 - +1130 1942 Aug 29 9:00 - +09 1945 Sep 8 @@ -520,7 +520,7 @@ Rule NC 1978 1979 - Feb 27 0:00 0 - Rule NC 1996 only - Dec 1 2:00s 1:00 - # Shanks & Pottenger say the following was at 2:00; go with IATA. Rule NC 1997 only - Mar 2 2:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Noumea 11:05:48 - LMT 1912 Jan 13 # Nouméa 11:00 NC +11/+12 @@ -559,7 +559,7 @@ Rule NZ 2007 max - Sep lastSun 2:00s 1:00 D Rule Chatham 2007 max - Sep lastSun 2:45s 1:00 - Rule NZ 2008 max - Apr Sun>=1 2:00s 0 S Rule Chatham 2008 max - Apr Sun>=1 2:45s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Auckland 11:39:04 - LMT 1868 Nov 2 11:30 NZ NZ%sT 1946 Jan 1 12:00 NZ NZ%sT @@ -585,7 +585,7 @@ Link Pacific/Auckland Antarctica/McMurdo Rule Cook 1978 only - Nov 12 0:00 0:30 - Rule Cook 1979 1991 - Mar Sun>=1 0:00 0 - Rule Cook 1979 1990 - Oct lastSun 0:00 0:30 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Rarotonga -10:39:04 - LMT 1901 # Avarua -10:30 - -1030 1978 Nov 12 -10:00 Cook -10/-0930 @@ -594,14 +594,14 @@ Zone Pacific/Rarotonga -10:39:04 - LMT 1901 # Avarua # Niue -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Niue -11:19:40 - LMT 1901 # Alofi -11:20 - -1120 1951 -11:30 - -1130 1978 Oct 1 -11:00 - -11 # Norfolk -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Norfolk 11:11:52 - LMT 1901 # Kingston 11:12 - +1112 1951 11:30 - +1130 1974 Oct 27 02:00 @@ -610,13 +610,13 @@ Zone Pacific/Norfolk 11:11:52 - LMT 1901 # Kingston 11:00 - +11 # Palau (Belau) -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Palau -15:02:04 - LMT 1844 Dec 31 # Koror 8:57:56 - LMT 1901 9:00 - +09 # Papua New Guinea -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Port_Moresby 9:48:40 - LMT 1880 9:48:32 - PMMT 1895 # Port Moresby Mean Time 10:00 - +10 @@ -646,7 +646,7 @@ Zone Pacific/Bougainville 10:22:16 - LMT 1880 11:00 - +11 # Pitcairn -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Pitcairn -8:40:20 - LMT 1901 # Adamstown -8:30 - -0830 1998 Apr 27 0:00 -8:00 - -08 @@ -731,7 +731,7 @@ Rule WS 2011 only - Apr Sat>=1 4:00 0 - Rule WS 2011 only - Sep lastSat 3:00 1 - Rule WS 2012 max - Apr Sun>=1 4:00 0 - Rule WS 2012 max - Sep lastSun 3:00 1 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5 -11:26:56 - LMT 1911 -11:30 - -1130 1950 @@ -740,7 +740,7 @@ Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5 # Solomon Is # excludes Bougainville, for which see Papua New Guinea -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara 11:00 - +11 @@ -763,7 +763,7 @@ Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara # was "11 hours slow on G.M.T." Go with Thorsen and assume Shanks & Pottenger # are off by an hour starting in 1901. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Fakaofo -11:24:56 - LMT 1901 -11:00 - -11 2011 Dec 30 13:00 - +13 @@ -776,14 +776,14 @@ Rule Tonga 2000 2001 - Nov Sun>=1 2:00 1:00 - Rule Tonga 2001 2002 - Jan lastSun 2:00 0 - Rule Tonga 2016 only - Nov Sun>=1 2:00 1:00 - Rule Tonga 2017 only - Jan Sun>=15 3:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Tongatapu 12:19:20 - LMT 1901 12:20 - +1220 1941 13:00 - +13 1999 13:00 Tonga +13/+14 # Tuvalu -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Funafuti 11:56:52 - LMT 1901 12:00 - +12 @@ -844,7 +844,7 @@ Zone Pacific/Funafuti 11:56:52 - LMT 1901 # uninhabited since World War II; was probably like Pacific/Kiritimati # Wake -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Wake 11:06:28 - LMT 1901 12:00 - +12 @@ -857,12 +857,12 @@ Rule Vanuatu 1984 only - Oct 23 0:00 1:00 - Rule Vanuatu 1985 1991 - Sep Sun>=23 0:00 1:00 - Rule Vanuatu 1992 1993 - Jan Sun>=23 0:00 0 - Rule Vanuatu 1992 only - Oct Sun>=23 0:00 1:00 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila 11:00 Vanuatu +11/+12 # Wallis and Futuna -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Wallis 12:15:20 - LMT 1901 12:00 - +12 diff --git a/backzone b/backzone index 380c492..b3d6efd 100644 --- a/backzone +++ b/backzone @@ -38,7 +38,7 @@ # commentary and rules associated with the entry. # # As explained in the zic man page, the zone columns are: -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Ethiopia # From Paul Eggert (2014-07-31): diff --git a/europe b/europe index 80c31fc..d3bd2df 100644 --- a/europe +++ b/europe @@ -122,7 +122,7 @@ # position is 51° 28' 30" N, 0° 18' 45" W. The longitude should # be within about ±2". The Ordnance Survey grid reference is TQ172761. # -# [This yields GMTOFF = -0:01:15 for London LMT in the 18th century.] +# [This yields UTOFF = -0:01:15 for London LMT in the 18th century.] # From Paul Eggert (1993-11-18): # @@ -500,7 +500,7 @@ Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00u 0 GMT # # Use Europe/London for Jersey, Guernsey, and the Isle of Man. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u @@ -538,7 +538,7 @@ Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 - Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 - Rule Eire 1996 max - Oct lastSun 1:00u -1:00 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00s -0:25:21 1:00 IST 1916 Oct 1 2:00s @@ -737,7 +737,7 @@ Rule Russia 1996 2010 - Oct lastSun 2:00s 0 - # These are for backward compatibility with older versions. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone WET 0:00 EU WE%sT Zone CET 1:00 C-Eur CE%sT Zone MET 1:00 C-Eur ME%sT @@ -797,14 +797,14 @@ Rule Albania 1982 only - Oct 3 0:00 0 - Rule Albania 1983 only - Apr 18 0:00 1:00 S Rule Albania 1983 only - Oct 1 0:00 0 - Rule Albania 1984 only - Apr 1 0:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Tirane 1:19:20 - LMT 1914 1:00 - CET 1940 Jun 16 1:00 Albania CE%sT 1984 Jul 1:00 EU CE%sT # Andorra -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Andorra 0:06:04 - LMT 1901 0:00 - WET 1946 Sep 30 1:00 - CET 1985 Mar 31 2:00 @@ -830,7 +830,7 @@ Rule Austria 1947 only - Apr 6 2:00s 1:00 S Rule Austria 1948 only - Apr 18 2:00s 1:00 S Rule Austria 1980 only - Apr 6 0:00 1:00 S Rule Austria 1980 only - Sep 28 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Vienna 1:05:21 - LMT 1893 Apr 1:00 C-Eur CE%sT 1920 1:00 Austria CE%sT 1940 Apr 1 2:00s @@ -862,7 +862,7 @@ Zone Europe/Vienna 1:05:21 - LMT 1893 Apr # Belarussian government decided against changing to winter time.... # http://eng.belta.by/all_news/society/Belarus-decides-against-adjusting-time… # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Minsk 1:50:16 - LMT 1880 1:50 - MMT 1924 May 2 # Minsk Mean Time 2:00 - EET 1930 Jun 21 @@ -926,7 +926,7 @@ Rule Belgium 1945 only - Apr 2 2:00s 1:00 S Rule Belgium 1945 only - Sep 16 2:00s 0 - Rule Belgium 1946 only - May 19 2:00s 1:00 S Rule Belgium 1946 only - Oct 7 2:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Brussels 0:17:30 - LMT 1880 0:17:30 - BMT 1892 May 1 12:00 # Brussels MT 0:00 - WET 1914 Nov 8 @@ -953,7 +953,7 @@ Rule Bulg 1979 only - Oct 1 1:00 0 - Rule Bulg 1980 1982 - Apr Sat>=1 23:00 1:00 S Rule Bulg 1980 only - Sep 29 1:00 0 - Rule Bulg 1981 only - Sep 27 2:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Sofia 1:33:16 - LMT 1880 1:56:56 - IMT 1894 Nov 30 # Istanbul MT? 2:00 - EET 1942 Nov 2 3:00 @@ -986,7 +986,7 @@ Rule Czech 1946 only - May 6 2:00s 1:00 S Rule Czech 1946 1949 - Oct Sun>=1 2:00s 0 - Rule Czech 1947 1948 - Apr Sun>=15 2:00s 1:00 S Rule Czech 1949 only - Apr 9 2:00s 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Prague 0:57:44 - LMT 1850 0:57:44 - PMT 1891 Oct # Prague Mean Time 1:00 C-Eur CE%sT 1945 May 9 @@ -1048,7 +1048,7 @@ Rule Denmark 1947 only - Aug 10 2:00s 0 - Rule Denmark 1948 only - May 9 2:00s 1:00 S Rule Denmark 1948 only - Aug 8 2:00s 0 - # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Copenhagen 0:50:20 - LMT 1890 0:50:20 - CMT 1894 Jan 1 # Copenhagen MT 1:00 Denmark CE%sT 1942 Nov 2 2:00s @@ -1145,7 +1145,7 @@ Rule Thule 1993 2006 - Oct lastSun 2:00 0 S Rule Thule 2007 max - Mar Sun>=8 2:00 1:00 D Rule Thule 2007 max - Nov Sun>=1 2:00 0 S # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28 -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 1996 @@ -1211,7 +1211,7 @@ Zone America/Thule -4:35:08 - LMT 1916 Jul 28 # Pituffik air base # From Urmet Jänes (2002-03-28): # The legislative reference is Government decree No. 84 on 2002-02-21. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Tallinn 1:39:00 - LMT 1880 1:39:00 - TMT 1918 Feb # Tallinn Mean Time 1:00 C-Eur CE%sT 1919 Jul @@ -1274,7 +1274,7 @@ Rule Finland 1981 1982 - Sep lastSun 3:00 0 - # Milne says Helsinki (Helsingfors) time was 1:39:49.2 (official document); # round to nearest. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Helsinki 1:39:49 - LMT 1878 May 31 1:39:49 - HMT 1921 May # Helsinki Mean Time 2:00 Finland EE%sT 1983 @@ -1364,7 +1364,7 @@ Rule France 1976 only - Sep 26 1:00 0 - # but Howse quotes the actual French legislation as saying 0:09:21. # Go with Howse. Howse writes that the time in France was officially based # on PMT-0:09:21 until 1978-08-09, when the time base finally switched to UTC. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 0:09:21 - PMT 1911 Mar 11 0:01 # Paris MT # Shanks & Pottenger give 1940 Jun 14 0:00; go with Excoffier and Le Corre. @@ -1412,7 +1412,7 @@ Rule SovietZone 1945 only - May 24 2:00 2:00 M # Midsummer Rule SovietZone 1945 only - Sep 24 3:00 1:00 S Rule SovietZone 1945 only - Nov 18 2:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Berlin 0:53:28 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 May 24 2:00 1:00 SovietZone CE%sT 1946 @@ -1440,7 +1440,7 @@ Link Europe/Zurich Europe/Busingen # is in Europe. Our reference location Tbilisi is in the Asian part. # Gibraltar -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Gibraltar -0:21:24 - LMT 1880 Aug 2 0:00s 0:00 GB-Eire %s 1957 Apr 14 2:00 1:00 - CET 1982 @@ -1471,7 +1471,7 @@ Rule Greece 1979 only - Apr 1 9:00 1:00 S Rule Greece 1979 only - Sep 29 2:00 0 - Rule Greece 1980 only - Apr 1 0:00 1:00 S Rule Greece 1980 only - Sep 28 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 @@ -1508,7 +1508,7 @@ Rule Hungary 1956 only - Sep lastSun 0:00 0 - Rule Hungary 1957 only - Jun Sun>=1 1:00 1:00 S Rule Hungary 1957 only - Sep lastSun 3:00 0 - Rule Hungary 1980 only - Apr 6 1:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Budapest 1:16:20 - LMT 1890 Oct 1:00 C-Eur CE%sT 1918 1:00 Hungary CE%sT 1941 Apr 8 @@ -1569,7 +1569,7 @@ Rule Iceland 1947 1967 - Apr Sun>=1 1:00s 1:00 - Rule Iceland 1949 only - Oct 30 1:00s 0 - Rule Iceland 1950 1966 - Oct Sun>=22 1:00s 0 - Rule Iceland 1967 only - Oct 29 1:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Atlantic/Reykjavik -1:28 - LMT 1908 -1:00 Iceland -01/+00 1968 Apr 7 1:00s 0:00 - GMT @@ -1676,7 +1676,7 @@ Rule Italy 1976 only - May 30 0:00s 1:00 S Rule Italy 1977 1979 - May Sun>=22 0:00s 1:00 S Rule Italy 1978 only - Oct 1 0:00s 0 - Rule Italy 1979 only - Sep 30 0:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Rome 0:49:56 - LMT 1866 Dec 12 0:49:56 - RMT 1893 Oct 31 23:49:56 # Rome Mean 1:00 Italy CE%sT 1943 Sep 10 @@ -1752,7 +1752,7 @@ Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - # Byalokoz 1919 says Latvia was 1:36:34. # Go with Byalokoz. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Riga 1:36:34 - LMT 1880 1:36:34 - RMT 1918 Apr 15 2:00 # Riga MT 1:36:34 1:00 LST 1918 Sep 16 3:00 # Latvian ST @@ -1822,7 +1822,7 @@ Link Europe/Zurich Europe/Vaduz # http://www.lrvk.lt/nut/11/n1749.htm -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time 1:35:36 - KMT 1919 Oct 10 # Kaunas Mean Time @@ -1866,7 +1866,7 @@ Rule Lux 1926 only - Apr 17 23:00 1:00 S Rule Lux 1927 only - Apr 9 23:00 1:00 S Rule Lux 1928 only - Apr 14 23:00 1:00 S Rule Lux 1929 only - Apr 20 23:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 1:00 Lux CE%sT 1918 Nov 25 0:00 Lux WE%sT 1929 Oct 6 2:00s @@ -1891,7 +1891,7 @@ Rule Malta 1974 only - Sep 16 0:00s 0 - Rule Malta 1975 1979 - Apr Sun>=15 2:00 1:00 S Rule Malta 1975 1980 - Sep Sun>=15 2:00 0 - Rule Malta 1980 only - Mar 31 2:00 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Malta 0:58:04 - LMT 1893 Nov 2 0:00s # Valletta 1:00 Italy CE%sT 1973 Mar 31 1:00 Malta CE%sT 1981 @@ -1960,7 +1960,7 @@ Zone Europe/Malta 0:58:04 - LMT 1893 Nov 2 0:00s # Valletta Rule Moldova 1997 max - Mar lastSun 2:00 1:00 S Rule Moldova 1997 max - Oct lastSun 3:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 1:55 - CMT 1918 Feb 15 # Chisinau MT 1:44:24 - BMT 1931 Jul 24 # Bucharest MT @@ -1976,7 +1976,7 @@ Zone Europe/Chisinau 1:55:20 - LMT 1880 # Monaco # Shanks & Pottenger give 0:09:20 for Paris Mean Time; go with Howse's # more precise 0:09:21. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Monaco 0:29:32 - LMT 1891 Mar 15 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time 0:00 France WE%sT 1945 Sep 16 3:00 @@ -2051,8 +2051,8 @@ Rule Neth 1945 only - Apr 2 2:00s 1:00 S Rule Neth 1945 only - Sep 16 2:00s 0 - # # Amsterdam Mean Time was +00:19:32.13, but the .13 is omitted -# below because the current format requires GMTOFF to be an integer. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# below because the current format requires UTOFF to be an integer. +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Amsterdam 0:19:32 - LMT 1835 0:19:32 Neth %s 1937 Jul 1 0:20 Neth +0020/+0120 1940 May 16 0:00 @@ -2071,7 +2071,7 @@ Rule Norway 1945 only - Oct 1 2:00s 0 - Rule Norway 1959 1964 - Mar Sun>=15 2:00s 1:00 S Rule Norway 1959 1965 - Sep Sun>=15 2:00s 0 - Rule Norway 1965 only - Apr 25 2:00s 1:00 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 1:00 Norway CE%sT 1940 Aug 10 23:00 1:00 C-Eur CE%sT 1945 Apr 2 2:00 @@ -2162,7 +2162,7 @@ Rule Poland 1959 1961 - Oct Sun>=1 1:00s 0 - Rule Poland 1960 only - Apr 3 1:00s 1:00 S Rule Poland 1961 1964 - May lastSun 1:00s 1:00 S Rule Poland 1962 1964 - Sep lastSun 1:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Warsaw 1:24:00 - LMT 1880 1:24:00 - WMT 1915 Aug 5 # Warsaw Mean Time 1:00 C-Eur CE%sT 1918 Sep 16 3:00 @@ -2267,7 +2267,7 @@ Rule Port 1980 only - Mar lastSun 0:00s 1:00 S Rule Port 1981 1982 - Mar lastSun 1:00s 1:00 S Rule Port 1983 only - Mar lastSun 2:00s 1:00 S # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Lisbon -0:36:45 - LMT 1884 -0:36:45 - LMT 1912 Jan 1 0:00u # Lisbon MT 0:00 Port WE%sT 1966 Apr 3 2:00 @@ -2326,7 +2326,7 @@ Rule Romania 1980 only - Apr 5 23:00 1:00 S Rule Romania 1980 only - Sep lastSun 1:00 0 - Rule Romania 1991 1993 - Mar lastSun 0:00s 1:00 S Rule Romania 1991 1993 - Sep lastSun 0:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Bucharest 1:44:24 - LMT 1891 Oct 1:44:24 - BMT 1931 Jul 24 # Bucharest MT 2:00 Romania EE%sT 1981 Mar 29 2:00s @@ -3365,7 +3365,7 @@ Zone Asia/Anadyr 11:49:56 - LMT 1924 May 2 # See Europe/Rome. # Serbia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Belgrade 1:22:00 - LMT 1884 1:00 - CET 1941 Apr 18 23:00 1:00 C-Eur CE%sT 1945 @@ -3471,7 +3471,7 @@ Rule SpainAfrica 1976 only - Aug 1 0:00 0 - Rule SpainAfrica 1977 only - Sep 28 0:00 0 - Rule SpainAfrica 1978 only - Jun 1 0:00 1:00 S Rule SpainAfrica 1978 only - Aug 4 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Madrid -0:14:44 - LMT 1900 Dec 31 23:45:16 0:00 Spain WE%sT 1940 Mar 16 23:00 1:00 Spain CE%sT 1979 @@ -3539,7 +3539,7 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. # # Source: The newspaper "Dagens Nyheter", 1916-10-01, page 7 upper left. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 1:00:14 - SET 1900 Jan 1 # Swedish Time 1:00 - CET 1916 May 14 23:00 @@ -3642,7 +3642,7 @@ Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 # See above comment. 0:29:46 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 @@ -3792,7 +3792,7 @@ Rule Turkey 1986 1995 - Sep lastSun 1:00s 0 - Rule Turkey 1994 only - Mar 20 1:00s 1:00 S Rule Turkey 1995 2006 - Mar lastSun 1:00s 1:00 S Rule Turkey 1996 2006 - Oct lastSun 1:00s 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Istanbul 1:55:52 - LMT 1880 1:56:56 - IMT 1910 Oct # Istanbul Mean Time? 2:00 Turkey EE%sT 1978 Oct 15 @@ -3890,7 +3890,7 @@ Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. # English; in the meantime, stick with the traditional English "Kiev" as that # means less disruption for our users. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # This represents most of Ukraine. See above for the spelling of "Kiev". Zone Europe/Kiev 2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 # Kiev Mean Time diff --git a/factory b/factory index d4e7659..9165f59 100644 --- a/factory +++ b/factory @@ -8,5 +8,5 @@ # time zone abbreviation "-00", indicating that the actual time zone # is unknown. -# Zone NAME GMTOFF RULES FORMAT +# Zone NAME UTOFF RULES FORMAT Zone Factory 0 - -00 diff --git a/localtime.c b/localtime.c index ac3790a..033e88f 100644 --- a/localtime.c +++ b/localtime.c @@ -98,11 +98,11 @@ static const char gmt[] = "GMT"; #endif struct ttinfo { /* time type information */ - int_fast32_t tt_gmtoff; /* UT offset in seconds */ + int_fast32_t tt_utoff; /* UT offset in seconds */ bool tt_isdst; /* used to set tm_isdst */ - int tt_abbrind; /* abbreviation list index */ + int tt_desigidx; /* abbreviation list index */ bool tt_ttisstd; /* transition is std time */ - bool tt_ttisgmt; /* transition is UT */ + bool tt_ttisut; /* transition is UT */ }; struct lsinfo { /* leap second information */ @@ -209,15 +209,15 @@ long altzone; # endif #endif -/* Initialize *S to a value based on GMTOFF, ISDST, and ABBRIND. */ +/* Initialize *S to a value based on UTOFF, ISDST, and DESIGIDX. */ static void -init_ttinfo(struct ttinfo *s, int_fast32_t gmtoff, bool isdst, int abbrind) +init_ttinfo(struct ttinfo *s, int_fast32_t utoff, bool isdst, int desigidx) { - s->tt_gmtoff = gmtoff; + s->tt_utoff = utoff; s->tt_isdst = isdst; - s->tt_abbrind = abbrind; + s->tt_desigidx = desigidx; s->tt_ttisstd = false; - s->tt_ttisgmt = false; + s->tt_ttisut = false; } static int_fast32_t @@ -270,15 +270,15 @@ static void update_tzname_etc(struct state const *sp, struct ttinfo const *ttisp) { #if HAVE_TZNAME - tzname[ttisp->tt_isdst] = (char *) &sp->chars[ttisp->tt_abbrind]; + tzname[ttisp->tt_isdst] = (char *) &sp->chars[ttisp->tt_desigidx]; #endif #if USG_COMPAT if (!ttisp->tt_isdst) - timezone = - ttisp->tt_gmtoff; + timezone = - ttisp->tt_utoff; #endif #ifdef ALTZONE if (ttisp->tt_isdst) - altzone = - ttisp->tt_gmtoff; + altzone = - ttisp->tt_utoff; #endif } @@ -335,7 +335,7 @@ scrub_abbrs(struct state *sp) */ for (i = 0; i < sp->typecnt; ++i) { register const struct ttinfo * const ttisp = &sp->ttis[i]; - register char * cp = &sp->chars[ttisp->tt_abbrind]; + char *cp = &sp->chars[ttisp->tt_desigidx]; if (strlen(cp) > TZ_ABBR_MAX_LEN && strcmp(cp, GRANDPARENTED) != 0) @@ -452,7 +452,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, return errno; for (stored = 4; stored <= 8; stored *= 2) { int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); - int_fast32_t ttisgmtcnt = detzcode(up->tzhead.tzh_ttisgmtcnt); + int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); int_fast64_t prevtr = 0; int_fast32_t prevcorr = 0; int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); @@ -468,7 +468,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, && 0 <= timecnt && timecnt < TZ_MAX_TIMES && 0 <= charcnt && charcnt < TZ_MAX_CHARS && (ttisstdcnt == typecnt || ttisstdcnt == 0) - && (ttisgmtcnt == typecnt || ttisgmtcnt == 0))) + && (ttisutcnt == typecnt || ttisutcnt == 0))) return EINVAL; if (nread < (tzheadsize /* struct tzhead */ @@ -478,7 +478,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, + charcnt /* chars */ + leapcnt * (stored + 4) /* lsinfos */ + ttisstdcnt /* ttisstds */ - + ttisgmtcnt)) /* ttisgmts */ + + ttisutcnt)) /* ttisuts */ return EINVAL; sp->leapcnt = leapcnt; sp->timecnt = timecnt; @@ -519,19 +519,19 @@ tzloadbody(char const *name, struct state *sp, bool doextend, sp->timecnt = timecnt; for (i = 0; i < sp->typecnt; ++i) { register struct ttinfo * ttisp; - unsigned char isdst, abbrind; + unsigned char isdst, desigidx; ttisp = &sp->ttis[i]; - ttisp->tt_gmtoff = detzcode(p); + ttisp->tt_utoff = detzcode(p); p += 4; isdst = *p++; if (! (isdst < 2)) return EINVAL; ttisp->tt_isdst = isdst; - abbrind = *p++; - if (! (abbrind < sp->charcnt)) + desigidx = *p++; + if (! (desigidx < sp->charcnt)) return EINVAL; - ttisp->tt_abbrind = abbrind; + ttisp->tt_desigidx = desigidx; } for (i = 0; i < sp->charcnt; ++i) sp->chars[i] = *p++; @@ -578,12 +578,12 @@ tzloadbody(char const *name, struct state *sp, bool doextend, register struct ttinfo * ttisp; ttisp = &sp->ttis[i]; - if (ttisgmtcnt == 0) - ttisp->tt_ttisgmt = false; + if (ttisutcnt == 0) + ttisp->tt_ttisut = false; else { if (*p != true && *p != false) return EINVAL; - ttisp->tt_ttisgmt = *p++; + ttisp->tt_ttisut = *p++; } } /* @@ -612,11 +612,11 @@ tzloadbody(char const *name, struct state *sp, bool doextend, int gotabbr = 0; int charcnt = sp->charcnt; for (i = 0; i < ts->typecnt; i++) { - char *tsabbr = ts->chars + ts->ttis[i].tt_abbrind; + char *tsabbr = ts->chars + ts->ttis[i].tt_desigidx; int j; for (j = 0; j < charcnt; j++) if (strcmp(sp->chars + j, tsabbr) == 0) { - ts->ttis[i].tt_abbrind = j; + ts->ttis[i].tt_desigidx = j; gotabbr++; break; } @@ -625,7 +625,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (j + tsabbrlen < TZ_MAX_CHARS) { strcpy(sp->chars + j, tsabbr); charcnt = j + tsabbrlen + 1; - ts->ttis[i].tt_abbrind = j; + ts->ttis[i].tt_desigidx = j; gotabbr++; } } @@ -764,12 +764,13 @@ typesequiv(const struct state *sp, int a, int b) else { register const struct ttinfo * ap = &sp->ttis[a]; register const struct ttinfo * bp = &sp->ttis[b]; - result = ap->tt_gmtoff == bp->tt_gmtoff && - ap->tt_isdst == bp->tt_isdst && - ap->tt_ttisstd == bp->tt_ttisstd && - ap->tt_ttisgmt == bp->tt_ttisgmt && - strcmp(&sp->chars[ap->tt_abbrind], - &sp->chars[bp->tt_abbrind]) == 0; + result = (ap->tt_utoff == bp->tt_utoff + && ap->tt_isdst == bp->tt_isdst + && ap->tt_ttisstd == bp->tt_ttisstd + && ap->tt_ttisut == bp->tt_ttisut + && (strcmp(&sp->chars[ap->tt_desigidx], + &sp->chars[bp->tt_desigidx]) + == 0)); } return result; } @@ -1234,7 +1235,7 @@ tzparse(const char *name, struct state *sp, bool lastditch) j = sp->types[i]; if (!sp->ttis[j].tt_isdst) { theirstdoffset = - -sp->ttis[j].tt_gmtoff; + - sp->ttis[j].tt_utoff; break; } } @@ -1243,7 +1244,7 @@ tzparse(const char *name, struct state *sp, bool lastditch) j = sp->types[i]; if (sp->ttis[j].tt_isdst) { theirdstoffset = - -sp->ttis[j].tt_gmtoff; + - sp->ttis[j].tt_utoff; break; } } @@ -1259,7 +1260,7 @@ tzparse(const char *name, struct state *sp, bool lastditch) for (i = 0; i < sp->timecnt; ++i) { j = sp->types[i]; sp->types[i] = sp->ttis[j].tt_isdst; - if (sp->ttis[j].tt_ttisgmt) { + if (sp->ttis[j].tt_ttisut) { /* No adjustment to transition time */ } else { /* @@ -1285,7 +1286,7 @@ tzparse(const char *name, struct state *sp, bool lastditch) theirstdoffset; } } - theiroffset = -sp->ttis[j].tt_gmtoff; + theiroffset = -sp->ttis[j].tt_utoff; if (sp->ttis[j].tt_isdst) theirdstoffset = theiroffset; else theirstdoffset = theiroffset; @@ -1532,14 +1533,14 @@ localsub(struct state const *sp, time_t const *timep, int_fast32_t setname, /* ** To get (wrong) behavior that's compatible with System V Release 2.0 ** you'd replace the statement below with - ** t += ttisp->tt_gmtoff; + ** t += ttisp->tt_utoff; ** timesub(&t, 0L, sp, tmp); */ - result = timesub(&t, ttisp->tt_gmtoff, sp, tmp); + result = timesub(&t, ttisp->tt_utoff, sp, tmp); if (result) { result->tm_isdst = ttisp->tt_isdst; #ifdef TM_ZONE - result->TM_ZONE = (char *) &sp->chars[ttisp->tt_abbrind]; + result->TM_ZONE = (char *) &sp->chars[ttisp->tt_desigidx]; #endif /* defined TM_ZONE */ if (setname) update_tzname_etc(sp, ttisp); @@ -2059,8 +2060,8 @@ time2sub(struct tm *const tmp, for (j = sp->typecnt - 1; j >= 0; --j) { if (sp->ttis[j].tt_isdst == yourtm.tm_isdst) continue; - newt = t + sp->ttis[j].tt_gmtoff - - sp->ttis[i].tt_gmtoff; + newt = (t + sp->ttis[j].tt_utoff + - sp->ttis[i].tt_utoff); if (! funcp(sp, &newt, offset, &mytm)) continue; if (tmcomp(&mytm, &yourtm) != 0) @@ -2163,14 +2164,14 @@ time1(struct tm *const tmp, otheri = types[otherind]; if (sp->ttis[otheri].tt_isdst == tmp->tm_isdst) continue; - tmp->tm_sec += sp->ttis[otheri].tt_gmtoff - - sp->ttis[samei].tt_gmtoff; + tmp->tm_sec += (sp->ttis[otheri].tt_utoff + - sp->ttis[samei].tt_utoff); tmp->tm_isdst = !tmp->tm_isdst; t = time2(tmp, funcp, sp, offset, &okay); if (okay) return t; - tmp->tm_sec -= sp->ttis[otheri].tt_gmtoff - - sp->ttis[samei].tt_gmtoff; + tmp->tm_sec -= (sp->ttis[otheri].tt_utoff + - sp->ttis[samei].tt_utoff); tmp->tm_isdst = !tmp->tm_isdst; } } diff --git a/northamerica b/northamerica index 05aea96..fcbf4f2 100644 --- a/northamerica +++ b/northamerica @@ -196,7 +196,7 @@ Rule US 2007 max - Nov Sun>=1 2:00 0 S # increase the chances that they'll actually get compiled and to # avoid the need to duplicate the US rules in another file. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone EST -5:00 - EST Zone MST -7:00 - MST Zone HST -10:00 - HST @@ -353,7 +353,7 @@ Rule NYC 1920 only - Oct lastSun 2:00 0 S Rule NYC 1921 1966 - Apr lastSun 2:00 1:00 D Rule NYC 1921 1954 - Sep lastSun 2:00 0 S Rule NYC 1955 1966 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58 -5:00 US E%sT 1920 -5:00 NYC E%sT 1942 @@ -413,7 +413,7 @@ Rule Chicago 1921 only - Mar lastSun 2:00 1:00 D Rule Chicago 1922 1966 - Apr lastSun 2:00 1:00 D Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24 -6:00 US C%sT 1920 -6:00 Chicago C%sT 1936 Mar 1 2:00 @@ -481,7 +481,7 @@ Rule Denver 1920 only - Oct lastSun 2:00 0 S Rule Denver 1921 only - May 22 2:00 0 S Rule Denver 1965 1966 - Apr lastSun 2:00 1:00 D Rule Denver 1965 1966 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Denver -6:59:56 - LMT 1883 Nov 18 12:00:04 -7:00 US M%sT 1920 -7:00 Denver M%sT 1942 @@ -534,7 +534,7 @@ Rule CA 1949 only - Jan 1 2:00 0 S Rule CA 1950 1966 - Apr lastSun 1:00 1:00 D Rule CA 1950 1961 - Sep lastSun 2:00 0 S Rule CA 1962 1966 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02 -8:00 US P%sT 1946 -8:00 CA P%sT 1967 @@ -642,7 +642,7 @@ Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02 # So they won't be waiting for Alaska to join them on 2019-03-10, but will # rather change their clocks twice in seven weeks. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Juneau 15:02:19 - LMT 1867 Oct 19 15:33:32 -8:57:41 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 @@ -762,7 +762,7 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 # Note that 1933-05-21 was a Sunday. # We're left to guess the time of day when Act 163 was approved; guess noon. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 12:00 @@ -792,7 +792,7 @@ Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 # Shanks says the 1944 experiment came to an end on 1944-03-17. # Go with the Arizona State Library instead. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Phoenix -7:28:18 - LMT 1883 Nov 18 11:31:42 -7:00 US M%sT 1944 Jan 1 0:01 -7:00 - MST 1944 Apr 1 0:01 @@ -818,7 +818,7 @@ Zone America/Phoenix -7:28:18 - LMT 1883 Nov 18 11:31:42 # quarter of Idaho county) and eastern Oregon (most of Malheur County) # switched four weeks late in 1974. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Boise -7:44:49 - LMT 1883 Nov 18 12:15:11 -8:00 US P%sT 1923 May 13 2:00 -7:00 US M%sT 1974 @@ -890,7 +890,7 @@ Zone America/Boise -7:44:49 - LMT 1883 Nov 18 12:15:11 Rule Indianapolis 1941 only - Jun 22 2:00 1:00 D Rule Indianapolis 1941 1954 - Sep lastSun 2:00 0 S Rule Indianapolis 1946 1954 - Apr lastSun 2:00 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Indianapolis -5:44:38 - LMT 1883 Nov 18 12:15:22 -6:00 US C%sT 1920 -6:00 Indianapolis C%sT 1942 @@ -910,7 +910,7 @@ Rule Marengo 1951 only - Apr lastSun 2:00 1:00 D Rule Marengo 1951 only - Sep lastSun 2:00 0 S Rule Marengo 1954 1960 - Apr lastSun 2:00 1:00 D Rule Marengo 1954 1960 - Sep lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Marengo -5:45:23 - LMT 1883 Nov 18 12:14:37 -6:00 US C%sT 1951 -6:00 Marengo C%sT 1961 Apr 30 2:00 @@ -934,7 +934,7 @@ Rule Vincennes 1956 1963 - Apr lastSun 2:00 1:00 D Rule Vincennes 1960 only - Oct lastSun 2:00 0 S Rule Vincennes 1961 only - Sep lastSun 2:00 0 S Rule Vincennes 1962 1963 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Vincennes -5:50:07 - LMT 1883 Nov 18 12:09:53 -6:00 US C%sT 1946 -6:00 Vincennes C%sT 1964 Apr 26 2:00 @@ -955,7 +955,7 @@ Rule Perry 1956 1963 - Apr lastSun 2:00 1:00 D Rule Perry 1960 only - Oct lastSun 2:00 0 S Rule Perry 1961 only - Sep lastSun 2:00 0 S Rule Perry 1962 1963 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Tell_City -5:47:03 - LMT 1883 Nov 18 12:12:57 -6:00 US C%sT 1946 -6:00 Perry C%sT 1964 Apr 26 2:00 @@ -971,7 +971,7 @@ Rule Pike 1955 only - May 1 0:00 1:00 D Rule Pike 1955 1960 - Sep lastSun 2:00 0 S Rule Pike 1956 1964 - Apr lastSun 2:00 1:00 D Rule Pike 1961 1964 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Petersburg -5:49:07 - LMT 1883 Nov 18 12:10:53 -6:00 US C%sT 1955 -6:00 Pike C%sT 1965 Apr 25 2:00 @@ -993,7 +993,7 @@ Rule Starke 1947 1954 - Sep lastSun 2:00 0 S Rule Starke 1955 1956 - Oct lastSun 2:00 0 S Rule Starke 1957 1958 - Sep lastSun 2:00 0 S Rule Starke 1959 1961 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Knox -5:46:30 - LMT 1883 Nov 18 12:13:30 -6:00 US C%sT 1947 -6:00 Starke C%sT 1962 Apr 29 2:00 @@ -1009,7 +1009,7 @@ Rule Pulaski 1946 1960 - Apr lastSun 2:00 1:00 D Rule Pulaski 1946 1954 - Sep lastSun 2:00 0 S Rule Pulaski 1955 1956 - Oct lastSun 2:00 0 S Rule Pulaski 1957 1960 - Sep lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Winamac -5:46:25 - LMT 1883 Nov 18 12:13:35 -6:00 US C%sT 1946 -6:00 Pulaski C%sT 1961 Apr 30 2:00 @@ -1020,7 +1020,7 @@ Zone America/Indiana/Winamac -5:46:25 - LMT 1883 Nov 18 12:13:35 -5:00 US E%sT # # Switzerland County, Indiana, did not observe DST from 1973 through 2005. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Indiana/Vevay -5:40:16 - LMT 1883 Nov 18 12:19:44 -6:00 US C%sT 1954 Apr 25 2:00 -5:00 - EST 1969 @@ -1045,7 +1045,7 @@ Rule Louisville 1941 only - Sep lastSun 2:00 0 S Rule Louisville 1946 only - Jun 2 2:00 0 S Rule Louisville 1950 1955 - Sep lastSun 2:00 0 S Rule Louisville 1956 1960 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Kentucky/Louisville -5:43:02 - LMT 1883 Nov 18 12:16:58 -6:00 US C%sT 1921 -6:00 Louisville C%sT 1942 @@ -1151,7 +1151,7 @@ Zone America/Kentucky/Monticello -5:39:24 - LMT 1883 Nov 18 12:20:36 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Detroit 1948 only - Apr lastSun 2:00 1:00 D Rule Detroit 1948 only - Sep lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Detroit -5:32:11 - LMT 1905 -6:00 - CST 1915 May 15 2:00 -5:00 - EST 1942 @@ -1168,7 +1168,7 @@ Rule Menominee 1946 only - Apr lastSun 2:00 1:00 D Rule Menominee 1946 only - Sep lastSun 2:00 0 S Rule Menominee 1966 only - Apr lastSun 2:00 1:00 D Rule Menominee 1966 only - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00 -6:00 US C%sT 1946 -6:00 Menominee C%sT 1969 Apr 27 2:00 @@ -1402,7 +1402,7 @@ Rule StJohns 2007 2011 - Mar Sun>=8 0:01 1:00 D Rule StJohns 2007 2010 - Nov Sun>=1 0:01 0 S # # St John's has an apostrophe, but Posix file names can't have apostrophes. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/St_Johns -3:30:52 - LMT 1884 -3:30:52 StJohns N%sT 1918 -3:30:52 Canada N%sT 1919 @@ -1415,7 +1415,7 @@ Zone America/St_Johns -3:30:52 - LMT 1884 # most of east Labrador # The name 'Happy Valley-Goose Bay' is too long; use 'Goose Bay'. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Goose_Bay -4:01:40 - LMT 1884 # Happy Valley-Goose Bay -3:30:52 - NST 1918 -3:30:52 Canada N%sT 1919 @@ -1489,7 +1489,7 @@ Rule Halifax 1956 1959 - Apr lastSun 2:00 1:00 D Rule Halifax 1956 1959 - Sep lastSun 2:00 0 S Rule Halifax 1962 1973 - Apr lastSun 2:00 1:00 D Rule Halifax 1962 1973 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Halifax -4:14:24 - LMT 1902 Jun 15 -4:00 Halifax A%sT 1918 -4:00 Canada A%sT 1919 @@ -1527,7 +1527,7 @@ Rule Moncton 1946 1956 - Sep lastSun 2:00 0 S Rule Moncton 1957 1972 - Oct lastSun 2:00 0 S Rule Moncton 1993 2006 - Apr Sun>=1 0:01 1:00 D Rule Moncton 1993 2006 - Oct lastSun 0:01 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 -5:00 - EST 1902 Jun 15 -4:00 Canada A%sT 1933 @@ -1556,7 +1556,7 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # For lack of better info, guess this practice began around 1970, contra to # Shanks & Pottenger who have this region observing AST/ADT. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Blanc-Sablon -3:48:28 - LMT 1884 -4:00 Canada A%sT 1970 -4:00 - AST @@ -1760,7 +1760,7 @@ Rule Toronto 1957 1973 - Oct lastSun 2:00 0 S # War,... [t]he cities agreed to implement DST during the summer # months for the remainder of the war years. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Toronto -5:17:32 - LMT 1895 -5:00 Canada E%sT 1919 -5:00 Toronto E%sT 1942 Feb 9 2:00s @@ -1835,7 +1835,7 @@ Rule Winn 1963 only - Sep 22 2:00 0 S Rule Winn 1966 1986 - Apr lastSun 2:00s 1:00 D Rule Winn 1966 2005 - Oct lastSun 2:00s 0 S Rule Winn 1987 2005 - Apr Sun>=1 2:00s 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16 -6:00 Winn C%sT 2006 -6:00 Canada C%sT @@ -1926,7 +1926,7 @@ Rule Swift 1957 only - Oct lastSun 2:00 0 S Rule Swift 1959 1961 - Apr lastSun 2:00 1:00 D Rule Swift 1959 only - Oct lastSun 2:00 0 S Rule Swift 1960 1961 - Sep lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Regina -6:58:36 - LMT 1905 Sep -7:00 Regina M%sT 1960 Apr lastSun 2:00 -6:00 - CST @@ -1957,7 +1957,7 @@ Rule Edm 1969 only - Apr lastSun 2:00 1:00 D Rule Edm 1969 only - Oct lastSun 2:00 0 S Rule Edm 1972 1986 - Apr lastSun 2:00 1:00 D Rule Edm 1972 2006 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Edmonton -7:33:52 - LMT 1906 Sep -7:00 Edm M%sT 1987 -7:00 Canada M%sT @@ -2050,7 +2050,7 @@ Rule Vanc 1946 1986 - Apr lastSun 2:00 1:00 D Rule Vanc 1946 only - Oct 13 2:00 0 S Rule Vanc 1947 1961 - Sep lastSun 2:00 0 S Rule Vanc 1962 2006 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Vancouver -8:12:28 - LMT 1884 -8:00 Vanc P%sT 1987 -8:00 Canada P%sT @@ -2370,7 +2370,7 @@ Rule NT_YK 1965 only - Oct lastSun 2:00 0 S Rule NT_YK 1980 1986 - Apr lastSun 2:00 1:00 D Rule NT_YK 1980 2006 - Oct lastSun 2:00 0 S Rule NT_YK 1987 2006 - Apr Sun>=1 2:00 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # aka Panniqtuuq Zone America/Pangnirtung 0 - -00 1921 # trading post est. -4:00 NT_YK A%sT 1995 Apr Sun>=1 2:00 @@ -2644,7 +2644,7 @@ Rule Mexico 2001 only - May Sun>=1 2:00 1:00 D Rule Mexico 2001 only - Sep lastSun 2:00 0 S Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D Rule Mexico 2002 max - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # Quintana Roo; represented by Cancún Zone America/Cancun -5:47:04 - LMT 1922 Jan 1 0:12:56 -6:00 - CST 1981 Dec 23 @@ -2837,7 +2837,7 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 -5:00 Bahamas E%sT 1976 -5:00 US E%sT @@ -2852,7 +2852,7 @@ Rule Barb 1977 1978 - Oct Sun>=1 2:00 0 S Rule Barb 1978 1980 - Apr Sun>=15 2:00 1:00 D Rule Barb 1979 only - Sep 30 2:00 0 S Rule Barb 1980 only - Sep 25 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Barbados -3:58:29 - LMT 1924 # Bridgetown -3:58:29 - BMT 1932 # Bridgetown Mean Time -4:00 Barb A%sT @@ -2866,7 +2866,7 @@ Rule Belize 1973 only - Dec 5 0:00 1:00 CDT Rule Belize 1974 only - Feb 9 0:00 0 CST Rule Belize 1982 only - Dec 18 0:00 1:00 CDT Rule Belize 1983 only - Feb 12 0:00 0 CST -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Belize -5:52:48 - LMT 1912 Apr -6:00 Belize %s @@ -2883,7 +2883,7 @@ Zone America/Belize -5:52:48 - LMT 1912 Apr # Friday, the same thing will happen in Bermuda. # http://www.theroyalgazette.com/apps/pbcs.dll/article?AID=/20060529/NEWS/105… -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Atlantic/Bermuda -4:19:18 - LMT 1930 Jan 1 2:00 # Hamilton -4:00 - AST 1974 Apr 28 2:00 -4:00 Canada A%sT 1976 @@ -2905,7 +2905,7 @@ Rule CR 1991 1992 - Jan Sat>=15 0:00 1:00 D Rule CR 1991 only - Jul 1 0:00 0 S Rule CR 1992 only - Mar 15 0:00 0 S # There are too many San Josés elsewhere, so we'll use 'Costa Rica'. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Costa_Rica -5:36:13 - LMT 1890 # San José -5:36:13 - SJMT 1921 Jan 15 # San José Mean Time -6:00 CR C%sT @@ -3111,7 +3111,7 @@ Rule Cuba 2012 only - Apr 1 0:00s 1:00 D Rule Cuba 2012 max - Nov Sun>=1 0:00s 0 S Rule Cuba 2013 max - Mar Sun>=8 0:00s 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Havana -5:29:28 - LMT 1890 -5:29:36 - HMT 1925 Jul 19 12:00 # Havana MT -5:00 Cuba C%sT @@ -3146,7 +3146,7 @@ Rule DR 1969 1973 - Oct lastSun 0:00 0:30 -0430 Rule DR 1970 only - Feb 21 0:00 0 EST Rule DR 1971 only - Jan 20 0:00 0 EST Rule DR 1972 1974 - Jan 21 0:00 0 EST -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Santo_Domingo -4:39:36 - LMT 1890 -4:40 - SDMT 1933 Apr 1 12:00 # S. Dom. MT -5:00 DR %s 1974 Oct 27 @@ -3161,7 +3161,7 @@ Rule Salv 1987 1988 - May Sun>=1 0:00 1:00 D Rule Salv 1987 1988 - Sep lastSun 0:00 0 S # There are too many San Salvadors elsewhere, so use America/El_Salvador # instead of America/San_Salvador. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/El_Salvador -5:56:48 - LMT 1921 # San Salvador -6:00 Salv C%sT @@ -3194,7 +3194,7 @@ Rule Guat 1991 only - Mar 23 0:00 1:00 D Rule Guat 1991 only - Sep 7 0:00 0 S Rule Guat 2006 only - Apr 30 0:00 1:00 D Rule Guat 2006 only - Oct 1 0:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Guatemala -6:02:04 - LMT 1918 Oct 5 -6:00 Guat C%sT @@ -3280,7 +3280,7 @@ Rule Haiti 2012 2015 - Mar Sun>=8 2:00 1:00 D Rule Haiti 2012 2015 - Nov Sun>=1 2:00 0 S Rule Haiti 2017 max - Mar Sun>=8 2:00 1:00 D Rule Haiti 2017 max - Nov Sun>=1 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Port-au-Prince -4:49:20 - LMT 1890 -4:49 - PPMT 1917 Jan 24 12:00 # P-a-P MT -5:00 Haiti E%sT @@ -3319,7 +3319,7 @@ Rule Hond 1987 1988 - May Sun>=1 0:00 1:00 D Rule Hond 1987 1988 - Sep lastSun 0:00 0 S Rule Hond 2006 only - May Sun>=1 0:00 1:00 D Rule Hond 2006 only - Aug Mon>=1 0:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Tegucigalpa -5:48:52 - LMT 1921 Apr -6:00 Hond C%sT # @@ -3340,7 +3340,7 @@ Zone America/Tegucigalpa -5:48:52 - LMT 1921 Apr # Neita L. The politician in all of us. Jamaica Observer 2014-09-20 # http://www.jamaicaobserver.com/columns/The-politician-in-all-of-us_17573647 # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1974 @@ -3348,7 +3348,7 @@ Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston -5:00 - EST # Martinique -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France -4:04:20 - FFMT 1911 May # Fort-de-France MT -4:00 - AST 1980 Apr 6 @@ -3412,7 +3412,7 @@ Rule Nic 2005 only - Apr 10 0:00 1:00 D Rule Nic 2005 only - Oct Sun>=1 0:00 0 S Rule Nic 2006 only - Apr 30 2:00 1:00 D Rule Nic 2006 only - Oct Sun>=1 1:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Managua -5:45:08 - LMT 1890 -5:45:12 - MMT 1934 Jun 23 # Managua Mean Time? -6:00 - CST 1973 May @@ -3424,7 +3424,7 @@ Zone America/Managua -5:45:08 - LMT 1890 -6:00 Nic C%sT # Panama -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Panama -5:18:08 - LMT 1890 -5:19:36 - CMT 1908 Apr 22 # Colón Mean Time -5:00 - EST @@ -3432,7 +3432,7 @@ Link America/Panama America/Cayman # Puerto Rico # There are too many San Juans elsewhere, so we'll use 'Puerto_Rico'. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan -4:00 - AST 1942 May 3 -4:00 US A%sT 1946 @@ -3444,7 +3444,7 @@ Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan # St Pierre and Miquelon # There are too many St Pierres elsewhere, so we'll use 'Miquelon'. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -4:00 - AST 1980 May -3:00 - -03 1987 @@ -3490,7 +3490,7 @@ Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre # by March 2018 for TCI. Magnetic Media. 2017-08-25. # http://magneticmediatv.com/2017/08/time-change-back-by-march-2018-for-tci/ # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Grand_Turk -4:44:32 - LMT 1890 -5:07:10 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1979 diff --git a/pacificnew b/pacificnew index 0e6cf07..3a20303 100644 --- a/pacificnew +++ b/pacificnew @@ -21,7 +21,7 @@ ## Rule Twilite XXXX max uspres Nov Sun>=7 2:00 0 S ## Rule Twilite XXXX max nonpres Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] +# Zone NAME UTOFF RULES/SAVE FORMAT [UNTIL] ## Zone America/Los_Angeles-PET -8:00 US P%sT XXXX ## -8:00 Twilite P%sT diff --git a/southamerica b/southamerica index b4bb3fa..a7c4a71 100644 --- a/southamerica +++ b/southamerica @@ -396,7 +396,7 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 - # plus is that this silences a zic complaint that there's no POSIX TZ # setting for timestamps past 2038. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # # Buenos Aires (BA), Capital Federal (CF), Zone America/Argentina/Buenos_Aires -3:53:48 - LMT 1894 Oct 31 @@ -577,7 +577,7 @@ Zone America/Argentina/Ushuaia -4:33:12 - LMT 1894 Oct 31 Link America/Curacao America/Aruba # Bolivia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/La_Paz -4:32:36 - LMT 1890 -4:32:36 - CMT 1931 Oct 15 # Calamarca MT -4:32:36 1:00 BST 1932 Mar 21 # Bolivia ST @@ -948,7 +948,7 @@ Rule Brazil 2018 only - Nov Sun>=1 0:00 1:00 - # From Daniel Soares de Oliveira (2019-04-26): # http://www.planalto.gov.br/ccivil_03/_Ato2019-2022/2019/Decreto/D9772.htm -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] # # Fernando de Noronha (administratively part of PE) Zone America/Noronha -2:09:40 - LMT 1914 @@ -1298,7 +1298,7 @@ Rule Chile 2019 max - Apr Sun>=2 3:00u 0 - Rule Chile 2019 max - Sep Sun>=2 4:00u 1:00 - # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 @@ -1347,7 +1347,7 @@ Zone Pacific/Easter -7:17:28 - LMT 1890 # Palmer has followed Chile. Prior to that, before the Falklands War, # Palmer used to be supplied from Argentina. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Antarctica/Palmer 0 - -00 1965 -4:00 Arg -04/-03 1969 Oct 5 -3:00 Arg -03/-02 1982 May @@ -1362,7 +1362,7 @@ Zone Antarctica/Palmer 0 - -00 1965 # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule CO 1992 only - May 3 0:00 1:00 - Rule CO 1993 only - Apr 4 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 -4:56:16 - BMT 1914 Nov 23 # Bogotá Mean Time -5:00 CO -05/-04 @@ -1387,7 +1387,7 @@ Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 # Netherlands as Kingdom Islands. This won't affect their time zones # though, as far as we know. # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad -4:30 - -0430 1965 -4:00 - AST @@ -1423,7 +1423,7 @@ Link America/Curacao America/Kralendijk # Caribbean Netherlands Rule Ecuador 1992 only - Nov 28 0:00 1:00 - Rule Ecuador 1993 only - Feb 5 0:00 0 - # -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Guayaquil -5:19:20 - LMT 1890 -5:14:00 - QMT 1931 # Quito Mean Time -5:00 Ecuador -05/-04 @@ -1526,7 +1526,7 @@ Rule Falk 1985 2000 - Sep Sun>=9 0:00 1:00 - Rule Falk 1986 2000 - Apr Sun>=16 0:00 0 - Rule Falk 2001 2010 - Apr Sun>=15 2:00 0 - Rule Falk 2001 2010 - Sep Sun>=1 2:00 1:00 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Atlantic/Stanley -3:51:24 - LMT 1890 -3:51:24 - SMT 1912 Mar 12 # Stanley Mean Time -4:00 Falk -04/-03 1983 May @@ -1535,13 +1535,13 @@ Zone Atlantic/Stanley -3:51:24 - LMT 1890 -3:00 - -03 # French Guiana -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Cayenne -3:29:20 - LMT 1911 Jul -4:00 - -04 1967 Oct -3:00 - -03 # Guyana -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Guyana -3:52:40 - LMT 1915 Mar # Georgetown -3:45 - -0345 1975 Jul 31 -3:00 - -03 1991 @@ -1635,7 +1635,7 @@ Rule Para 2010 2012 - Apr Sun>=8 0:00 0 - # http://www.presidencia.gov.py/archivos/documentos/DECRETO1264_ey9r8zai.pdf Rule Para 2013 max - Mar Sun>=22 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Asuncion -3:50:40 - LMT 1890 -3:50:40 - AMT 1931 Oct 10 # Asunción Mean Time -4:00 - -04 1972 Oct @@ -1664,13 +1664,13 @@ Rule Peru 1990 only - Apr 1 0:00 0 - # IATA is ambiguous for 1993/1995; go with Shanks & Pottenger. Rule Peru 1994 only - Jan 1 0:00 1:00 - Rule Peru 1994 only - Apr 1 0:00 0 - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Lima -5:08:12 - LMT 1890 -5:08:36 - LMT 1908 Jul 28 # Lima Mean Time? -5:00 Peru -05/-04 # South Georgia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Atlantic/South_Georgia -2:26:08 - LMT 1890 # Grytviken -2:00 - -02 @@ -1678,7 +1678,7 @@ Zone Atlantic/South_Georgia -2:26:08 - LMT 1890 # Grytviken # uninhabited; scientific personnel have wintered # Suriname -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Paramaribo -3:40:40 - LMT 1911 -3:40:52 - PMT 1935 # Paramaribo Mean Time -3:40:36 - PMT 1945 Oct # The capital moved? @@ -1686,7 +1686,7 @@ Zone America/Paramaribo -3:40:40 - LMT 1911 -3:00 - -03 # Trinidad and Tobago -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 -4:00 - AST @@ -1957,7 +1957,7 @@ Zone America/Montevideo -3:44:51 - LMT 1908 Jun 10 # ... published in the official Gazette [2016-04-18], here: # http://historico.tsj.gob.ve/gaceta_ext/abril/1842016/E-1842016-4551.pdf -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Caracas -4:27:44 - LMT 1890 -4:27:40 - CMT 1912 Feb 12 # Caracas Mean Time? -4:30 - -0430 1965 Jan 1 0:00 diff --git a/systemv b/systemv index 24c8f64..20c435d 100644 --- a/systemv +++ b/systemv @@ -23,7 +23,7 @@ Rule SystemV 1975 only - Oct lastSun 2:00 0 S Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D Rule SystemV 1976 max - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] +# Zone NAME UTOFF RULES/SAVE FORMAT [UNTIL] ## Zone SystemV/AST4ADT -4:00 SystemV A%sT ## Zone SystemV/EST5EDT -5:00 SystemV E%sT ## Zone SystemV/CST6CDT -6:00 SystemV C%sT diff --git a/tz-how-to.html b/tz-how-to.html index 0bb66ad..ab8ae34 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -314,7 +314,7 @@ rule, so there should be no change.</li> <tr> <td colspan="6" align="center"><table><tr><td> <pre> -#Zone NAME GMTOFF RULES FORMAT [UNTIL] +#Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:09:24 -6:00 US C%sT 1920 -6:00 Chicago C%sT 1936 Mar 1 2:00 @@ -419,7 +419,7 @@ differing by 24 hours; this corresponds to a movement of the Date Line. For example:</p> <pre> -#Zone NAME GMTOFF RULES FORMAT [UNTIL] +#Zone NAME UTOFF RULES FORMAT [UNTIL] Zone America/Juneau 15:02:19 - LMT 1867 Oct 18 -8:57:41 - LMT ... </pre> @@ -458,7 +458,7 @@ given alphabetic string.</li> <p>An example of a specific amount of time is:</p> <pre> -#Zone NAME GMTOFF RULES FORMAT [UNTIL] +#Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Honolulu ... 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 12:00 ... @@ -466,7 +466,7 @@ Zone Pacific/Honolulu ... 1933 Apr 30 2:00 <p>Hawaii tried daylight saving time for three weeks in 1933 and decided they didn’t like it. <code>8-) </code>Note that -the <code>GMTOFF</code> column always contains the standard time +the <code>UTOFF</code> column always contains the standard time offset, so the wall clock time during this period was GMT − 10:30 + 1:00 = GMT − 9:30.</p> @@ -492,7 +492,7 @@ appropriate Rule’s <code>LETTER</code> column</li> <p>An example of a slash is:</p> <pre> -#Zone NAME GMTOFF RULES FORMAT [UNTIL] +#Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/London ... 1996 0:00 EU GMT/BST </pre> @@ -569,7 +569,7 @@ Rule US 1945 only - Sep lastSun 2:00 0 S <tr> <td colspan="6" align="center"><table><tr><td> <pre> -#Zone NAME GMTOFF RULES FORMAT [UNTIL] +#Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 2:00 diff --git a/tzfile.5 b/tzfile.5 index 2f70915..b591e56 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -37,7 +37,7 @@ These values are, in order: .RS .TP -.I tzh_ttisgmtcnt +.I tzh_ttisutcnt The number of UT/local indicators stored in the file. .TP .I tzh_ttisstdcnt @@ -87,21 +87,21 @@ entries, each defined as follows: .nf .ta .5i +\w'unsigned char\0\0'u struct ttinfo { - int32_t tt_gmtoff; + int32_t tt_utoff; unsigned char tt_isdst; - unsigned char tt_abbrind; + unsigned char tt_desigidx; }; .in -.5i .fi .sp Each structure is written as a four-byte signed integer value for -.IR tt_gmtoff , +.IR tt_utoff , in a standard byte order, followed by a one-byte value for .I tt_isdst and a one-byte value for -.IR tt_abbrind . +.IR tt_desigidx . In each structure, -.I tt_gmtoff +.I tt_utoff gives the number of seconds to be added to UT, .I tt_isdst tells whether @@ -109,7 +109,7 @@ tells whether should be set by .BR localtime (3) and -.I tt_abbrind +.I tt_desigidx serves as an index into the array of time zone abbreviation bytes that follow the .I ttinfo @@ -136,7 +136,7 @@ were specified as standard time or wall clock time, and are used when a timezone file is used in handling POSIX-style timezone environment variables. .IP * -.I tzh_ttisgmtcnt +.I tzh_ttisutcnt UT/local indicators, each stored as a one-byte value; they tell whether the transition times associated with local time types were specified as UT or local time, diff --git a/tzfile.h b/tzfile.h index 446c8d5..52673d6 100644 --- a/tzfile.h +++ b/tzfile.h @@ -46,7 +46,7 @@ struct tzhead { char tzh_magic[4]; /* TZ_MAGIC */ char tzh_version[1]; /* '\0' or '2' or '3' as of 2013 */ char tzh_reserved[15]; /* reserved; must be zero */ - char tzh_ttisgmtcnt[4]; /* coded number of trans. time flags */ + char tzh_ttisutcnt[4]; /* coded number of trans. time flags */ char tzh_ttisstdcnt[4]; /* coded number of trans. time flags */ char tzh_leapcnt[4]; /* coded number of leap seconds */ char tzh_timecnt[4]; /* coded number of transition times */ @@ -72,7 +72,7 @@ struct tzhead { ** transition time is wall clock time ** if absent, transition times are ** assumed to be wall clock time -** tzh_ttisgmtcnt (char)s indexed by type; if 1, transition +** tzh_ttisutcnt (char)s indexed by type; if 1, transition ** time is UT, if 0, ** transition time is local time ** if absent, transition times are diff --git a/zic.c b/zic.c index 03f33ee..29cd684 100644 --- a/zic.c +++ b/zic.c @@ -94,7 +94,7 @@ struct rule { zic_t r_tod; /* time from midnight */ bool r_todisstd; /* above is standard time if 1 */ /* or wall clock time if 0 */ - bool r_todisgmt; /* above is GMT if 1 */ + bool r_todisut; /* above is GMT if 1 */ /* or local time if 0 */ bool r_isdst; /* is this daylight saving time? */ zic_t r_stdoff; /* offset from default time (which is @@ -118,7 +118,7 @@ struct zone { lineno z_linenum; const char * z_name; - zic_t z_gmtoff; + zic_t z_utoff; char * z_rule; const char * z_format; char z_format_specifier; @@ -233,7 +233,7 @@ static int typecnt; */ #define ZF_NAME 1 -#define ZF_GMTOFF 2 +#define ZF_UTOFF 2 #define ZF_RULE 3 #define ZF_FORMAT 4 #define ZF_TILYEAR 5 @@ -247,7 +247,7 @@ static int typecnt; ** Which fields are which on a Zone continuation line. */ -#define ZFC_GMTOFF 0 +#define ZFC_UTOFF 0 #define ZFC_RULE 1 #define ZFC_FORMAT 2 #define ZFC_TILYEAR 3 @@ -409,11 +409,11 @@ static struct attype { bool dontmerge; unsigned char type; } * attypes; -static zic_t gmtoffs[TZ_MAX_TYPES]; +static zic_t utoffs[TZ_MAX_TYPES]; static char isdsts[TZ_MAX_TYPES]; -static unsigned char abbrinds[TZ_MAX_TYPES]; +static unsigned char desigidx[TZ_MAX_TYPES]; static bool ttisstds[TZ_MAX_TYPES]; -static bool ttisgmts[TZ_MAX_TYPES]; +static bool ttisuts[TZ_MAX_TYPES]; static char chars[TZ_MAX_CHARS]; static zic_t trans[TZ_MAX_LEAPS]; static zic_t corr[TZ_MAX_LEAPS]; @@ -1403,13 +1403,13 @@ inzsub(char **fields, int nfields, bool iscont) register char * cp; char * cp1; static struct zone z; - register int i_gmtoff, i_rule, i_format; + register int i_utoff, i_rule, i_format; register int i_untilyear, i_untilmonth; register int i_untilday, i_untiltime; register bool hasuntil; if (iscont) { - i_gmtoff = ZFC_GMTOFF; + i_utoff = ZFC_UTOFF; i_rule = ZFC_RULE; i_format = ZFC_FORMAT; i_untilyear = ZFC_TILYEAR; @@ -1420,7 +1420,7 @@ inzsub(char **fields, int nfields, bool iscont) } else if (!namecheck(fields[ZF_NAME])) return false; else { - i_gmtoff = ZF_GMTOFF; + i_utoff = ZF_UTOFF; i_rule = ZF_RULE; i_format = ZF_FORMAT; i_untilyear = ZF_TILYEAR; @@ -1431,7 +1431,7 @@ inzsub(char **fields, int nfields, bool iscont) } z.z_filename = filename; z.z_linenum = linenum; - z.z_gmtoff = gethms(fields[i_gmtoff], _("invalid UT offset")); + z.z_utoff = gethms(fields[i_utoff], _("invalid UT offset")); if ((cp = strchr(fields[i_format], '%')) != 0) { if ((*++cp != 's' && *cp != 'z') || strchr(cp, '%') || strchr(fields[i_format], '/')) { @@ -1624,26 +1624,26 @@ rulesub(struct rule *rp, const char *loyearp, const char *hiyearp, } rp->r_month = lp->l_value; rp->r_todisstd = false; - rp->r_todisgmt = false; + rp->r_todisut = false; dp = ecpyalloc(timep); if (*dp != '\0') { ep = dp + strlen(dp) - 1; switch (lowerit(*ep)) { case 's': /* Standard */ rp->r_todisstd = true; - rp->r_todisgmt = false; + rp->r_todisut = false; *ep = '\0'; break; case 'w': /* Wall */ rp->r_todisstd = false; - rp->r_todisgmt = false; + rp->r_todisut = false; *ep = '\0'; break; case 'g': /* Greenwich */ case 'u': /* Universal */ case 'z': /* Zulu */ rp->r_todisstd = true; - rp->r_todisgmt = true; + rp->r_todisut = true; *ep = '\0'; break; } @@ -1876,22 +1876,24 @@ writezone(const char *const name, const char *const string, char version, toi = 0; fromi = 0; for ( ; fromi < timecnt; ++fromi) { - if (toi != 0 && ((attypes[fromi].at + - gmtoffs[attypes[toi - 1].type]) <= - (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 - : attypes[toi - 2].type]))) { + if (toi != 0 + && ((attypes[fromi].at + + utoffs[attypes[toi - 1].type]) + <= (attypes[toi - 1].at + + utoffs[toi == 1 ? 0 + : attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; } if (toi == 0 || attypes[fromi].dontmerge - || (gmtoffs[attypes[toi - 1].type] - != gmtoffs[attypes[fromi].type]) + || (utoffs[attypes[toi - 1].type] + != utoffs[attypes[fromi].type]) || (isdsts[attypes[toi - 1].type] != isdsts[attypes[fromi].type]) - || (abbrinds[attypes[toi - 1].type] - != abbrinds[attypes[fromi].type])) + || (desigidx[attypes[toi - 1].type] + != desigidx[attypes[fromi].type])) attypes[toi++] = attypes[fromi]; } timecnt = toi; @@ -2084,24 +2086,24 @@ writezone(const char *const name, const char *const string, char version, } } if (hidst >= 0 && mrudst >= 0 && hidst != mrudst && - gmtoffs[hidst] != gmtoffs[mrudst]) { + utoffs[hidst] != utoffs[mrudst]) { isdsts[mrudst] = -1; - type = addtype(gmtoffs[mrudst], - &chars[abbrinds[mrudst]], + type = addtype(utoffs[mrudst], + &chars[desigidx[mrudst]], true, ttisstds[mrudst], - ttisgmts[mrudst]); + ttisuts[mrudst]); isdsts[mrudst] = 1; omittype[type] = false; } if (histd >= 0 && mrustd >= 0 && histd != mrustd && - gmtoffs[histd] != gmtoffs[mrustd]) { + utoffs[histd] != utoffs[mrustd]) { isdsts[mrustd] = -1; - type = addtype(gmtoffs[mrustd], - &chars[abbrinds[mrustd]], + type = addtype(utoffs[mrustd], + &chars[desigidx[mrustd]], false, ttisstds[mrustd], - ttisgmts[mrustd]); + ttisuts[mrustd]); isdsts[mrustd] = 0; omittype[type] = false; } @@ -2124,11 +2126,11 @@ writezone(const char *const name, const char *const string, char version, continue; if (ttisstds[i]) stdcnt = thistypecnt; - if (ttisgmts[i]) + if (ttisuts[i]) utcnt = thistypecnt; - if (indmap[abbrinds[i]] >= 0) + if (indmap[desigidx[i]] >= 0) continue; - thisabbr = &chars[abbrinds[i]]; + thisabbr = &chars[desigidx[i]]; for (j = 0; j < thischarcnt; ++j) if (strcmp(&thischars[j], thisabbr) == 0) break; @@ -2136,7 +2138,7 @@ writezone(const char *const name, const char *const string, char version, strcpy(&thischars[thischarcnt], thisabbr); thischarcnt += strlen(thisabbr) + 1; } - indmap[abbrinds[i]] = j; + indmap[desigidx[i]] = j; } if (pass == 1 && !want_bloat()) { utcnt = stdcnt = thisleapcnt = 0; @@ -2148,7 +2150,7 @@ writezone(const char *const name, const char *const string, char version, tzh = tzh0; memcpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = version; - convert(utcnt, tzh.tzh_ttisgmtcnt); + convert(utcnt, tzh.tzh_ttisutcnt); convert(stdcnt, tzh.tzh_ttisstdcnt); convert(thisleapcnt, tzh.tzh_leapcnt); convert(locut + thistimecnt + hicut, tzh.tzh_timecnt); @@ -2157,7 +2159,7 @@ writezone(const char *const name, const char *const string, char version, DO(tzh_magic); DO(tzh_version); DO(tzh_reserved); - DO(tzh_ttisgmtcnt); + DO(tzh_ttisutcnt); DO(tzh_ttisstdcnt); DO(tzh_leapcnt); DO(tzh_timecnt); @@ -2200,9 +2202,9 @@ writezone(const char *const name, const char *const string, char version, int h = (i == old0 ? thisdefaulttype : i == thisdefaulttype ? old0 : i); if (!omittype[h]) { - puttzcode(gmtoffs[h], fp); + puttzcode(utoffs[h], fp); putc(isdsts[h], fp); - putc(indmap[abbrinds[h]], fp); + putc(indmap[desigidx[h]], fp); } } if (thischarcnt != 0) @@ -2226,7 +2228,7 @@ writezone(const char *const name, const char *const string, char version, ++j; j = types[j - 1]; } - todo = tadd(trans[i], -gmtoffs[j]); + todo = tadd(trans[i], -utoffs[j]); } else todo = trans[i]; puttzcodepass(todo, fp, pass); puttzcode(corr[i], fp); @@ -2238,7 +2240,7 @@ writezone(const char *const name, const char *const string, char version, if (utcnt != 0) for (i = old0; i < typecnt; i++) if (!omittype[i]) - putc(ttisgmts[i], fp); + putc(ttisuts[i], fp); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); @@ -2294,7 +2296,7 @@ doabbr(char *abbr, struct zone const *zp, char const *letters, if (slashp == NULL) { char letterbuf[PERCENT_Z_LEN_BOUND + 1]; if (zp->z_format_specifier == 'z') - letters = abbroffset(letterbuf, zp->z_gmtoff + stdoff); + letters = abbroffset(letterbuf, zp->z_utoff + stdoff); else if (!letters) letters = "%s"; sprintf(abbr, format, letters); @@ -2359,8 +2361,7 @@ stringoffset(char *result, zic_t offset) } static int -stringrule(char *result, const struct rule *const rp, const zic_t dstoff, - const zic_t gmtoff) +stringrule(char *result, struct rule *const rp, zic_t dstoff, zic_t utoff) { register zic_t tod = rp->r_tod; register int compat = 0; @@ -2407,8 +2408,8 @@ stringrule(char *result, const struct rule *const rp, const zic_t dstoff, result += sprintf(result, "M%d.%d.%d", rp->r_month + 1, week, wday); } - if (rp->r_todisgmt) - tod += gmtoff; + if (rp->r_todisut) + tod += utoff; if (rp->r_todisstd && !rp->r_isdst) tod += dstoff; if (tod != 2 * SECSPERMIN * MINSPERHOUR) { @@ -2500,7 +2501,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) dstr.r_dycode = DC_DOM; dstr.r_dayofmonth = 1; dstr.r_tod = 0; - dstr.r_todisstd = dstr.r_todisgmt = false; + dstr.r_todisstd = dstr.r_todisut = false; dstr.r_isdst = stdrp->r_isdst; dstr.r_stdoff = stdrp->r_stdoff; dstr.r_abbrvar = stdrp->r_abbrvar; @@ -2508,7 +2509,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) stdr.r_dycode = DC_DOM; stdr.r_dayofmonth = 31; stdr.r_tod = SECSPERDAY + stdrp->r_stdoff; - stdr.r_todisstd = stdr.r_todisgmt = false; + stdr.r_todisstd = stdr.r_todisut = false; stdr.r_isdst = false; stdr.r_stdoff = 0; stdr.r_abbrvar @@ -2521,7 +2522,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) return -1; abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar; len = doabbr(result, zp, abbrvar, false, 0, true); - offsetlen = stringoffset(result + len, -zp->z_gmtoff); + offsetlen = stringoffset(result + len, - zp->z_utoff); if (! offsetlen) { result[0] = '\0'; return -1; @@ -2533,7 +2534,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) dstrp->r_isdst, dstrp->r_stdoff, true); if (dstrp->r_stdoff != SECSPERMIN * MINSPERHOUR) { offsetlen = stringoffset(result + len, - -(zp->z_gmtoff + dstrp->r_stdoff)); + - (zp->z_utoff + dstrp->r_stdoff)); if (! offsetlen) { result[0] = '\0'; return -1; @@ -2541,7 +2542,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) len += offsetlen; } result[len++] = ','; - c = stringrule(result + len, dstrp, dstrp->r_stdoff, zp->z_gmtoff); + c = stringrule(result + len, dstrp, dstrp->r_stdoff, zp->z_utoff); if (c < 0) { result[0] = '\0'; return -1; @@ -2550,7 +2551,7 @@ stringzone(char *result, struct zone const *zpfirst, ptrdiff_t zonecount) compat = c; len += strlen(result + len); result[len++] = ','; - c = stringrule(result + len, stdrp, dstrp->r_stdoff, zp->z_gmtoff); + c = stringrule(result + len, stdrp, dstrp->r_stdoff, zp->z_utoff); if (c < 0) { result[0] = '\0'; return -1; @@ -2568,12 +2569,12 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) register ptrdiff_t i, j; register bool usestart, useuntil; register zic_t starttime, untiltime; - register zic_t gmtoff; + register zic_t utoff; register zic_t stdoff; register zic_t year; register zic_t startoff; register bool startttisstd; - register bool startttisgmt; + register bool startttisut; register int type; register char * startbuf; register char * ab; @@ -2609,7 +2610,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) ** for noting the need to unconditionally initialize startttisstd. */ startttisstd = false; - startttisgmt = false; + startttisut = false; min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); @@ -2703,16 +2704,16 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) useuntil = i < (zonecount - 1); if (useuntil && zp->z_untiltime <= min_time) continue; - gmtoff = zp->z_gmtoff; + utoff = zp->z_utoff; eat(zp->z_filename, zp->z_linenum); *startbuf = '\0'; - startoff = zp->z_gmtoff; + startoff = zp->z_utoff; if (zp->z_nrules == 0) { stdoff = zp->z_stdoff; doabbr(startbuf, zp, NULL, zp->z_isdst, stdoff, false); - type = addtype(oadd(zp->z_gmtoff, stdoff), + type = addtype(oadd(zp->z_utoff, stdoff), startbuf, zp->z_isdst, startttisstd, - startttisgmt); + startttisut); if (usestart) { addtt(starttime, type); usestart = false; @@ -2748,16 +2749,16 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (useuntil) { /* ** Turn untiltime into UT - ** assuming the current gmtoff and + ** assuming the current utoff and ** stdoff values. */ untiltime = zp->z_untiltime; - if (!zp->z_untilrule.r_todisgmt) + if (!zp->z_untilrule.r_todisut) untiltime = tadd(untiltime, - -gmtoff); + -utoff); if (!zp->z_untilrule.r_todisstd) untiltime = tadd(untiltime, - -stdoff); + -stdoff); } /* ** Find the rule (of those to do, if any) @@ -2770,7 +2771,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) continue; eats(zp->z_filename, zp->z_linenum, rp->r_filename, rp->r_linenum); - offset = rp->r_todisgmt ? 0 : gmtoff; + offset = rp->r_todisut ? 0 : utoff; if (!rp->r_todisstd) offset = oadd(offset, stdoff); jtime = rp->r_temp; @@ -2804,7 +2805,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) usestart = false; if (usestart) { if (ktime < starttime) { - startoff = oadd(zp->z_gmtoff, + startoff = oadd(zp->z_utoff, stdoff); doabbr(startbuf, zp, rp->r_abbrvar, @@ -2813,9 +2814,9 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) false); continue; } - if (*startbuf == '\0' && - startoff == oadd(zp->z_gmtoff, - stdoff)) { + if (*startbuf == '\0' + && startoff == oadd(zp->z_utoff, + stdoff)) { doabbr(startbuf, zp, rp->r_abbrvar, @@ -2828,14 +2829,14 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) rp->r_filename, rp->r_linenum); doabbr(ab, zp, rp->r_abbrvar, rp->r_isdst, rp->r_stdoff, false); - offset = oadd(zp->z_gmtoff, rp->r_stdoff); + offset = oadd(zp->z_utoff, rp->r_stdoff); if (!want_bloat() && !useuntil && !do_extend && prevrp && rp->r_hiyear == ZIC_MAX && prevrp->r_hiyear == ZIC_MAX) break; type = addtype(offset, ab, rp->r_isdst, - rp->r_todisstd, rp->r_todisgmt); + rp->r_todisstd, rp->r_todisut); if (defaulttype < 0 && !rp->r_isdst) defaulttype = type; if (rp->r_hiyear == ZIC_MAX @@ -2856,9 +2857,9 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (*startbuf == '\0') error(_("can't determine time zone abbreviation to use just after until time")); else { - bool isdst = startoff != zp->z_gmtoff; + bool isdst = startoff != zp->z_utoff; type = addtype(startoff, startbuf, isdst, - startttisstd, startttisgmt); + startttisstd, startttisut); if (defaulttype < 0 && !isdst) defaulttype = type; addtt(starttime, type); @@ -2869,12 +2870,12 @@ error(_("can't determine time zone abbreviation to use just after until time")); */ if (useuntil) { startttisstd = zp->z_untilrule.r_todisstd; - startttisgmt = zp->z_untilrule.r_todisgmt; + startttisut = zp->z_untilrule.r_todisut; starttime = zp->z_untiltime; if (!startttisstd) starttime = tadd(starttime, -stdoff); - if (!startttisgmt) - starttime = tadd(starttime, -gmtoff); + if (!startttisut) + starttime = tadd(starttime, -utoff); } } if (defaulttype < 0) @@ -2924,11 +2925,11 @@ addtt(zic_t starttime, int type) } static int -addtype(zic_t gmtoff, char const *abbr, bool isdst, bool ttisstd, bool ttisgmt) +addtype(zic_t utoff, char const *abbr, bool isdst, bool ttisstd, bool ttisut) { register int i, j; - if (! (-1L - 2147483647L <= gmtoff && gmtoff <= 2147483647L)) { + if (! (-1L - 2147483647L <= utoff && utoff <= 2147483647L)) { error(_("UT offset out of range")); exit(EXIT_FAILURE); } @@ -2939,17 +2940,11 @@ addtype(zic_t gmtoff, char const *abbr, bool isdst, bool ttisstd, bool ttisgmt) if (j == charcnt) newabbr(abbr); else { - /* - ** See if there's already an entry for this zone type. - ** If so, just return its index. - */ - for (i = 0; i < typecnt; i++) { - if (gmtoff == gmtoffs[i] && isdst == isdsts[i] && - j == abbrinds[i] && - ttisstd == ttisstds[i] && - ttisgmt == ttisgmts[i]) - return i; - } + /* If there's already an entry, return its index. */ + for (i = 0; i < typecnt; i++) + if (utoff == utoffs[i] && isdst == isdsts[i] && j == desigidx[i] + && ttisstd == ttisstds[i] && ttisut == ttisuts[i]) + return i; } /* ** There isn't one; add a new one, unless there are already too @@ -2960,11 +2955,11 @@ addtype(zic_t gmtoff, char const *abbr, bool isdst, bool ttisstd, bool ttisgmt) exit(EXIT_FAILURE); } i = typecnt++; - gmtoffs[i] = gmtoff; + utoffs[i] = utoff; isdsts[i] = isdst; ttisstds[i] = ttisstd; - ttisgmts[i] = ttisgmt; - abbrinds[i] = j; + ttisuts[i] = ttisut; + desigidx[i] = j; return i; } diff --git a/zoneinfo2tdf.pl b/zoneinfo2tdf.pl index c8c5591..33a9d3b 100755 --- a/zoneinfo2tdf.pl +++ b/zoneinfo2tdf.pl @@ -28,7 +28,7 @@ while (<>) { $contZone = ''; if ($type eq 'zone') { - # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] + # Zone NAME UTOFF RULES/SAVE FORMAT [UNTIL] my $nfields = @fields; $nfields >= 5 or warn "bad zone line"; if ($nfields > 6) { -- 2.21.0

6 10

[PROPOSED] More clarification/explanation from RFC 8536
by Paul Eggert June 18, 2019

June 18, 2019

This just changes documentation: it does not change code or data. Mostly, it just adopts more terminology from RFC 8536. It also contains an example of what the std/wall and UT/local indicators are for. * newtzset.3, theory.html, tz-how-to.html, tzfile.5, tzfile.h, zic.8: In documentation and comments, make it clearer that local time equals wall clock time. * tzfile.5, tzfile.h: In documentation and comments, say that when isut is 1, isstd must also be 1. * tzfile.5: Specify that bytes are 8 bits, that binary integers use two's complement, and that booleans use 0 and 1. Say that UT offsets are never equal to -2**31, and that they realistically are in the range [-89999, 93599]. Say that leap second counts are signed. Say why std/wall and UT/local indicators are present, and give AKST9AKDT as an example. Do not say that the first standard-time ttinfo is used by localtime, as the actual heuristic is far more complicated; instead, document what RFC 8536 says as what's normally used. * zic.c (struct rule): Adjust comments. --- newtzset.3 | 4 ++-- theory.html | 10 ++++---- tz-how-to.html | 14 ++++++------ tzfile.5 | 62 +++++++++++++++++++++++++++++++++----------------- tzfile.h | 15 ++++++------ zic.8 | 16 ++++++------- zic.c | 6 ++--- 7 files changed, 73 insertions(+), 54 deletions(-) diff --git a/newtzset.3 b/newtzset.3 index 29e8a21..4959851 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -65,8 +65,8 @@ falls back on Universal Time (UT). .PP If .B TZ -is null, the best available approximation to local wall -clock time, as specified by the +is null, the best available approximation to local (wall +clock) time, as specified by the .IR tzfile (5)-format file .B localtime diff --git a/theory.html b/theory.html index e580ccc..61d556b 100644 --- a/theory.html +++ b/theory.html @@ -955,7 +955,7 @@ an older <code>zic</code>. </li> <li> In POSIX, there is no tamper-proof way for a process to learn the - system's best idea of local wall clock. + system's best idea of local (wall clock) time. This is important for applications that an administrator wants used only at certain times – without regard to whether the user has fiddled the @@ -1052,14 +1052,14 @@ an older <code>zic</code>. </li> <li> A function <code>tzsetwall</code> has been added to arrange for the - system's best approximation to local wall clock time to be delivered + system's best approximation to local (wall clock) time to be delivered by subsequent calls to <code>localtime</code>. - Source code for portable applications that "must" run on local wall - clock time should call <code>tzsetwall</code>; + Source code for portable applications that "must" run on local + time should call <code>tzsetwall</code>; if such code is moved to "old" systems that do not provide <code>tzsetwall</code>, you will not be able to generate an executable program. - (These functions also arrange for local wall clock time to + (These functions also arrange for local time to be used if <code>tzset</code> is called – directly or indirectly – and there is no <code>TZ</code> environment variable; portable applications should not, however, rely on this diff --git a/tz-how-to.html b/tz-how-to.html index 7274af4..2e4842d 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -102,7 +102,7 @@ in some localizable way. It’s used in the file, <code>pacificnew</code>, to determine whether a given year will have a US presidential election; but everything related to that use is commented out.) -<p>The <code>SAVE</code> column contains the wall clock offset from +<p>The <code>SAVE</code> column contains the local (wall clock) offset from local standard time. This is usually either zero for standard time or one hour for daylight saving time; but there’s no reason, in principle, why it can’t @@ -250,10 +250,10 @@ Rule US 2007 max - Nov Sun>=1 2:00 0 S <p>There are two interesting things to note here.</p> <p>First, the time that something happens (in the <code>AT</code> -column) is not necessarily the local wall clock time. The time can be +column) is not necessarily the local (wall clock) time. The time can be suffixed with ‘s’ (for “standard”) to mean -local standard time (different from wall clock time when observing -daylight saving time); or it can be suffixed with ‘g’, +local standard time, different from local (wall clock) time when observing +daylight saving time; or it can be suffixed with ‘g’, ‘u’, or ‘z’, all three of which mean the standard time at the <a href="https://en.wikipedia.org/wiki/Prime_Meridian">prime meridian</a>. @@ -265,8 +265,8 @@ href="https://en.wikipedia.org/wiki/Coordinated_Universal_Time">UTC</a>” (whichever was official at the time); ‘z’ stands for the <a href="https://en.wikipedia.org/wiki/Nautical_time">nautical time zone</a> Z (a.k.a. “Zulu” which, in turn, stands for ‘Z’). -The time can also be suffixed with ‘w’ meaning “wall -clock time;” but it usually isn’t because that’s the +The time can also be suffixed with ‘w’ meaning local (wall +clock) time; but it usually isn’t because that’s the default.</p> <p>Second, the day in the <code>ON</code> column, in addition to @@ -467,7 +467,7 @@ Zone Pacific/Honolulu ... 1933 Apr 30 2:00 <p>Hawaii tried daylight saving time for three weeks in 1933 and decided they didn’t like it. <code>8-) </code>Note that the <code>STDOFF</code> column always contains the standard time -offset, so the wall clock time during this period was GMT − +offset, so the local (wall clock) time during this period was GMT − 10:30 + 1:00 = GMT − 9:30.</p> <p>The <code>FORMAT</code> column specifies the usual abbreviation of diff --git a/tzfile.5 b/tzfile.5 index b591e56..d13029c 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -16,6 +16,13 @@ The timezone information files used by are typically found under a directory with a name like .IR /usr/share/zoneinfo . These files use the format described in Internet RFC 8536. +Each file is a sequence of 8-bit bytes. +In a file, a binary integer is represented by a sequence of one or +more bytes in network order (bigendian, or high-order byte first), +with all bits significant, +a signed binary integer is represented using two's complement, +and a boolean is represented by a one-byte binary integer that is +either 0 (false) or 1 (true). The format begins with a 44-byte header containing the following fields: .IP * 2 The magic four-byte ASCII sequence @@ -30,11 +37,7 @@ or .IP * Fifteen bytes containing zeros reserved for future use. .IP * -Six four-byte integer values -written in a standard byte order -(the high-order byte of the value is written first). -These values are, -in order: +Six four-byte integer values, in the following order: .RS .TP .I tzh_ttisutcnt @@ -64,7 +67,7 @@ depend on the contents of the header: .IP * 2 .I tzh_timecnt four-byte signed integer values sorted in ascending order. -These values are written in standard byte order. +These values are written in network byte order. Each is used as a transition time (as returned by .BR time (2)) at which the rules for computing local time change. @@ -96,7 +99,7 @@ struct ttinfo { .sp Each structure is written as a four-byte signed integer value for .IR tt_utoff , -in a standard byte order, followed by a one-byte value for +in network byte order, followed by a one-byte boolean for .I tt_isdst and a one-byte value for .IR tt_desigidx . @@ -114,14 +117,23 @@ serves as an index into the array of time zone abbreviation bytes that follow the .I ttinfo structure(s) in the file. +The +.I tt_utoff +value is never equal to -2**31, to let 32-bit clients negate it without +overflow. +Also, in realistic applications +.I tt_utoff +is in the range [-89999, 93599] (i.e., more than -25 hours and less +than 26 hours); this allows easy support by implementations that +already support the POSIX-required range [-24:59:59, 25:59:59]. .IP * .I tzh_leapcnt -pairs of four-byte values, written in standard byte order; +pairs of four-byte values, written in network byte order; the first value of each pair gives the nonnegative time (as returned by .BR time (2)) at which a leap second occurs; -the second gives the +the second is a signed integer specifying the .I total number of leap seconds to be applied during the time period starting at the given time. @@ -130,28 +142,36 @@ Each transition is for one leap second, either positive or negative; transitions always separated by at least 28 days minus 1 second. .IP * .I tzh_ttisstdcnt -standard/wall indicators, each stored as a one-byte value; +standard/wall indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types -were specified as standard time or wall clock time, -and are used when a timezone file is used in handling POSIX-style -timezone environment variables. +were specified as standard time or local (wall clock) time. .IP * .I tzh_ttisutcnt -UT/local indicators, each stored as a one-byte value; +UT/local indicators, each stored as a one-byte boolean; they tell whether the transition times associated with local time types -were specified as UT or local time, -and are used when a timezone file is used in handling POSIX-style -timezone environment variables. +were specified as UT or local time. +If a UT/local indicator is set, the corresponding standard/wall indicator +must also be set. +.PP +The standard/wall and UT/local indicators were designed for +transforming a TZif file's transition times into transitions appropriate +for another time zone specified via a POSIX-style TZ string that lacks rules. +For example, when TZ="AKST9AKDT" and there is no TZif file "AKST9AKDT", +the transition times might be adapted from a TZif file with the +well-known name "posixrules" that is present only for this purpose and +is a copy of the file "America/New_York", a file with a different UT offset. +POSIX does not specify this obsolescent transformational behavior and +widely used platforms such as GNU/Linux do not support it correctly, so users +desiring Alaska time should specify TZ="America/Anchorage" for better +historical coverage, or TZ="AKST9AKDT,M3.2.0,M11.1.0" for POSIX +conformance and coverage for recent timestamps only. .PP The .BR localtime (3) function -uses the first standard-time +normally uses the first .I ttinfo structure in the file -(or simply the first -.I ttinfo -structure in the absence of a standard-time structure) if either .I tzh_timecnt is zero or the time argument is less than the first transition time recorded diff --git a/tzfile.h b/tzfile.h index 52673d6..ee91104 100644 --- a/tzfile.h +++ b/tzfile.h @@ -69,14 +69,15 @@ struct tzhead { ** one (char [4]) total correction after above ** tzh_ttisstdcnt (char)s indexed by type; if 1, transition ** time is standard time, if 0, -** transition time is wall clock time -** if absent, transition times are -** assumed to be wall clock time -** tzh_ttisutcnt (char)s indexed by type; if 1, transition -** time is UT, if 0, -** transition time is local time -** if absent, transition times are +** transition time is local (wall clock) +** time; if absent, transition times are ** assumed to be local time +** tzh_ttisutcnt (char)s indexed by type; if 1, transition +** time is UT, if 0, transition time is +** local time; if absent, transition +** times are assumed to be local time. +** When this is 1, the corresponding +** std/wall indicator must also be 1. */ /* diff --git a/zic.8 b/zic.8 index 02b6048..3a4d96f 100644 --- a/zic.8 +++ b/zic.8 @@ -385,13 +385,12 @@ to other applications requiring greater precision. The source format does not specify any maximum precision. Any of these forms may be followed by the letter .B w -if the given time is local +if the given time is local or .q "wall clock" time, .B s -if the given time is local -.q "standard" -time, or +if the given time is standard time without any adjustment for daylight saving, +or .B u (or .B g @@ -399,7 +398,7 @@ or .BR z ) if the given time is universal time; in the absence of an indicator, -wall clock time is assumed. +local (wall clock) time is assumed. These forms ignore leap seconds; for example, if a leap second occurs at 00:59:60 local time, .q "1:00" @@ -478,7 +477,8 @@ a file name component is a maximal substring that does not contain .q "/" . .TP .B STDOFF -The amount of time to add to UT to get standard time. +The amount of time to add to UT to get standard time, +without any adjustment for daylight saving. This field has the same format as the .B AT and @@ -636,7 +636,7 @@ or (an abbreviation of) .q "Rolling" if the leap second time given by the other fields should be interpreted as -local wall clock time. +local (wall clock) time. .SH "EXTENDED EXAMPLE" Here is an extended example of .B zic @@ -720,7 +720,7 @@ coincides with and is equal to a clock retreat caused by a change in UT offset, .B zic produces a single transition to daylight saving at the new UT offset -(without any change in wall clock time). +without any change in local (wall clock) time. To get separate transitions use multiple zone continuation lines specifying transition instants using universal time. diff --git a/zic.c b/zic.c index b3665bd..3fb32c7 100644 --- a/zic.c +++ b/zic.c @@ -92,10 +92,8 @@ struct rule { int r_wday; zic_t r_tod; /* time from midnight */ - bool r_todisstd; /* above is standard time if 1 */ - /* or wall clock time if 0 */ - bool r_todisut; /* above is GMT if 1 */ - /* or local time if 0 */ + bool r_todisstd; /* is r_tod standard time? */ + bool r_todisut; /* is r_tod UT? */ bool r_isdst; /* is this daylight saving time? */ zic_t r_save; /* offset from standard time */ const char * r_abbrvar; /* variable part of abbreviation */ -- 2.21.0

1 0

[PROPOSED] Fix 'zic -b slim' bug with TZ='CET'
by Paul Eggert June 15, 2019

June 15, 2019

Without this fix, 'zic -b slim' can mishandle transitions in the few obsolescent zones like CET that do not start with local mean time. For example, for CET it incorrectly optimizes away the first and third transitions, and treats the second transition as one to standard time instead of to DST. * zic.c (swaptypes): Remove. All uses removed. (writezone): Swap indices rather than contents of the old type 0 and the new (default) type 0 array entries. --- zic.c | 44 +++++++++++++++++++------------------------- 1 file changed, 19 insertions(+), 25 deletions(-) diff --git a/zic.c b/zic.c index 34228a5..03f33ee 100644 --- a/zic.c +++ b/zic.c @@ -1810,17 +1810,6 @@ atcomp(const void *avp, const void *bvp) return (a < b) ? -1 : (a > b); } -static void -swaptypes(int i, int j) -{ - { zic_t t = gmtoffs[i]; gmtoffs[i] = gmtoffs[j]; gmtoffs[j] = t; } - { char t = isdsts[i]; isdsts[i] = isdsts[j]; isdsts[j] = t; } - { unsigned char t = abbrinds[i]; abbrinds[i] = abbrinds[j]; - abbrinds[j] = t; } - { bool t = ttisstds[i]; ttisstds[i] = ttisstds[j]; ttisstds[j] = t; } - { bool t = ttisgmts[i]; ttisgmts[i] = ttisgmts[j]; ttisgmts[j] = t; } -} - struct timerange { int defaulttype; ptrdiff_t base, count; @@ -2066,7 +2055,6 @@ writezone(const char *const name, const char *const string, char version, THISDEFAULTTYPE appears as type 0 in the output instead of OLD0. TYPEMAP also omits unused types. */ old0 = strlen(omittype); - swaptypes(old0, thisdefaulttype); #ifndef LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH /* @@ -2085,12 +2073,16 @@ writezone(const char *const name, const char *const string, char version, if (isdsts[types[i]]) mrudst = types[i]; else mrustd = types[i]; - for (i = old0; i < typecnt; i++) - if (!omittype[i]) { - if (isdsts[i]) - hidst = i; - else histd = i; - } + for (i = old0; i < typecnt; i++) { + int h = (i == old0 ? thisdefaulttype + : i == thisdefaulttype ? old0 : i); + if (!omittype[h]) { + if (isdsts[h]) + hidst = i; + else + histd = i; + } + } if (hidst >= 0 && mrudst >= 0 && hidst != mrudst && gmtoffs[hidst] != gmtoffs[mrudst]) { isdsts[mrudst] = -1; @@ -2204,12 +2196,15 @@ writezone(const char *const name, const char *const string, char version, if (hicut) putc(currenttype, fp); - for (i = old0; i < typecnt; i++) - if (!omittype[i]) { - puttzcode(gmtoffs[i], fp); - putc(isdsts[i], fp); - putc((unsigned char) indmap[abbrinds[i]], fp); - } + for (i = old0; i < typecnt; i++) { + int h = (i == old0 ? thisdefaulttype + : i == thisdefaulttype ? old0 : i); + if (!omittype[h]) { + puttzcode(gmtoffs[h], fp); + putc(isdsts[h], fp); + putc(indmap[abbrinds[h]], fp); + } + } if (thischarcnt != 0) fwrite(thischars, sizeof thischars[0], thischarcnt, fp); @@ -2244,7 +2239,6 @@ writezone(const char *const name, const char *const string, char version, for (i = old0; i < typecnt; i++) if (!omittype[i]) putc(ttisgmts[i], fp); - swaptypes(old0, thisdefaulttype); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); -- 2.21.0

1 0

[PROPOSED] * NEWS: Mention -b slim briefly.
by Paul Eggert June 14, 2019

June 14, 2019

--- NEWS | 1 + 1 file changed, 1 insertion(+) diff --git a/NEWS b/NEWS index 0e4c688..7aaae11 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: Brazil no longer observes DST. + 'zic -b slim' outputs smaller TZif files; please try it out. Palestine's 2019 spring-forward transition was on 03-29, not 03-30. Changes to future timestamps -- 2.21.0

1 0

[PROPOSED 1/3] Tune and simplify addtype
by Paul Eggert June 14, 2019

June 14, 2019

* zic.c (addtype): Avoid the need to call strcmp each time through the loop checking for duplicate zone types. The strcmp is unnecessary if we already have checked for duplicate abbreviations and so can just look at the strings’ offsets. So, look for those duplicates first. --- zic.c | 36 +++++++++++++++++++----------------- 1 file changed, 19 insertions(+), 17 deletions(-) diff --git a/zic.c b/zic.c index 2cd8cc7..3e27a48 100644 --- a/zic.c +++ b/zic.c @@ -2876,16 +2876,28 @@ addtype(zic_t gmtoff, char const *abbr, bool isdst, bool ttisstd, bool ttisgmt) { register int i, j; - /* - ** See if there's already an entry for this zone type. - ** If so, just return its index. - */ - for (i = 0; i < typecnt; ++i) { + if (! (-1L - 2147483647L <= gmtoff && gmtoff <= 2147483647L)) { + error(_("UT offset out of range")); + exit(EXIT_FAILURE); + } + + for (j = 0; j < charcnt; ++j) + if (strcmp(&chars[j], abbr) == 0) + break; + if (j == charcnt) + newabbr(abbr); + else { + /* + ** See if there's already an entry for this zone type. + ** If so, just return its index. + */ + for (i = 0; i < typecnt; i++) { if (gmtoff == gmtoffs[i] && isdst == isdsts[i] && - strcmp(abbr, &chars[abbrinds[i]]) == 0 && + j == abbrinds[i] && ttisstd == ttisstds[i] && ttisgmt == ttisgmts[i]) return i; + } } /* ** There isn't one; add a new one, unless there are already too @@ -2895,22 +2907,12 @@ addtype(zic_t gmtoff, char const *abbr, bool isdst, bool ttisstd, bool ttisgmt) error(_("too many local time types")); exit(EXIT_FAILURE); } - if (! (-1L - 2147483647L <= gmtoff && gmtoff <= 2147483647L)) { - error(_("UT offset out of range")); - exit(EXIT_FAILURE); - } + i = typecnt++; gmtoffs[i] = gmtoff; isdsts[i] = isdst; ttisstds[i] = ttisstd; ttisgmts[i] = ttisgmt; - - for (j = 0; j < charcnt; ++j) - if (strcmp(&chars[j], abbr) == 0) - break; - if (j == charcnt) - newabbr(abbr); abbrinds[i] = j; - ++typecnt; return i; } -- 2.21.0

1 2

UTC calculation for March 12, 3001 [IANA #1143241], [PR 9419866]
by Lasher, Beth June 10, 2019

June 10, 2019

In the year 3001, Daylight Savings time is applied on Sunday March 9, 3001 as expected. (Eastern Standard time). BUT on the following Thursday, March 12, 3001 at 3 am, it seems that another Daylight Savings Time change is applied. After March 12, 3001, the UTC time zone offset for Eastern Daylight Savings Time is 3 hours (not 4) and remains that way until the year 9999. Is this correct? What is the cause of this second time offset change?

10 16

[PROPOSED] Cite US DST legislation
by Paul Eggert June 7, 2019

June 7, 2019

* northamerica: Cite all the US federal DST legislation. (US): Adjust table to match the legislation more closely. This does not affect the TZif output files. --- northamerica | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/northamerica b/northamerica index 65827ec..52898de 100644 --- a/northamerica +++ b/northamerica @@ -93,10 +93,24 @@ # was the first nationwide legal time standard, and apparently # time was just called "Standard Time" or "Daylight Saving Time". -# From Arthur David Olson: -# US Daylight Saving Time ended on the last Sunday of *October* in 1974. -# See, for example, the front page of the Saturday, 1974-10-26 -# and Sunday, 1974-10-27 editions of the Washington Post. +# From Paul Eggert (2019-06-04): +# Here is the legal basis for the US federal rules. +# * Public Law 65-107 (1918-03-19) implemented standard and daylight saving +# time for the first time across the US, springing forward on March's last +# Sunday and falling back on October's last Sunday. +# * Public Law 66-40 (1919-08-20) repealed DST on October 1919's last Sunday. +# * Public Law 77-403 (1942-01-20) started wartime DST on 1942-02-09. +# * Public Law 79-187 (1945-09-25) ended wartime DST on 1945-09-30. +# * Public Law 89-387 (1966-04-13) reinstituted a national standard for DST, +# from April's last Sunday to October's last Sunday, effective 1967. +# * Public Law 93-182 (1973-12-15) moved the 1974 spring-forward to 01-06. +# * Public Law 94-434 (1974-10-05) moved the 1975 spring-forward to +# February's last Sunday. +# * Public Law 99-359 (1986-07-08) moved the spring-forward to April's first +# Sunday. +# * Public Law 109-50 (2005-08-08), effective 2007, moved the spring-forward +# to March's second Sunday and the fall-back to November's first Sunday. +# All transitions are at 02:00 local time. # From Arthur David Olson: # Before the Uniform Time Act of 1966 took effect in 1967, observance of @@ -152,11 +166,11 @@ Rule US 1918 1919 - Mar lastSun 2:00 1:00 D Rule US 1918 1919 - Oct lastSun 2:00 0 S Rule US 1942 only - Feb 9 2:00 1:00 W # War Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace -Rule US 1945 only - Sep lastSun 2:00 0 S +Rule US 1945 only - Sep 30 2:00 0 S Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1967 1973 - Apr lastSun 2:00 1:00 D Rule US 1974 only - Jan 6 2:00 1:00 D -Rule US 1975 only - Feb 23 2:00 1:00 D +Rule US 1975 only - Feb lastSun 2:00 1:00 D Rule US 1976 1986 - Apr lastSun 2:00 1:00 D Rule US 1987 2006 - Apr Sun>=1 2:00 1:00 D Rule US 2007 max - Mar Sun>=8 2:00 1:00 D -- 2.21.0

5 8

tzdb-latest.tar.gz download issue
by Matt Johnson June 4, 2019

June 4, 2019

The lzip file, https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz redirects to https://data.iana.org/time-zones/tzdb-latest.tar.lz and downloads successfully. The gzip file, https://www.iana.org/time-zones/repository/tzdb-latest.tar.gz redirects to https://data.iana.org/time-zones/tzdb-latest.tar.gz and then fails with a 404. They both used to work, not sure what happened. Thanks, Matt

4 4

Extend POSIX TZ to allow transition times outside 00-24 range, permanent DST
by Paul Eggert June 3, 2019

June 3, 2019

I recently proposed extending the POSIX spec for TZ strings. Please see: http://austingroupbugs.net/view.php?id=1252 This proposal is a modest one, as it doesn't specify TZ strings like 'America/Los_Angeles'. Instead it merely specifies the strings generated by zic and stored into TZif files. This includes strings like '<-03>3<-02>,M3.5.0/-2,M10.5.0/-1' which use times of day outside the 00-24 range, and strings like 'EST5EDT,0/0,J365/25' that represent permanent daylight saving time. This extension to POSIX TZ strings has already been specified in Internet RFC 8536 section 3.3.1 <https://tools.ietf.org/html/rfc8536#page-13> and I think it's a good idea to backport the extension to POSIX itself, as this will bless the common practice of taking the last line of a TZif file and using it as a TZ string on small platforms that lack room to store the TZif files. Please feel free to comment at austingroupbugs.net.

1 0

[PROPOSED] Add an outline to tz-link.html
by Paul Eggert June 1, 2019

June 1, 2019

* tz-link.html: Add an outline, so that it’s more like theory.html. --- tz-link.html | 94 ++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index e0d8cc8..85fc001 100644 --- a/tz-link.html +++ b/tz-link.html @@ -18,6 +18,46 @@ histories and planned futures are often recorded only fitfully. Here is a summary of attempts to organize and record relevant data in this area. </p> + <h3>Outline</h3> + <nav> + <ul> + <li>The <code><abbr>tz</abbr></code> database product and process + <ul> + <li><a href="#tzdb">The <code><abbr>tz</abbr></code> database</a></li> + <li><a href="#download">Downloading the <code><abbr>tz</abbr></code> database</a></li> + <li><a href="#changes">Changes to the <code><abbr>tz</abbr></code> database</a></li> + <li><a href="#commentary">Commentary on the <code><abbr>tz</abbr></code> database</a></li> + </ul> + </li> + <li>Uses of the <code><abbr>tz</abbr></code> database + <ul> + <li><a href="#web">Web sites using recent versions of the <code><abbr>tz</abbr></code> database</a></li> + <li><a href="#protocols">Network protocols for <code><abbr>tz</abbr></code> data</a></li> + <li><a href="#compilers">Other <code><abbr>tz</abbr></code> compilers</a></li> + <li><a href="#TZif">Other <abbr>TZif</abbr> readers</a></li> + <li><a href="#software">Other <code><abbr>tz</abbr></code>-based time zone software</a></li> + </ul> + </li> + <li>Related data + <ul> + <li><a href="#other-dbs">Other time zone databases</a></li> + <li><a href="#maps">Maps</a></li> + <li><a href="#boundaries">Time zone boundaries</a></li> + </ul> + </li> + <li>Timekeeping concepts + <ul> + <li><a href="#civil">Civil time concepts and history</a></li> + <li><a href="#national">National histories of legal time</a></li> + <li><a href="#precision">Precision timekeeping</a></li> + <li><a href="#notation">Time notation</a></li> + <li><a href="#see-also">See also</a></li> + </ul> + </li> + </ul> + </nav> + +<section> <h2 id="tzdb">The <code><abbr title="time zone">tz</abbr></code> database</h2> <p> The <a href="https://en.wikipedia.org/wiki/Public_domain">public-domain</a> @@ -88,6 +128,9 @@ Universal Time</a> (<abbr>UTC</abbr>). The database also records when daylight saving time was in use, along with some time zone abbreviations such as <abbr>EST</abbr> for Eastern Standard Time in the <abbr>US</abbr>.</p> +</section> + +<section> <h2 id="download">Downloading the <code><abbr>tz</abbr></code> database</h2> <p> The following <a @@ -148,6 +191,9 @@ specified by <a href="https://tools.ietf.org/html/8536">Internet The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> +</section> + +<section> <h2 id="changes">Changes to the <code><abbr>tz</abbr></code> database</h2> <p> The <code><abbr>tz</abbr></code> code and data @@ -226,6 +272,9 @@ found in <a href="theory.html">Theory and pragmatics of the tz code and data</a> <a href="https://a0.github.io/a0-tzmigration/">A0 TimeZone Migration</a> displays changes between recent <code><abbr>tzdb</abbr></code> versions. </p> +</section> + +<section> <h2 id="commentary">Commentary on the <code><abbr>tz</abbr></code> database</h2> <ul> <li>The article @@ -239,6 +288,9 @@ href="https://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonz literary appreciation of the Olson/Zoneinfo/tz database</a> comments on the database's style.</li> </ul> +</section> + +<section> <h2 id="web">Web sites using recent versions of the <code><abbr>tz</abbr></code> database</h2> <p> @@ -270,6 +322,9 @@ calculates the current time difference between locations.</li> <li><a href="http://www.wx-now.com">Weather Now</a> and <a href="http://www.thetimenow.com">The Time Now</a> list the weather too.</li> </ul> +</section> + +<section> <h2 id="protocols">Network protocols for <code><abbr>tz</abbr></code> data</h2> <ul> <li>The <a href="https://www.ietf.org">Internet Engineering Task Force</a>'s @@ -302,6 +357,9 @@ title="Extensible Markup Language">XML</abbr></a> format, and a variant uses <a href="https://www.json.org"><abbr title="JavaScript Object Notation">JSON</abbr></a> format.</li> </ul> +</section> + +<section> <h2 id="compilers">Other <code><abbr>tz</abbr></code> compilers</h2> <ul> <li><a href="https://sourceforge.net/projects/vzic/">Vzic</a> is a <a @@ -439,6 +497,9 @@ source into text files, along with a runtime that can read those files. Tcl is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> +</section> + +<section> <h2 id="TZif">Other <abbr>TZif</abbr> readers</h2> <ul> <li>The <a @@ -497,6 +558,9 @@ package contains <a href="https://www.haskell.org">Haskell</a> code that parses and uses <abbr>TZif</abbr> data. It is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> +</section> + +<section> <h2 id="software">Other <code><abbr>tz</abbr></code>-based time zone software</h2> <ul> <li><a href="https://foxclocks.org">FoxClocks</a> @@ -554,6 +618,9 @@ a macOS program. Its developers <a href="http://veladg.com/tzoffer.html">offer free licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> </ul> +</section> + +<section> <h2 id="other-dbs">Other time zone databases</h2> <ul> <li><a href="https://www.astro.com/atlas">Time-zone Atlas</a> @@ -582,6 +649,9 @@ Schedules Information Manual</a> of the International Air Transport Association gives current time zone rules for airports served by commercial aviation.</li> </ul> +</section> + +<section> <h2 id="maps">Maps</h2> <ul> <li>The <a href="https://www.cia.gov/index.html">United States Central @@ -609,6 +679,9 @@ much is time wrong around the world?</a> maps the difference between mean solar and standard time, highlighting areas such as western China where the two differ greatly. It's a bit out of date, unfortunately.</li> </ul> +</section> + +<section> <h2 id="boundaries">Time zone boundaries</h2> <p>Geographical boundaries between timezones are available from several <a href="https://en.wikipedia.org/wiki/Geolocation">geolocation</a> @@ -683,6 +756,9 @@ for land and territorial waters only). A captain can change ship's clocks any time after entering a new time zone; midnight changes are common.</li> </ul> +</section> + +<section> <h2 id="civil">Civil time concepts and history</h2> <ul> <li><a href="https://www.nist.gov/pml/time-and-frequency-division/popular-links/walk-thr…">A @@ -704,6 +780,9 @@ time zone boundary.</li> <li><a href="http://statoids.com/tconcept.html">Basic Time Zone Concepts</a> discusses terminological issues behind time zones.</li> </ul> +</section> + +<section> <h2 id="national">National histories of legal time</h2> <dl> <dt>Australia</dt> @@ -790,6 +869,9 @@ Navy (SOHMA) publishes an annual <a href="http://www.armada.gub.uy/sohma/index.php/servicios/datos-astronomicos" hreflang="es">almanac (in Spanish)</a>.</dd> </dl> +</section> + +<section> <h2 id="precision">Precision timekeeping</h2> <ul> <li><a @@ -878,6 +960,9 @@ without Leap Seconds</a> gives pointers on this contentious issue, which was active until 2015 and could become active again.</li> </ul> +</section> + +<section> <h2 id="notation">Time notation</h2> <ul> <li>The <a id="CLDR" href="http://cldr.unicode.org">Unicode Common Locale Data @@ -946,18 +1031,23 @@ any future changes to the rules. One should never set local time is nine hours ahead of <abbr>UT</abbr> and the time zone is called "<abbr>GMT</abbr>".</li> </ul> +</section> + +<section> <h2 id="see-also">See also</h2> <ul> <li><a href="theory.html">Theory and pragmatics of the tz code and data</a></li> <li><a href="tz-art.html">Time and the Arts</a></li> </ul> +</section> + +<footer> <hr> -<address> This web page is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. <br> Please send corrections to this web page to the <a href="mailto:tz@iana.org">time zone mailing list</a>. -</address> +</footer> </body> </html> -- 2.17.1

1 0

Hong Kong Time history
by P Chan May 31, 2019

May 31, 2019

*According to the Hong Kong Daylight-Saving Regulations, 1941, the 1941 spring-forward transition was at 03:00. http://sunzi.lib.hku.hk/hkgro/view/g1941/304271.pdf http://sunzi.lib.hku.hk/hkgro/view/g1941/305516.pdf *According to some articles from South China Morning Post, +08 was resumed on 1945-11-18 at 02:00. https://i.imgur.com/M2IsZ3c.png https://i.imgur.com/iOPqrVo.png https://i.imgur.com/fffcGDs.png *Some newspapers published on said the 1946 spring-forward transition was on 04-21 at 00:00. The Kung Sheung Evening News 1946-04-20 (Chinese) https://i.imgur.com/ZSzent0.png https://mmis.hkpl.gov.hk///c/portal/cover?c=QF757YsWv5%2FH7zGe%2FKF%2BFLYsu… p.4 The Kung Sheung Daily News 1946-04-21 (Chinese) https://i.imgur.com/7ecmRlcm.png https://mmis.hkpl.gov.hk///c/portal/cover?c=QF757YsWv5%2BQBGt1%2BwUj5qG2Gqt… p.4 *According to the Summer Time Ordinance (1946), the fallback transitions between 1946 and 1952 were at 03:30 Standard Time (+08) http://oelawhk.lib.hku.hk/archive/files/bb74b06a74d5294620a15de560ab33c6.pdf *Some other laws and regulations related to DST from 1953 to 1979 Summer Time Ordinance 1953 https://i.imgur.com/IOlJMav.jpg Summer Time (Amendment) Ordinance 1965 https://i.imgur.com/8rofeLa.jpg Interpretation and General Clauses Ordinance (1966) https://i.imgur.com/joy3msj.jpg Emergency (Summer Time) Regulation 1973 https://i.imgur.com/OpRWrKz.jpg Interpretation and General Clauses (Amendment) Ordinance 1977 https://i.imgur.com/RaNqnc4.jpg Resolution of the Legislative Council passed on 9 May 1979 https://www.legco.gov.hk/yr78-79/english/lc_sitg/hansard/h790509.pdf#page=39 P Chan

4 7

[PROPOSED 1/2] Update URLs
by Paul Eggert May 31, 2019

May 31, 2019

* northamerica, theory.html, tz-art.html, tz-how-to.html, tz-link.html: Update URLs. A lot of this is replacing "http:" by "https:" when either will do; most of the rest is updating URLs that moved. The substantive changes are upgrading from ISO 8601:2004 to ISO 8601-1:2019, adding a C++20 link, removing URLs for DJGPP and Walltime-js (now obsolete), removing URLs maintained by the National Physical Laboratory and astrologyschool.com (no longer existing), and saying that draft-murchison-tzdist-geolocate is expired. --- northamerica | 2 +- theory.html | 12 ++++---- tz-art.html | 48 ++++++++++++++--------------- tz-how-to.html | 4 +-- tz-link.html | 83 +++++++++++++++++++++----------------------------- 5 files changed, 68 insertions(+), 81 deletions(-) diff --git a/northamerica b/northamerica index fce043f..65827ec 100644 --- a/northamerica +++ b/northamerica @@ -2494,7 +2494,7 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # From Paul Eggert (2001-03-03): # -# http://www.latimes.com/news/nation/20010303/t000018766.html +# https://www.latimes.com/archives/la-xpm-2001-mar-03-mn-32561-story.html # James F. Smith writes in today's LA Times # * Sonora will continue to observe standard time. # * Last week Mexico City's mayor Andrés Manuel López Obrador decreed that diff --git a/theory.html b/theory.html index e373022..e580ccc 100644 --- a/theory.html +++ b/theory.html @@ -88,7 +88,7 @@ href="https://en.wikipedia.org/wiki/POSIX">POSIX</a>, an international standard for <a href="https://en.wikipedia.org/wiki/Unix">UNIX</a>-like systems. As of this writing, the current edition of POSIX is: <a -href="http://pubs.opengroup.org/onlinepubs/9699919799/"> The Open +href="https://pubs.opengroup.org/onlinepubs/9699919799/"> The Open Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2017, 2018 Edition. Because the database's scope encompasses real-world changes to civil @@ -186,7 +186,7 @@ in decreasing order of importance: href="https://en.wikipedia.org/wiki/ASCII">ASCII</a> letters, '<code>.</code>', '<code>-</code>' and '<code>_</code>'. Do not use digits, as that might create an ambiguity with <a - href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag…">POSIX + href="https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta…">POSIX <code>TZ</code> strings</a>. A file name component must not exceed 14 characters or start with '<code>-</code>'. @@ -379,8 +379,8 @@ in decreasing order of importance: special meaning to the <a href="https://en.wikipedia.org/wiki/Unix_shell">UNIX shell</a> and cause commands like - '<code><a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set">set</a> - `<a href="http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html">date</a>`</code>' + '<code><a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#s…">set</a> + `<a href="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html">date</a>`</code>' to have unexpected effects. Previous editions of this guideline required upper-case letters, but the Congressman who introduced @@ -1354,11 +1354,11 @@ Sources for time on other planets: Michael Allison and Robert Schmunk, "<a href="https://www.giss.nasa.gov/tools/mars24/help/notes.html">Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock</a>" - (2015-06-30). + (2018-12-13). </li> <li> Jia-Rui Chong, - "<a href="http://articles.latimes.com/2004/jan/14/science/sci-marstime14">Workdays + "<a href="https://www.latimes.com/archives/la-xpm-2004-jan-14-sci-marstime14-story.ht…">Workdays Fit for a Martian</a>", <cite>Los Angeles Times</cite> (2004-01-14), pp A1, A20–A21. </li> diff --git a/tz-art.html b/tz-art.html index 32f523e..8c57174 100644 --- a/tz-art.html +++ b/tz-art.html @@ -25,7 +25,7 @@ briefly says why France has more time zones than Russia. "About Time" (1962; 59 minutes) is part of the Bell Science extravaganza, with Frank Baxter, Richard Deacon, and Les Tremayne. Its advisor was Richard Feynman, and it was voiced by Mel Blanc. -(<a href="http://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> +(<a href="https://www.imdb.com/title/tt0154110/">IMDb entry</a>.)</li> </ul> <h2>Movies</h2> <ul> @@ -36,14 +36,14 @@ there is a reference to British Double Summer Time. The time does not play a large part in the plot; it's just a passing reference to the time when one of the characters was supposed to have died (but didn't). -(<a href="http://us.imdb.com/title/tt0038733/">IMDb entry.</a>) +(<a href="https://www.imdb.com/title/tt0038733/">IMDb entry.</a>) (Dave Cantor) <li> The 1953 railway comedy movie <em>The Titfield Thunderbolt</em> includes a play on words on British Double Summer Time. Valentine's wife wants him to leave the pub and asks him, "Do you know what time it is?" And he, happy where he is, replies: "Yes, my love. Summer double time." -(<a href="http://us.imdb.com/title/tt0046436/">IMDb entry.</a>) +(<a href="https://www.imdb.com/title/tt0046436/">IMDb entry.</a>) (Mark Brader, 2009-10-02) </li> <li> @@ -56,7 +56,7 @@ a gigantic computerized theft. To achieve this, at one location the crooks interfere with the microwave system supplying time signals to the computer, advancing the time by 0.1 second each minute over the last hour of 1999. (So this movie teaches us that 0.1 × 60 = 10.) -(<a href="http://us.imdb.com/title/tt0137494/">IMDb entry.</a>) +(<a href="https://www.imdb.com/title/tt0137494/">IMDb entry.</a>) (Mark Brader, 2009-10-02) </li> <li> @@ -183,7 +183,7 @@ European readers of the 1870s clearly held the U.S. press in deep contempt; the protagonists cross the U.S. without once reading a paper. Available versions include -<a href="http://www.literature.org/Works/Jules-Verne/eighty">an English +<a href="https://www.gutenberg.org/ebooks/103">an English translation</a>, and <a href="https://fourmilab.ch/etexts/www/tdm80j">the original French</a> "with illustrations from the original 1873 French-language edition". @@ -203,7 +203,7 @@ part in the novel." (Paul Eggert, 2006-04-22) </li> <li> John Dunning, <a -href="http://books.simonandschuster.com/Two-OClock-Eastern-Wartime/John-Dunning/9…"><em>Two +href="https://www.simonandschuster.com/books/Two-OClock-Eastern-Wartime/John-Dunn…"><em>Two O'Clock, Eastern Wartime</em></a>, 2001. Mystery, history, daylight saving time, and old-time radio. </li> @@ -234,7 +234,7 @@ Todd Strait, drums</td></tr> <tr><td>Notes</td><td>CD notes "additional lyric by Karrin Allyson; arranged by Russ Long and Karrin Allyson"</td></tr> <tr><td>ADO Rating</td><td>1 star</td></tr> -<tr><td><a href="http://www.allmusic.com/album/i-didnt-know-about-you-mw0000618657">AMG Rating</a></td><td>4 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/i-didnt-know-about-you-mw0000618657">AMG Rating</a></td><td>4 stars</td></tr> <tr><td>Penguin Rating</td><td>3.5 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Kevin Mahogany</td></tr> @@ -249,7 +249,7 @@ Ray Drummond, bass; Ralph Moore, tenor saxophone; Lewis Nash, drums</td></tr> <tr><td>ADO Rating</td><td>1.5 stars</td></tr> -<tr><td><a href="http://www.allmusic.com/album/double-rainbow-mw0000620371">AMG Rating</a></td><td>3 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/double-rainbow-mw0000620371">AMG Rating</a></td><td>3 stars</td></tr> <tr><td>Penguin Rating</td><td>3 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Joe Williams</td></tr> @@ -263,7 +263,7 @@ The Robert Farnon [39 piece] Orchestra</td></tr> <tr><td>Notes</td><td>This CD is also available as part of a 3-CD package from Telarc, "Triple Play" (CD-83461)</td></tr> <tr><td>ADO Rating</td><td>black dot</td></tr> -<tr><td><a href="http://www.allmusic.com/album/heres-to-life-mw0000623648">AMG Rating</a></td><td>2 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/heres-to-life-mw0000623648">AMG Rating</a></td><td>2 stars</td></tr> <tr><td>Penguin Rating</td><td>3 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Charles Fambrough</td></tr> @@ -278,7 +278,7 @@ Edward Simon, piano; Lenny White, drums; Marion Simon, percussion</td></tr> <tr><td>ADO Rating</td><td>2 stars</td></tr> -<tr><td><a href="http://www.allmusic.com/album/keeper-of-the-spirit-mw0000176559">AMG Rating</a></td><td>unrated</td></tr> +<tr><td><a href="https://www.allmusic.com/album/keeper-of-the-spirit-mw0000176559">AMG Rating</a></td><td>unrated</td></tr> <tr><td>Penguin Rating</td><td>3 stars</td></tr> </table> <hr> @@ -296,7 +296,7 @@ David Piltch, string bass</td></tr> <tr><td>Notes</td><td>Lyrical reference to "Eastern Standard Time" in Tom Waits' "Purple Avenue"</td></tr> <tr><td>ADO Rating</td><td>2.5 stars</td></tr> -<tr><td><a href="http://www.allmusic.com/album/blame-it-on-my-youth-mw0000274303">AMG Rating</a></td><td>3 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/blame-it-on-my-youth-mw0000274303">AMG Rating</a></td><td>3 stars</td></tr> <tr><td>Penguin Rating</td><td>unrated</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Milt Hinton</td></tr> @@ -327,7 +327,7 @@ and Good Time Charlie. <a href="http://www.chiaroscurojazz.com/album.php?C=310">Album info</a> is available.</td></tr> <tr><td>ADO Rating</td><td>3 stars</td></tr> -<tr><td><a href="http://www.allmusic.com/album/old-man-time-mw0000269353">AMG Rating</a></td><td>4.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/old-man-time-mw0000269353">AMG Rating</a></td><td>4.5 stars</td></tr> <tr><td>Penguin Rating</td><td>3 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Alan Broadbent</td></tr> @@ -341,7 +341,7 @@ Putter Smith, Bass; Frank Gibson, Jr., drums</td></tr> <tr><td>Notes</td><td>The CD cover features an analemma for equation-of-time fans</td></tr> <tr><td>ADO Rating</td><td>1 star</td></tr> -<tr><td><a href="http://www.allmusic.com/album/pacific-standard-time-mw0000645433">AMG Rating</a></td><td>4 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/pacific-standard-time-mw0000645433">AMG Rating</a></td><td>4 stars</td></tr> <tr><td>Penguin Rating</td><td>3.5 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Anthony Braxton/Richard Teitelbaum</td></tr> @@ -356,7 +356,7 @@ Leo Smith, trumpet and miscellaneous instruments; Leroy Jenkins, violin and miscellaneous instruments; Richard Teitelbaum, modular moog and micromoog synthesizer</td></tr> <tr><td>ADO Rating</td><td>black dot</td></tr> -<tr><td><a href="http://www.allmusic.com/album/silence-time-zones-mw0000595735">AMG Rating</a></td><td>4 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/silence-time-zones-mw0000595735">AMG Rating</a></td><td>4 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Charles Gayle</td></tr> <tr><td>CD</td><td>Time Zones</td></tr> @@ -366,7 +366,7 @@ Richard Teitelbaum, modular moog and micromoog synthesizer</td></tr> <tr><td>Total Time</td><td>49:06</td></tr> <tr><td>Personnel</td><td>Charles Gayle, piano</td></tr> <tr><td>ADO Rating</td><td>1 star</td></tr> -<tr><td><a href="http://www.allmusic.com/album/time-zones-mw0000349642">AMG Rating</a></td><td>4.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/time-zones-mw0000349642">AMG Rating</a></td><td>4.5 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>The Get Up Kids</td></tr> <tr><td>CD</td><td>Eudora</td></tr> @@ -375,7 +375,7 @@ Richard Teitelbaum, modular moog and micromoog synthesizer</td></tr> <tr><td>ID</td><td>357</td></tr> <tr><td>Total Time</td><td>65:12</td></tr> <tr><td>Notes</td><td>Includes the song "Central Standard Time." Thanks to Colin Bowern for this information.</td></tr> -<tr><td><a href="http://www.allmusic.com/album/eudora-mw0000592063">AMG Rating</a></td><td>2.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/eudora-mw0000592063">AMG Rating</a></td><td>2.5 stars</td></tr> <tr><td> </td><td></td></tr> <tr><td>Artist</td><td>Coldplay</td></tr> @@ -420,7 +420,7 @@ Supernaw.</td></tr> <tr><td>ID</td><td>272</td></tr> <tr><td>Total Time</td><td>73:05</td></tr> <tr><td>Notes</td><td>Includes the song "Twilight Time Zone."</td></tr> -<tr><td><a href="http://www.allmusic.com/album/lobster-leaps-in-mw0000794929">AMG Rating</a></td><td>3.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/lobster-leaps-in-mw0000794929">AMG Rating</a></td><td>3.5 stars</td></tr> <tr><td>ADO Rating</td><td>2 stars</td></tr> <tr><td> </td><td></td></tr> @@ -431,7 +431,7 @@ Supernaw.</td></tr> <tr><td>Label</td><td>Columbia</td></tr> <tr><td>ID</td><td>CK-8905</td></tr> <tr><td>Total Time</td><td>45:36</td></tr> -<tr><td><a href="http://www.allmusic.com/album/the-times-they-a-changin-mw0000202344">AMG Rating</a></td><td>4.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/the-times-they-a-changin-mw0000202344">AMG Rating</a></td><td>4.5 stars</td></tr> <tr><td>ADO Rating</td><td>1.5 stars</td></tr> <tr><td>Notes<td>The title song is also available on "Bob Dylan's Greatest Hits" and "The Essential Bob Dylan."</td></tr> <tr><td> </td><td></td></tr> @@ -442,7 +442,7 @@ Supernaw.</td></tr> <tr><td>Label</td><td>Universal Jazz France</td></tr> <tr><td>ID</td><td>B0012688-02</td></tr> <tr><td>Total Time</td><td>42:31</td></tr> -<tr><td><a href="http://www.allmusic.com/album/tide-mw0000815692">AMG Rating</a></td><td>3.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/tide-mw0000815692">AMG Rating</a></td><td>3.5 stars</td></tr> <tr><td>ADO Rating</td><td>2.5 stars</td></tr> <tr><td>Notes<td>Includes the song "Fire and Wood" with the lyric "The clocks were turned back you remember/Think it's still November." @@ -455,7 +455,7 @@ Supernaw.</td></tr> <tr><td>ID</td><td>B0005171-02</td></tr> <tr><td>Total Time</td><td>156:22</td></tr> <tr><td>ADO Rating</td><td>1 star</td></tr> -<tr><td><a href="http://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-master…">AMG Rating</a></td><td>4.5 stars</td></tr> +<tr><td><a href="https://www.allmusic.com/album/youre-getting-better-the-word-jazz-dot-maste…">AMG Rating</a></td><td>4.5 stars</td></tr> <tr><td>Notes</td><td>Includes the piece "What Time Is It" ("He knew what time it was everywhere...that counted").</td></tr> </table> @@ -478,16 +478,16 @@ The related book <em>What If?</em> has an entry </li> <li> Pig kills time in <a -href="http://www.gocomics.com/pearlsbeforeswine/2016/11/06"><em>Pearls +href="https://www.gocomics.com/pearlsbeforeswine/2016/11/06"><em>Pearls Before Swine</em> (2016-11-06)</a>. </li> <li> Stonehenge is abandoned in <a -href='http://www.gocomics.com/nonsequitur/2017/03/12'><em>Non Sequitur</em> +href='https://www.gocomics.com/nonsequitur/2017/03/12'><em>Non Sequitur</em> (2017-03-12)</a>. <li> The boss freaks out in <a -href='http://dilbert.com/strip/1998-03-14'><em>Dilbert</em> (1998-03-14)</a>. +href='https://dilbert.com/strip/1998-03-14'><em>Dilbert</em> (1998-03-14)</a>. </li> <li> Peppermint Patty: "What if the world comes to an end tonight, Marcie?" @@ -495,7 +495,7 @@ Peppermint Patty: "What if the world comes to an end tonight, Marcie?" Marcie: "I promise there'll be a tomorrow, sir ... in fact, it's already tomorrow in Australia!" <br> -(Charles M. Schulz, <a href='http://www.gocomics.com/peanuts/1980/06/13'><em>Peanuts</em>, 1980-06-13</a>) +(Charles M. Schulz, <a href='https://www.gocomics.com/peanuts/1980/06/13'><em>Peanuts</em>, 1980-06-13</a>) </li> </ul> <h2>Jokes</h2> diff --git a/tz-how-to.html b/tz-how-to.html index 8471b67..0bb66ad 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -535,9 +535,9 @@ href="https://en.wikipedia.org/wiki/Internationalization_and_localization">local the abbreviations. They are intended to be the values returned through the <code>"%Z"</code> format specifier to <a href="https://en.wikipedia.org/wiki/C_(programming_language)">C</a>’s -<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html"><code>strftime</code></a> +<a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html"><code>strftime</code></a> function in the -<a href="http://kirste.userpage.fu-berlin.de/chemnet/use/info/libc/libc_19.html#SEC3…">“C” locale</a>. +<a href="https://kirste.userpage.fu-berlin.de/chemnet/use/info/libc/libc_19.html#SEC…">“C” locale</a>. <li>If there is no generally-accepted abbreviation for a time zone, a numeric offset is used instead, e.g., <code>+07</code> for 7 hours diff --git a/tz-link.html b/tz-link.html index 89ebd40..e0d8cc8 100644 --- a/tz-link.html +++ b/tz-link.html @@ -41,8 +41,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://www.openbsd.org">Open<abbr>BSD</abbr></a>, <a href="https://www.chromium.org/chromium-os">Chromium OS</a>, <a href="https://cygwin.com">Cygwin</a>, -<a href="http://www.delorie.com/djgpp/"><abbr -title="DJ's GNU Programming Platform">DJGPP</abbr></a>, <a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, <a href="https://www.mysql.com">MySQL</a>, <a href="https://en.wikipedia.org/wiki/WebOS"><abbr @@ -50,13 +48,13 @@ title="Web Operating System">webOS</abbr></a>, <a href="https://ibm.com/aix"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, <a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, -<a href="https://www.apple.com/ios/"><abbr +<a href="https://www.apple.com/ios"><abbr title="iPhone OS">iOS</abbr></a>, -<a href="https://www.apple.com/macos/">macOS</a>, +<a href="https://www.apple.com/macos">macOS</a>, <a href="https://www.microsoft.com/en-us/windows">Microsoft Windows</a>, -<a href="https://www.hpe.com/info/openvms">Open<abbr +<a href="https://www.vmssoftware.com">Open<abbr title="Virtual Memory System">VMS</abbr></a>, -<a href="https://www.oracle.com/database/index.html">Oracle Database</a>, and +<a href="https://www.oracle.com/database/">Oracle Database</a>, and <a href="https://www.oracle.com/solaris">Oracle Solaris</a>.</p> <p> Each main entry in the database represents a <dfn>timezone</dfn> @@ -251,16 +249,15 @@ 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="http://worldclock.com">The World Clock</a> +<a href="https://worldclock.com">The World Clock</a> are time zone converters.</li> <li><a -href="http://twiki.org/cgi-bin/xtra/tzdatepick.html">Date and Time Gateway</a> +href="https://twiki.org/cgi-bin/xtra/tzdatepick.html">Date and Time Gateway</a> lets you see the <code><abbr>TZ</abbr></code> values directly.</li> <li><a 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="http://www.timezoneconverter.com/cgi-bin/tzc.tzc">Time Zone -Converter</a> +<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 timezone information for all countries</a> displays tables of DST rules. @@ -284,10 +281,10 @@ along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses the Internet draft <a +mailing list</a> discussed the Internet draft <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a>, which lets a client determine its timezone +Geolocate Extension</a> (now expired), which let a client determine its timezone from its geographic location using a <a href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> @@ -318,7 +315,7 @@ General Public License (<abbr title="General Public License">GPL</abbr>)</a>.</li> <li><a href="https://sourceforge.net/projects/tzical/">tziCal – tz database conversion utility</a> is like Vzic, except for the <a -href="https://www.microsoft.com/net">.NET framework</a> +href="https://dotnet.microsoft.com">.NET framework</a> and with a <abbr>BSD</abbr>-style license.</li> <li><a href="https://metacpan.org/release/DateTime-TimeZone">DateTime::TimeZone</a> @@ -336,11 +333,9 @@ 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 the next iteration of <a -href="https://isocpp.org/std/the-standard"><em><abbr -title="International Organization for Standardization">ISO</abbr> -International Standard ISO/IEC 14882:2017(E) – Programming -Language C++</em></a>. +forward</a> for inclusion in +<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 <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> <li><a id="ICU" href="http://site.icu-project.org">International Components for @@ -366,8 +361,7 @@ tool</a> compiles <code><abbr>tz</abbr></code> source into the format used by Oracle Java.</li> <li>The <a href="https://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html">Java -SE <code>java.time</code> <abbr>API</abbr></a> in Java 8 and later -can be supplemented by <a +SE 8 Date and Time</a> <abbr>API</abbr> can be supplemented by <a href="https://www.threeten.org/threeten-extra/">ThreeTen-Extra</a>, which is freely available under a <abbr>BSD</abbr>-style license.</li> <li><a href="https://www.joda.org/joda-time/">Joda-Time – Java date @@ -409,16 +403,14 @@ license.</li> <li><a href="https://github.com/mde/timezone-js">TimezoneJS.Date</a>'s <abbr>API</abbr> is upward compatible with standard JavaScript Dates. It is freely available under the Apache License.</li> -<li><a href="https://github.com/sproutsocial/walltime-js">Walltime-js</a> -translates <abbr>UT</abbr> to local time. It is freely available under -the <abbr>MIT</abbr> license.</li> </ul> <li><a href="https://github.com/JuliaTime/">JuliaTime</a> contains a compiler from <code><abbr>tz</abbr></code> source into <a href="https://julialang.org/">Julia</a>. It is freely available under the <abbr>MIT</abbr> license.</li> -<li><a href="https://github.com/pavkam/tzdb">Delphi/<abbr -title="Free Pascal Compiler">FPC</abbr> Time Zone Database</a> +<li><a href="https://github.com/pavkam/tzdb"><abbr>TZDB</abbr> – +<abbr>IANA</abbr> Time Zone Database for Delphi/<abbr +title="Free Pascal Compiler">FPC</abbr></a> compiles from <code><abbr>tz</abbr></code> source into <a href="https://en.wikipedia.org/wiki/Object_Pascal">Object Pascal</a> as compiled by <a href="https://en.wikipedia.org/wiki/Delphi_(IDE)">Delphi</a> @@ -542,7 +534,7 @@ which stores time zone data in the <a href="https://unicode.org/cldr/charts/latest/supplemental/zone_tzid.html">Zone → Tzid table</a> or <a -href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml"><abbr>XML</abbr> +href="https://github.com/unicode-org/cldr/blob/master/common/supplemental/windows…"><abbr>XML</abbr> file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs to <code><abbr>tz</abbr></code> names. These mappings can be performed programmatically via the <a href="https://github.com/mj1856/TimeZoneConverter">TimeZoneConverter</a> .NET library, @@ -598,15 +590,15 @@ title="Central Intelligence Agency">CIA</abbr>)</a> publishes a <a href="https://www.cia.gov/library/publications/the-world-factbook/graphics/ref_ma…">time zone map</a>; the <a -href="https://www.lib.utexas.edu/maps/world.html">Perry–Castañeda +href="https://legacy.lib.utexas.edu/maps/world.html">Perry–Castañeda Library Map Collection</a> of the University of Texas at Austin has copies of recent editions. The pictorial quality is good, but the maps do not indicate daylight saving time, and parts of the data are a few years out of date.</li> -<li><a href="https://www.worldtimezone.com">Current time around the world -and standard time zones map of the world</a> +<li><a href="https://www.worldtimezone.com">World Time Zone Map +with current time</a> has several fancy time zone maps; it covers Russia particularly well. The maps' pictorial quality is not quite as good as the <abbr>CIA</abbr>'s @@ -715,7 +707,7 @@ Zone Concepts</a> discusses terminological issues behind time zones.</li> <h2 id="national">National histories of legal time</h2> <dl> <dt>Australia</dt> -<dd>The Parliamentary Library has commissioned a <a +<dd>The Parliamentary Library commissioned a <a href="https://www.aph.gov.au/binaries/library/pubs/rp/2009-10/10rp10.pdf">research paper on daylight saving time in Australia</a>. The Bureau of Meteorology publishes a list of <a @@ -733,8 +725,8 @@ Portuguese)</a>.</dd> <dt>Canada</dt> <dd>National Research Council Canada publishes current and some older information about <a -href="https://www.nrc-cnrc.gc.ca/eng/services/time/time_zones.html">time -zones & daylight saving time</a>.</dd> +href="https://nrc.canada.ca/en/certifications-evaluations-standards/canadas-offic…">time +zones and daylight saving time</a>.</dd> <dt>Chile</dt> <dd>The Hydrographic and Oceanographic Service of the Chilean Navy publishes a <a href="https://www.horaoficial.cl/historia_hora.html" hreflang="es">history of @@ -760,7 +752,7 @@ of Legal Time in Germany</a>.</dd> href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" hreflang="he">announcements (in Hebrew)</a>.</dd> <dt>Italy</dt> -<dd>The National Institute of Metrological Research maintains a +<dd>The National Institute of Metrological Research publishes a <a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml" hreflang="it">table of civil time (in Italian)</a>.</dd> <dt>Malaysia</dt> @@ -777,22 +769,17 @@ covers the history of local time in the Netherlands from ancient times.</dd> <dt>New Zealand</dt> <dd>The Department of Internal Affairs maintains a brief <a href="https://www.dia.govt.nz/Daylight-Saving-History">History of -Daylight Saving</a>. The privately-maintained <a -href="http://astrologyschool.com/nztime.html">History of New Zealand -time</a> has more details.</dd> +Daylight Saving</a>.</dd> <dt>Singapore</dt> <dd><a id="Singapore" -href="http://www.math.nus.edu.sg/aslaksen/teaching/timezone.html">Why +href="http://www.math.nus.edu.sg/~mathelmr/teaching/timezone.html">Why is Singapore in the "Wrong" Time Zone?</a> details the history of legal time in Singapore and Malaysia.</dd> <dt>United Kingdom</dt> <dd><a href="https://www.polyomino.org.uk/british-time/">History of legal time in Britain</a> discusses in detail the country -with perhaps the best-documented history of clock adjustments. -The National Physical Laboratory also maintains an <a -href="http://www.npl.co.uk/educate-explore/what-is-time/archive-of-summer-time-da…">Archive -of Summer time dates</a>.</dd> +with perhaps the best-documented history of clock adjustments.</dd> <dt>United States</dt> <dd>The Department of Transportation's <a href="https://www.transportation.gov/regulations/recent-time-zone-proceedings">Recent @@ -800,7 +787,7 @@ Time Zone Proceedings</a> lists changes to time zone boundaries.</dd> <dt>Uruguay</dt> <dd>The Oceanography, Hydrography, and Meteorology Service of the Uruguayan Navy (SOHMA) publishes an annual <a -href="http://www.armada.mil.uy/Pagina/institucion/dimat/sohma/almanaque.html" hreflang="es">almanac +href="http://www.armada.gub.uy/sohma/index.php/servicios/datos-astronomicos" hreflang="es">almanac (in Spanish)</a>.</dd> </dl> <h2 id="precision">Precision timekeeping</h2> @@ -905,14 +892,14 @@ both <abbr title="Locale Data Markup Language">LDML</abbr> (an <abbr>XML</abbr> format) and <abbr>JSON</abbr>. <li> <a href="https://www.cl.cam.ac.uk/~mgk25/iso-time.html">A summary of -the international standard date and time notation</a> is a good -summary of +the international standard date and time notation</a> covers <a -href="https://www.iso.org/standard/40874.html"><em><abbr>ISO</abbr> -8601:2004 – Data elements and interchange formats – Information -interchange – Representation of dates and times</em></a>.</li> +href="https://www.iso.org/standard/70907.html"><em><abbr +title="International Organization for Standardization">ISO</abbr> +8601-1:2019 – Date and time – Representations for information +interchange – Part 1: Basic rules</em></a>.</li> <li> -<a href="https://www.w3.org/TR/xmlschema-2/#dateTime"><abbr>XML</abbr> +<a href="https://www.w3.org/TR/xmlschema/#dateTime"><abbr>XML</abbr> Schema: Datatypes – dateTime</a> specifies a format inspired by <abbr>ISO</abbr> 8601 that is in common use in <abbr>XML</abbr> data.</li> <li><a href="https://tools.ietf.org/html/rfc5322#section-3.3">§3.3 of -- 2.21.0

1 1

Fwd: Historical timezone data for Bonin Islands (Ogasawara)
by Phake Nick May 29, 2019

May 29, 2019

Hello all, I have recently received some new information about timezone history of Bonin Islands, Japan as detailed in the attached message. Because their last time change to return to Japanese time when they return to Japanese rule was right before 1970, it mean per the current tz database rule, the information doesn't warrant creation of a new timezone for Bonin Islands itself and is thus as an anecdotal note for interest purpose only. However, in the attached link, it described some special timekeeping phenomenon regarding Marcus island, another remote island currently owned by Japanese in the same administrative unit as Bonin Islands. Many reports claim that the American coastal guard on the American quarter of the island use its own coastal guard time, and most sources describe the time as UTC+11, being two hours faster than JST used by some Japanese personnel on the island. Some sites describe it as same as Wake Island/Guam time although it would be incorrect to be same as Guam. And then in a few Japanese governmental report from 1980s (from National Institute of Information and Communications Technology) regarding the construction of VLBI facility on the Marcus Island, it claimed that there're three time standard being used on the island at the time which include not just JST (UTC+9) or [US]CG time (UTC+11) but also a JMSDF time (UTC+10) (Japan Maritime Self-Defense Force). Unfortunately there are no other sources that mentioned such time and there are also no information on things like how the tine was used. ---------- Forwarded message --------- From: Wakaba Date: 2019-1-28 Mon 13:48 Subject: Re: Question related to the page 昭和のサマータイム on suikawiki To: Phake Nick >> Hello, I see that there're a lot of information about DST at the time in Japan on Suikawiki, but a special area that's not mentioned in the page os Ogasawara 小笠原諸島 (Bonin Islands) which seems to have its own different history of governance. Do you know where can information related to timezone of the islands can be found? > Unfortunately we have no reliable source on time in US-controlled Ogasawara Islands at the moment. It turns out that National Diet Library of Japan has several reports by Japanese Government officers that describe the time used in islands when they visited there. According to them (and other sources such as newspapers), standard time UTC + 10 (JST + 1) and DST UTC + 11 (JST + 2) was used until its return to Japan at 1968-06-26 00:00 JST. The exact periods of DST are still unknown. I guessed Guam, Mariana, and Bonin and Marcus districts might have synchronized their DST periods, but reports imply they had their own decisions, i.e. there were three or more different time zones. Details: https://wiki.suikawiki.org/n/%E5%B0%8F%E7%AC%A0%E5%8E%9F%E8%AB%B8%E5%B3%B6%…

2 1

Update zone.tab with #KyivNotKiev
by Ігор Чигінь May 29, 2019

May 29, 2019

Hello, it's almost 28 years of using city name of non-existing USSR. I propose to use correct timezone name in zone.tab (also zone1970.tab?) UA +5026+03031 Europe/Kyiv More info from MFA of Ukraine: https://mfa.gov.ua/en/page/open/id/5418 Thanks, Ihor

3 2

https://www.timeanddate.com/news/time/brazil-scraps-dst.html
by DONATELLA SABELLICO May 28, 2019

May 28, 2019

Hi, this is the new Brasil announcement... https://www.timeanddate.com/news/time/brazil-scraps-dst.html We used the tzdb-2019a.tar.lz<https://data.iana.org/time-zones/releases/tzdb-2019a.tar.lz> (452.2kb) It seems they are ok for this year 2019 since I did not see any change DST for incoming Nov. Am I correct? When the new table are planned? thanks ::DISCLAIMER:: -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2 1

Re: [tz] Issue with Africa/Casablanca
by Paul Eggert May 20, 2019

May 20, 2019

David Gauchard wrote: > What would you think of an > additional option like "--near-future" which would always produce not an > empty description for all timezones ? If it's that important for newlib perhaps we should just make it the default, under the argument that a POSIX-compatible prediction, even if wrong during Ramadan, is better than no prediction at all (as that will cause these clients to be wrong the whole year).

1 1

Issue with Africa/Casablanca
by David Gauchard May 18, 2019

May 18, 2019

Hello, Latest version of zic produces an empty TZ string with Africa/Casablanca (and El Aaiun) Would it better be at least GMT0 ? Thanks

2 1

[PROPOSED] Assume zic 2004 or later in "Apr Sun>=25" etc.
by Paul Eggert May 18, 2019

May 18, 2019

* asia (Zion), northamerica (Toronto): Use constructs like "Apr Sun>=25" and "Apr Fri<=1" that have been supported by zic since 2004. Although Solaris 8 used pre-2004 zic, Solaris 8 reached end-of-life in March 2012. * zic.8: State more clearly that "Apr Sun>=25" is allowed. --- asia | 19 +------------------ northamerica | 17 ++++------------- zic.8 | 9 +++++++++ 3 files changed, 14 insertions(+), 31 deletions(-) diff --git a/asia b/asia index f97c830..9518756 100644 --- a/asia +++ b/asia @@ -1782,32 +1782,15 @@ Rule Zion 2004 only - Sep 22 1:00 0 S # # ftp://ftp.cs.huji.ac.il/pub/tz/announcements/2005+beyond.ps -# From Paul Eggert (2012-10-26): -# I used Ephraim Silverberg's dst-israel.el program -# <ftp://ftp.cs.huji.ac.il/pub/tz/software/dst-israel.el> (2005-02-20) -# along with Ed Reingold's cal-hebrew in GNU Emacs 21.4, -# to generate the transitions from 2005 through 2012. -# (I replaced "lastFri" with "Fri>=26" by hand.) -# The spring transitions all correspond to the following Rule: -# -# Rule Zion 2005 2012 - Mar Fri>=26 2:00 1:00 D -# -# but older zic implementations (e.g., Solaris 8) do not support -# "Fri>=26" to mean April 1 in years like 2005, so for now we list the -# springtime transitions explicitly. - # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Zion 2005 only - Apr 1 2:00 1:00 D +Rule Zion 2005 2012 - Apr Fri<=1 2:00 1:00 D Rule Zion 2005 only - Oct 9 2:00 0 S -Rule Zion 2006 2010 - Mar Fri>=26 2:00 1:00 D Rule Zion 2006 only - Oct 1 2:00 0 S Rule Zion 2007 only - Sep 16 2:00 0 S Rule Zion 2008 only - Oct 5 2:00 0 S Rule Zion 2009 only - Sep 27 2:00 0 S Rule Zion 2010 only - Sep 12 2:00 0 S -Rule Zion 2011 only - Apr 1 2:00 1:00 D Rule Zion 2011 only - Oct 2 2:00 0 S -Rule Zion 2012 only - Mar Fri>=26 2:00 1:00 D Rule Zion 2012 only - Sep 23 2:00 0 S # From Ephraim Silverberg (2013-06-27): diff --git a/northamerica b/northamerica index 8e5e351..fce043f 100644 --- a/northamerica +++ b/northamerica @@ -1701,19 +1701,10 @@ Rule Toronto 1922 1923 - May Sun>=8 2:00 1:00 D # was meant. Rule Toronto 1922 1926 - Sep Sun>=15 2:00 0 S Rule Toronto 1924 1927 - May Sun>=1 2:00 1:00 D -# The 1927-to-1939 rules can be expressed more simply as -# Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S -# Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D -# Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D -# Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S -# The rules below avoid use of Sun>=25 -# (which pre-2004 versions of zic cannot handle). -Rule Toronto 1927 1932 - Sep lastSun 2:00 0 S -Rule Toronto 1928 1931 - Apr lastSun 2:00 1:00 D -Rule Toronto 1932 only - May 1 2:00 1:00 D -Rule Toronto 1933 1940 - Apr lastSun 2:00 1:00 D -Rule Toronto 1933 only - Oct 1 2:00 0 S -Rule Toronto 1934 1939 - Sep lastSun 2:00 0 S +Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S +Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D +Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D +Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D diff --git a/zic.8 b/zic.8 index 6d893c2..89ea2d9 100644 --- a/zic.8 +++ b/zic.8 @@ -317,6 +317,15 @@ may be abbreviated or spelled out in full. There must be no white space characters within the .B ON field. +The +.q <= +and +.q >= +constructs can result in a day in the neighboring month; +for example, the IN-ON combination +.q "Oct Sun>=31" +stands for the first Sunday on or after October 31, +even if that Sunday occurs in November. .TP .B AT Gives the time of day at which the rule takes effect, -- 2.21.0

1 0

Estimate for a new tzdb release with Brazil rules.
by Chris Woodbury May 17, 2019

May 17, 2019

> Robert Elz kre at munnari.OZ.AU on Tue May 14 07:35:10 UTC 2019 wrote: > > When I once thought I might try that, I got told "git: command not found" > I have no interest whatever in installing that thing, just for this > >kre Wow. Perhaps one might check if "git" was installed. As we've no information as to what kind of system you're running on, it's hard to help you. (It might be as simple as it isn't in your PATH.) After checking the obvious, I usually start with Google: how to install "git" on .... If you're not the sysadmin, perhaps that would be a good place to start, too. She/he may have more motivation, too.

8 11

Decree for Chile DST change
by Juan Correa May 17, 2019

May 17, 2019

I couldn't find the decree for the chilean DST change until today (even when it was published on November 23th on the Official Gazette, I searched for it on december 2018 with no avail) http://www.diariooficial.interior.gob.cl/publicaciones/2018/11/23/42212/01/… The only extra bit of information is that America/Punta_Arenas is confirmed to not change until 2022 -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

2 1

Some extra information about the Eucla zone
by Gilmore Davidson May 17, 2019

May 17, 2019

After Australia’s clock change last weekend, the national broadcaster has published an article about the Eucla time zone: https://www.abc.net.au/news/2019-04-08/this-remote-stretch-of-desert-has-it… <https://www.abc.net.au/news/2019-04-08/this-remote-stretch-of-desert-has-it…> > Sergeant Chamberlain said when it comes to life on the Nullarbor, the custom made time zone was at the lower end of quirky. Some interesting snippets of information include a rough description of the geographical boundaries... > The time zone exists for about 340 kilometres and takes in the tiny roadhouse communities of Cocklebiddy, Madura, Madura, Eucla and Border Village. …and an indication that the zone has definitely been in existence since before the 1970 cut-off of the database: > Mr Pike has lived on the Nullarbor for 47 years > > […] > > 'Why'? > > "Good question," Mr Pike said. > > "I don't even know that, and it's been going for over 50 years.” This doesn’t change any of the existing data, but could be useful as a reference. Cheers, Gil

2 1

[PROPOSED] Ignore more non-source files
by Paul Eggert May 16, 2019

May 16, 2019

* .gitignore: Ignore *.diff, *.i, *.orig, *.rej, *.tar. Ignore check_* files, as they are created by ‘make check’. --- .gitignore | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.gitignore b/.gitignore index 1e62d11..cf3b825 100644 --- a/.gitignore +++ b/.gitignore @@ -2,14 +2,20 @@ # This file is in the public domain. *.a *.asc +*.diff +*.i *.o +*.orig *.patch +*.rej +*.tar *.tar.* *.txt *.tzs *.zi *~ ChangeLog +check_* date leapseconds tzselect -- 2.21.0

1 0

[PROPOSED] Bring zic man page up to date
by Paul Eggert May 16, 2019

May 16, 2019

* zic.8: Don’t mention time(2), since zic does not rely on time_t any more. Mention other ways that -v generates warnings. ON fields can’t contain non-space white space characters either. Remove incorrect assertion that fractional seconds are not allowed. --- zic.8 | 60 +++++++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 48 insertions(+), 12 deletions(-) diff --git a/zic.8 b/zic.8 index 524a113..6d893c2 100644 --- a/zic.8 +++ b/zic.8 @@ -110,9 +110,7 @@ Be more verbose, and complain about the following situations: The input specifies a link to a link. .PP A year that appears in a data file is outside the range -of years representable by -.BR time (2) -values. +of representable years. .PP A time of 24:00 or more appears in the input. Pre-1998 versions of @@ -124,6 +122,36 @@ Pre-2004 versions of .B zic prohibit this. .PP +A time zone abbreviation uses a +.B %z +format. +Pre-2015 versions of +.B zic +do not support this. +.PP +A timestamp contains fractional seconds. +Pre-2018 versions of +.B zic +do not support this. +.PP +The input contains abbreviations that are mishandled by pre-2018 versions of +.B zic +due to a longstanding coding bug. +These abbreviations include +.q L +for +.q Link , +.q mi +for +.q min , +.q Sa +for +.q Sat , +and +.q Su +for +.q Sun . +.PP The output file does not contain all the information about the long-term future of a timezone, because the future cannot be summarized as an extended POSIX TZ string. For example, as of 2019 this problem @@ -137,8 +165,15 @@ code designed for older output formats. These compatibility issues affect only timestamps before 1970 or after the start of 2038. .PP -A time zone abbreviation has fewer than 3 characters. -POSIX requires at least 3. +The output file contains more than 1200 transitions, +which may be mishandled by some clients. +The current reference client supports at most 2000 transitions; +pre-2014 versions of the reference client support at most 1200 +transitions. +.PP +A time zone abbreviation has fewer than 3 or more than 6 characters. +POSIX requires at least 3, and requires implementations to support +at least 6. .PP An output file name contains a byte that is not an ASCII letter, .q "\*-" , @@ -279,7 +314,7 @@ or a weekday name preceded by (e.g., .BR "lastSunday" ) may be abbreviated or spelled out in full. -Note that there must be no spaces within the +There must be no white space characters within the .B ON field. .TP @@ -455,7 +490,7 @@ and .TP .B UNTIL The time at which the UT offset or the rule(s) change for a location. -It takes the form of YEAR [MONTH [DAY [TIME]]]. +It takes the form of one to four fields YEAR [MONTH [DAY [TIME]]]. If this is specified, the time zone information is generated from the given UT offset and rule change until the time specified, which is interpreted using @@ -587,10 +622,10 @@ Rule EU 1979 1995 \*- Sep lastSun 1:00u 0 \*- Rule EU 1981 max \*- Mar lastSun 1:00u 1:00 S Rule EU 1996 max \*- Oct lastSun 1:00u 0 \*- .sp -.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'0:34:08\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u +.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'0:29:45.50\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u # Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 \*- LMT 1853 Jul 16 - 0:29:46 \*- BMT 1894 Jun + 0:29:45.50 \*- BMT 1894 Jun 1:00 Swiss CE%sT 1981 1:00 EU CE%sT .sp @@ -601,9 +636,10 @@ Link Europe/Zurich Europe/Vaduz In this example, the timezone is named Europe/Zurich but it has an alias as Europe/Vaduz. This example says that Zurich was 34 minutes and 8 seconds east of UT until 1853-07-16 at 00:00, when the legal offset -was changed to 7\(de\|26\(fm\|22.50\(sd; although this works out to -0:29:45.50, the input format cannot represent fractional seconds so it -is rounded here. After 1894-06-01 at 00:00 the UT offset became one hour +was changed to 7\(de\|26\(fm\|22.50\(sd, which works out to 0:29:45.50; +.B zic +treats this by rounding it to 0:29:46. +After 1894-06-01 at 00:00 the UT offset became one hour and Swiss daylight saving rules (defined with lines beginning with .q "Rule Swiss") apply. From 1981 to the present, EU daylight saving rules have -- 2.21.0

1 0

[PROPOSED] Assume zic 2017c or later when shrinking
by Paul Eggert May 16, 2019

May 16, 2019

The tzdata.zi file was first released in 2017c, and deliberately avoided zic features that were also new to that release, to avoid problems with people mistakenly running older zic when generating this new file. After a year’s wait it is reasonable to assume that anybody using this new file is also using a new-enough zic. This saves about 900 bytes in tzdata.zi. * NEWS: Mention this. * zishrink.awk (gen_rule_name, prehash_rule_names) (process_input_line, output_saved_lines): For clarity, use the convention that parameters are on the first line of function definition, and local vars are on later lines. (process_input_line): Assume zic 2017c or later. Make line types more explicit. --- NEWS | 5 +++++ zishrink.awk | 44 +++++++++++++++++++++++--------------------- 2 files changed, 28 insertions(+), 21 deletions(-) diff --git a/NEWS b/NEWS index c939b8f..be6dd26 100644 --- a/NEWS +++ b/NEWS @@ -25,6 +25,11 @@ Unreleased, experimental changes Europe/Rome between those dates. (Thanks to Stephen Trainor and Luigi Rosa.) + Changes to build procedure + + tzdata.zi now assumes zic 2017c or later. This shrinks tzdata.zi + by a percent or so. + Release 2019a - 2019-03-25 22:01:33 -0700 diff --git a/zishrink.awk b/zishrink.awk index 8876b68..4e187ac 100644 --- a/zishrink.awk +++ b/zishrink.awk @@ -20,7 +20,8 @@ function record_hash(n, name) # Return a shortened rule name representing NAME, # and record this relationship to the hash table. -function gen_rule_name(name, n) +function gen_rule_name(name, \ + n) { # Use a simple memonic: the first two letters. n = substr(name, 1, 2) @@ -29,7 +30,8 @@ function gen_rule_name(name, n) return n } -function prehash_rule_names(name) +function prehash_rule_names( \ + name) { # Rule names are not part of the tzdb API, so substitute shorter # ones. Shortening them consistently from one release to the next @@ -148,20 +150,21 @@ function prehash_rule_names(name) } } -# Process an input line and save it for later output. +# Process the input line LINE and save it for later output. -function process_input_line(line, field, end, i, n, startdef) +function process_input_line(line, \ + field, end, i, n, startdef, \ + linkline, ruleline, zoneline) { # Remove comments, normalize spaces, and append a space to each line. sub(/#.*/, "", line) line = line " " gsub(/[\t ]+/, " ", line) - # Abbreviate keywords. Do not abbreviate "Link" to just "L", - # as pre-2017c zic erroneously diagnoses "Li" as ambiguous. - sub(/^Link /, "Li ", line) - sub(/^Rule /, "R ", line) - sub(/^Zone /, "Z ", line) + # Abbreviate keywords and determine line type. + linkline = sub(/^Link /, "L ", line) + ruleline = sub(/^Rule /, "R ", line) + zoneline = sub(/^Zone /, "Z ", line) # SystemV rules are not needed. if (line ~ /^R SystemV /) return @@ -169,7 +172,7 @@ function process_input_line(line, field, end, i, n, startdef) # Replace FooAsia rules with the same rules without "Asia", as they # are duplicates. if (match(line, /[^ ]Asia /)) { - if (line ~ /^R /) return + if (ruleline) return line = substr(line, 1, RSTART) substr(line, RSTART + 5) } @@ -179,21 +182,19 @@ function process_input_line(line, field, end, i, n, startdef) while (match(line, /:0[^:]/)) line = substr(line, 1, RSTART - 1) substr(line, RSTART + 2) - # Abbreviate weekday names. Do not abbreviate "Sun" and "Sat", as - # pre-2017c zic erroneously diagnoses "Su" and "Sa" as ambiguous. + # Abbreviate weekday names. while (match(line, / (last)?(Mon|Wed|Fri)[ <>]/)) { end = RSTART + RLENGTH line = substr(line, 1, end - 4) substr(line, end - 1) } - while (match(line, / (last)?(Tue|Thu)[ <>]/)) { + while (match(line, / (last)?(Sun|Tue|Thu|Sat)[ <>]/)) { end = RSTART + RLENGTH line = substr(line, 1, end - 3) substr(line, end - 1) } - # Abbreviate "max", "only" and month names. - # Do not abbreviate "min", as pre-2017c zic erroneously diagnoses "mi" - # as ambiguous. + # Abbreviate "max", "min", "only" and month names. gsub(/ max /, " ma ", line) + gsub(/ min /, " mi ", line) gsub(/ only /, " o ", line) gsub(/ Jan /, " Ja ", line) gsub(/ Feb /, " F ", line) @@ -221,7 +222,7 @@ function process_input_line(line, field, end, i, n, startdef) n = split(line, field) # Abbreviate rule names. - i = field[1] == "Z" ? 4 : field[1] == "Li" ? 0 : 2 + i = zoneline ? 4 : linkline ? 0 : 2 if (i && field[i] ~ /^[^-+0-9]/) { if (!rule[field[i]]) rule[field[i]] = gen_rule_name(field[i]) @@ -231,11 +232,11 @@ function process_input_line(line, field, end, i, n, startdef) # If this zone supersedes an earlier one, delete the earlier one # from the saved output lines. startdef = "" - if (field[1] == "Z") + if (zoneline) zonename = startdef = field[2] - else if (field[1] == "Li") + else if (linkline) zonename = startdef = field[3] - else if (field[1] == "R") + else if (ruleline) zonename = "" if (startdef) { i = zonedef[startdef] @@ -254,7 +255,8 @@ function process_input_line(line, field, end, i, n, startdef) output_line[nout++] = line } -function output_saved_lines(i) +function output_saved_lines( \ + i) { for (i = 0; i < nout; i++) if (output_line[i]) -- 2.21.0

1 0

[PROPOSED] zic: omit pre-2017c chatter unless -v
by Paul Eggert May 16, 2019

May 16, 2019

* zic.c (byword): Put pre-2017c warnings in the same category as other pre-2015 etc. warnings: that is, output the warnings only if -v is given. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 4bafe5d..5b932dc 100644 --- a/zic.c +++ b/zic.c @@ -3140,8 +3140,8 @@ byword(const char *word, const struct lookup *table) else return NULL; /* multiple inexact matches */ } - /* Warn about any backward-compatibility issue with pre-2017c zic. */ - if (foundlp) { + if (foundlp && noise) { + /* Warn about any backward-compatibility issue with pre-2017c zic. */ bool pre_2017c_match = false; for (lp = table; lp->l_word; lp++) if (itsabbr(word, lp->l_word)) { -- 2.21.0

1 0

Estimate for a new tzdb release with Brazil rules.
by Pramoth Murali May 14, 2019

May 14, 2019

Wanted to request a follow-up to an earlier comment https://mm.icann.org/pipermail/tz/2019-April/027877.html <https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.…> . Specifically, “No rush for a new tzdb release (but of course we'll want something out before October :-)”. Do we have an estimate for when the new tzdb release might be available containing the Brazil rules? Is there any way I can request this be updated sooner than later? Understand there was a patch attached in an earlier thread. My company would ideally prefer to align with a more formal release cadence to get these changes. Thanks! -- Pramoth

6 8

Spelling of Ukrainian cities #KyivNotKiev
by Vitaliy Stavropolskiy May 12, 2019

May 12, 2019

Hi! Maybe it's time to change the spelling of Ukrainian cities <https://mfa.gov.ua/en/page/open/id/5418>? I've found a comment in the tzdb: > # Admittedly English-language spelling of Ukrainian names is > # controversial, and some day "Kyiv" may become substantially more popular > in > # English; in the meantime, stick with the traditional English "Kiev" as > that > # means less disruption for our users. I think it's the right time to change it. For example, a lot of Airports and international media did it. For example,The Guardian: https://twitter.com/shaunwalker7/status/1095687682582286337 https://www.theguardian.com/guardian-observer-style-guide-k Airports in London, Toronto, Istanbul, Bucharest, etc.: 1. https://twitter.com/GamanOleksandr/status/1108371955353305095 2. https://procol-harum.livejournal.com/1091764.html?utm_source=twsharing&utm_… 3. https://www.facebook.com/UkrEmbassyDK/posts/2189053684497098 You can find a lot of other examples by using hashtag #KyivNotKiev Here is the link to the official information from the Ministry of Foreign Affairs of Ukraine: https://mfa.gov.ua/en/page/open/id/5418 Please, consider. Best regards, Vitalii Stavropolskyi

10 10

Issue with EST timezone
by Chris Woodbury May 11, 2019

May 11, 2019

Would it be "letting the cat out of the bag" to say that the timezone he's probably looking for is EST5EDT?

1 0

Re: [tz] Issue with EST timezone
by Paul Eggert May 11, 2019

May 11, 2019

On 5/7/19 3:53 AM, Manjusri Mahendran -X (manjmahe - INFOSYS LIMITED at Cisco) wrote: > > We have issues on Call Manager running on EST timezone. > > Could see that there is no replacement added for deprecated timezones > EST, HST and MST whereas other deprecated timezones such as “Brazil > East” and “Singapore” has a replacement. > > How are these three timezones different from the rest of deprecated ones.? They aren't deprecated. EST, HST, and MST are still in tzdb, in the 'northamerica' file. They've been there since 2005. It sounds like you've run into an issue that is downstream from tzdb.

8 10

Europe/Rome, 22 Sep 1866 rule
by Stephen Trainor May 7, 2019

May 7, 2019

In looking into Europe/Rome, I see there is the following rule: # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Rome 0:49:56 - LMT 1866 Sep 22 (line 1660, europe, tzdb-2019a) In reading the page referenced in this 2016 thread on historical Italy time zones (https://mm.icann.org/pipermail/tz/2016-October/024363.html <https://mm.icann.org/pipermail/tz/2016-October/024363.html>), it states: "Regio Decreto del 22 Settembre 1866 n° 3224 di Re Vittorio Emanuele II ( in vigore dal 12 Dicembre 1866 ) Il servizio dei convogli nelle ferrovie, quello dei telegrafi, delle poste, delle messaggerie e dei piroscafi postali nelle Provincie Continentali del Regno d’Italia, verrà regolato col tempo medio di Roma a datare dal giorno in cui sarà attivato l’orario delle strade ferrate per la prossima stagione invernale 1866 – 1867.” (source: http://www.ac-ilsestante.it/MERIDIANE/ora_legale/ORA_LEGALE_ESTIVA_IN_ITALI… <http://www.ac-ilsestante.it/MERIDIANE/ora_legale/ORA_LEGALE_ESTIVA_IN_ITALI…>) This implies that the law went into effect on 12 December 1866, rather than the date of the decree (22 Sep 1866). This is further supported by this source: https://web.archive.org/web/20070824155341/http://www.iav.it/planetario/did… <https://web.archive.org/web/20070824155341/http://www.iav.it/planetario/did…>, which states: "In Italy in 1866 there were 6 railway times (Torino, Verona, Firenze, Roma, Napoli, Palermo). On that year it was decided to unify them, adopting the average time of Rome (even if this city was not yet part of the kingdom). On the 12th December 1866, on the starting of the winter time table, it took effect in the railways, the post office and the telegraph, not only for the internal service but also for the public. Moreover, without any particular law, but on a free initiative of the main Italian cities and as a consequence of the practical advantages of tying the railway time to the city time, and also for patriotic reasons ( Rome was not part of kingdom) it was decided to use the Rome time in public and private life producing thus a national time. Milano set the public watches on the Rome time on the same day (12th December 1866), Torino and Bologna on the 1st January 1867, Venezia the 1st May 1880 and the last city was Cagliari in 1886.” I wonder if the rule should be modified to 1866 Dec 12, instead of 1866 Sep 22? Stephen Trainor

3 2

Reason for 24:00
by Marketa Calabkova May 4, 2019

May 4, 2019

Hi, I am just wondering why there is 24:00 in the AT column for some countries (including Iran, Amman and Santiago) while there is 0:00 elsewhere. Could you please explain it to me? Thank you, Marketa Calabkova

3 3

Morocco timezone update
by Mustapha Alaouy May 4, 2019

May 4, 2019

Hello there, There is an upcoming timezone change in Morocco where the country will switch to GMT this Sunday at 3AM just before the month of Ramadan, and it will revert back to GMT+1 on June 9th. A reference to the recently published decision on the State's Official Bulletin: http://www.mapnews.ma/en/actualites/general/morocco-back-gmt-may-5-300-am-h… <http://www.mapnews.ma/en/actualites/general/morocco-back-gmt-may-5-300-am-h…> Thanks in advance

2 1

Comments for Europe/Kiev
by Leon V May 4, 2019

May 4, 2019

Hi First of all, my apologies if I'm not doing the right thing by sending this suggestion to this email - I couldn't find a more relevant process in CONTRIBUTING for the amendment I suggest. I'd like to suggest to remove the following paragraph in europe file: # Anyway, none of the common English-language spellings (Kiev, Kyiv, Kieff, # Kijeff, Kijev, Kiyef, Kiyeff) do justice to the common pronunciation in # Ukrainian, namely [ˈkɪjiu̯] (IPA). This pronunciation has nothing like an # English "v" or "f", and instead trails off with what an English-speaker # would call a demure "oo" sound, and it would would be better anglicized as # "Kuiyu". Here's a sound file, if you would like to do as the Kuiyuvians do: # https://commons.wikimedia.org/wiki/File:Uk-Київ.ogg Reasons for that: 1. I don't see how it's relevant 2. There are multiple major mistakes in it: a. there are no other common spellings of Kyiv other than Kyiv and Kiev. Searching the Internet for all other suggested spellings can easily confirm it; b. [ˈkɪjiu̯] is absolutely not a valid transcription; c. neither Ukrainian nor Russian standards would suggest to use f at the end of the written word, although when pronounced it may sound somewhat reminiscient of f (depending on pronunciation); d. I don't believe there is an English speaker who would pronounce "Kuiyu" similar to what it's actually pronounced in either Russian or Ukrainian; e. the linked sound file is of low quality and seems to either have a second half of the last letter cut off or just pronounced by someone very drunk. It's not pronounced with "u" at the end neither in Ukrainian nor in Russian, not even close. About me: born in Russia, lived for 30 years in Kyiv, 4+ years in Sydney, Australia. Have been working with English speakers from pretty much all around the world for 15+ years. Kind regards Leon

2 1

Is there having Astana alias for Asia/Almaty? If yes, changing that to Nur-Sultan can be considered.
by 柳芯宇 May 3, 2019

May 3, 2019

Because this is confirmed per their changes to Constitution of the Republic of Kazakhstan.

2 1

Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication
by Martin Burnicki April 30, 2019

April 30, 2019

Don't know if this has already been known, or if it's really relevant for this list, but ... "Big tech warns of 'Japan's millennium bug' ahead of Akihito's abdication" https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-mil… 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

7 9

Brazil no longer has DST changes - decreet signed today
by Marcus Diniz April 28, 2019

April 28, 2019

Hello Paul, TZ team, Brazil no longer has DST changes - decreet signed today https://g1.globo.com/politica/noticia/2019/04/25/bolsonaro-assina-decreto-q… https://economia.ig.com.br/2019-04-25/bolsonaro-assina-nesta-quinta-feira-d… Can you please update the southamerica timezone file? Marcus Diniz

6 10

Brazilian state of Goiás may abolish DST
by World Time Zone April 27, 2019

April 27, 2019

According to some news Brazilian state of Goiás may abolish DST: "The Energy and Mines Commission of the House of Representatives approved a Legislative Decree that suspends daylight saving time in Goiás." http://www.infomoney.com.br/minhas-financas/consumo/noticia/7061178/comissa… Also, ".... this year the federal government even considered not implementing daylight saving time, but left the decision to 2018." Alexander Krivenyshev https://www.WorldTimeZone.com

5 5

[PATCH] * northamerica: Comment re Regina 1914-1917.
by Paul Eggert April 26, 2019

April 26, 2019

--- northamerica | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/northamerica b/northamerica index eee8de0..8e5e351 100644 --- a/northamerica +++ b/northamerica @@ -1843,6 +1843,13 @@ Zone America/Winnipeg -6:28:36 - LMT 1887 Jul 16 # Willett (1914-03) notes that DST "has been in operation ... in the # City of Moose Jaw, Saskatchewan, for one year." +# From Paul Eggert (2019-04-26): +# Chris Pearce's book "The Great Daylight Saving Time Controversy" (2017) +# says that Regina observed DST in 1914-1917. No dates and times, +# unfortunately. It also says that in 1914 Saskatoon observed DST +# from 1 June to 6 July, and that DST was also tried out in Davidson, +# Melfort, and Prince Albert. + # From Paul Eggert (2006-03-22): # Shanks & Pottenger say that since 1970 this region has mostly been as Regina. # Some western towns (e.g. Swift Current) switched from MST/MDT to CST in 1972. -- 2.20.1

1 0

Brazil: DST cancelled in Brazil
by Clésio Takahashi April 26, 2019

April 26, 2019

Hello, >From now on, DST in Brazil will not be applied anymore. This is the decree making it official, signed by the President yesterday: http://www.planalto.gov.br/ccivil_03/_Ato2019-2022/2019/Decreto/D9772.htm Best regards, Clésio Takahashi Technical Account Manager Red Hat Brasil, SCE LATAM clesio(a)redhat.com M: +55 11 9 9137 7013 Partnering with you to help achieve your business goals: https://www.redhat.com/en/services

1 0

DST Brazil is over
by Daniel Soares de Oliveira April 26, 2019

April 26, 2019

DST Brazilian is over. The Brazilian government announces the end of summer time, in 2019/2020 there will be no change of schedule. [1] [1]https://g1.globo.com/economia/noticia/2019/04/05/governo-anuncia-fim-do-h… Atenciosamente, Daniel Soares de Oliveira Setor de Suporte Técnico Fone: (51)3210-3826

5 5

DST Brazil is over[2]
by Daniel Soares de Oliveira April 25, 2019

April 25, 2019

Hi, - DST Brazilian is over - President signs decree that extinguishes daylight saving time. [1] - Ministry of mines and energy publishes information on the suspension of daylight saving time in Brazil. [2] - Decree published has not yet been updated, awaiting official publication. [3] [1] - https://g1.globo.com/politica/noticia/2019/04/25/bolsonaro-assina-decreto-q… [2] - http://www.mme.gov.br/web/guest/pagina-inicial/outras-noticas/-/asset_publi… [3] - http://www.planalto.gov.br/ccivil_03/_ato2007-2010/2008/decreto/d6558.htm Best Regards, Daniel S. de Oliveira

1 0

"Washington House OKs step toward year-round daylight saving"
by Arthur David Olson April 24, 2019

April 24, 2019

Per an Associated Press report: "...the Washington House passed a measure Saturday that would make...later sunsets permanent in the state all year—if Congress allows it." https://wtop.com/national/2019/03/washington-house-oks-step-toward-year-rou…

5 4

Giuntella & Mazzonna on health and economic costs of DST
by Paul Eggert April 20, 2019

April 20, 2019

A recently-published report by researchers from Pitt and USI found that daylight saving time reduces sleep duration by an average of 19 minutes in the US, and that this harms people's health and workers' wages. The researchers used CDC and US Census data to compare behavior on the western and eastern sides of time zone boundaries, and reported that individuals using daylight-saving time are 11% more likely to be overweight and 5.6% more likely to be obese. On average their wages are 3% lower. Effects are strongest on those with early work schedules. The researchers give the following bounds for the US annual economic costs of these effects: $2.35 billion ($82 per capita) for increased healthcare costs, and $612 million ($23 per capita) for worker productivity losses. These are lower bounds: actual costs are most likely higher. Costs are in 2017 dollars. Giuntella G, Mazzonna F. Sunset time and the economic effects of social jetlag; evidence from US time zone borders. J Health Econ. 2019. https://doi.org/10.1016/j.jhealeco.2019.03.007 (draft: https://pdfs.semanticscholar.org/3dd9/bf55292c1396a912b82c736ea3485dd5b884.…) A summary can be found in: Ingraham C. How living on the wrong side of a time zone can be hazardous to your health. Washington Post. 2019-04-19 06:00 -04. https://www.washingtonpost.com/business/2019/04/19/how-living-wrong-side-ti…

2 1

Re: [tz] Will Morocco switch from +01 to +00 during Ramadan next year?
by Naoufal Semlali April 18, 2019

April 18, 2019

Hello, Please be informed that the Moroccan government has decided today to move back the clocks temporarily during Ramadan. Therefore, Morocco will be on GMT starting from Sunday, May 5th 2019 at 3am. The switch to GMT+1 will occur on Sunday, June 9th 2019 at 2am. Please find below the articles confirming this news. Source (French) : https://www.leconomiste.com/flash-infos/le-maroc-repassera-au-gmt-le-5-mai http://fr.le360.ma/societe/voici-la-date-du-retour-a-lheure-legale-au-maroc… https://www.lesiteinfo.com/maroc/officiel-le-maroc-repasse-a-lheure-gmt/ https://www.medias24.com/retour-a-l-heure-gmt-dimanche-5-mai-1616.html Regards, -------- Message d'origine -------- De : Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>> Date : 01/11/2018 06:21 (GMT+01:00) À : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>>, Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>>, Adlouni mehdi <adlounimehdi(a)gmail.com<mailto:adlounimehdi@gmail.com>>, Imad Bidaoui <imad.bida8(a)gmail.com<mailto:imad.bida8@gmail.com>>, Mohamed Essedik Najd <es.najd(a)gmail.com<mailto:es.najd@gmail.com>>, Milamber <milamberspace(a)gmail.com<mailto:milamberspace@gmail.com>>, Mounir EL MOKHTARI <momokhtari(a)gmail.com<mailto:momokhtari@gmail.com>> Objet : Re: Will Morocco switch from +01 to +00 during Ramadan next year? Hello Paul, The 2019 Ramadan period is supposed to be from May 5th to June 4th. We usually move clocks back the previous week end and come back to the +1 the week end after. So it supposed to be sunday april 28 and sunday june 12. The government does not announce yet the decision about this temporarily change. But it s 99% sure that it will be the case, as the previous years. A non official survey was done these days, showing that 64% of asked peopke are ok for moving from +1 to +0 during Ramadan. https://leconomiste.com/article/1035870-enquete-l-economiste-sunergia-64-de… I will share the official decision once it s published. Regards, Abdelkader Maamar -------- Message d'origine -------- De : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>> Date : 01/11/2018 05:23 (GMT+01:00) À : Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>>, Adlouni mehdi <adlounimehdi(a)gmail.com<mailto:adlounimehdi@gmail.com>>, Imad Bidaoui <imad.bida8(a)gmail.com<mailto:imad.bida8@gmail.com>>, Mohamed Essedik Najd <es.najd(a)gmail.com<mailto:es.najd@gmail.com>>, Milamber <milamberspace(a)gmail.com<mailto:milamberspace@gmail.com>>, Mounir EL MOKHTARI <momokhtari(a)gmail.com<mailto:momokhtari@gmail.com>> Objet : Will Morocco switch from +01 to +00 during Ramadan next year? If you have information about whether Morocco will move clocks back temporarily during Ramadan next year, please write to me or to tz(a)iana.org<mailto:tz@iana.org>. Thanks. I wrote more about this question here: https://mm.icann.org/pipermail/tz/2018-November/027146.html ________________________________ [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 4

question around santiago tz, and sync tz
by gerar.moisset＠orange.com April 16, 2019

April 16, 2019

Hello. We have upgraded and use now tzdata2019a data from iana. We have new customer using our service (java service updated with tzupdater) with tz in Santiago. If I check Santiago time zone I see: (GMT-04:00) America/Santiago [hasDST:false] #seems to be good since tzdata2019a (GMT-04:00) America/Santiago - Summer Time [hasDST:true] #not good since 7 avr 2019 - Daylight Saving Time Ended My question is: If I check timeanddate for Santiago on: https://www.timeanddate.com/worldclock/chile/santiago I can see : DST for Santiago start on 8 sep 2019 What will be the new values for this tz? Will its included into next tz iana update? And when? where can i find little tutorial around this? I need to automatically synchronize our platform, what will be the best way for us from your internet access? Kind regards. Gérard Moisset Orange/TGI/OLS/BIZZ/UCEM/WUC Spécialiste en Technologies Plate-Formes Services +33 5 34 54 40 77 <http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/ToolBar.do?action=default%26…> +33 6 80 45 05 71 <http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/ToolBar.do?action=default%26…> gerar.moisset(a)orange.com <mailto:gerar.moisset@orange.com> me joindre d'un clic ! [http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/images/telephone.gif]<http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/ToolBar.do?action=default%26…> [http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/images/mobile.gif] <http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/ToolBar.do?action=default%26…> [call : gerar.moisset(a)orange.com] <callto:%3Csip:gerar.moisset@orange.com%3E> [http://clicvoice.sso.infra.ftgroup/ClicvoiceV2/images/sms.gif] <https://monsi.sso.francetelecom.fr/index.asp?target=http://smsnet.sso.franc…> [Email : gerar.moisset(a)orange.com] <mailto:gerar.moisset@orange.com> _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

2 1

GPS Week Number Rollover Apr 6/7
by Chris Woodbury April 12, 2019

April 12, 2019

The airlines' software problems are most likely with Notices to Airman (NOTAMs). These are public domain data and announcements of airspace restrictions, etc. which AeroData, Inc. has been contracted by the FAA to provide since 1990. It looks like they do it for the EU, too. These announcements are part of the suite of software that AeroData provides. Every media outlet is mentioning weight and balance (read fuel load and cargo balancing for aircraft before take off) and completely missing the part that does airspace restriction, route and waypoint calculations that will certainly involve GPS information. Ya' gotta love the media...

2 2

Chile Continental Time changed to standard time April 6
by Gardner, Stephanie (Enel X) April 11, 2019

April 11, 2019

Hello, I've just joined this mailing list and I don't fully understand how this works, but I'm writing because have a dilemma. My understanding is that Chile Continental time changed back to standard time on April 6. See https://www.horaoficial.cl/aviso/informacion.html which states: "Dispone fecha cambio huso horario para el 6 de abril de 2019, de acuerdo a lo siguiente: a. Chile Continental (desde Región de Arica y Parinacota hasta Aysén), a las 24:00 hora local, pasará a huso horario UTC-4, y deberá atrasar los relojes en una hora." However, this is not reflected in the 2019-03-25 release. I therefore have an application which is using the incorrect UTC offset as a result. What is the process for getting that change into the database? Thanks, Stephanie Gardner Product Manager Enel X North America, Inc. www.enelx.com/northamerica

2 1

Am I missing an implicit rule?
by Grilled Chipolatas April 11, 2019

April 11, 2019

Hello, I have been working with the database lately and have had issues to read Morocco rules. I tried to look in the archives of the mailing list but didn't find my answer. Currently the database contains these bits: Rule Morocco 2017 only - Jul 2 2:00 1:00 - Rule Morocco 2018 only - May 13 3:00 0 - Rule Morocco 2018 only - Jun 17 2:00 1:00 - Rule Morocco 2019 only - May 5 3:00 -1:00 - Rule Morocco 2019 only - Jun 9 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco +00/+01 1984 Mar 16 1:00 - +01 1986 0:00 Morocco +00/+01 2018 Oct 28 3:00 1:00 Morocco +01/+00 I wonder if the database should add this rule dated to the switching to permanent DST: Rule Morocco 2018 only - Oct 28 3:00 0 - Or am I missing an implicit rule: being that a new zone change discard any current rule (here Morocco 2018 only - Jun 17 2:00 1:00 - )? Thanks for any clarification, Maxime Vinzio

2 1

Re: [tz] DST in Palestine will start one week later
by Grace D'Alfonso April 11, 2019

April 11, 2019

Your discussion on Palestine’s DST has not touched on the fact that there are two different time zones for Palestine: (1) Asia/Gaza (covering the Gaza Strip) and (2) Asia/Hebron (covering the West Bank). Does your recent discussion relate to both time zones or to one specific time zone? For your information, timeanddate.com is showing different DST change dates for each regions However, it seems to have the wrong information for the city of Nablus (at least). The Palestine Exchange is located in Nablus and it clearly changed time today (29 March) according to its website: http://www.pex.ps/PSEWebSite/English/Default.aspx, while timeanddate.com indicates that it changed on 23 March. Thanks for any help you can provide in clarifying the time zone for this very confusing region! Regards, Grace D'Alfonso Copp Clark Limited Toronto, ON Canada Tel. +1-647-382-4262 www.coppclark.com www.marketholidays.com www.goodbusinessday.com Copp Clark is the authoritative source for information on holiday observances affecting world financial markets. Our trading hours, early closing and holiday reference data are trusted and recognized globally as the market standard.

5 6

Brazil might end DST
by Steffen Thorsen April 7, 2019

April 7, 2019

According to multiple sources the Brazilian president wants to get rid of DST. https://gmconline.com.br/noticias/politica/bolsonaro-horario-de-verao-deve-… https://g1.globo.com/economia/noticia/2019/04/05/governo-anuncia-fim-do-hor… https://republicadecuritiba.net/2019/04/05/bolsonaro-afirma-que-brasil-nao-… There might be some formalities still, but given these articles it seems very likely that they actually will stop changing clocks. Best regards, Steffen Thorsen - timeanddate.com

3 2

Issue in tz America/Santiago
by Alberto Jose Rivera Rojas April 4, 2019

April 4, 2019

Before install the time change patch tzdata2019a the date command delivers the next output Thu Apr 4 11:07:36 CLST 2019 After installing the time change patch tzdata2019a the date command delivers the next output Thu Apr 4 11:07:36 -03 2019 we modified the lines 1278 changing -3 for CLST and -4 CLT. attachment Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - CLT 1916 Jul 1 # Chile Time -4:42:46 - SMT 1918 Sep 10 -4:00 - CLT 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile CL%sT 1932 Sep 1 -4:00 - CLT 1942 Jun 1 -5:00 - CLT 1942 Aug 1 -4:00 - CLT 1946 Jul 15 -4:00 1:00 CLST 1946 Sep 1 # central Chile -4:00 - CLT 1947 Apr 1 -5:00 - CLT 1947 May 21 23:00 -4:00 Chile CL%sT -- Atte. Alberto Rivera. +56944771319

2 1

GPS Week Number Rollover Apr 6/7
by Brian Inglis April 2, 2019

April 2, 2019

Expect some amount of time related disruption around April 7 00:00 GPS as the GPS 1K week cycle rolls over and GPS receivers that have not been patched or updated to use new CNAV and MNAV messages, or compensate for not doing so, provide incorrect time, position, and navigation solutions. Garmin, for example, rolled out updated firmware for some of their receivers, including the 18x popular on NTP servers, just over a week ago. Previous rollovers have shown symptoms of clocks being out by multiples of 256 weeks, some resetting to the GPS epoch at 1980 Jan 06 Sun 00:00:00+0000, showing misleading position and navigation solutions, depending on what inputs are used to solve the 4D simultaneous equations. Airlines, ships, and well maintained commercial trucks shouldn't crash, but the rest of us should check any devices using GPS! If my script is correct, the rollover occurs at the indicated instant on the time scales below: 2019 Apr 06 Sat 23:59:42+0000 JD 2458580.499792 MJD 58579.999792 ToD 86382 NTP 3763583982 Unix 1554595182 GPS We 2048 Cy 2 Wn 0 Wa 0 ToW 0 DoW 0 ToD 0 TAI-UTC 37 TAI-GPS 19 GPS-UTC 18 [*NOT* an April Fools post, unfortunately!] -- 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.

2 2

DST in Palestine will start one week later
by Even Scharning March 29, 2019

March 29, 2019

DST in Palestine will start on 30 March this year, not 23 March as the time zone database predicted. Some references (in Arabic): http://pnn.ps/news/401130 http://palweather.ps/ar/node/50136.html https://ramallah.news/post/123610/%D9%85%D9%88%D8%B9%D8%AF-%D8%A7%D9%84%D8%… Even Scharning https://time.is

9 14

Will there be a 2019b update soon?
by Patsy Franklin March 27, 2019

March 27, 2019

Hi, Since there is now an experimental patch for the 2019a update, will there be a 2019b released soon? What would be the anticipated time frame for the update? Thanks, Patsy

3 2

Europe/Dublin daylight saving time format confusion
by Guruswamy Basavaiah March 27, 2019

March 27, 2019

Hello, Generated timezone files using the below command on release 2018e. zic -L /dev/null -d output_dir -y "sh yearistype.sh" europe zdump show daylight saving flag (isdst=1) is wrongly set for Europe/Dublin. Daylight saving time should start from March 31 and end on October 27. But here it shows reverse. zdump -v /home/basavaia/output_dir/Europe/Dublin | grep 2019 /home/basavaia/output_dir/Europe/Dublin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 00:59:59 2019 GMT isdst=1 gmtoff=0 /home/basavaia/output_dir/Europe/Dublin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 02:00:00 2019 IST isdst=0 gmtoff=3600 /home/basavaia/output_dir/Europe/Dublin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 01:59:59 2019 IST isdst=0 gmtoff=3600 /home/basavaia/output_dir/Europe/Dublin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 01:00:00 2019 GMT isdst=1 gmtoff=0 Above Behavior is same in 2019a also. If I check the same on 2018a, it gives proper output. zdump -v /home/basavaia/2018a/Europe/Dublin | grep 2019 /home/basavaia/2018a/Europe/Dublin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 00:59:59 2019 GMT isdst=0 gmtoff=0 /home/basavaia/2018a/Europe/Dublin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 02:00:00 2019 IST isdst=1 gmtoff=3600 /home/basavaia/2018a/Europe/Dublin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 01:59:59 2019 IST isdst=1 gmtoff=3600 /home/basavaia/2018a/Europe/Dublin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 01:00:00 2019 GMT isdst=0 gmtoff=0 Is my understanding correct? And this behavior is introduced in commit 127b4af7219e6df9253b34e390797c5527b8cc66 I am not in this mailing list, please include my email id while responding. -- Guruswamy Basavaiah

2 1

Re: [tz] [tz-announce] 2019a release of tz code and data available
by Paul Eggert March 26, 2019

March 26, 2019

On 3/26/19 6:02 AM, Michael H Deckers wrote: > > In the file NEWS, I read > > Release 20198 - 2019-03-25 22:01:33 -0700 > > instead of > > Release 2019a - 2019-03-25 22:01:33 -0700 > > Maybe a file transfer error? No, it's a typo. Sorry about that. I fixed it as per attached. Thanks for reporting it.

1 0

European Parliament votes to drop DST by 2021, leaving it to member states
by Tim Parenti March 26, 2019

March 26, 2019

The European Parliament has just voted 410-192 in favor of dropping its DST requirement in the EU by 2021. The vote is not the last word on the issue but will form the basis of discussions with EU countries to produce a final law. Under the proposal, each member state would decide amongst three options: - to continue with twice-a-year clock changes, - to stick permanently to summer time, or - to stick permanently to winter time. All member states would need to inform the European Commission of their choice ahead of the proposed switch, by April 2020. They would then coordinate with the bloc's executive so that their decisions do not disrupt the functioning of the single market. The European Commission proposed in September ending the practice after an EU-wide opinion survey showed a large majority in favor of doing so. The survey generated 4.6 million responses, with 84% of respondents wanting to end seasonal clock changes. Critics say the survey was dominated by Germans, who made up 70% of the respondents. https://www.dw.com/en/eu-parliament-votes-to-end-daylight-savings/a-48064185 https://www.rte.ie/news/europe/2019/0326/1038689-eu-daylight-savings/ -- Tim Parenti

5 8

Re: [tz] Proposed changes for Argentina, Jan Mayen, worldtimeengine.com, etc.
by REMI ACIEN March 26, 2019

March 26, 2019

Provenance : Courrier<https://go.microsoft.com/fwlink/?LinkId=550986> pour Windows 10 For Atlantic /Jan Mayen , UTC-1 . It’ s yes .

2 1

[tz-announce] 2019a release of tz code and data available
by Paul Eggert March 26, 2019

March 26, 2019

The 2019a 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: Palestine "springs forward" on 2019-03-30 instead of 2019-03-23. Metlakatla "fell back" to rejoin Alaska Time on 2019-01-20 at 02:00. Changes to past and future timestamps Palestine will not start DST until 2019-03-30, instead of 2019-03-23 as previously predicted. Adjust our prediction by guessing that spring transitions will be between 24 and 30 March, which matches recent practice since 2016. (Thanks to Even Scharning and Tim Parenti.) Metlakatla ended its observance of Pacific standard time, rejoining Alaska Time, on 2019-01-20 at 02:00. (Thanks to Ryan Stanley and Tim Parenti.) Changes to past timestamps Israel observed DST in 1980 (08-02/09-13) and 1984 (05-05/08-25). (Thanks to Alois Treindl and Isaac Starkman.) Changes to time zone abbreviations Etc/UCT is now a backward-compatibility link to Etc/UTC, instead of being a separate zone that generates the abbreviation "UCT", which nowadays is typically a typo. (Problem reported by Isiah Meadows.) Changes to code zic now has an -r option to limit the time range of output data. For example, 'zic -r @1000000000' limits the output data to timestamps starting 1000000000 seconds after the Epoch. This helps shrink output size and can be useful for applications not needing the full timestamp history, such as TZDIST truncation; see Internet RFC 8536 section 5.1. (Inspired by a feature request from Christopher Wong, helped along by bug reports from Wong and from Tim Parenti.) Changes to documentation Mention Internet RFC 8536 (February 2019), which documents TZif. tz-link.html now cites tzdata-meta <https://tzdata-meta.timtimeonline.com/>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2019a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2019a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2019a.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 14c73382cf95efd5f189379427b7b37ca22b9eff dated 2019-03-25 22:01:33 -0700 and tagged '2019a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 7cc76ce6be4a67c3e1b2222cb632d2de9dabb76899793a938f87a1d4bb20e462cabdae9e3b986aaabaa400795370510095d236dbad5aff4c192d0887f0ecedf5 tzcode2019a.tar.gz d8eb5b2b68abee08bd2b0d2134bce85b5c0aee85168e9697a607604ed5be7d1539ac60fda9b37e0c9c793ef6251978bc250563a0af59497fde775499964bb5aa tzdata2019a.tar.gz 5971d53ceb8cd9e0723d0694c2dca5a3781b9c84bdfef2eb324e9f94fb0b25da263cf59b5429bc77e12e549130aab8c8b1755c34d62bf672c184210c629328f2 tzdb-2019a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjRR5xAAqsWv2T1beL9TnJ2JaadySGOZiJg3M3RqW8Vm4Dd0ye8Dz8t+YtDtBX1/ 8+xGdlS7LWjwK2EQC6xWhp0EiqpiFjMU1FRGFeAlAOOv8SE0dPRfP9vIeKzCNXKp UwtSrzM5JUX6/iza9UUTlzpwHaEM/gVIfP+sLgT15RJiB84teHro/rpcfOvNRyj1 bteknySCtbPcETe9VW3qH2YgMRtNQgkt/DcJgCvY2qWLsnicWRH9Ec6NhqYLFpuv QwvqC0Odaehrytu+DNhi1wuxt90YHgGHMgIZXtG+kO8eJy2aWFP9zQJ80wVvNqat Xgl6T5AU5ZIdBEQkMnk0EhqFlKYFX/81hEWT0gsMBCzteVFhhQQPPyptUwtL5U17 MX1oVaZbiTbTCqjAjHAJbfW61Fbu9H0wzZhoRLvDqaFfOxQ1HEMh2Ioh+KlJ0nLw +l5dLNed7D/kjRE0ja7Jj+ocCl4Hf1DTQknfqtk1USGctWLZ3WfKHk6jCS0vid7g IrN6POYhZ6kg4NLF1G2pD7tTiog37Kvd/c3FHC76cqbbA5wkye+L/A73xmy0qOlv tp14wxd99ETI5loWgMb5SgRzzeEjNbTrG5AuAOX0qK4Fz3cEdK9/PYYJDSOkueJJ 0DpP9Eo3Kmhhk7E4PheygmX+Vk+Ntutu7jx8r6EFNck/erZrnJs= =kJqF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjTPrg/9HBD7RK0/e2NQc/IEg0BeZPOG/SsWOo78lQ23UVwqXdXqQz9LJXl9gTqM ENe8Ecknctk6fmfriAYnSydXx/MwWDbze5nmi4p7wzlogL/ctPILJvQbc/T62fDK NpGNwDlaUX/ht7cRG9VO+oun3Zc7efGHJB9UpZDDVZGtq6VT5+AZIryM12XvHfcR g0P+0pZfZu9LI4H0K/JUmNnRRXLoq6/5OsV6+hFlTzS7quVfUu+Vb+gsoUVejXld 77hNvqdAaRBwVW69hjdUL2WJXymQtP/1ZoeOVHskti0HQBFRJsDc4Fhs3Pe5MUWd PXVanz/C0sHhHbTLfHs4wVQvNg4g4OP5nl9DyF+KG2SqfuqWOzfbEs5bc8dGqFCk HLdj7Nd4eQA8x/Xl6OSukE1yzUR8Xkb9GFgTmpHlP7uq/TH2URJdd/ZXhSgPv+u6 bM9ghH9eirnVDPxWxsj0bwkZYHY6eJC8pgLPpXsxBY0ktJD/hqS1IMXOAyPRj9fO uRt7QLcsJW+wx6Q7ggsgTs7cxnq/Pk55S0lcp63mAu960+2XuBy8ffFJp4J2OwqS U6nBCtAZ6ZONKvsoQ4UpIcNfkYEiM3A4XNjn/rL2Jtb0cDA8e0j66/k1vcOc9p6u KQSXvSrhoqGTqhKy03XuQJ7LYhSgtD790sxFOXWS59cs/WcLO+M= =g5BY -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs54ACgkQ7ZfpDmKq fjQOExAAj3bXlkhyxx2pTIt2sEiE687kRa3VOKYeLnSLyWfOSAKFsrEXiPHNGPJ9 Xn9PjUZa7cZ+5IiZoHYr37GbDqs0VdTrnt/SId+fxhv14DoCJsQT2yuji7aWrBnp LOIscrsvvciNk6035bWJjuLZRyDYqm8MKBSBCgKuuFOCCy/mFprW42nzM/L9QK3p vhnDrKnXlDF4pu3J6w5MThZyTbJOD4zqMIMgdfuBLlOjks5smLTVmTN0QTuZyVca Cr8T4+BTGnmMfGkgGCG1/33DZg58q/Q7l8hqKkaK6znErPFk5cCE7S/Ty32hD91o x6YUQNxEYai9nhgirr55mYc4/X4BjiqRA/Dzw+Nbum0AC1OtNijqHmy1frZRyky5 jwFaMWEIxSTKKd/FexqBUuw6KpciEtVM46VCa73VQN5/3RqaXiA7f36zi7HB3flC jdKqmse2yMGASavYRMVvY/LT8TC+DPZ2+8hbHproLmz5y7tFgXh+eSqj+SwKIw/5 SADRjIaTCQS6KUm5syUc0Nu4Oi9fEifdnOJ6WM0/yj2ix40D1dXwRSuja2Tf1sM1 DkO05GH0G3+0zjKMROMKwXM8PahXvePcRuaKROO9Nx+mBZ3MvYpaOORecQ7flJKb GINC0cwwbDiLF/k+ESruOlCZ57D6ChUABptKwiPOrmNcqDRYiOo= =6VXD -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2019a/tzdata2019a-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2019a/tzdata2019a-rearguard.tar.… with the following SHA-512 and GPG checksums: 1ebca45c43aaed76fcb8894a5e8321975cc74a272a9e7b83b2f4ca9d5c2c0b4a4de276bd019d95468ce7e6b88d8afdab70b17580071b8a54cdf2218c2bb8a069 tzdata2019a-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlyZs50ACgkQ7ZfpDmKq fjTGig//QSof18SghwQoHqUCxUEKhblFyV7+mSzEMdF3J+eSCpt+SsoN75NaLHYm GoBlJkmYFOxnyWjbzvn9dcr9/vHXu0D5P8Bd2NvVEULRSJ/Kb+uOsXsic38Z5Uz6 hJ/9Il/7mAYF23diYLtOuuVoeuKrHhmS/9jzACu6jXMwaXXWfMpbm3NGVLgXNIPe QD93PUq/aQ87OwmysZBhXui0PR5Pakg3nWSj7jTtAKhbRFOZdN5g9OxneYvaCmmC K2s+mvXRnQiImNnTvXavAEWw3Gz3MP7972JYdmd6gm9Q+lfNf1ykbM8Z4KO+rDMk YTfQCrNpAtmGP3TqNgFtzBouQAmjoQ8+Lyh7jjGArxZEpZVle+7zSGOoB/US4otz hrHrzg/6rNmYWL5Xvg8rhgtG0fp8uZABhA0s9gV2Qz8TRnArTUoLoYWiEGpfQ7Vf uHU1947DSMebshg4BYBmLvcEr2/KH7TMholRMllTv5soM7sX3bariejI8u5dcDhk wRyiBZhLJbFd+of6kNeo5jPm9caDOWrp3vq2xryyiN1M9s3gu8BfrBcSI2tE2l6F uOMAuaeNOfuoLuAYghgkXWM1DvZo81ePQXAVW9CIsg+aT1wcCRk0TPRn+OiPjbKQ YS4ULentOrEnxdKfFC1XIJ4JQZuDjhyW2vlkboWhc1zT5a83erc= =bFDj -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 24, 2019

March 24, 2019

LD 144 http://legislature.maine.gov/legis/bills/display_ps.asp?paper=HP0126&PID=un… Ought Not to Proceed LD 885 http://legislature.maine.gov/legis/bills/display_ps.asp?paper=HP0659&PID=un… Tabled I would expect no changes to Maine's timezone in the meantime.

1 0

Error display in America/Santiago - tzdata2018i
by Pedro Salas Díaz March 19, 2019

March 19, 2019

Hello: I'm Pedro Salas Diaz from Chile , and I'm working in TZ change for my servers timezone. When I compile our timezone, I see that timezone is not displayed correctly. >zdump -v America/Santiago | grep 2019 zdump: warning: zone "America/Santiago" abbreviation "-05" lacks alphabetic at start America/Santiago Sun Apr 7 02:59:59 2019 UTC = Sat Apr 6 23:59:59 2019 -03 isdst=1 America/Santiago Sun Apr 7 03:00:00 2019 UTC = Sat Apr 6 23:00:00 2019 -04 isdst=0 America/Santiago Sun Sep 8 03:59:59 2019 UTC = Sat Sep 7 23:59:59 2019 -04 isdst=0 America/Santiago Sun Sep 8 04:00:00 2019 UTC = Sun Sep 8 01:00:00 2019 -03 isdst=1 I found some errors in our apps, because the TZ is not showed as "CLT" nor "CLST". To resolve this, i modified "southamerica" file (these lines) ********************************************************************************** # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Chile 1927 1931 - Sep 1 0:00 1:00 S Rule Chile 1928 1932 - Apr 1 0:00 0 - Rule Chile 1968 only - Nov 3 4:00u 1:00 S Rule Chile 1969 only - Mar 30 3:00u 0 - Rule Chile 1969 only - Nov 23 4:00u 1:00 S Rule Chile 1970 only - Mar 29 3:00u 0 - Rule Chile 1971 only - Mar 14 3:00u 0 - Rule Chile 1970 1972 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1972 1986 - Mar Sun>=9 3:00u 0 - Rule Chile 1973 only - Sep 30 4:00u 1:00 S Rule Chile 1974 1987 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1987 only - Apr 12 3:00u 0 - Rule Chile 1988 1990 - Mar Sun>=9 3:00u 0 - Rule Chile 1988 1989 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1990 only - Sep 16 4:00u 1:00 S Rule Chile 1991 1996 - Mar Sun>=9 3:00u 0 - Rule Chile 1991 1997 - Oct Sun>=9 4:00u 1:00 S Rule Chile 1997 only - Mar 30 3:00u 0 - Rule Chile 1998 only - Mar Sun>=9 3:00u 0 - Rule Chile 1998 only - Sep 27 4:00u 1:00 S Rule Chile 1999 only - Apr 4 3:00u 0 - Rule Chile 1999 2010 - Oct Sun>=9 4:00u 1:00 S Rule Chile 2000 2007 - Mar Sun>=9 3:00u 0 - # N.B.: the end of March 29 in Chile is March 30 in Universal time, # which is used below in specifying the transition. Rule Chile 2008 only - Mar 30 3:00u 0 - Rule Chile 2009 only - Mar Sun>=9 3:00u 0 - Rule Chile 2010 only - Apr Sun>=1 3:00u 0 - Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 2014 - Apr Sun>=23 3:00u 0 - Rule Chile 2012 2014 - Sep Sun>=2 4:00u 1:00 S Rule Chile 2016 2018 - May Sun>=9 3:00u 0 - Rule Chile 2016 2018 - Aug Sun>=9 4:00u 1:00 S Rule Chile 2019 max - Apr Sun>=2 3:00u 0 - Rule Chile 2019 max - Sep Sun>=2 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - CLT 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - CLT 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile CL%sT 1932 Sep 1 -4:00 - CLT 1942 Jun 1 -5:00 - CLT 1942 Aug 1 -4:00 - CLT 1946 Jul 15 -4:00 1:00 CLST 1946 Sep 1 # central Chile -4:00 - CLT 1947 Apr 1 -5:00 - CLT 1947 May 21 23:00 -4:00 Chile CL%sT ***************************************************************************************** I changed som "-" for "S" and "-03" for "CLST" and "-04" is "CLT". I compiled again and It works well. I send you this information if It is useful. Regards. Pedro Salas Diaz

2 1

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 19, 2019

March 19, 2019

Public Hearings were held on March 11, 2019 on each LD. 60% and 50% public hearing testimony respectively for each LD was in opposition. TV and radio broadcasters made up the opposition. http://legislature.maine.gov/bills/display_ps.asp?snum=129&paper=HP0126PID=… http://legislature.maine.gov/bills/display_ps.asp?snum=129&paper=HP0659PID=… Works sessions are scheduled for March 20, 2019. Summary: No time zone change looks probable. Will update after the work session

1 0

tzdb under the ASIS&T microscope
by Paul Eggert March 17, 2019

March 17, 2019

tzdb was the subject of an academic study published at the most recent annual meeting of the Association for Information Science & Technology: Hauser E. UNIX time, UTC, and datetime: Jussivity, prolepsis, and incorrigibility in modern timekeeping. Proc ASIS&T. 2018;55(1):161-70. https://doi.org/10.1002/pra2.2018.14505501018 For those of us not into the lingo, "jussivity" refers to how much a word or concept commands or exhorts us, and is related to the jussive mood of verbs in some languages. For example in the Latin phrase "doceas iter" ("teach the way") in the Aeneid, the mood of "doceas" means that people ought to teach the way. "Prolepsis" refers to foreshadowing, as in a proleptic calendar that is projected backward into the past or projected into the future. "Incorrigibility" refers to the property of a belief that a person cannot give up; here, the idea is that tzdb provides its own grounds for truth and its users can't (and don't want to) correct tzdb. As you can probably tell from my having to explain the words in the title, the tz mailing list was not the intended audience of this paper. Still, it can be amusing to see how outsiders see us.

5 9

[PROPOSED] zic option for including data from a certain year onward
by Christopher Wong March 15, 2019

March 15, 2019

>From 4093e426a42421fd2d8579b07e8edb3fb116f561 Mon Sep 17 00:00:00 2001 From: Christopher Wong <christwo(a)axis.com> Date: Tue, 5 Feb 2019 15:02:57 +0100 Subject: [PATCH] zic.c: Add -k option to keep specified year and onward The -k option will take a year as input. It will strip away historical transition data before the specified year. The TZif files will be truncated. --- zic.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 69 insertions(+), 3 deletions(-) diff --git a/zic.c b/zic.c index 2ebc66a..9a3b1f5 100644 --- a/zic.c +++ b/zic.c @@ -178,6 +178,7 @@ static void mkdirs(char const *, bool); static void newabbr(const char * abbr); static zic_t oadd(zic_t t1, zic_t t2); static void outzone(const struct zone * zp, ptrdiff_t ntzones); +static zic_t ytime(zic_t year); static zic_t rpytime(const struct rule * rp, zic_t wantedy); static void rulesub(struct rule * rp, const char * loyearp, const char * hiyearp, @@ -610,6 +611,10 @@ static const char * leapsec; static const char * tzdefault; static const char * yitcommand; +/* This is used to truncate tzfiles. Only year specified by keepyear and + onward will be kept. Don't expect year to be outside range 0-9999. */ +static zic_t keepyear; + int main(int argc, char **argv) { @@ -640,7 +645,8 @@ main(int argc, char **argv) } else if (strcmp(argv[k], "--help") == 0) { usage(stdout, EXIT_SUCCESS); } - while ((c = getopt(argc, argv, "d:l:L:p:st:vy:")) != EOF && c != -1) + keepyear = ZIC_MIN; + while ((c = getopt(argc, argv, "d:k:l:L:p:st:vy:")) != EOF && c != -1) switch (c) { default: usage(stderr, EXIT_FAILURE); @@ -654,6 +660,22 @@ _("%s: More than one -d option specified\n"), return EXIT_FAILURE; } break; + case 'k': + if (keepyear == ZIC_MIN) { + keepyear = atoi(optarg); + /* Don't expect year to be outside range 0-9999. */ + if (keepyear < 0) + keepyear = 0; + if (keepyear > 9999) + keepyear = 9999; + } + else { + fprintf(stderr, +_("%s: More than one -k option specified\n"), + progname); + return EXIT_FAILURE; + } + break; case 'l': if (lcltime == NULL) lcltime = optarg; @@ -1749,7 +1771,7 @@ writezone(const char *const name, const char *const string, char version, register FILE * fp; register ptrdiff_t i, j; register int leapcnt32, leapi32; - register ptrdiff_t timecnt32, timei32; + register ptrdiff_t timecnt32, timei32, timei; register int pass; static const struct tzhead tzh0; static struct tzhead tzh; @@ -1865,6 +1887,37 @@ writezone(const char *const name, const char *const string, char version, --leapcnt32; ++leapi32; } + + timei = 0; + if (keepyear != ZIC_MIN) { + /* Discard transitions that happened before the keepyear. */ + int nbr_removes; + + nbr_removes = 0; + for (i = timei32; i < timecnt; ++i) + if (ats[i] < ytime(keepyear)) + ++nbr_removes; + timecnt32 -= nbr_removes; + timei32 += nbr_removes; + + nbr_removes = 0; + for (i = 0; i < timecnt; ++i) + if (ats[i] < ytime(keepyear)) + ++nbr_removes; + + if (nbr_removes > 0) { + /* Override the last removed transition time with the first transition + time that is the start point of the truncation range. Set defaulttype + to this first transition time. */ + --nbr_removes; + ats[nbr_removes] = ytime(keepyear); + defaulttype = types[nbr_removes]; + } + + timecnt -= nbr_removes; + timei += nbr_removes; + } + /* ** Remove old file, if any, to snap links. */ @@ -1910,7 +1963,7 @@ writezone(const char *const name, const char *const string, char version, thisleapi = leapi32; thisleapcnt = leapcnt32; } else { - thistimei = 0; + thistimei = timei; thistimecnt = timecnt; toomanytimes = thistimecnt >> 31 >> 31 >> 2 != 0; thisleapi = 0; @@ -3107,6 +3160,19 @@ tadd(zic_t t1, zic_t t2) } /* +** Given a year, compute the date (in seconds since January 1, +** 1970, 00:00). +*/ + +static zic_t +ytime(zic_t year) +{ + struct rule xr = { 0 }; + xr.r_dayofmonth = 1; + return rpytime(&xr, year); +} + +/* ** Given a rule, and a year, compute the date (in seconds since January 1, ** 1970, 00:00 LOCAL time) in that year that the rule refers to. */ -- 2.11.0 ?

4 18

[PROPOSED] Fix 'make clean' problem with clean_*.dir
by Paul Eggert March 11, 2019

March 11, 2019

* Makefile (clean_misc, clean): Use rm -fr on patterns that can match directories, so that 'make clean' works even if there is a directory check_zishrink.dir. Stick with rm -f on patterns that should match only files, for safety. --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 4bc72a9..25f1d35 100644 --- a/Makefile +++ b/Makefile @@ -847,11 +847,13 @@ check_zishrink_posix check_zishrink_right: \ touch $@ clean_misc: + rm -fr check_*.dir rm -f *.o *.out $(TIME_T_ALTERNATIVES) \ check_* core typecheck_* \ date tzselect version.h zdump zic yearistype libtz.a clean: clean_misc - rm -fr *.dir *.zi tzdb-*/ $(TZS_NEW) + rm -fr *.dir tzdb-*/ + rm -f *.zi $(TZS_NEW) maintainer-clean: clean @echo 'This command is intended for maintainers to use; it' -- 2.20.1

1 0

Please remove tzdata2018f
by Ankur Rana March 11, 2019

March 11, 2019

Hello Paul/Team, While doing tzdata upgrade to version 2018f, we found below issue. java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:226) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:222) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:643) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more We further found that the issue was addressed in version 2018g. To avoid any reoccurrence of same, would it be possible to prevent the tzdata version 2018f from downloading on iana site? [Ericsson]<http://www.ericsson.com/> ANKUR RANA Senior Software Developer Bussiness Area Digital Services - Development Unit Ericsson Block A, King Canyon "ASF Insignia" THE IT/ITES SEZ, Faridabad Road, Gawal Pahari, Gurgaon 122003, India Phone +91-124-3088600 Mobile +91-9811264594 ankur.rana(a)ericsson.com www.ericsson.com [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign> Legal entity: Ericsson India Global Services Pvt Ltd, registered office in Gurgaon. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

8 14

Why is `Etc/UCT` not an alias of `Etc/UTC`?
by Isiah Meadows March 10, 2019

March 10, 2019

They seem to refer to the same thing, so it doesn't make much sense to me why they're considered different. I also looked in the relevant file in the source, `/etcetera`, and there doesn't seem to be any rationale for it. Was this an oversight? ----- Isiah Meadows contact(a)isiahmeadows.com www.isiahmeadows.com

11 24

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 8, 2019

March 8, 2019

http://legislature.maine.gov/bills/getPDF.asp?paper=HP0659&item=1&snum=129 Text of No. 885, Rep. Baileys Proposal This one is light on substance too and impeded by: 15 United States Code, Section 260a https://www.law.cornell.edu/uscode/text/15/260a

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed* Update
by C Yohman March 8, 2019

March 8, 2019

Text of No. 144, Rep. Kessler's Proposal http://legislature.maine.gov/bills/getPDF.asp?paper=HP0126&item=1&snum=129 Seems light on substance. I remain firm that this likely goes nowhere.

1 0

Proposed Change to Maine's Time Zone *No Current Action Needed*
by C Yohman March 8, 2019

March 8, 2019

Long-time lurker, first time poster. I'm putting this on the periphery, in case it comes to pass (Probability: infinitesimal). Variations come about every decade. Not that it matters in this context, but the change would make sense for the eastern half of the state with commerce ties to New Brunswick and The Maritimes. Not so much for the western half of the state where the commerce ties are strong to New Hampshire & Massachusetts. That's just a slice of the perspective. Ironically, the two measures were introduced by two southern Maine representatives. Summary: "The two bills are proposed by Democratic lawmakers and take different approaches to eliminating the time change. Rep. Chris Kessler of South Portland’s bill would move Maine into the Atlantic time zone, which would mean the state would no longer set clocks back in fall. Rep. Donna Bailey, of Saco, has proposed keeping Maine in daylight saving time all year if the federal government also does so. Florida passed a similar bill." Source: https://www.pressherald.com/2019/03/07/bills-would-say-good-night-to-daylig… (Limited access. Google Chrome -> New Incognito Window is your option for multiple free views) Further Sources: https://wgme.com/news/local/bill-would-move-maine-into-atlantic-time-zone Rep. Kessler & Rep. Bailey have been contacted for the Reference LD # or further information. Sample email sent: Representative Kessler, Citizen of Waterboro, Maine here (work in Portland, commute through a sliver of South Portland), but I read your name is attached to one of the bills. "Rep. Chris Kessler of South Portland’s bill would move Maine into the Atlantic time zone, which would mean the state would no longer set clocks back in fall." https://www.pressherald.com/2019/03/07/bills-would-say-good-night-to-daylig… I have no opinion on the matter, but if there was a change there would likely need to be a change to tzdata, the database that keeps track of timezones across the world. https://www.iana.org/time-zones Ultimately, at a basic level, it allows you to set the correct timezone on your electronic devices. What is the LD number for the measure, or where can I read the proposed text to understand the proposed change better? Regards, Chance Yohman Follow-Up: Hearing scheduled for March 11th. Will update when I know.

1 0

Arbitrary default system time?
by Arthur David Olson March 7, 2019

March 7, 2019

A question about current operating systems. They have differing ways of establishing a system-wide default local time zone at installation time. Are the current ways flexible enough to allow establishing a zone that's not in the database (for example, Freedonia Standard Time--FST--for a newly created country)? (If not, adding a zic option to help with the matter might be of use.) @dashdashado

2 1

Re: [tz] Israel DST in 1980 and 1984 ?
by Alois Treindl March 7, 2019

March 7, 2019

-------- Forwarded Message -------- Subject: Re: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 20:49:56 +0200 From: Isaac Starkman To: Alois Treindl <alois(a)astro.ch> Dear Alois, It is correct. Summer time was in that period in 1980 and 1984, see https://www.ynet.co.il/articles/0,7340,L-3951073,00.html You can of course read it in translation. I checked the local newspapers for that years. It started on midnight and end at 01.00 am Isaac On Wed, Mar 6, 2019 at 6:42 PM Alois Treindl <alois(a)astro.ch <mailto:alois@astro.ch>> wrote: Dear Isaac, can you comment on the validity of this document? Best regards Alois -------- Forwarded Message -------- Subject: [tz] Israel DST in 1980 and 1984 ? Date: Wed, 6 Mar 2019 17:40:19 +0100 From: Alois Treindl <alois(a)astro.ch> <mailto:alois@astro.ch> To: tz(a)iana.org <mailto:tz@iana.org> I have been pointed to this document http://www.moin.gov.il/Documents/%D7%A9%D7%A2%D7%95%D7%9F%20%D7%A7%D7%99%D7… whose authenticity and origin I cannot affirm, lacking Hebrew. It concerns the years 1980 and 1984, 2 August 1980 - 13 Sept 1980 5 May 1984 - 25 August 1984 and claims that DST was in force during those periods.

2 1

Israel DST in 1980 and 1984 ?
by Alois Treindl March 6, 2019

March 6, 2019

1 0

EU summer time heading for a mess
by Tony Finch March 6, 2019

March 6, 2019

Some states want to keep it. The discussions are in flux. The change might occur in 2020 or 2021. https://m.dw.com/en/european-parliament-set-to-end-eu-wide-daylight-savings… Tony. -- f.anthony.n.finch <dot(a)dotat.at> http://dotat.at

2 1

Pennsylvania State Rep seeking to end DST
by Matthew Donadio March 6, 2019

March 6, 2019

Not sure if this will go anywhere, but a Pennsylvania State Rep is seeking a co-sponsor to end DST in the state: https://www.legis.state.pa.us/cfdocs/legis/CSM/showMemoPublic.cfm?chamber=H… >From a quick read of the memo, it looks like he has done his homework on what it would actually take from beginning to end to get this done. --Matthew Donadio (matt(a)mxd120.com)

1 0

[IANA #1136519] America / Sao_Paulo in the Time Zone Database
by Amanda Baber via RT March 5, 2019

March 5, 2019

Hi, We've been asked to submit this message to the mailing list on a requester's behalf: === Contact Name: ricardotiellet Contact Email: rhiccarddo(a)hotmail.com Please, this case needs to be fixed: Wrong> America / Sao_Paulo Right> America / Brasilia If there is a need for disambiguation, just add a suffix: _DF = Federal District or Federal Capital so use: America / Brasilia_DF if there is any compatibility problem with graphical accentuation, Use Brasilia without an acute accent on the first i (í) https://en.wikipedia.org/wiki/Bras%C3%ADlia https://en.wikipedia.org/wiki/Brasilia Please contact me if you need. Thanks a lot. === He indicated to us that he may not check the mailing list for replies. Best regards, Amanda Baber Lead IANA Services Specialist

4 4

tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
by Hans-Joerg Happel March 1, 2019

March 1, 2019

Dear all, as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb policies. As it is a slightly separate / more general point, I'll single that thread out from the initial "Hanoi" discussion. In particular, I'd like to understand the background of the following item (taken from https://data.iana.org/time-zones/theory.html#naming) >There should typically be at least one name for each ISO 3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1> officially >assigned two-letter code for an inhabited country or territory. I initially thought this would be the reason for the "Links" of "Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok". However, latest discussion in the "Hanoi" thread rather attributed these two aliases to backwards compatibility after prior data was moved to the backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): In contrast to data stored using "Asia/Bangkok", systems/data using the "Asia/Phnom_Penh" name/link/alias/id would not need to change/re-configure in case the government of Cambodia decides to deviate from "Asia/Bangkok" at some time b) Politically: Even if tzdb names might not be intended as "names", they do surface from time to time, as with configuring time zones on a machine [1], or by applications just passing through tzdb names. I can somehow understand that this is not fully satisfactory in the Vietnam/Hanoi case right now (see below). While it is neither the intention nor the concern of tzdb to deal with this, one can argue that in practice, there is still clearly a practical impact of tzdb names/ids. So any information on the rationale for the above-quoted rule is appreciated. Also, I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end? If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. In case Vietnam would deviate from "Asia/Bangkok" in the future (by either Thai or Vietnamese decision), legacy data might need to be change to an "Asia/Hanoi" identifier. I'd be interested in pointers if this aspect was ever discussed here or is considered relevant at all. Thanks and best, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..yielding the following dialogue: Please select a country whose clocks agree with yours. 1) Afghanistan 18) Israel 35) Palestine ......... 15) Indonesia 32) Nepal 49) Vietnam 16) Iran 33) Oman 50) Yemen 17) Iraq 34) Pakistan #? 49 Please select one of the following time zone regions. 1) Indochina (most areas) 2) Vietnam (south) ...which looks better, but is also not ideal from a user point-of-view... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): Asia/Bangkok / Indochina Time Asia/Bangkok / Indochina Zeit Asia/Bangkok / Heure d'Indochine Asia/Ho_Chi_Minh / Indochina Time Asia/Ho_Chi_Minh / Indochina Zeit Asia/Ho_Chi_Minh / Heure d'Indochine Asia/Phnom_Penh / Indochina Time Asia/Phnom_Penh / Indochina Zeit Asia/Phnom_Penh / Heure d'Indochine Asia/Saigon / Indochina Time Asia/Saigon / Indochina Zeit Asia/Saigon / Heure d'Indochine Asia/Vientiane / Indochina Time Asia/Vientiane / Indochina Zeit Asia/Vientiane / Heure d'Indochine VST / Indochina Time VST / Indochina Zeit VST / Heure d'Indochine -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142

22 105

adding LLT to the Time Zone Database
by filip Feb. 26, 2019

Feb. 26, 2019

Greetings everyone! I was told that this is the community/staff of this mailing list that i should poke if i want to add an entry into the Time Zone Database. I am working at the company Firo Solutions and we have implemented LLT(liberland time) into our systems and it all works great. However, We want to add support for LLT into several larger programming libraries some maintainers have told us that we need to get LLT/Liberland Time into your database in order to get it officially supported. Liberland is a pretty new country(2015) and the timezone is UTC+1(same as serbian). Could it be added to your database? It shouldnt be so hard i think and in iana i trust! Take Care and have a good week! Sincerely Filip

3 3

Summary document for 2/5/2019 CalConnect event
by Arthur David Olson Feb. 26, 2019

Feb. 26, 2019

A summary document for the 2/5/2019 CalConnect event is now available at... http://lists.calconnect.org/pipermail/timezonediscuss-l-calconnect.org/2019… @dashdashado

2 1

possible error or new zone?
by Steven Abner Feb. 25, 2019

Feb. 25, 2019

Hi, been years, please check out Asia/Dushanbe zone, either a typo or strange new zone? DST/+05/+06. Included is file I hope you find helpful. It's what helped me spot the oddity.

2 3

UTC(+00:00) 13:55 - 23/02/2019
by Rodrigo Mota Feb. 24, 2019

Feb. 24, 2019

2 1

Re: [tz] tz Digest, Vol 89, Issue 38
by KP Feb. 22, 2019

Feb. 22, 2019

Its cant! Vào 11:01, Th 6, 22 thg 2, 2019 <tz-request(a)iana.org đã viết: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Please remove tzdata2018f (Paul Eggert) > 2. Re: Please remove tzdata2018f (Philip Paeps) > 3. Re: Please remove tzdata2018f (Marcos Passos) > 4. Re: Please remove tzdata2018f (Marcos Passos) > 5. Re: Please remove tzdata2018f (Philip Paeps) > 6. Re: Please remove tzdata2018f (Brian Inglis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Feb 2019 11:03:25 -0800 > From: Paul Eggert <eggert(a)cs.ucla.edu> > To: Ankur Rana <ankur.rana(a)ericsson.com>, "tz(a)iana.org" <tz(a)iana.org> > Cc: "Sunil A. K." <sunil.a.k(a)ericsson.com>, Nishit Khosla > <Nishit.Khosla(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: <1a71a103-df7c-858c-eb96-ef07221760f1(a)cs.ucla.edu> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 2/20/19 11:31 PM, Ankur Rana wrote: > > would it be possible to prevent the tzdata version 2018f from > > downloading on iana site? > > Although it would be possible I doubt whether it would be a good idea. > 2018f does work for many downstream users, and these users wouldn't > benefit by its withdrawal from publication. Besides, standard practice > should be to use the latest version, falling back on a previous version > only if there's trouble. > > > > ------------------------------ > > Message: 2 > Date: Fri, 22 Feb 2019 09:55:05 +0900 > From: "Philip Paeps" <philip(a)trouble.is> > To: "Ankur Rana" <ankur.rana(a)ericsson.com> > Cc: "Sunil A. K." <sunil.a.k(a)ericsson.com>, tz(a)iana.org, Nishit Khosla > <Nishit.Khosla(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: <68869755-39C8-4978-A0FF-C5209A05E76A(a)trouble.is> > Content-Type: text/plain; format=flowed > > On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote: > > While doing tzdata upgrade to version 2018f > > Note that you should really be upgrading to 2018i, which is the latest > version. > > > java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on > > line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 > > S' > > Java is known to be broken with respect to the last ten years or so of > changes to the tzdb data format. You'll need to generate "rearguard" > format data to feed to the Java updater. > > Paul also helpfully provides rearguard tarballs on his webpage > https://web.cs.ucla.edu/~eggert/tz/release/. > > You can easily generate those yourself by running make > rearguard_tarballs on the distribution from iana.org. > > > To avoid any reoccurrence of same, would it be possible to prevent the > > tzdata version 2018f from downloading on iana site? > > It seems silly to pull one release from an archive going back to 1993 > because one third-party implementation (even if it's a popular one) > cannot cope with the data format. > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Ministry of Information > > > ------------------------------ > > Message: 3 > Date: Thu, 21 Feb 2019 22:14:52 -0300 > From: Marcos Passos <marcospassos.com(a)gmail.com> > To: Philip Paeps <philip(a)trouble.is>, Stephen Colebourne > <scolebourne(a)joda.org> > Cc: Nishit Khosla <Nishit.Khosla(a)ericsson.com>, "Sunil A. K." > <sunil.a.k(a)ericsson.com>, tz(a)iana.org, Ankur Rana > <ankur.rana(a)ericsson.com>, Jaspreet Singh D > <jaspreet.d.singh(a)ericsson.com> > Subject: Re: [tz] Please remove tzdata2018f > Message-ID: > <CANA3Des+0ZG=p33EndxeWhYAsysriW+2y9= > Dr6rZJE2EYzEbyQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Stephen can confirm it, but I built all versions since 2018 using JSR-310 > a few months and the result was correct. > > On Thu, Feb 21, 2019 at 21:55 Philip Paeps <philip(a)trouble.is> wrote: > > > On 2019-02-21 16:31:39 (+0900), Ankur Rana wrote: > > > While doing tzdata upgrade to version 2018f > > > > Note that you should really be upgrading to 2018i, which is the latest > > version. > > > > > java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on > > > line 1842 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 > > > S' > > > > Java is known to be broken with respect to the last ten years or so of > > changes to the tzdb data format. You'll need to generate "rearguard" > > format data to feed to the Java updater. > > > > Paul also helpfully provides rearguard tarballs on his webpage > > https://web.cs.ucla.edu/~eggert/tz/release/. > > > > You can easily generate those yourself by running make > > rearguard_tarballs on the distribution from iana.org. > > > > > To avoid any reoccurrence of same, would it be possible to prevent the > > > tzdata version 2018f from downloading on iana site? > > > > It seems silly to pull one release from an archive going back to 1993 > > because one third-party implementation (even if it's a popular one) > > cannot cope with the data format. > > > > Philip > > > > -- > > Philip Paeps > > Senior Reality Engineer > > Ministry of Information > > >

1 0

[PROPOSED] Swaziland changed its name to Eswatini
by Paul Eggert Feb. 20, 2019

Feb. 20, 2019

This does not change time data, only a name field in iso3166.tab. * africa, backzone: Update comments accordingly. * iso3166.tab: Update SZ name. --- africa | 8 ++++---- backzone | 2 +- iso3166.tab | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/africa b/africa index 0a0f586..e4936e4 100644 --- a/africa +++ b/africa @@ -374,6 +374,9 @@ Zone Africa/Cairo 2:05:09 - LMT 1900 Oct # check the time. PRI's The World. 2015-01-30 15:15 -05. # https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-bet… +# Eswatini (formerly Swaziland) +# See Africa/Johannesburg. + # Gabon # See Africa/Lagos. @@ -1188,7 +1191,7 @@ Zone Africa/Johannesburg 1:52:00 - LMT 1892 Feb 8 1:30 - SAST 1903 Mar 2:00 SA SAST Link Africa/Johannesburg Africa/Maseru # Lesotho -Link Africa/Johannesburg Africa/Mbabane # Swaziland +Link Africa/Johannesburg Africa/Mbabane # Eswatini # # Marion and Prince Edward Is # scientific station since 1947 @@ -1230,9 +1233,6 @@ Zone Africa/Juba 2:06:28 - LMT 1931 2:00 Sudan CA%sT 2000 Jan 15 12:00 3:00 - EAT -# Swaziland -# See Africa/Johannesburg. - # Tanzania # See Africa/Nairobi. diff --git a/backzone b/backzone index c464ce6..380c492 100644 --- a/backzone +++ b/backzone @@ -204,7 +204,7 @@ Zone Africa/Maseru 1:50:00 - LMT 1903 Mar 2:00 1:00 SAST 1944 Mar 19 2:00 2:00 - SAST -# Swaziland +# Eswatini (formerly Swaziland) Zone Africa/Mbabane 2:04:24 - LMT 1903 Mar 2:00 - SAST diff --git a/iso3166.tab b/iso3166.tab index 98fb988..a4ff61a 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -9,8 +9,8 @@ # All text uses UTF-8 encoding. The columns of the table are as follows: # # 1. ISO 3166-1 alpha-2 country code, current as of -# ISO 3166-1 N905 (2016-11-15). See: Updates on ISO 3166-1 -# http://isotc.iso.org/livelink/livelink/Open/16944257 +# ISO 3166-1 N976 (2018-11-06). See: Updates on ISO 3166-1 +# https://isotc.iso.org/livelink/livelink/Open/16944257 # 2. The usual English name for the coded region, # chosen so that alphabetic sorting of subsets produces helpful lists. # This is not the same as the English name in the ISO 3166 tables. @@ -235,7 +235,7 @@ ST Sao Tome & Principe SV El Salvador SX St Maarten (Dutch) SY Syria -SZ Swaziland +SZ Eswatini (Swaziland) TC Turks & Caicos Is TD Chad TF French Southern & Antarctic Lands -- 2.20.1

2 2

Add new timezone for Hanoi Capital, Vietnam
by KP Feb. 20, 2019

Feb. 20, 2019

These are the reasons that I think are reasonable - After merging with Ha Tay, Hanoi (capital) is the largest province in Vietnam - +7:00 (North Vietnam and All Vietnam since 1975) timezone has been the longest unified timezone ever, compared to Asia/Saigon, Asia/Ho_Chi_Minh (modified many times) I would like to suggest adding a timezone for Hanoi or changing the name from Asia/Ho_Chi_Minh to Asia/Hanoi as the official timezone for Vietnam. Having the same article should be considered https://tz.iana.narkive.com/foJrvdQn/tz-patch-tzdata-asia-ha-noi-add-new-ti…

13 54

[PROPOSED] Check theory.html too
by Paul Eggert Feb. 19, 2019

Feb. 19, 2019

* Makefile (CHECK_WEB_PAGES): Add check_theory.html. (check_theory.html): New dependency and rule. --- Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 680f040..f88c913 100644 --- a/Makefile +++ b/Makefile @@ -493,7 +493,8 @@ MANTXTS= newctime.3.txt newstrftime.3.txt newtzset.3.txt \ COMMON= calendars CONTRIBUTING LICENSE Makefile \ NEWS README theory.html version WEB_PAGES= tz-art.html tz-how-to.html tz-link.html -CHECK_WEB_PAGES=check_tz-art.html check_tz-how-to.html check_tz-link.html +CHECK_WEB_PAGES=check_theory.html check_tz-art.html \ + check_tz-how-to.html check_tz-link.html DOCS= $(MANS) date.1 $(MANTXTS) $(WEB_PAGES) PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica @@ -806,9 +807,10 @@ check_tzs: $(TZS) $(TZS_NEW) touch $@ check_web: $(CHECK_WEB_PAGES) +check_theory.html: theory.html check_tz-art.html: tz-art.html check_tz-link.html: tz-link.html -check_tz-art.html check_tz-link.html: +check_theory.html check_tz-art.html check_tz-link.html: $(CURL) -sS --url https://validator.w3.org/nu/ -F out=gnu \ -F file=@$$(expr $@ : 'check_$.*$') -o $@.out && \ test ! -s $@.out || { cat $@.out; exit 1; } -- 2.20.1

1 0

Fwd: Re: Add new timezone for Hanoi Capital, Vietnam
by Phake Nick Feb. 19, 2019

Feb. 19, 2019

---------- Forwarded message --------- From: Phake Nick <c933103(a)gmail.com> Date: 2019-2-19 Tue 08:30 Subject: Re: [tz] Add new timezone for Hanoi Capital, Vietnam To: KP <khaiphan9x(a)gmail.com> But, take today as an example, today's sun goes up at Hanoi at 6:24am while it goes down at 5:56pm, whereas at Ho Chi Minh City it goes up at 6:12am and goes down at 6:01pm, which mean there are only like about ten minutes or so difference? On 2019-2-19 Tue 00:42, KP <khaiphan9x(a)gmail.com> wrote: > There is a difference between day and night time of 2 regions. > > Vào 20:06, Th 2, 18 thg 2, 2019 Phake Nick <c933103(a)gmail.com đã viết: > >> Could you explain what is the difference in time in Hanoi and HCMC you >> was referring to in the message? >> >> On 2019-2-18 Mon 18:21, KP <khaiphan9x(a)gmail.com> wrote: >> >>> Thank you from the above friends, so you can see that the +7 time zone >>> of Hanoi has a longer history and maybe 1 time zone is Asia/Hanoi. If you >>> live in Vietnam, you will clearly see the difference in time in Hanoi and >>> HCMC, in the future when Vietnam is more developed, it may be necessary to >>> adjust the HN and HCMC timezone. Paul Eggert, I know that there must be >>> some rules for forming time zones. However, I see many exceptions such as >>> Shanghai and Beijing, there are many other places that I have not >>> mentioned. I think Hanoi too full of criteria for a time zone, or you can >>> consider it an exception. Why not? >>> >>>>

1 0

Today's CalConnect event
by Arthur David Olson Feb. 14, 2019

Feb. 14, 2019

I listened in on today's just-concluded CalConnect event; CalConnect is "the calendaring and scheduling consortium." Just a few notes. I heard hopes for work on the time zone database, both changes (to opaque time zone identifiers) and additions (of localization information, zone boundary information, and sequencing information to track splits and mergers of time zones). There was recognition that the database work is a volunteer effort and that there's a limit to what volunteers can do. There was mention by an ISO person of ISO's effort to establish a time zone registry with requirements for advance notification of changes; the hope is that the ISO's governmental connections would help encourage compliance. A Google representative noted the company's "under construction" (no details provided) effort to develop a time zone information distribution mechanism that would allow data to get from IANA publication to in-the-field devices within a month (seen as a reasonable objective that would deal with most real-world situations). Folks saw value in having open database maintenance processes (such as the one now used by IANA) and in having multiple sources of time zone information (that can be cross-checked against one another). I trust that other folks will correct and elaborate as appropriate. @dashdashado

11 18

[PROPOSED] Internet RFC 8536 has been published
by Paul Eggert Feb. 14, 2019

Feb. 14, 2019

* Makefile, NEWS, theory.html, tz-link.html, tzfile.5, tzfile.h: Mention the new RFC. --- Makefile | 4 ++-- NEWS | 2 ++ theory.html | 4 +++- tz-link.html | 13 ++++++------- tzfile.5 | 14 ++++++++++++-- tzfile.h | 3 +++ 6 files changed, 28 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 1e0a5e4..680f040 100644 --- a/Makefile +++ b/Makefile @@ -115,8 +115,8 @@ TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) TIME_T_ALTERNATIVES_HEAD = int64_t TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t -# What kind of TZif data files to generate. -# (TZif is the binary time zone data format that zic generates.) +# What kind of TZif data files to generate. (TZif is the binary time +# zone data format that zic generates; see Internet RFC 8536.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only diff --git a/NEWS b/NEWS index 7a84052..f5d708c 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,8 @@ Unreleased, experimental changes Changes to documentation + Mention Internet RFC 8536 (February 2019), which documents TZif. + tz-link.html now cites tzdata-meta <https://tzdata-meta.timtimeonline.com/>. diff --git a/theory.html b/theory.html index a8da065..5ea1369 100644 --- a/theory.html +++ b/theory.html @@ -983,7 +983,9 @@ an older <code>zic</code>. constrained to be a string containing abbreviations and numeric data as described <a href="#POSIX">above</a>. The file's format is <dfn><abbr>TZif</abbr></dfn>, - a timezone information format that contains binary data. + a timezone information format that contains binary data; see + <a href="https://tools.ietf.org/html/8536">Internet + <abbr>RFC</abbr> 8536</a>. The daylight saving time rules to be used for a particular timezone are encoded in the <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, diff --git a/tz-link.html b/tz-link.html index efeacd0..89ebd40 100644 --- a/tz-link.html +++ b/tz-link.html @@ -144,7 +144,9 @@ After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into machine-readable binary files, one for each location. The binary files -are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>). +are in a special timezone information format (<dfn><abbr>TZif</abbr></dfn>) +specified by <a href="https://tools.ietf.org/html/8536">Internet +<abbr>RFC</abbr> 8536</a>. The code also lets you read a <abbr>TZif</abbr> file and interpret timestamps for that location.</p> @@ -282,15 +284,12 @@ along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis -mailing list</a> discusses two Internet drafts: <a +mailing list</a> discusses the Internet draft <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate">TZDIST -Geolocate Extension</a> lets a client determine its timezone +Geolocate Extension</a>, which lets a client determine its timezone from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and -<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif">The -Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of -<abbr>TZif</abbr> data.</li> +href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) diff --git a/tzfile.5 b/tzfile.5 index bbdccfc..2f70915 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -15,7 +15,8 @@ The timezone information files used by .BR tzset (3) are typically found under a directory with a name like .IR /usr/share/zoneinfo . -These files begin with a 44-byte header containing the following fields: +These files use the format described in Internet RFC 8536. +The format begins with a 44-byte header containing the following fields: .IP * 2 The magic four-byte ASCII sequence .q "TZif" @@ -384,6 +385,15 @@ of one hour, or of 15 minutes, or of 1 minute. .BR tzset (3), .BR tzselect (8), .BR zdump (8), -.BR zic (8) +.BR zic (8). +.PP +Olson A, Eggert P, Murchison K. The Time Zone Information Format (TZif). +2019 Feb. +.UR https://\:www.rfc-editor.org/\:info/\:rfc8536 +Internet RFC 8536 +.UE +.UR https://\:doi.org/\:10.17487/\:RFC8536 +doi:10.17487/RFC8536 +.UE . .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson. diff --git a/tzfile.h b/tzfile.h index 27a38cc..446c8d5 100644 --- a/tzfile.h +++ b/tzfile.h @@ -33,6 +33,9 @@ #define TZDEFRULES "posixrules" #endif /* !defined TZDEFRULES */ + +/* See Internet RFC 8536 for more details about the following format. */ + /* ** Each file begins with. . . */ -- 2.20.1

2 5

Fwd: RFC 8536 on The Time Zone Information Format (TZif)
by Ken Murchison Feb. 13, 2019

Feb. 13, 2019

FYI. -------- Forwarded Message -------- Subject: RFC 8536 on The Time Zone Information Format (TZif) Date: Tue, 12 Feb 2019 12:48:24 -0800 (PST) From: rfc-editor(a)rfc-editor.org Reply-To: ietf(a)ietf.org To: ietf-announce(a)ietf.org, rfc-dist(a)rfc-editor.org CC: drafts-update-ref(a)iana.org, rfc-editor(a)rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 8536 Title: The Time Zone Information Format (TZif) Author: A. Olson, P. Eggert, K. Murchison Status: Standards Track Stream: IETF Date: February 2019 Mailbox: arthurdavidolson(a)gmail.com, eggert(a)cs.ucla.edu, murch(a)fastmailteam.com Pages: 34 Characters: 83992 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-murchison-tzdist-tzif-16.txt URL: https://www.rfc-editor.org/info/rfc8536 DOI: 10.17487/RFC8536 This document specifies the Time Zone Information Format (TZif) for representing and exchanging time zone information, independent of any particular service or protocol. Two media types for this format are also defined. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor(a)rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC

1 0

zic option for including data from a certain year onward
by Christopher Wong Feb. 5, 2019

Feb. 5, 2019

Hi, I think the tzdb is very good with its history. However, I would like to minimize the size and has been looking into how to achieve that. Will it be of any interest with an option in zic to include only data from a certain year onward? What is the best way? 1.? Remove the Rules and Zone entries not relevant for that year onward during the parsing. Tried this, but ended up with with some nasty warnings. 2. Make changes in writezone-function. Trying this now, but I am getting confused with types, omittype, typemap, and so on. It would be good if someone that knows the code can give me some hints if this is the right place to make such a change. BR, Christopher Wong

4 4

About time
by Arthur David Olson Feb. 2, 2019

Feb. 2, 2019

Having stumbled across a copy of the educational film "About Time," I can correct the quotations that kick off the README file; the diffs should be attached. @dashdashado

4 3

Europe/Budapest timezone
by Lev Feb. 2, 2019

Feb. 2, 2019

Dear all, I've downloaded the current time zone data from this link: https://data.iana.org/time-zones/releases/tzdata2018i.tar.gz , and compiled the time zone files with zic. For Europe/Budapest, I got this tz string: CET-1CEST,M3.5.0,M10.5.0/3 I think IMHO it should be: CET-1CEST,M3.5.0/2,M10.5.0/3 Best regards, Levente -- Levente Kovacs Senior Electronic Engineer W: http://levente.logonex.eu

4 5

Fwd: Bulletin C number 57
by Tim Parenti Feb. 1, 2019

Feb. 1, 2019

FYI, per IERS Bulletin C57, there will be no leap second on 2019-06-30. Unfortunately, NIST is affected by the partial shutdown of the US government <https://www.commerce.gov/news/blog/2018/12/shutdown-due-lapse-congressional…> which has been ongoing since 2018-12-22 00:00 -05, so most of their website is unavailable, meaning it will likely be some time before they publish an updated leap-seconds.list. But since the current NIST file doesn't expire until 2019-06-28, we've got some time before we have to deal with that. Last we had left the problem of being able to take the equivalent file directly from the IERS at https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list, some lines had been added to https://hpiers.obspm.fr/iers/bul/bulc/README on 2017-04-11, but the exact text did not make any assertions about surrounding files, and we would prefer the notice be added to leap-seconds.list itself. (There are a few other typos therein which I spotted as well.) See: https://mm.icann.org/pipermail/tz/2017-April/024990.html https://mm.icann.org/pipermail/tz/2017-April/024988.html In light of the current US/NIST situation, it would be helpful to re-energize these efforts. Happy to help Christian and others come up with something workable. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Mon, 7 Jan 2019 at 10:56 Subject: Bulletin C number 57 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 07 January 2019 Bulletin C 57 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2019. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

8 19

[calsify] Streaming info for CalConnect Public Time Zone Workshop on February 5 in Zurich, Switzerland
by David Thewlis Jan. 31, 2019

Jan. 31, 2019

The CalConnect Public Time Zone Workshop will be next Tuesday, 5 February 2019, between 1400 and 1730 Central European Time. We have made arrangements with our host, Google, to stream the CalConnect Public Time Zone Workshop <https://www.calconnect.org/events/calconnect-public-time-zone-worksjop> for any interested parties who cannot be present. (The workshop was announced in November and we did get a few queries as to streaming.) The streaming will be done using Google Hangouts; the URL to join the stream is https://meet.google.com/qjb-zbip-cpf <https://meet.google.com/qjb-zbip-cpf>. You do have to have a google id of some sort (gmail is fine) to join the streaming. When you access the stream, your request to join will be authorized. Please do not attempt to join before 1345 CET. The workshop itself will take place between 1400-1730 CET. The inbound audio and video stream will be disabled, so this will be a one-way outbound feed. However, there is a chat function so you can ask questions via the chat. Our plan is to take periodic pauses so the chat questions can be brought up and answered. If that proves impractical we will answer the chat questions after the workshop is over, so you’ll want to include an e-mail address for a response. Dave Thewlis Here’s the original post: Please note that this is NOT an IETF event. CalConnect <http://www.calconnect.org/> will host a Public Time Zone Workshop on Tuesday afternoon, February 5th, during its conference at Google in Zürich, Switzerland <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019>. The Time Zone Workshop will be Tuesday February 5th from 13:30 to 17:30 at the Google facility <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019#location>. This workshop will be focussed on the potential impact of EU Summer Time changes and how the changes might be mitigated; please see our news release <http://www.calconnect.org/news/2018/10/30/calconnect-calls-eu-reconsider-ti…>. The workshop is open to the public but you must register in advance. There is no fee to attend the workshop. Attendees are invited to stay for a Welcome Reception following the workshop. More information will be provided as planning continues. The workshop is intended for anyone who needs to plan and prepare for this and other TZ/DST changes, in particular representatives from governments, industries affected by tz changes (travel, financial, health, device manufacturers, etc.), organizations deploying tz data, and organizations maintaining and updating tz data. Please register for this event at https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets… <https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets…>. We invite anyone who is interested in or concerned by the pending changes and how time zone change information might better be distributed and implemented to attend. Dave Thewlis -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org <http://www.calconnect.org/> | Dave.Thewlis(a)calconnect.org <mailto:Dave.Thewlis@calconnect.org> _______________________________________________ calsify mailing list calsify(a)ietf.org https://www.ietf.org/mailman/listinfo/calsify

1 0

DST ends 2040 in Oracle database
by Joachim Damm Jan. 31, 2019

Jan. 31, 2019

Hello, we found one issue in the Oracle database that DST calculation is wrong from 2040 and beyond. I create a SR at Oracle and the Oracle support told me, that this behavior is from the IANA tzdata file and not from Oracle. My question is, if this is the case, where can I find the required information? If this is not the case, please let me also know to give the information to the Oracle support. I will appreciate your feedback regarding the information from the Oracle SR team! Mit freundlichen Grüßen / Kind Regards i.A. Joachim Damm Senior Database Consultant Systems Integration [cid:image001.jpg@01CF7F53.FD0881C0] Werum IT Solutions GmbH Wulf-Werum-Str. 3, 21337 Lüneburg, Germany T +49 4131 8900-515 F +49 4131 8900-20 Joachim.Damm(a)Werum.com<mailto:Joachim.Damm@Werum.com> www.werum.com<http://www.werum.com/> Geschäftsführer / Managing Directors: Rüdiger Schlierenkämper, Richard Nagorny, Hans-Peter Subel RG Lüneburg / Court of Jurisdiction: Lüneburg, Germany Handelsregisternummer / Commercial Register: HRB 204984 USt.-IdNr. / VAT No.: DE 116 083 850 Connect with us: [cid:image006.jpg@01D4B3D4.B9323120] <https://www.linkedin.com/company/werum> [cid:image007.jpg@01D4B3D4.B9323120] <https://twitter.com/werum> [cid:image008.jpg@01D4B3D4.B9323120] <http://www.vimeo.com/werum> [cid:image009.jpg@01D4B3D4.B9323120] <https://www.youtube.com/werum>

12 23

Re: [tz] DST ends 2040 in Oracle database
by Brian Inglis Jan. 31, 2019

Jan. 31, 2019

On 2019-01-31 15:25, Scott Nelson wrote: >> On Jan 31, 2019, at 4:17 PM, Brian Inglis wrote: >> Device expiration date is specified as ISO: >> https://www.ecfr.gov/cgi-bin/retrieveECFR?n=se21.8.801_118 >> "Title 21 → Chapter I → Subchapter H → Part 801 → Subpart A → §801.18 >> Title 21: Food and Drugs >> PART 801—LABELING >> Subpart A—General Labeling Provisions >> §801.18 Format of dates provided on a medical device label. >> ... >> (a) In general. Whenever the label of a medical device includes a printed >> expiration date, date of manufacture, or any other date intended to be brought >> to the attention of the user of the device, the date must be presented in the >> following format: The year, using four digits; followed by the month, using two >> digits; followed by the day, using two digits; each separated by hyphens. For >> example, January 2, 2014, must be presented as 2014-01-02. >> ... >> [78 FR 58818, Sept. 24, 2013]” > Yeah, but the exception is rather large: > (b) Exceptions. (1) A combination product that properly bears a National Drug > Code (NDC) number is not subject to the requirements of paragraph (a) of this > section. Why I restricted my statement to "Device expiration date" -- 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.

1 0

new NIST leap-seconds.list
by Chris Woodbury Jan. 31, 2019

Jan. 31, 2019

Thanks to Dr. Levine, NIST has a newer version of leap-seconds.list with an expiry of 28 Dec 2019. Hurrah!! (Note: I re-named it so I could see the different versions.) $ FIPS180 -f NIST_leap-seconds.3676924800.2019-01-31 -v -h Generated SHA digest matches file digest File name: NIST_leap-seconds.3676924800.2019-01-3 Original file name: leap-seconds.3676924800 Last modified: 31 Jan 2019 08:02:47 UTC Updated: 08 Jul 2016 00:00:00 UTC Expires: 28 Dec 2019 00:00:00 UTC #h 83c68138 d3650221 07dbbbcd 11fcc859 ced1106a $

1 0

Time Zone Standards
by Samah Kareem Jan. 31, 2019

Jan. 31, 2019

Hello All I want to ask about references, countries can change their time zone depending on, I want name of standards, guidelines if any. Regards Samah Kareem

3 2

Daylight saving in 2372
by Arthur David Olson Jan. 30, 2019

Jan. 30, 2019

In the "Star Trek: Deep Space Nine" episode "Paradise Lost," Captain Sisko, at Starfleet's San Francisco headquarters, mentions "19 hundred 47 hours P. S. T." Per one source*, theepisode is set in June 2372. Seems there's no daylight saving in San Francisco in 2372, but the "standard" "S" is still used. @dashdashado _ *http://www.johnstonsarchive.net/startrek/st-episodes-1.html

5 5

Bulletin C number 57
by Chris Woodbury Jan. 30, 2019

Jan. 30, 2019

Something else, as it may not be obvious. The comments and white space do not contribute to the FIPS 180 digest and they may all be edited with impunity. This is the primary reason that using the date in the comments as data is such a bad idea. There's absolutely is no way to detect any changes or tampering. So, if someone doesn't like the fact that I put in the sign of the TAI-UTC delta T (or the MJD) as comments, edit it out. (Or any line starting with # (except the timestamps) for that matter.) Paul, your "corrected" leap-seconds.list file is an attachment.

1 0

California Prop 7 approved by voters
by Alan Mintz Jan. 29, 2019

Jan. 29, 2019

Since I don't see it mentioned... In November 2018, California voters approved Proposition 7 (by a 60-40 vote), which allows the state legislature to put the state on UTC-7 (the current DST) year-round. It requires a 2/3 majority in legislature, and federal law would have to be changed to allow it as well. Apparently, Florida did something similar, and Senator Marco Rubio is pushing bills in the U.S. Senate to legalize the changes. [ http://www.capradio.org/articles/2018/11/08/californias-daylight-saving-pro… ] California Assembly Bill 7 <http://leginfo.legislature.ca.gov/faces/billStatusClient.xhtml?bill_id=2019…> was introduced in December 2018 and is currently in committee. U.S. Senate bills S. 2536 <https://www.congress.gov/bill/115th-congress/senate-bill/2536> and S. 2537 <https://www.congress.gov/bill/115th-congress/senate-bill/2537> were introduced in March 2018 and are currently in committee. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Re: [tz] Bulletin C number 57
by Chris Woodbury Jan. 29, 2019

Jan. 29, 2019

Brian Inglis is correct, changes to the "white space" [newline, space, tab, and carriage return] and comments do not change FIPS 180 Secure Hash Standard (SHS) digests. And, yes, Paul Eggert is correct, I have a script that generated the file I submitted to the mailing list. However, it was written for my personal use (I generate my own leap-seconds.list file for use by NTPd on my local systems) and does decidedly *not* meet all the restrictions placed upon the code within the TZ sphere.by ICANN/IANA (and IETF?). I shudder at the thought of making it do so. First, it uses GNU's sha1sum to calculate the FIPS 180 digest string. sha1sum will return the same digest as FIPS 180 given the *same input*. The trick is getting the same input... It also uses tolower() in AWK to ease the parsing it does. (I've got a FIPS180 shell function, too.) Two, the script is really automatic. It parses Bulletin C and the USNO/MAIA's leapsec.dat file. I use AWK to pull leap-second data from leapsec.dat, convert it to NTP timestamps and TAI-UTC offsets, which, along with the data extracted from Bulletin C (which provides the update and expiry timestamps) is all the information needed to make a leap-seconds.list file. Lastly, *it literally drives me nuts* (see real mail address) that leapseconds.awk uses the date in the comments to generate "leapseconds". So, no, I don't think I'll change the comments in the file. THEY'RE COMMENTS! There is no, none, zero, nada guarantee the comments represent anything in particular. Data on the other hand, does ... we really should be using it. Maybe we should be using USNO/MAIA leapsec.dat to generate the ZIC Leap directives in the first place. The date there is not a comment. It's also easier to manipulate days than seconds (86400 time less chance of an overflow.) We could even generate our own version of leap-seconds.list for downstream users (and never worry about government shutdowns again). (A trade-off with Paris rioting?) IERS/USNO/MAIA Bulletin A (ser7.dat), series14.txt and leapsec.dat could be used instead of the the copyright files at the Paris Observatory. This is not to say I won't help. I would be glad to provide leapseconds.awk code that use the *actual data* to generate the proper ZIC Leap directives. I have several versions of leapseconds.awk that meet all hoops the TZ code must be put through. In particular, I, and Dennis Ferguson, have AWK functions that manipulate NTP timestamps into a format that can generate date strings usable for ZIC LEAP directives. Thanks to dennis.c.ferguson for the germ of an idea to start years on 1 March when calculating leap-days. BTW, Dennis, 15th century Gregorian timestamps are not proleptic. The Gregorian calendar starts on 15 Oct 1582 (14th cent). A belated and long overdue thanks to Paul for pointing out Dennis function. I apologize. Finally, this is all moot, the shutdown is over, NIST will eventually make an updated leap-seconds.list file (with the wrong update timestamp but a correct expiry). Also, Jeff Prillaman at USNO Time Services Dept. has put up an updated leap-seconds.list file at Tycho.USNO.Navy.Mil. (Thank you, Jeff !!) (The GIT backup source for leap-seconds.list (I hope)?)

1 0

Java TZDB compiler
by Marcos Passos Jan. 26, 2019

Jan. 26, 2019

Hello, The Java TZDB compiler models transitions in terms of historical transitions and transition rules. All transition rules start one year after the latest year among the unbounded rules in the TZDB database for a given zone. Reading the docs, I found the following explanation about that extra year: Also add one more year to avoid weird case where penultimate year has odd > offset. Does anyone know what does it mean and in which cases does it occur? - Marcos

2 2

How long will the rearguard formats continue be provided?
by Pramoth Murali Jan. 25, 2019

Jan. 25, 2019

Hello! Our team utilizes a custom version of tzcode and a calendar utility that don't support negative DST offsets that was brought back in 2018e nor the 2018f fallback transactions Japan rules that were at 25:00 hour. We utilized 2018i rearguard-format version and we were able to utilize 2018i with our parsers. The 2018i announcement mentions that the rearguard is intended to be a temporary transition aid; that raises fear if we have to patch one of the upcoming tzdata releases that don't provide a rearguard with similar fixes. While we are planning to work on fixes for our timezone parsers; in order to ensure we have enough leeway for our new solutions, we would be curious to know how long will these rearguard versions (with no negative offsets) continue to be provided?

4 4