- tz - lists.iana.org

WSJ follows AP to Kyiv
by Chris Woodbury Oct. 26, 2019

Oct. 26, 2019

i can't help but notice, with Ukraine dominating the news, that *every single* reference that I've seen (US State Dept, MSNBC, CNN, ABC News, NBC News, CBS News, every graphic, etc, with the capitol mentioned) has spelled it Kyiv.

2 1

[PROPOSED 1/2] * northamerica: Update Garland URL.
by Paul Eggert Oct. 24, 2019

Oct. 24, 2019

--- northamerica | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/northamerica b/northamerica index 8771d96..42e18c7 100644 --- a/northamerica +++ b/northamerica @@ -86,7 +86,7 @@ # For more about the first ten years of DST in the United States, see # Robert Garland, Ten years of daylight saving from the Pittsburgh standpoint # (Carnegie Library of Pittsburgh, 1927). -# http://www.clpgh.org/exhibit/dst.html +# https://web.archive.org/web/20160517155308/http://www.clpgh.org/exhibit/dst… # # Shanks says that DST was called "War Time" in the US in 1918 and 1919. # However, DST was imposed by the Standard Time Act of 1918, which -- 2.21.0

1 1

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