- tz - lists.iana.org

Changes in daylight saving rules in Brazil
by Alexandre Henrique Soares Dias Nov. 6, 2019

Nov. 6, 2019

Dear IANA Team, My name is Alexandre Dias and I'm a Data Scientist at a Brazilian Startup called Looqbox. As an R programmer and knowing that R uses the international standard IANA time zone rules. I would like to inform that the current Brazilian government changed daylight saving rules for "America/Sao_Paulo" timezone. This changes occurred this year and many devices are operating under the wrong hour of the day. Usually, at this time of the year we had to advance our clock by one hour going from -03 GMT to -02. However, as I said, this is no longer the rules and the clocks must remain -03 GMT. Following there is a print of this phenomenon showing that R is display and returning the wrong time for my timezone: [image: image.png] <https://files.slack.com/files-pri/T0NA05E3Y-FQ4LFH6CV/image.png> The correct output should be "2019-11-04 13:25:27 -03". Given the problems that may arise from this kind of behavior, I kindly ask you to apply the changes I informed above as soon as possible. Sincerely yours, Alexandre Henrique Soares Dias Data Scientist at Looqbox

3 2

No more DST in Brazil
by Sergio Leal Nov. 4, 2019

Nov. 4, 2019

Dear Sirs, I am a PHP programmer and I verified a problem when I setted a timezone location to "America/Sao_Paulo" for a program. I observed that data was showing dates and times with 1 hour difference. After some search, I downloaded the TZ database from https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz where I believe that Brazilian DST remains setted, despite of Brazilian Governament has officialy cancelled DST in Brazil as described in the file southamerica finded in the TZ database in lines 946 to 949. I hope I could help. Regards, Sergio Leal Enviado do Email para Windows 10

4 3

61472314_Letter from the Embassy of Ukraine
by Embassy of Ukraine in the USA Nov. 4, 2019

Nov. 4, 2019

2 1

Please add Kaliningrad City (UTC+2)
by westmail24＠yandex.com Nov. 4, 2019

Nov. 4, 2019

Hello, If possible, add please Kaliningrad (Russia), UTC+2 without DST in new "tzdata". (It's Moscow -1 Hour.) Regards, Andrew, Russia.

2 1

Potential problem with Sao_Paulo TZ in tzdata2019c
by Bryan Coleman Nov. 1, 2019

Nov. 1, 2019

It appears there is a bug with the America/Sao_Paulo time zone; specifically, with the 2014-02-15/16 DST change. Not sure the best way to confirm and/or if there is someone that can quickly check/verify. Thoughts? I found this while working with java and noticed it after upgrading from adoptopenjdk version 8u222_b10 to version 8u232_b09. I believe 222 utilizes tzdata2019a while 232 utilizes tzdata2019c. I understand that there are many things that could cause the issue from the code running in java down the stack to the tzdata; however, believe tzdata is the most likely culprit. Any thoughts/ideas of how to track this down? Thank you, Bryan Reference Output: jdk 8.222_b10 2014-02-15 23:59:59 BRST: 1392515999000 2014-02-15 23:00:00 BRST: 1392512400000 2014-02-15 23:00:00 BRT : 1392516000000 2014-02-16 00:00:00 BRST: 1392516000000 2014-02-16 00:00:00 BRT : 1392519600000 jdk 8.232_b09 2014-02-15 23:59:59 BRST: 1392519599000 2014-02-15 23:00:00 BRST: 1392516000000 2014-02-15 23:00:00 BRT : 1392516000000 2014-02-16 00:00:00 BRST: 1392519600000 2014-02-16 00:00:00 BRT : 1392519600000

2 1

logical and arithmetic ops and operator precedence.
by christos＠zoulas.com Oct. 29, 2019

Oct. 29, 2019

Hi, Can we please change in zdump.c: if (lotm_ok & tm_ok ? (delta(&tm, &lotm) == t - lot && tm.tm_isdst == lotm.tm_isdst && strcmp(abbr(&tm), ab) == 0) : lotm_ok == tm_ok) { to: if ((lotm_ok && tm_ok) ? (delta(&tm, &lotm) == t - lot && tm.tm_isdst == lotm.tm_isdst && strcmp(abbr(&tm), ab) == 0) : lotm_ok == tm_ok) { for clarity? Both lotm_ok and tm_ok are booleans... Thanks, christos

4 4

Changes in time zone Pacific/Norfolk
by Nishit Doshi Oct. 26, 2019

Oct. 26, 2019

Norfolk Islands have implemented the DST schedule of Australia. Please Implement the changes as soon as possible.

4 3

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