- tz - lists.iana.org

South Sudan to change time zone?
by Steffen Thorsen Jan. 20, 2021

Jan. 20, 2021

Quite a few sources, but they seem mostly to be syndicated from the same story tell that: "South Sudan will change its time zone by setting the clock back 1 hour on February 1, 2021, the government spokesperson has said. According to the minister of information, Michael Makuei Lueth, South Sudan will change its offset from UTC+3 to UTC+2." from https://eyeradio.org/south-sudan-adopts-new-time-zone-makuei/ and a bit different here: https://radiotamazuj.org/en/news/article/south-sudan-to-change-time-zone-ne… Best regards, Steffen Thorsen - timeanddate.com

5 8

Kyiv NOT Kiev
by Vyacheslav Lukin Jan. 18, 2021

Jan. 18, 2021

Hello, My name is Viacheslav Lukin and I live in Kyiv, Ukraine. Could you please change incorrect spelling Kiev in database to correct Kyiv? Campaing #KyivNotKiev: https://en.wikipedia.org/wiki/KyivNotKiev Wikipedia and Google use the spelling Kyiv: https://en.wikipedia.org/wiki/Kyiv https://www.google.com/maps/place/Kyiv In Ukraine use the spelling Kyiv: https://static.ukrinform.com/photos/2015_10/thumb_files/630_360_1443988512-… https://static.ukrinform.com/photos/2019_02/thumb_files/630_360_1550082358-… https://static.dw.com/image/49169749_303.jpg Ukrainian companies use the spelling Kyiv: https://kyivstar.ua/ https://www.kyivpost.com/

2 1

Rename timezone
by Вітя kor0p Jan. 18, 2021

Jan. 18, 2021

Hello, I'm from Ukraine, and I want to change the name of Europe/Kiev timezone to Europe/Kyiv, because it's the right translation of the capital of Ukraine. Some countries, media, and organizations start using the correct name. #KyivNotKiev. The wiki article about this: https://en.wikipedia.org/wiki/Kyiv With hope to changes, Victor

2 1

Negative leap seconds in mainstream media
by Arthur David Olson Jan. 12, 2021

Jan. 12, 2021

"Why Scientists Want to Shorten the Minute to 59 Seconds" https://www.popularmechanics.com/science/a35165130/leap-second-shorten-minu… (As noted on Twitter by Molly Conger, @socialistdogmom.) @dashdashado

8 10

No leap second on 2021-06-30
by Tim Parenti Jan. 9, 2021

Jan. 9, 2021

Per IERS, Bulletin C 61 (2021-01-07) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.61 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Thu, 7 Jan 2021 at 08:05 Subject: Bulletin C number 61 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 2021 Bulletin C 61 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 2021. 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

1 0

Europe/Kiev to be renamed to Europe/Kyiv
by Андрій Лавріненко Jan. 8, 2021

Jan. 8, 2021

Good afternoon! I'd like to report that the spelling of this Ukrainian city name has been changed from Kiev to *Kyiv*, as reflected by Google Maps <https://www.google.com/maps/place/%D0%9A%D0%B8%D1%97%D0%B2,+%D0%A3%D0%BA%D1…>, Wikipedia <https://en.wikipedia.org/wiki/Kyiv>, the UN <https://www.un.org/Depts/Cartographic/map/profile/ukraine.pdf>. Hope that will be useful to inform the tz name update. -- Best regards, Andrii Lavrinenko

2 1

zic bug: Wall-clock ordering of transition times
by Tim Parenti Jan. 4, 2021

Jan. 4, 2021

I noticed a bug while incorporating changes to commentary for the Turks and Caicos Islands… https://mm.icann.org/pipermail/tz/2020-December/029609.html Our contemporaneous use of "3:00" in the UNTIL field for the 2018-03-11 change intentionally avoided two clock changes in a row (first from 01:59:59 AST to 01:00:00 EST, then from 01:59:59 EST to 03:00:00 EDT an hour later). https://github.com/eggert/tz/commit/8792d7bed2c684cf842592fd7779645f335a33f6 My recently-added commentary clarifies the reasoning behind this and concludes that the order was likely intended to take effect from 03:00 -04, once the Eastern US had sprung forward, and not at 02:00 -04 as the text suggests. However, I noticed that using "2:00" in the UNTIL field instead doesn't actually result in the expected extra transition: --- to2050.tzs 2020-12-05 14:11:12.000000000 -0500 +++ to2050new.tzs 2020-12-05 14:17:31.000000000 -0500 @@ -5201,7 +5201,7 @@ 2014-03-09 03 -04 EDT 1 2014-11-02 01 -05 EST 2015-03-08 03 -04 AST -2018-03-11 03 -04 EDT 1 +2018-03-11 02 -04 EDT 1 2018-11-04 01 -05 EST 2019-03-10 03 -04 EDT 1 2019-11-03 01 -05 EST It seems that, the 02:00 wall-clock time having already been approached once for the transition out from AST, zic assumes that the transition specified in the US Rule at the same wall-clock time has also taken simultaneous effect in Eastern Time, although in reality it wouldn't yet for another hour. In this case, the wall-clock times of these two transitions are identical, while in actuality the transitions are meant to take effect sequentially. It appears that this bug also manifests in other cases where the strict ordering of transitions does not exactly match the strict ordering of wall-clock times: Trying out "2:30" in the UNTIL field should mean that the Zone transition should happen 30 minutes BEFORE the US Rule would take effect (and thus require two transitions), but by wall-clock time, it would "appear" to be 30 minutes AFTER (fooling zic into thinking only the "latter" Zone transition is needed as the Rule would have "already" taken effect). And, indeed, the results are similarly incorrect here, too: --- to2050.tzs 2020-12-05 14:11:12.000000000 -0500 +++ to2050new.tzs 2020-12-05 14:36:07.000000000 -0500 @@ -5201,7 +5201,7 @@ 2014-03-09 03 -04 EDT 1 2014-11-02 01 -05 EST 2015-03-08 03 -04 AST -2018-03-11 03 -04 EDT 1 +2018-03-11 02:30 -04 EDT 1 2018-11-04 01 -05 EST 2019-03-10 03 -04 EDT 1 2019-11-03 01 -05 EST Certainly an edge case in this particular instance, but given that many historical transitions coincide tightly with transitions in other regions being "joined" or "left", perhaps one worth a further look. -- Tim Parenti

5 16

No Scottish time zone in the 1990s
by Clive D.W. Feather Dec. 30, 2020

Dec. 30, 2020

An interesting (for us on TZ) little bit of history. https://www.bbc.co.uk/news/uk-50950961 "National archives: Sir John Major snubbed separate Scottish time zone" -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

1 0

[tz-announce] 2020f release of tz code and data available
by Paul Eggert Dec. 29, 2020

Dec. 29, 2020

The 2020f release of the tz code and data is available, reflecting the following change to the build procedure: 'make rearguard_tarballs' no longer generates a bad rearguard.zi, fixing a 2020e bug. (Problem reported by Deborah Goldsmith.) There are no changes to the data since 2020e. The build-procedure change was circulated on the tz mailing list and is intended for downstream consumers that can process only rearguard format. Please see the PS at the end of this email for more info about rearguard format. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020f.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 846c3ac7abc246094dd754ac6dc90423148a5107 dated 2020-12-29 00:17:46 -0800 and tagged '2020f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5f6bf1b508434842eb9dacacc744b5f3375c35b88e401ef372b5fde80ad2f523484fe52a6e99460e402230406ebf6a9261a97efde45a610f8e8085893d55c4ed tzcode2020f.tar.gz dd312def18c807452fda2e697514e2064c5f51ebdbedd0cfe6f231252c76ee5d4409f653b295ed5657b7d30b868690047fdb70a10942e69eaa40b77473e3f9ca tzdata2020f.tar.gz a2efd9cb6308c75de382ff1ddc524dad5da10d76d86c6bf41ab2f979fffae1356b2599b3fcc045eab1cb56b16f9371663da5be57c1f43591517be62e65abbf1c tzdb-2020f.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5ukACgkQ7ZfpDmKq fjSOqA//d2SuaDA9HEXuGXOgTV2f9Iu8x4XF3cIc/UYIh/9yi7T1jVhRD70rPjTO 0g1ohBPoT/oY5OaFholMuZfoIwNgPv2K4c05xNrmNdbbz/3iaddm1zpD5WutRw2c u+hqrR1C5p/ICoSEH+/SAwmBFYEpQYCnkFUScC7YeGoZzzpKls3l/8hvUFaKt8SW ssgS/nVA3L54W8Hdu8WUl2Nz7xmkN3zzRseZMsU3+CrUwXtGzyySZPAJR1Ryk1ee PgwZaoteeGFl08Y7QfvyZBc7xakgnMEdhFB+m2SH//RO6DLjjuWlSAV9wMCk6dZq Uu3yZDVfsV91kiXOavdZFGXQCGXFVmkU7cZnSlpGWuIQGDX0iLOdcuWTFSEw+Av6 UP0cKyX2gJdXaqsYaBpgkCNh0SzG8ui5sS+vimCXG0+0d3z5ru2sHOTSkDxAke6a Jbs5PCz4HXpkIbbE73j+GzaoGWvbzqIledXV+J18uOAcfX13Ejft1nMFyZYh2vvJ 3DH3j1KA0NMs1u9o2F3HWPQcGZKuLFg0BxU2hEeIqbEwXAs980Mo5xrDtFRk4VLy Sg/o6XiREeXV06gXLqlP0vKa+qf88J9u18wMuuiPX1NmNZOcdekVVZtYQ5VhDjbZ xcg3S7YG9HUB+SxnAWQ21jaioQPLYB0Sc2/2vo8VzvIDE9iy8FI= =WeIr -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5ukACgkQ7ZfpDmKq fjQ8ug//WH7DpYFvSYMKpSj6gG0m5lK0JXcs062EKGQNsVoUjSVImu3VPbpUS9tu cO3NCUmeqTmwhUOuZQN2qGAT2KyNhcLTlza8xuRQm/tJ7SYpArseY9rudQtkjbCi uWELQi5+a6CA/PBBRJzDJwQPTf4wDZr24vDd29tKqBho5T5cisudXHhqh1Bm0Bfr NPyPsS6+oLJofIVsU0I5V+fbnU98ny5I1r/OyVIJgAlvEcb0kMDr0fBfu1dNvJI9 Tyl3kvdLSMCgf/lRXEFYJpI0RuUeIAsOvHaSwSCHKGc7FHzgDiK1U5D/4z5Ipo02 0AQKkLFkEbzwou/5KtX2Q3+yba1AGu64C7elu+aKepUNGhkzAaJrl2xNNM25Sdn4 1WvxOt43GTIze0cr9UHm942sU5UxH0ahv4h9pEbqJ44UVzBhuDDqcMXYJEWhdhMf 6dgRA7SJThuX7tN758to9Ze9XyXMdzAPdJKs/wyLrRGyDq0dXlRTVPL4Nk9ZqRQh FYJlOhM2TGSg7VsNgn8gneODaaQJpJ7jVSIwicQtWES2K2oblrFz4LSeXm39xZDc 0JRNh/fSeRygCGrjD7CLqq88UGTxhEuZbEXKXSPMLC+7j7JF/CmCVj8HjNw8M3Cy uk/Tfamala66AGltxPwKchTPBJH8F4tZy+4krfYXByoIX5h+Ta4= =Fk0g -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/q5usACgkQ7ZfpDmKq fjSp4A//aoSQ/VDoYZhE5F7PXV+td9DTVGABdA6ubQppymgX8uJvuBgk46pDRmVw Yba4dVcblTzjbCNDCBf9+nkgj46hGdql10t9bjgBDKf5MVQwp8hDyQfj3qbJciBD E0JSMXw3JQpuK1YVqxTXldINxtaSaLJUhYh1inBmEs8uX+vrwzURmYhF7NLoG7GL ymClE3BAJwkNXuRJ4tAMhEaANdShnre+uJWWW7DeNZPrHVKhSSD7IyAWin3vNUEj FA3ELERWgTVbkpmsUUH+5VtUIp8dE9jGxzgaPfy4KmuN0D4qiEgjSg23AFZDWqwF jDX2OlQl7J9oQfeUUBooee1S6IkVCC0+WNJPhSjeeKV8CUBBT5YKtTAgnx14bgkc nL01dF49WxA2MrQMWd794jh6dpMwDzdWw4gdEMLoiSOKRpO5E5iHzjM7c0WWyrGl Hqh6ZmBZz+17wBFSd7QQtLpwWajl+yGgSONJcw0cnvdjleJ6m89vcdzsrsD55ONT uRZK1TEaZqYG6U6lk/XxDsVQiC1CQ9/vWOPT8bhd2wdIhf9g0skN+MNachKQfs11 9Xn+pfMk79Vgatbbq9rDk0F3v6gRjayYRDtcVCFoOmrdXWmRhQtvyerm6wCILsFU gWpdS8tIo/4dwbypyot/5fe0ZEUBJGfbe7PSZu7a64DTgecE5R8= =mWt8 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

Joda-Time compiler broken again
by Stephen Colebourne Dec. 28, 2020

Dec. 28, 2020

The latest 2020e release broke the Joda-Time compiler again. https://github.com/JodaOrg/joda-time/runs/1607329443?check_suite_focus=true… Presumably, some rule now contains a 31 in a 30 day month now? Stephen

5 8

[tz-announce] 2020e release of tz code and data available
by Paul Eggert Dec. 27, 2020

Dec. 27, 2020

The 2020e 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: Volgograd switches to Moscow time on 2020-12-27 at 02:00. Changes to future timestamps Volgograd changes time zone from +04 to +03 on 2020-12-27 at 02:00. (Thanks to Alexander Krivenyshev and Stepan Golosunov.) Changes to past timestamps Correct many pre-1986 transitions, fixing entries originally derived from Shanks. The fixes include: - Australia: several 1917 through 1971 transitions - Bahamas: several 1941 through 1945 transitions - Bermuda: several 1917 through 1956 transitions - Belize: several 1942 through 1968 transitions - Ghana: several 1915 through 1956 transitions - Israel and Palestine: several 1940 through 1985 transitions - Kenya and adjacent: several 1908 through 1960 transitions - Nigeria and adjacent: correcting LMT in Lagos, and several 1905 through 1919 transitions - Seychelles: the introduction of standard time in 1907, not 1906 - Vanuatu: DST in 1973-1974, and a corrected 1984 transition (Thanks to P Chan.) Because of the Australia change, Australia/Currie (King Island) is no longer needed, as it is identical to Australia/Hobart for all timestamps since 1970 and was therefore created by mistake. Australia/Currie has been moved to the 'backward' file and its corrected data moved to the 'backzone' file. Changes to past time zone abbreviations and DST flags To better match legislation in Turks and Caicos, the 2015 shift to year-round observance of -04 is now modeled as AST throughout before returning to Eastern Time with US DST in 2018, rather than as maintaining EDT until 2015-11-01. (Thanks to P Chan.) Changes to documentation The zic man page now documents zic's coalescing of transitions when a zone falls back just before DST springs forward. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020e.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 efc5c061920f1d5820d66b7ec88ebff144c55b3f dated 2020-12-22 15:14:34 -0800 and tagged '2020e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 37656ee4400f6e7ac8b3d4b515ea2ae940de05e8a95873112a4ec08afc11227214f269e4ef1bedb0389497958dd07a6d4721191e441920bc45c235b029a8a885 tzcode2020e.tar.gz 1e64b5c91b9e56923cf8e3e079781c59c8afb6c379b38b9b91ef493929814d50c29a6368cfcf77db08a7af3b6876387bac5617f64ac965a5bddab436d17862c4 tzdata2020e.tar.gz 77e62a3717d179b13f35710dedd87d780649edf6c338c056e41ba58d49225e512074a5fbfa3ae52242bea6b28d1a08bb0e2b07ff7a3aed031dc9d357dac34170 tzdb-2020e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifpwACgkQ7ZfpDmKq fjQrYA//Z3ky92YK4p8GAejA/69W92B2n+uATB7YPOVJXjWOieo+nmlJihEaY447 bxsLfrExy/AwM5wUoqu9JPQmjUGQYxQR0MjIdpzLeWNCGx+NM8n2j+9K00VXxIXX 356rhSNclm5a/1AmkeeDeYK1C8Fw3QIQnaqeTMHDZ/Txv2UncAMshHR2P+9c2i/k N5A+XK0X3+YNHs/0AHbFobRonynw68cogTeSdslMxFtjWV1iTNNR7c8hHHCDXMgJ sjF7hJ7d6RHBRDQn53XgJdR/OKPaj1RJXncP1Be9j6J1M5wepkHJFVS7/66dDl+g 7TyimxnE/y5gxNVk1JWF9ssz31ksGBRbwq1P8IdF3/EsNF3tTB3eqmKM7PB55Oiu k9MWSDo5/fjfdhH24oYUhocJmMN+n2iiBjAh+mWOq1KNPBGtugbztSZPNXuHDHn9 vsAVuuOdK7FvZcbzE0kMqh3gCmp1YBPcXUSnlqLGaowwlykfoYYR0MGz8AdvJreE 5Su2wfiPlI/B2zvVmJ1i2LFr+9nfVFWlmXGAwFmHunpEKTHB9b0HKXVdsJL9qZC2 Gm7SXPMzHEjZ1G420jT8Bx0qfGLC62jTq98QSK6BdcfLd0AsU+rstmQviFZOtSAv qEPrAXPXUraEwMs2/dR+eXR0DWQMEbUWgtmxJM3jHOGnWRseAQc= =xaDL -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifpwACgkQ7ZfpDmKq fjSC+w/9HzW/PbI7gfxfbPkF0fCyHCl2OWWrLlJi1m0G72balJ+BmkhI3vvnBGwK 3OKhvN/HOxA4d11JpXiYmPuQ7iuCDO8nRTDWbtg5nuEdP3FOJqUBD0HKDjTg/UUo haXoFxJwPklPqGOiIsFklEQWgVwpN+LwZkL7b2yjjadL0k5ukx6z/G2lJ5qF2i63 f3Gbe/oG/UYd3ERlDpjvgn2tJWfmoS0S3qU3Y9TpraL3NrmunnbtIFDW7SIEM2oP W4XmtkNgBQGlHS1/x/vocNo31h6KyzqVg6OSyvk88Fzp8vE+gHGOVTLR2RdNh/0H NQDi+Pj65KlIJUsjcLmZo+Huv+eNUfzwBcG+LGwUhay0q+2kaeGTs6epohYFNZen A/0/nzXJBohqcBnbLcBYVf+AZUHuPs5lTkG3OZpdRSvkmw6lELlJbBQMEf/HP/kG l43x9DEe0Dr2oDIEr1mfjszFJqKvSg43QJnTgUJtd0SqITazC1N9XuIZj0uXJ64g zfC1aByJ1FLNJmkMDKbl+OzVg7o53sS2gzL/EaGp43NeOPVa84w5MSWdZnuPz8xa 8KDdcaqWeY+mdLonfq5K/DZhOcV6UanBEXFFrmGZymSSqF2zYPpzPBB/7+B29S5F 68v8ScTY8a3fKjhQqrqzNOOKbVMSwM7m8dZ5o69nIW/knvdmxeg= =eekA -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl/ifp0ACgkQ7ZfpDmKq fjQnxA//ZYROGBW1B1b7EY+j8b8z8oBsrzuN+PHkpmXqXre/rVJfIU7NoRoOoZ27 U3JDYPhQ6jy3fOCkW8Xa/eBwEe9PXfBnlpjAYbQ4d7KUvxzDauNG7Sch/aOKuQqE LIM9B+Gdyojn1dAimKcVh8z+lSH3f+gaL3/kCDAPDCJqxsDpbnzQ5rsgpf7OlkG8 6yBRo4wNsW6D49nEVScCPwtmlMQUBFesV0J49rZ74NL9eArIjjdHgwSSc0RtSTLx VT8yDmV1ZW93W4+ZKwfnyPb/u8w8O5NP42SoWHOdXV40UpyU/jWfioKPhbLr+D1R AU+uPE/GBpIPEd6dL75WNMQWvSPkER+QEcTYdzJIMiqOpwUXEADn5/miH3JiJ1Cx rgkQuukOzmmshL3YiKxWM2WT41NdVZn4MrXx3TfS2gw0Am4zElkRwcNanFc7Ksyl PNoJrypAKPnArG3+P0LSFxq9nQUsaajlYcAqYthRtzTicPA13iXWml/ATh1sw36H rJAEAVBg2TmIHo4/zlEuV7alrnBT0tIz38RtGvGA7lVB0w8ZLrh3BqyezucoK3Zc GsleX8wkJrrWMcdVPnRUCfCosx8IN57349mnL2g5v1B3Ij/ytYy4yDr8H7/vAX2c ddaxW1aluGBzL48ZKKJedDP/vZgRWINXMAyEyqdXW2G33aMsFlw= =IS+h -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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'.

4 14

Daylight saving time in Argentina
by Pol Dec. 24, 2020

Dec. 24, 2020

I have some inconsistencies in the database regarding some time changes in Argentina. I would like to know what is the possibility of corroborating and making these changes. To give just one example, 03-06-1993 Buenos Aires, Argentina would still be GMT -2 (due to the time change from -3 to -2 that took place on 10-18-1992) and the return to -2 occurred just the next day (03-07-1993). Thanks in advance Pol Neiman <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Libre de virus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

2 1

Time zone and UTC
by Jacques Grillet Dec. 24, 2020

Dec. 24, 2020

Hello Do you propose a database to download ordered by UTC with 2 columns If not, where is it possible to have this data UTC | Time zone name Thank you Meilleures salutations, Jacques Grillet M. 079 219 17 78

2 1

tzdata-latest.tar.gz tarball points to tzdata2020d
by Kiran Ravikumar Dec. 23, 2020

Dec. 23, 2020

Hello, Looks like the latest(tzdata-latest.tar.gz) release tar bundle points to tzdata2020d - https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz. Can we get it updated to tzdata2020e? Thanks, Kiran

2 1

Re: [tz] Volgograd is planning to change its time zone back to Moscow on December 20, 2020
by Paul Eggert Dec. 23, 2020

Dec. 23, 2020

On 12/2/20 2:57 PM, wtz wrote: > (State Duma plan to pass the Bill in the second and third reading next week - > around December 9, 2020) Thanks for keeping us up-to-date. After December 9, it'll still need a look-see by the Federation Council and a signing by the president before it's a done deal. Not much time before the time change on December 20. I suppose people will just use "Europe/Moscow" if their tzdb copies aren't updated in time. Your source says "в скандальном вопросе" ("v skandal'nom voprose"), a curious choice of words. The extreme lack of notice is scandalous from my point of view, and perhaps the source is making the same point.

6 9

[PATCH] Improve doc of zic coalescing zone+DST transitions
by Paul Eggert Dec. 22, 2020

Dec. 22, 2020

* zic.8: Improve documentation for how certain transitions are coalesced. Also, use current data for America/Menominee instead an America/Grand_Turk entry that not in current data. Improvements suggested by Tim Parenti. --- zic.8 | 36 +++++++++++++++++++++--------------- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git a/zic.8 b/zic.8 index 2273dad..60262d7 100644 --- a/zic.8 +++ b/zic.8 @@ -590,35 +590,41 @@ first transition into standard time. In a single zone it is an error if two rules take effect at the same instant, or if two zone changes take effect at the same instant. .PP -If a continuation line subtracts from the UT offset after a transition that -would be interpreted to be later if using the continuation line's rules, the +If a continuation line subtracts +.I N +seconds from the UT offset after a transition that would be +interpreted to be later if using the continuation line's UT offset and +rules, the .q "until" -time of the earlier zone or continuation line is interpreted according -to the continuation line's rules. +time of the previous zone or continuation line is interpreted +according to the continuation line's UT offset and rules, and any rule +that would otherwise take effect in the next +.I N +seconds is instead assumed to take effect simultaneously. For example: .br .ne 7 .nf .in +2m -.ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'max\0\0'u +\w'\*-\0\0'u +\w'Mar\0\0'u +\w'Sun>=8\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u +.ta \w'# Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'2006\0\0'u +\w'\*-\0\0'u +\w'Oct\0\0'u +\w'lastSun\0\0'u +\w'2:00\0\0'u +\w'SAVE\0\0'u .sp # Rule NAME FROM TO \*- IN ON AT SAVE LETTER/S -Rule US 2007 max \*- Mar Sun>=8 2:00 1:00 D -Rule US 2007 max \*- Nov Sun>=1 2:00 0 S -.ta \w'Zone\0\0America/Grand_Turk\0\0'u +\w'STDOFF\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u +Rule US 1967 2006 - Oct lastSun 2:00 0 S +Rule US 1967 1973 - Apr lastSun 2:00 1:00 D +.ta \w'Zone\0\0America/Menominee\0\0'u +\w'STDOFF\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u # Zone\0\0NAME STDOFF RULES FORMAT [UNTIL] -Zone\0\0America/Grand_Turk \*-4:00 \*- AST 2018 Mar 11 2:00 - \*-5:00 US E%sT +Zone\0\0America/Menominee \*-5:00 \*- EST 1973 Apr 29 2:00 + \*-6:00 US C%sT .sp .in .fi -Here, an incorrect reading would be there were two clock changes on 2018-03-11, -the first from 02:00 AST (\*-04) to 01:00 EST (\*-05), -and the second an hour later from 02:00 EST (\*-05) to 03:00 EDT (\*-04). +Here, an incorrect reading would be there were two clock changes on 1973-04-29, +the first from 02:00 EST (\*-05) to 01:00 CST (\*-06), +and the second an hour later from 02:00 CST (\*-06) to 03:00 CDT (\*-05). However, .B zic -interprets this more sensibly as a single transition from 02:00 AST (\*-04) to -02:00 EDT (\*-04). +interprets this more sensibly as a single transition from 02:00 CST (\*-05) to +02:00 CDT (\*-05). .PP A link line has the form .sp -- 2.27.0

1 0

Re: [tz] Europe/Volgograd timezone changes in Russia
by Novoselov, Iliya Dec. 22, 2020

Dec. 22, 2020

?Hello, We're writing you on behalf of Russian software developer - Nexign, and all of its clients. Your IANA DB is used in our products as an industrial standart. The reason of this email is that Russian government is about to decide to change the Europe/Volgograd timezone from +4 to +3. This is going to affect our software and our customers, so we would like to know: 1. Are you aware of this changes? 2. Has the patch of IANA DB been planned already? If not, what should be done for that to happen, and how can we help? --------------------------------------------------------------------- Iliya Novoselov Teamlead, "Tariffication" Domain, Saint-Petersburg city Maintenance and Support Department nexign iliya.novoselov(a)nexign-systems.com<mailto:iliya.novoselov@nexign-systems.com> nexign-systems.com ---------------------------------------------------------------------

5 7

Ontario moving to permanent DST? Perhaps someday.
by Tim Parenti Dec. 5, 2020

Dec. 5, 2020

The Legislative Assembly of Ontario has passed a bill which would advance standard time in the province by one hour and repeal the seasonal clock changes — effectively putting the province on year-round daylight saving time. https://globalnews.ca/news/7485079/ontario-daylight-saving-time-amendment-a… According to MPP Jeremy Roberts, who introduced the private member's bill, the legislation would require "coordination" with neighboring jurisdictions such as Quebec and New York state, and "would not come into effect until the Attorney General decides it should come into effect." Indeed, the text of the bill states that the act "comes into force on a day to be named by proclamation of the Lieutenant Governor", who represents the Canadian monarch. The bill passed the assembly unanimously on its third reading and received Royal Assent on 30 November 2020. https://www.ola.org/en/legislative-business/bills/parliament-42/session-1/b… https://www.ola.org/sites/default/files/node-files/bill/document/pdf/2020/2… -- Tim Parenti

1 0

Volgograd is planning to change its time zone back to Moscow on December 20, 2020
by wtz＠worldtimezone.com Dec. 2, 2020

Dec. 2, 2020

The State Duma approved (Nov 24, 2020) the transition of the Volgograd region to the Moscow time zone. According to Draft Federal Law N 1012130-7 "On amendments to article 5 of the Federal law" "On the calculation of time" Nest step is approval by the Federation Council and the President. If approved by the the Federation Council and the President, this Federal Law 1012130-7 will enter into force on December 20, 2020 See reference links below: https://sozd.duma.gov.ru/bill/1012130-7 http://docs.cntd.ru/document/566418247 The State Duma approved the transition of the Volgograd region to the Moscow time zone. https://gorvesti.ru/society/gosduma-progolosovala-za-vozvrat-volgogradskoy-… Volgograd oblast (Volgograd) is going to change its time zone back to Moscow time (from UTC+4 (MSK+1) to UTC+3 (MSK)) on December 20, 2020 https://www.worldtimezone.com/dst_news/dst_news_russia76.html Regards, Alexander Krivenyshev, WorldTimeZone.com

4 4

Some time zone history (1)
by Paul Eggert Dec. 2, 2020

Dec. 2, 2020

> The Determination of the Time Ordinance, 1919 commenced on 1919-11-24. Thanks for catching my typo; proposed patch attached and installed into GitHub. > Also, the Defence (Revocation) (No.4) Regulations, 1945 commenced on 1946-01-06. True, but how would that affect tzdb? As I understand it, those regulations <https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256> repeal DST, but on 1946-01-06 Gold Coast was already on standard time (having switched from DST on 1946-01-01). Hence on 1946-01-06 there was no clock transition, merely a change in which regulation was in force.

2 2

From (ISO3166-1 alpha2 + ISO3166-2) country+region code to timezone?
by Joseph Ernest Nov. 30, 2020

Nov. 30, 2020

Hello, How is it possible to get the timezone for a specific datetime and a (ISO3166-1 alpha2, ISO3166-2) pair, i.e. a country code + region code ? Example: ISO3166 -> TimezoneDE-BE -> Europe/Berlin AU-TAS -> Australia/Hobart or Australia/Tasmania US-NY -> America/NewYork Thank you in advance,Jo PS: I have seen the file "iso3166.tab" but this is only for country codes, i.e. the first part of ISO3166.

3 2

Time zones in conflict areas
by Andriy Ivanchenko Nov. 29, 2020

Nov. 29, 2020

It looks like your base has inadvertently become a hostage to politics. Theoretically, your point of view should coincide with UN resolutions. It says that Russia temporarily occupied Crimea. And this territory is still considered Ukrainian. You can find evidence on the google => “site:undocs.org crimea occupation”. I found the following information in your database: # From Alexander Krivenyshev (2014-03-17): # time change at 2:00 (2am) on March 30, 2014 # https://vz.ru/news/2014/3/17/677464.html # From Paul Eggert (2014-03-30): # 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. 2:00 EU EE%sT 2014 Mar 30 2:00 4:00 - MSK 2014 Oct 26 2:00s 3:00 - MSK The source of your time change data comes from the occupying country. Unreliable source. Can you tell me the reasons for your decision? And don't you plan to correct this mistake? Do you have evidence of the legitimacy of the government that changed the time zone in the conflict area?

10 29

Re: [tz] KyivNotKiev
by Hal Murray Nov. 28, 2020

Nov. 28, 2020

> The major problem is that lazy programmers simply list the tz id's as if > they are all that is available. Adding extra id's will just result in both > being listed and then one gets even more complaints? Would it help if there was a translation file readily available? I'm picturing one for each language or country or whatever. The idea is to distribute them with the tz data so that individual programmers that want to do the right thing and use appropriate names rather than file names in their UI don't have the excuse that the data isn't available. The problem then becomes who decides what goes into the table. I see several options. One is to use some official government source, USGS or State Dept in the US. Another would be to find a trusted volunteer (or team) for each file. How much of the raw data is available online already? Would such a file be easy to maintain if there was a URL pointing to the source. (The idea is to avoid discussions like Kiev/Kyiv.) -- These are my opinions. I hate spam.

2 1

KyivNotKiev
by Andriy Ivanchenko Nov. 27, 2020

Nov. 27, 2020

Hello What do I need to do for you to make such changes? https://en.wikipedia.org/wiki/KyivNotKiev Are such changes possible? Original: Вітаю Що я повинен зробити, щоб ви зробили подібні зміни? https://uk.wikipedia.org/wiki/KyivNotKiev Такі зміни можливі?

22 49

Some time zone history (1)
by P Chan Nov. 25, 2020

Nov. 25, 2020

Australia Legislation related to the DST in 1917 and 1942-1944: Daylight Saving Act 1916 (No. 40 of 1916) [1916-12-21, commenced on 1917-01-01] http://classic.austlii.edu.au/au/legis/cth/num_act/dsa1916401916192/ Daylight Saving Repeal Act 1917 (No. 35 of 1917) [1917-09-25] http://classic.austlii.edu.au/au/legis/cth/num_act/dsra1917351917243/ Statutory Rules 1941, No. 323 [1941-12-24] https://www.legislation.gov.au/Details/C1941L00323 Statutory Rules 1942, No. 392 [1942-09-10] https://www.legislation.gov.au/Details/C1942L00392 Statutory Rules 1943, No. 241 [1943-09-29] https://www.legislation.gov.au/Details/C1943L00241 All transition times should be 02:00 standard time. Tasmania observed DST in 1916-1919. Daylight Saving Act, 1916 (7 Geo V, No 2) [1916-09-22] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsa19167gvn2267/ Daylight Saving Amendment Act, 1917 (8 Geo V, No 5) [1917-10-01] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsaa19178gvn5347/ Daylight Saving Act Repeal Act, 1919 (10 Geo V, No 9) [1919-10-24] http://classic.austlii.edu.au/au/legis/tas/num_act/tdsara191910gvn9339/ King Island is only mentioned in the 1967 Act but not the 1968 Act. Therefore it possibly observed DST from 1968/69. Daylight Saving Act 1967 (No. 33 of 1967) [1967-09-22] http://classic.austlii.edu.au/au/legis/tas/num_act/dsa196733o1967211/ Daylight Saving Act 1968 (No. 42 of 1968) [1968-10-15] http://classic.austlii.edu.au/au/legis/tas/num_act/dsa196842o1968211/ ---------- Bermuda Apart from the current rules, DST was also observed in 1917-1918, 1942-1945, 1947-1952 and 1956. Most of the information can be found online from the Bermuda National Library - Digital Collection which includes The Royal Gazette (RG) until 1957 https://bnl.contentdm.oclc.org/digital/ I will cite the ID. For example, [10000] means https://bnl.contentdm.oclc.org/digital/collection/BermudaNP02/id/10000 1917: Apr 5 midnight to Sep 30 midnight Daylight Saving Act, 1917 (1917 No. 13) [1917-04-02] Bermuda Acts and Resolves 1917, p 37-38 https://books.google.com/books?id=M-lCAQAAMAAJ&pg=PA36-IA2 RG, 1917-04-04, p 6 [42340] gives the spring forward date. 1918: Apr 13 midnight to Sep 15 midnight Daylight Saving Act, 1918 (1918 No. 9) [1918-04-06] Bermuda Acts and Resolves 1917, p 13 https://books.google.com/books?id=K-lCAQAAMAAJ&pg=RA1-PA7 Note that local mean time was still used before 1930. During WWII, DST was introduced by Defence Regulations 1942: Jan 11 02:00 to Oct 18 02:00 [113646], [115726] 1943: Mar 21 02:00 to Oct 31 02:00 [116704], [118193] 1944: Mar 12 02:00 to Nov 5 02:00 [119225], [121593] 1945: Mar 11 02:00 to Nov 4 02:00 [122369], [124461] RG, 1942-01-08, p 2, 1942-10-12, p 2 , 1943-03-06, p 2, 1943-09-03, p 1, 1944-02-29, p 6, 1944-09-20, p 2, 1945-02-13, p 2, 1945-11-03, p 1 In 1946, the House of Assembly rejected DST twice. [128686], [128076] RG, 1946-03-16 p 1,1946-04-13 p 1 1947: third Sunday in May 02:00 to second Sunday in September 02:00 DST in 1947 was defined in the Daylight Saving Act, 1947 (1947: No. 12) which expired at the end of the year. [125784] ,[132405], [144454], [138226] RG, 1947-02-27, p 1, 1947-05-15, p 1, 1947-09-13, p 1, 1947-12-30, p 1 1948-1952: fourth Sunday in May 02:00 to first Sunday in September 02:00 DST in 1948 was defined in the Daylight Saving Act, 1948 (1948 : No. 12) which was set to expired at the end of the year but it was extended until the end of 1952 and was not further extended. [129802], [139403], [146008], [135240], [144330], [139049], [143309], [148271], [149773], [153589], [153802], [155924] RG, 1948-04-13, p 1, 1948-05-22, p 1, 1948-09-04, p 1, 1949-05-21, p1, 1949-09-03, p 1, 1950-05-27 p 1, 1950-09-02, p 1, 1951-05-27, p 1, 1951-09-01, p 1, 1952-05-23, p 1, 1952-09-26, p 1, 1952-12-21, p 8 In 1953-1955, the House of Assembly rejected DST each year. [158996], [162620], [166720] RG, 1953-05-02, p 1, 1954-04-01 p 1, 1955-03-12, p 1 1956: fourth Sunday in May 02:00 to last Sunday in October 02:00 Time Zone (Seasonal Variation) Act, 1956 (1956: No.44) [1956-05-25] Bermuda Public Acts 1956, p 331-332 https://books.google.com/books?id=Xs1AlmD_cEwC&pg=PA63 The extension of the Act was rejected by the House of Assembly. [176218] RG, 1956-12-13, p 1 >From the Chronological Table of Public and Private Acts up to 1985, it seems that there does not exist other Acts related to DST before 1973. https://books.google.com/books?id=r9hMAQAAIAAJ&pg=RA23-PA1 Public Acts of the Legislature of the Islands of Bermuda, Together with Statutory Instruments in Force Thereunder, Vol VII ---------- Gold Coast (Ghana) Interpretation Amendment Ordinance, 1915 (No.24 of 1915) [1915-11-02] Ordinances of the Gold Coast, Ashanti, Northern Territories 1915, p 69-71 https://books.google.com/books?id=ErA-AQAAIAAJ&pg=PA70 This Ordinance added "'Time' shall mean Greenwich Mean Time" to the Interpretation Ordinance, 1876. Determination of the Time Ordinance, 1919 (No. 18 of 1919) [1919-11-24] Ordinances of the Gold Coast, Ashanti, Northern Territories 1919, p 75-76 https://books.google.com/books?id=MbA-AQAAIAAJ&pg=PA75 This Ordinance removed the previous definition of time and introduced DST. Time Determination Ordinance (Cap. 214) The Laws of the Gold Coast (including Togoland Under British Mandate) Vol. II (1937), p 2328 https://books.google.com/books?id=Z7M-AQAAIAAJ&pg=PA2328 Revised edition of the 1919 Ordinance. Time Determination (Amendment) Ordinance, 1940 (No. 9 of 1940) [1940-04-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1940, p 22 https://books.google.com/books?id=1ao-AQAAIAAJ&pg=PA22 This Ordinance changed the forward transition from September to May. Defence (Time Determination Ordinance Amendment) Regulations, 1942 (Regulations No. 6 of 1942) [1942-01-31, commenced on 1942-02-08] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1942, p 48 https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA48 These regulations advanced the time by thirty minutes. Defence (Time Determination Ordinance Amendment (No.2)) Regulations, 1942 (Regulations No. 28 of 1942) [1942-04-25] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1942, p 87 https://books.google.com/books?id=Das-AQAAIAAJ&pg=PA87 These regulations abolished DST and changed the time to GMT+0:30. Defence (Revocation) (No.4) Regulations, 1945 (Regulations No. 45 of 1945) [1945-10-24, commenced on 1946-01-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1945, p 256 https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA256 These regulations revoked the previous two sets of Regulations. Time Determination (Amendment) Ordinance, 1945 (No. 18 of 1945) [1946-01-06] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1945, p 69 https://books.google.com/books?id=9as-AQAAIAAJ&pg=PA69 This Ordinance abolished DST. Time Determination (Amendment) Ordinance, 1950 (No. 26 of 1950) [1950-07-22] Annual Volume of the Laws of the Gold Coast: Containing All Legislation Enacted During Year 1950, p 35 https://books.google.com/books?id=e60-AQAAIAAJ&pg=PA35 This Ordinance restored DST but with thirty minutes offset. Time Determination Ordinance (Cap. 264) The Laws of the Gold Coast, Vol. V (1954), p 380 https://books.google.com/books?id=Mqc-AQAAIAAJ&pg=PA380 Revised edition of the Time Determination Ordinance. Time Determination (Amendment) Ordinance, 1956 (No. 21 of 1956) [1956-08-29] Annual Volume of the Ordinances of the Gold Coast Enacted During the Year 1956, p 83 https://books.google.com/books?id=VLE-AQAAIAAJ&pg=PA83 This Ordinance abolished DST.

2 4

Fwd: [IANA #1173666] Time zone change - Yukon Canada
by Paul Eggert Nov. 25, 2020

Nov. 25, 2020

Thanks, I'm forwarding this to the tz mailing list so that the OIC is archived. -------- Forwarded Message -------- Subject: Re: [tz] [IANA #1173666] Time zone change - Yukon Canada Date: Tue, 24 Nov 2020 14:00:25 -0700 From: Brian Inglis <Brian.Inglis(a)SystematicSw.ab.ca> Reply-To: Brian.Inglis(a)SystematicSw.ab.ca Organization: Systematic Software To: Andrew.Smith(a)gov.yk.ca CC: Paul Eggert <eggert(a)cs.ucla.edu>, Tim Parenti <tim(a)timtimeonline.com> Hi Andrew, Thanks very much for following up on those and getting back to me: I have an interest in these Canadian laws and orders and been digging on Yukon and other sites a number of times. I realize that unfortunately many of these laws and orders are short documents that could easily be missed stuck to others in files, or during scanning, and lost to posterity, or may turn up unexpectedly elsewhere at some later date. I will add this OIC to my personal archive of Canadian and Yukon tz history and pass it along to the tz maintainers who may publish it on the public repositories. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada [PMed to maintainers as received off-list - hope you guys don't mind? Please credit Andrew for any publication.] On 2020-11-24 10:57, Andrew.Smith(a)gov.yk.ca wrote: > Hi Brian - > Following up on this now that the dust has settles in Yukon. > I have attached OIC 1980-02. > My legislative colleagues have let me know that they do not have a copy of CO 1966-20 available in their records (it may be archived deep in the stacks or lost in the intervening half-century). > > Be well. > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > Government of Yukon > T: 867-667-5875 > > Perhaps the Yukon Government representative could also help us fill a couple of holes in Yukon legislative time zone history and comments in: > > http://mm.icann.org/pipermail/tz/2015-April/022200.html > and > > http://mm.icann.org/pipermail/tz/attachments/20150417/4ba8d35e/0001-Better-… > > ✱ CO 1966-20 establishing Yukon (East) Standard Time (like PST) and Yukon (West) Standard Time (like YST) is not available on the Yukon, CanLii, or other sites, although it was revoked by CO 1967-59; from: > > Standard Time and Time Zones in Canada; Thomson, Malcolm M.; JRASC, Vol. 64, pp.129-162; June 1970; SAO/NASA Astrophysics Data System (ADS) http://adsabs.harvard.edu/abs/1970JRASC..64..129T p.156: > > "Yukon Territory Commissioner's Order 1967-59 Interpretation Ordinance > > The Commissioner of the Yukon Territory, pursuant to the Interpretation Ordinance, is pleased to and doth hereby order as follows: > > 1. Commissioner's Order 1966-20 dated at Whitehorse in the Yukon Territory on 27th January, 1966, is hereby revoked." > > ✱ OIC 1980/02 establishing Yukon DST is not available on the Yukon, CanLii, or other sites, although it was revoked by OIC 1987/56; from: > > Yukon Daylight Saving Time, YOIC 1987/56 http://www.canlii.org/en/yk/laws/regu/yoic-1987-56/latest/yoic-1987-56.html > > "O.I.C. 1987/056 INTERPRETATION ACT > > INTERPRETATION ACT > Pursuant to section 36 of the Interpretation Act, the Commissioner in Executive Council orders as follows: > > 1. In every year between > (a) two o'clock in the morning in the first Sunday in April, and > (b) two o'clock in the morning in the last Sunday in October, Standard Time shall be reckoned as seven hours behind Greenwich Time and called Yukon Daylight Saving Time. > > 2. Order-In-Council 1980/02 is hereby revoked."

1 1

What's "right"?
by Paul Gilmartin Nov. 17, 2020

Nov. 17, 2020

Hello, TZ, In: ftp://ftp.iana.org/tz/tz-link.html I read: The tz code and data support leap seconds via an optional "right" configuration, ... Empirically, this seems to assume time_t of TAI-10. This isn't GPS, which I understand to be TAI-19: http://www.bipm.org/utils/en/pdf/time_ann_rep/Time_annual_report_2015/25_ut… TAI-10 is (accidentally?) the epoch of the IBM z/OS TOD clock. I find a couple references to "zoneinfo/right" in Makefile and NEWS. Is there more complete documentation of "right" and its rationale elsewhere? Thanks, gil

12 56

TIme in Belize
by P Chan Nov. 13, 2020

Nov. 13, 2020

Below are some laws related to the time in British Honduras/Belize: Definition of Time Ordinance, 1927 (No.4 of 1927) [1927-04-01] Ordinances of British Honduras Passed in the Year 1927, p 19-20 https://books.google.com/books?id=LqEpAQAAMAAJ&pg=RA3-PA19 Definition of Time (Amendment) Ordinance, 1942 (No. 5 of 1942) [1942-06-27] Ordinances of British Honduras Passed in the Year 1942, p 31-32 https://books.google.com/books?id=h6MpAQAAMAAJ&pg=RA6-PA95-IA44 Definition of Time Ordinance, 1945 (No. 19 of 1945) [1945-12-15] Ordinances of British Honduras Passed in the Year 1945, p 49-50 https://books.google.com/books?id=xaMpAQAAMAAJ&pg=RA2-PP1 Definition of Time Ordinance, 1947 (No. 1 of 1947) [1947-03-11] Ordinances of British Honduras Passed in the Year 1947, p 1-2 https://books.google.com/books?id=xaMpAQAAMAAJ&pg=RA3-PA1 Time (Definition of) Ordinance (Chapter 180) The Laws of British Honduras in Force on the 15th Day of September, 1958 , Volume IV, p 2580 https://books.google.com/books?id=v5QpAQAAMAAJ&pg=PA2580 Time (Definition of) (Amendment) Ordinance, 1968 (No. 13 of 1968) [1968-08-03] https://books.google.com/books?id=xij7KEB_58wC&pg=RA1-PA428-IA9 Definition of Time Act (Chapter 339) Law of Belize, Revised Edition 2000 http://www.belizelaw.org/web/lawadmin/PDF%20files/cap339.pdf

5 14

Yukon time - Google contact?
by Andrew.Smith＠gov.yk.ca Nov. 2, 2020

Nov. 2, 2020

Hi all. Is there anyone from Google on the list, or has a Google contact for time? I tried getting in touch with their Canada offices earlier, but they didn't get back to me. Yukon is on our new time now, but some Google services are showing us incorrectly on Pacific Standard Time. Google Home and Chrome specifically are showing that, Android is displaying correctly. Thanks. Hope this is the biggest hiccup we see up here. [cid:image001.png@01D6B07D.A5900CD0] Andrew G. Smith Intergovernmental Relations Executive Council Office T 867-667-5875 | C 867-335-6008 | Yukon.ca

1 1

[PROPOSED] Port 'make rearguard_tarballs' to Solaris 10
by Paul Eggert Oct. 27, 2020

Oct. 27, 2020

* Makefile (tarballs, etc.): Export AWK to submake, for Solaris 10 which needs something like 'make AWK=nawk rearguard_tarballs'. (.KEEP_STATE): Remove. .KEEP_STATE is a Solaris 'make' feature that breaks 'make rearguard_tarballs' because it causes submakes to mistakenly consider files to be out-of-date. As .KEEP_STATE is not specified by POSIX and is ignored by GNU 'make' it should not be needed. --- Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Makefile b/Makefile index a0b6aeb..5064a19 100644 --- a/Makefile +++ b/Makefile @@ -1012,7 +1012,7 @@ tarballs rearguard_tarballs traditional_tarballs \ signatures rearguard_signatures traditional_signatures: \ version set-timestamps.out rearguard.zi VERSION=`cat version` && \ - $(MAKE) VERSION="$$VERSION" $@_version + $(MAKE) AWK='$(AWK)' VERSION="$$VERSION" $@_version # These *_version rules are intended for use if VERSION is set by some # other means. Ordinarily these rules are used only by the above @@ -1110,8 +1110,6 @@ strftime.o: private.h tzfile.h zdump.o: version.h zic.o: private.h tzfile.h version.h -.KEEP_STATE: - .PHONY: ALL INSTALL all .PHONY: check check_time_t_alternatives .PHONY: check_web check_zishrink -- 2.25.1

1 0

Israel DST
by P Chan Oct. 27, 2020

Oct. 27, 2020

Here is a full list of the orders related to the DST in Mandatory Palestine/Israel in 1940-2004.

4 5

Yukon and the zone.tab file
by Chris Walton Oct. 27, 2020

Oct. 27, 2020

The two Yukon entries in the zone.tab file still have descriptions with the name "Pacific": CA +6043-13503 America/Whitehorse *Pacific* - Yukon (east) CA +6404-13925 America/Dawson *Pacific* - Yukon (west) Please consider changing the descriptions to something like this: CA +6043-13503 America/Whitehorse *MST* - Yukon (east) CA +6404-13925 America/Dawson *MST* - Yukon (west) Thank you. -chris

2 1

State of Palestine Time zone - need to update
by heba.hamad＠mtit.gov.ps Oct. 26, 2020

Oct. 26, 2020

,Dear Sir.I’m Heba Hamad .I have been appointed as a focal point by the Ministry of telecommunication and information technology (state of Palestine) to communicate with you I’m contacting you in regard to the time zone data base the field related to the state of Palestine. I checked the published data regarding the time zones related to Palestine and noticed that it’s not accurate, and hence I would like to ask for an update to the time zone data base related to Palestine to be as follow PS State of Palestine Asia/AlQuds UTC +2:00 :Instead of the following data PS State of Palestine Asia/Gaza UTC +2:00 PS State of Palestine Asia/Hebron UTC +2:00 .Kindly advise if any documents, information or procedures are needed from our side ,Best Regards

3 2

My public key via GitHub and WKD for verifying tzdb distributions
by Paul Eggert Oct. 25, 2020

Oct. 25, 2020

Recently users have had trouble verifying tzdb releases because they could not obtain the GPG public key that I use to sign the releases. These problems stem from the denial-of-service attacks on public keyservers last year, combined with my extending the expiration of my longstanding public key, which had been due to expire in August. The expiration-date extension had problems propagating to public keyservers that use the traditional method of key distribution. To try to help ameliorate this problem I recently did two things. First, I uploaded my public key to the development repository on GitHub. You can now use <https://github.com/eggert/tz/tags> to verify every tzdb release starting with 2012e. (Older releases are not tagged, as discussed in the 2013f NEWS entry.) Second, at my suggestion the UCLA Computer Science Department has added WKD support to cs.ucla.edu, and you can now verify my key independently via WKD. See an example below for how to do this. In the longer term, the IANA have been working on a way to have IANA authorities sign distributions, and eventually we hope to have something implemented along those lines. Thanks to Phil Pennock for his suggestions and help in improving the process of verifying tzdb distributions. PS. For more about last year's denial-of-service attacks and the use of WKD instead of traditional public keyservers, please see: Osborne C. PGP SKS key network poisoned by unknown hackers. ZDNet. 2019-07-04. https://www.zdnet.com/article/openpgp-flooded-with-spam-by-unknown-hackers/ Koch W. OpenPGP Web Key Directory. Active Internet-Draft. 2020-05-26. https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/ What is a Web Key Directory? GnuPG e.V. 2020-07-06. https://wiki.gnupg.org/WKD PPS. Here is one way to verify a key via WKD, using the 'gpg' shell command. You'll need a recent-enough GnuPG: version 2.1.23 (2017-08-23) or later should suffice. $ gpg --auto-key-locate wkd --locate-keys eggert(a)cs.ucla.edu gpg: key ED97E90E62AA7E34: public key "Paul Eggert <eggert(a)cs.ucla.edu>" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: no ultimately trusted keys found pub rsa4096 2010-09-03 [SC] [expires: 2021-08-31] 7E3792A9D8ACF7D633BC1588ED97E90E62AA7E34 uid [ unknown] Paul Eggert <eggert(a)cs.ucla.edu> sub rsa4096 2010-09-03 [E] [expires: 2021-08-31]

1 0

Re: [tz] tz leap-seconds.list
by Paul Eggert Oct. 25, 2020

Oct. 25, 2020

On 10/25/20 10:45 AM, Kristin Minchev wrote: > The [leap-seconds.list] file itself doesn't have any license information > (nor NIST's). Under current US law a file that contains no license information normally defaults to being copyrighted with no license granted. The NIST is an arm of the US government, though, so under US law its publications are public domain so we don't have to worry about redistributing the NIST file even though it contains no license info. I just now searched for the top ten "leap-seconds.list" hits on Google. The #1, #3, #4, #6, #7 and #9 hits were about the NIST file, and of these all but #9 were about the tzdb copy of the NIST file (#9 was unclear). The #5 and #10 hits were about the IERS file. (#2 and #8 were false matches.) So even though the IERS file is published by the primary source for leap seconds, licensing issues have prevented the IERS file from being the most popular in practice. We've attempted to contact the IERS multiple times to get its file's license clarified, but haven't made much progress. > And most of the data comes from IERS anyway. That's fine: under US law, data cannot be copyrighted. There was a court case about this; see <https://www.eff.org/press/releases/eff-wins-protection-time-zone-database>. I installed the attached patch to the tzdb development repository to try to explain this all a bit better, without getting too long-winded about it.

1 0

Time in Kenya
by P Chan Oct. 24, 2020

Oct. 24, 2020

The standard time of GMT+2:30 was adopted in the East Africa Protectorate on 1 May 1908. https://books.google.com/books?id=e-cAC-sjPSEC&pg=PA274 At midnight on 30 June 1928 the clocks throughout Kenya was put forward half an hour by the Alteration of Time Ordinance, 1928. https://gazettes.africa/archive/ke/1928/ke-government-gazette-dated-1928-05… https://books.google.com/books?id=2S0S6os32ZUC&pg=PA813 The 1928 ordinance was repeal by the Alteration of Time (repeal) Ordinance, 1929 and the time was restored to GMT+2:30 at midnight on 4 January 1930. https://books.google.com/books?id=_g18jIZQlwwC&pg=PA2701 The Alteration of Time Ordinance, 1936 changed the time to GMT+2:45 and repealed the previous ordinance at midnight on 31 December 1936 . https://books.google.com/books?id=K7j41z0aC5wC&pg=PA705 The Defence (Amendment of Laws No. 120) Regulations changed the time to GMT+3 at midnight on 31 July 1942. https://books.google.com/books?hl=zh-TW&id=c_E-AQAAIAAJ&pg=PA331 The provision of the 1936 ordinance was not repealed and was later incorporated in the Interpretation and General Clauses Ordinance in 1948. Although it was overridden by the 1942 regulations. https://dds.crl.edu/item/217517 (p.101) In 1950, the Interpretation and General Clauses Ordinance was amended to adopt GMT+3 permanently as the 1942 regulations were due to expire on 10 December. https://books.google.com/books?id=jvR8mUDAwR0C&pg=PA787 https://books.google.com/books?id=-_dQAQAAMAAJ&pg=PA294

3 2

make rearguard_tarballs fails creates tzdataunknown-rearguard.tar.gz file with latest tzdata lzip
by Carlos Jimenez Oct. 22, 2020

Oct. 22, 2020

Hello, I've encountered two issues with the two latest files for the tz changes: https://data.iana.org/time-zones/releases/tzdb-2020c.tar.lz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz 1) The touch command for the new pacificnew empty file won't work on centos6 or centos7. The date format syntax is generating an error: I noticed this was already fixed here: https://github.com/eggert/tz/commit/ce89cbaa436f336dca4b239fa528405abd7d84b… How long before that makes it to the /tzdb-2020c.tar.lz file? 2) Upon manually fixing the touch issue by replacing the touch command with the fixed version, I am now getting the wrong filenames for the rearguard file and tzcode and tzdata: Steps: [root@centos7 tzdb-2020c]# lzip -d tzdb-latest.tar.lz [root@centos7 tzdb-2020c]# mkdir tzdata-latest && tar xf tzdb-latest.tar -C tzdata-latest [root@centos7 tzdb-2020c]# pwd /home/tzdata/tzdata-2020c/tzdb-2020c [root@centos7 tzdb-2020c]# make rearguard_tarballs I get the following file as a result $tzdataunknown-rearguard.tar.gz I have reproduced this on centos6, centos7 and Mac OS 10.15.6. I get the following errors as well when I execute it: [root@centos6 tzdb-2020c]# make rearguard_tarballs >> ../../makeoutput.txt fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git fatal: Not a git repository (or any of the parent directories): .git Attached is the make output. This impacts us directly since we have customers in Fiji. I'm trying to reverse engineer and review what may be going wrong but any help would be great. -Carlos

2 2

Support for Etc/GMT -style zones ids with partial hours
by Neil Fuller Oct. 22, 2020

Oct. 22, 2020

Would there be any support in this community for adding new Etc/GMT[-+] zone identifiers but with partial hours? e.g. something like "Etc/GMT-5:30" These might introduce some technical challenges, but I can see a use which I will explain below. I haven't yet investigated the impact on Android (where I deal with much of the time zone work), but I thought I'd ask for thoughts before expending any effort prototyping. Thanks, Neil. ------------------ Motivating case: Taking Android as an example, the platform uses TZDB zone identifiers as the basis for most time zone support. Directly, via a tzif-based file (used for libc mktime/localtime / Android's custom implementation of java.util.TimeZone), and indirectly via ICU4C and ICU4J. In situations like we had this week with Palestine, i.e. less than one week's notice before a DST transition change, the usual advice for users affected is "Please manually select an alternative time zone that has the offset you need until you receive a software update". e.g. Microsoft Windows appears to do the same [1] Side note: There are related cases for devices that have fallen out of their OEM's support window and will never receive a TZDB update again. The utility of these devices can degrade over time as their version of TZDB slowly drifts from the user's reality. Users continuing to use these devices may no longer be able to use the identifier for their actual location and get the behavior they need. Instead, they have to select an alternative zone ID that has the offset they need. If they're not lucky, they may be forced to pick an alternative zone ID which has its own DST schedule which might not match their requirements for the full year. The Stock Android settings UI, starting with Android Pie (9.0), allows users to select from the fixed "Etc/GMT-5" style identifiers from TZDB in addition to the more regular "Europe/London"-style zone identifiers associated with geographical regions. The original use case for this was to allow pilots to select Etc/UTC, and we added support for selecting all the other fixed Etc/GMT[+-] zones at the same time. The current Etc/GMT[+-] zone identifiers in TZDB only cover whole hour offsets. There are various places that use 30 minute offsets, and a few that use 45/15 minute offsets [2]. For the cases where devices cannot receive rules updates (in time, or at all), it would be useful to have the full range of 30-minute fixed-offset possibilities for users to select from instead. I'm choosing to ignore the 15/45 minute ones right now as they appear much less common / useful. Because most of our infrastructure treats TZDB as "ground truth" it would be beneficial to get this support in TZDB rather than carrying local patches to each library. [1] https://techcommunity.microsoft.com/t5/daylight-saving-time-time-zone/inter… - this example is for Fiji / 2020b [2] https://www.timeanddate.com/time/time-zones-interesting.html - zones with offsets other than integer hours -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

3 6

[PATCH] Port to downstream HP-UX-style ‘make’
by Paul Eggert Oct. 22, 2020

Oct. 22, 2020

HP-UX ‘make’ considers a target to be out-of-date if its timestamp equals that of a dependency, and POSIX allows this ‘make’ behavior. So, when putting timestamps on files in tarballs, add 1 to a file’s timestamp if it depends on some other file with the same timestamp. That way, when someone unpackages a tarball on an HP-UX host, its ‘make’ will avoid rebuilding files like ‘version’ that are up-to-date in the tarball. * Makefile (SET_TIMESTAMP_N, SET_TIMESTAMP, SET_TIMESTAMP_DEP): New macros. (set-timestamps.out, set-tzs-timestamp.out) (tzdata$(VERSION)-rearguard.tar.gz, tzdb-$(VERSION).tar.lz): Use them instead of invoking ‘touch’ by hand. (set-timestamps.out): Set the timestamp of tzdata.zi after that of version, since the former depends on the latter. --- Makefile | 43 +++++++++++++++++++++++++++++++++---------- 1 file changed, 33 insertions(+), 10 deletions(-) diff --git a/Makefile b/Makefile index 40b81d1..3b9d59e 100644 --- a/Makefile +++ b/Makefile @@ -872,11 +872,34 @@ $(MANTXTS): workman.sh LC_ALL=C sh workman.sh `expr $@ : '$.*$\.txt$$'` >$@.out mv $@.out $@ +# Set file timestamps deterministically if possible, +# so that tarballs containing the timestamps are reproducible. +# +# '$(SET_TIMESTAMP_N) N DEST A B C ...' sets the timestamp of the +# file DEST to the maximum of the timestamps of the files A B C ..., +# plus N if GNU ls and touch are available. +SET_TIMESTAMP_N = sh -c '\ + n=$$0 dest=$$1; shift; \ + touch -cmr `ls -t "$$@" | sed 1q` "$$dest" && \ + if test $$n != 0 && \ + lsout=`ls -n --time-style="+%s" "$$dest" 2>/dev/null`; then \ + set x $$lsout && \ + touch -cmd @`expr $$7 + $$n` "$$dest"; \ + else :; fi' +# If DEST depends on A B C ... in this Makefile, callers should use +# $(SET_TIMESTAMP_DEP) DEST A B C ..., for the benefit of any +# downstream 'make' that considers equal timestamps to be out of date. +# POSIX allows this 'make' behavior, and HP-UX 'make' does it. +# If all that matters is that the timestamp be reproducible +# and plausible, use $(SET_TIMESTAMP). +SET_TIMESTAMP = $(SET_TIMESTAMP_N) 0 +SET_TIMESTAMP_DEP = $(SET_TIMESTAMP_N) 1 + # Set the timestamps to those of the git repository, if available, # and if the files have not changed since then. -# This uses GNU 'touch' syntax 'touch -d@N FILE', -# where N is the number of seconds since 1970. -# If git or GNU 'touch' is absent, don't bother to sync with git timestamps. +# This uses GNU 'ls --time-style=+%s', which outputs the seconds count, +# and GNU 'touch -d@N FILE', where N is the number of seconds since 1970. +# If git or GNU is absent, don't bother to sync with git timestamps. # Also, set the timestamp of each prebuilt file like 'leapseconds' # to be the maximum of the files it depends on. set-timestamps.out: $(EIGHT_YARDS) @@ -894,16 +917,16 @@ set-timestamps.out: $(EIGHT_YARDS) fi || exit; \ done; \ fi - touch -cmr `ls -t $(LEAP_DEPS) | sed 1q` leapseconds + $(SET_TIMESTAMP_DEP) leapseconds $(LEAP_DEPS) for file in `ls $(MANTXTS) | sed 's/\.txt$$//'`; do \ - touch -cmr `ls -t $$file workman.sh | sed 1q` $$file.txt || \ + $(SET_TIMESTAMP_DEP) $$file.txt $$file workman.sh || \ exit; \ done - touch -cmr `ls -t $(TZDATA_ZI_DEPS) | sed 1q` tzdata.zi - touch -cmr `ls -t $(VERSION_DEPS) | sed 1q` version + $(SET_TIMESTAMP_DEP) version $(VERSION_DEPS) + $(SET_TIMESTAMP_DEP) tzdata.zi $(TZDATA_ZI_DEPS) touch $@ set-tzs-timestamp.out: $(TZS) - touch -cmr `ls -t $(TZS_DEPS) | sed 1q` $(TZS) + $(SET_TIMESTAMP_DEP) $(TZS) $(TZS_DEPS) touch $@ # The zics below ensure that each data file can stand on its own. @@ -1018,7 +1041,7 @@ tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out for f in $(TDATA) $(PACKRATDATA); do \ rearf=tzdata$(VERSION)-rearguard.dir/$$f; \ $(AWK) -v DATAFORM=rearguard -f ziguard.awk $$f >$$rearf && \ - touch -cmr `ls -t ziguard.awk $$f` $$rearf || exit; \ + $(SET_TIMESTAMP_DEP) $$rearf ziguard.awk $$f || exit; \ done sed '1s/$$/-rearguard/' \ <version >tzdata$(VERSION)-rearguard.dir/version @@ -1037,7 +1060,7 @@ tzdb-$(VERSION).tar.lz: set-timestamps.out set-tzs-timestamp.out rm -fr tzdb-$(VERSION) mkdir tzdb-$(VERSION) ln $(ENCHILADA) tzdb-$(VERSION) - touch -cmr `ls -t tzdb-$(VERSION)/* | sed 1q` tzdb-$(VERSION) + $(SET_TIMESTAMP) tzdb-$(VERSION) tzdb-$(VERSION)/* LC_ALL=C && export LC_ALL && \ tar $(TARFLAGS) -cf - tzdb-$(VERSION) | lzip -9 >$@.out mv $@.out $@ -- 2.25.1

1 0

Pacific/Norfolk Island DST
by Victor Cawit Oct. 22, 2020

Oct. 22, 2020

Hi there! I would like to please request for a timezone change on our island please? If you need a reference for this change, please see below link for the legal formal application of DST in Norfolk Island Each year, from the first Sunday in October, clocks on Norfolk Island will need to be moved forward one hour and then back one hour on the first Sunday in April. In 2019, DST will begin at 2am on Sunday 6 October and end at 2am on Sunday 5 April 2020..... http://www.norfolkonlinenews.com/norfolk-island-free-news/introduction-to-d… Thank you very much! Your effort on making this happen is very much appreciated. If you need any more information regarding the matter above, please don't hesitate to contact me. Have a good day! Regards, [cid:image003.jpg@01D69E2D.1FA78EC0] Victor Michael Cawit | Senior Technical Officer - International Communications Norfolk Telecom Norfolk Island Regional Council PO Box 95, Norfolk Island 2899 | 9 New Cascade Road, Norfolk Island T (+6723) 22244 (ext. 115) www.norfolkisland.gov.nf<http://www.norfolkisland.gov.nf/> Integrity | Communication | Accountability | Respect | Excellence IMPORTANT NOTICE REGARDING CONTENT The views expressed in this e-mail are not necessarily those of the Norfolk Island Regional Council unless otherwise stated. The Norfolk Island Regional Council does not warrant that this message is free from viruses or any other defect or error. IMPORTANT NOTICE REGARDING CONFIDENTIALITY This electronic message is intended only for the addressee and may contain confidential information. If you are not the addressee, any transmission, distribution or photocopying of this e-mail is strictly prohibited. The confidentiality attached to this e-mail is not waived, lost or destroyed by reasons of a mistaken delivery to you. The information contained in this e-mail transmission may also be subject to Freedom of Information legislation. If you have received this e-mail in error, please contact the author of the message, as soon as practicable. Please consider the environment before printing.

3 3

[tz-announce] 2020d release of tz code and data available
by Paul Eggert Oct. 21, 2020

Oct. 21, 2020

The 2020d 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 ends DST earlier than predicted, on 2020-10-24. Changes to past and future timestamps Palestine ends DST on 2020-10-24 at 01:00, instead of 2020-10-31 as previously predicted (thanks to Sharef Mustafa.) Its 2019-10-26 fall-back was at 00:00, not 01:00 (thanks to Steffen Thorsen.) Its 2015-10-23 transition was at 01:00 not 00:00, and its spring 2020 transition was on March 28 at 00:00, not March 27 (thanks to Pierre Cashon.) This affects Asia/Gaza and Asia/Hebron. Assume future spring and fall transitions will be on the Saturday preceding the last Sunday of March and October, respectively. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020d.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 ab21ad9710b88f28995b7ed47c6efda47ffb1be5 dated 2020-10-21 11:24:13 -0700 and tagged '2020d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 315ce86574780d89482761298137b2871a21cb4391886abdc9f29c6cc09e8b8f6585f96d3f4dfef8d7b54e24720214f5c77144114ad58cc91aa5bbde350c0f9b tzcode2020d.tar.gz 362e4569a666b0776614be3f63f1fe3d5ae259055e7051c9875f36023db9c52b0c5a10c19067114443a4cf2bf92475f8a0aebdf79bac836d967527fcdea4e9b6 tzdata2020d.tar.gz d7e74331d10d17a855363fbae16d55dbf422c1bc3ac4aff56c897d78cea185f16a9342927e292923198bb8a2f4230ca1eb3d23960b44f5c71db153cf83ed3f7c tzdb-2020d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYEACgkQ7ZfpDmKq fjQONxAAsutVmD1mKngEto0UotZPTOM74RbV11sim+D9PGg04JbQIDUhclmW3Zw7 CAp0QTu0MBs78lA2qugIyv5ma/61LanOA9pcBdjlJ5DA485wAvMCW9deUfK50pTA nzYri3uZ2IwISao4hBWUP7IGQ0fSpbfSiSoxTMcYbNRVWCnDJhfC97SsegMPSN5q 4lPit82uCLIa6s4vk/SuHPFO21TJY5e7DouUG7vkdJRJIX8GUNUMV47IO8cQQUD6 O4Zvsd6ha49iRDJy6mDkIrMpK3r0yC58kZaMXzV++XZA+G4D7sYZbkKnukTGMky/ bB0v2oTIB5BulkM1u1b5/hR0aZ8WlFk6WEDVP6jG+Vvb5rZW4nkOoFI2JjI2vFhZ p0PgzThn8sqUQn2lGbsYA8w7DujKW7nZ5ENFbHhWDm4GHYCRQSTTFU7tHGQbkzqg XFgvYbdPW2er/vpbw5QXSUa3UwdssiXuGUvLMka0aYKPPe5ahAkyE+jDEwoN3K9h e561luc13HwmjOwVxmya4IAomAb+IM4Pt821aKOzELD0epBdk7YmlD0kcqh4LeqR lxawXbLlGQHBAv4DBC58eQNGcP3DaC7fCPhG+cfL9jT1Ygbm8Ncg9ndWZVn5RS1X 7WCqkX9tSFN6CJkd2ozVzoJWjE8NdotdFI05e5Az2zaNmnV6iSk= =/2fr -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYEACgkQ7ZfpDmKq fjR5wxAAjzC37QyQyyLS3GePbM3GAY0kDf40ieCHU9LBEBqTDXFbC8WaMCc+3jQ+ +iaFJbjK6iJeaZLr+y9ea+W47fKmBd0ogW6mR11HiJdmGKncPze1O9aae/thT2UJ KG3FIZYE5hERkyeNMHjwUJqVKcrg5VaE0iuUOlGrwpnNwPQl80zyRWhi0RbMomHR XD7jvMwpTy+x7lEWXA7WLUcxHwY3ezdMjPOwX+9EAVMMNCNEgRSaeBFIo9z3YUnc ppMnQ537TqfvmdvslDc+c6AXI2PqwHBQSluWMNUJHnC8KXdwFB+G2LJRdov7WqdU +dnUKZsGwMxPHqgbNpINf4q48tIg6xEDVXH12973EV1Rh4Tao0g4l18WpFOCXqeI /vNETZHkcqNkhpMb5XI289LU3Mc889RjEjwhpKJv0RN+bw5sRvgftY8j/Vp1Jty0 gHpCA3M1YRglq0SBpfsWpXJsz3T1EcRdT5XToTpG321OsRoymjZ7txqF5siAiWBo P7zGgBe+0mIZ3bSDI/o1a/yuL0jwjTru2SbC6B9maOZXw2iPzEB6j8grFLmsUj7u e/s5jaqYrPTD8PsvBO1r20sP2HwQHhvew+TemVhSuW0yfqifffx0ybwZrw6oF0Ig SEPdSJkwsiOu7U/cKIFuClsZUaiOjjWu9SMWKUNm6AHXpO8CuCk= =48vS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+QfYMACgkQ7ZfpDmKq fjSyeg//b9pfaBM+EFrf87F1UmgTeSF+s9mtWjuD65z+6QBSr4tHH0sFD00KbYrS F3kaJTvzvxiDlMs/aTSWi7PsXWns9FRa5GKylkkAhTihbkXBAQny7l3em+emZy5t 6PY0MowcLXf3/HoyxMgkXBPxm+U0d9Bv7+yRmvX1WsmyKcbHhn41nw+HUFJNwOW3 mP4RnirQTghvvGJ0eEiWeXtdqzsLyw661SFWZZ/odCpTCYCwSU28boDJmsCMyPcR CM1QcUvPs1YPXWXYYh6f1tl6RGx8sG+4KLFGNwj6Gr5SkUu2tEddMVfJqmRwQNuQ crz0q/R4wuDRnpK4aJMrrW2Vakm6s8CAett1PivMAcH1Rjhceo0JvRUvOUKSyaFc cPZys8qHX/7LfN5SW3Gb12vPBMKrBF8FWGQionD8Ym9p8motCWU8/yoqZBCOjswJ RZiI8yserCWUpauJgLrXQri6DrpGXGyTVIT7kK6zKwnqnrreogkE7K5gQL93qXnw K6EX7UMS/bXfJu8NDwvS/6KcDSnBcCWCpOqe6bynKkgqKlgkF58lStchQN1YDbF1 MXjl6Feq55yAD+YcOb8ZEXZgPbmAo3RChKKLW3SU0Lq3VbjqNZlujvh9ZsaJNMv+ AtsfxLPRxtIeoWKkFR2mRvbqYWPMCrEUvp1pPpFsoFS4pGZPjJ4= =yRLG -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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

Palestine to end summer time on Oct 24th
by Pierre Cashon Oct. 21, 2020

Oct. 21, 2020

The summer time this year started on March 28 at 00:00. https://wafa.ps/ar_page.aspx?id=GveQNZa872839351758aGveQNZ http://www.palestinecabinet.gov.ps/portal/meeting/details/50284 The winter time in 2015 started on October 23 at 01:00. [https://wafa.ps/ar_page.aspx?id=CgpCdYa670694628582aCgpCdY](https://www.waf… http://www.palestinecabinet.gov.ps/portal/meeting/details/27583

2 1

Re: [tz] from tzdata2020a to tzdata2020b: iana, tzupdater, or local issue?
by Paul Eggert Oct. 20, 2020

Oct. 20, 2020

On 10/13/20 2:07 AM, gerar.moisset(a)orange.com wrote: > I'd like to know why we are obliged to patch tzdata2020b-rearguard.tar.gz? It's because TZUpdater uses tzdb internals that are not documented under "Interface stability" <https://data.iana.org/time-zones/theory.html#stability>, and when these internal details are changed, TZUpdater sometimes fails. > For us impact is it breaks automatic tz update. > Does it mean we need to leave this kind of tz update? As noted in <https://mm.icann.org/pipermail/tz/2020-October/029340.html> there will be a workaround in the next tzdb release, which should be reasonably soon, so one option is to wait until tzdb 2020c comes out and try its rearguard tarball. That being said, there's little coordination between the maintainers of tzdb and of TZUpdater, and as far as I know nobody has tested this specific workaround code. (You might be the first one to try it when 2020c comes out. :-) > Does it come from iana src content ? > If not we are not obliged to reply, but I’d like to understand, > does it come from tzupdater, or kind of jdk, or jdk version? It's an incompatibility between tzdb (as published by IANA) and TZUpdater (maintained by Oracle). > tzupdater-2.2.0, TZUpdater 2.3.1 is out, and you might want to update to it for other reasons. However, I expect that it has the same problem here that 2.2.0 does. > openjdk version "1.8.0_191" > OpenJDK Runtime Environment (build 1.8.0_191-b12) > OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode) > > Here is the workaround: > ... > gzip -d tzdata2020b-rearguard.tar.gz > touch pacificnew #empty file > tar -rfv tzdata2020b-rearguard.tar pacificnew > gzip -v tzdata2020b-rearguard.tar Yes, that should work for 2020b. It shouldn't be needed for 2020c and later. > ${JAVA_HOME_OPV}/bin/java -jar ${TZ_UPDATER_JAR} -u -f -l file:///${TZ_DATA_NFS} > $JAVA_HOME_OPV/bin/java -jar ${TZ_UPDATER_JAR} -V|head -2|tail -1|awk -F":" '{print $2}'|awk -F"-" '{print $1}' > > It returns expected result: tzdata2020b This is a strong indication that the workaround should indeed work once 2020c comes out.

2 2

[tz-announce] 2020c release of tz code and data available
by Paul Eggert Oct. 20, 2020

Oct. 20, 2020

The 2020c 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 starts DST later than usual, on 2020-12-20. Changes to future timestamps Fiji will start DST on 2020-12-20, instead of 2020-11-08 as previously predicted. DST will still end on 2021-01-17. (Thanks to Raymond Kumar and Alan Mintz.) Assume for now that the later-than-usual start date is a one-time departure from the recent pattern. Changes to build procedure Rearguard tarballs now contain an empty file pacificnew. Some older downstream software expects this file to exist. (Problem reported by Mike Cullinan.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020c.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020c.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 ab21ad9710b88f28995b7ed47c6efda47ffb1be5 dated 2020-10-16 11:15:53 -0700 and tagged '2020c' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: c77fa69d2a005ba7cff602b2267983fd01613f81385bc13c90b9581d69fb0ac73491641cac81e0e5d7dd00ed120c45103859902c2d10da9d25c98b33354f88f7 tzcode2020c.tar.gz bbd66fe236ba0949261cb238bfed454c03b4500b239dc38f1b8fef8d229136f5964c1a8386fe54484e4e5e34a3c28a7b66ee7374ff7e0dd07865d78fc53bf96c tzdata2020c.tar.gz 2b436868e33d9de284a97ec75990995c9ffd8b3086b5d93613b119762492df3d4be79d3e910ba1bbacb005f44d36dca31b72f9d314bafcc23b790628c3dc47ec tzdb-2020c.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IYACgkQ7ZfpDmKq fjT9TxAAs00Q8ggp+GUDbom/Ue9QRiLhTKhoy5mE0mDq0T+4eEVh4T4FH7cO+BEt unSfXYsLUfu0g/Lq9mhj0XMT7n3wKfmGjgrbcx+/s7hd8/ArIT/5gKiJWzhUvotg J67VeHrmR9xJim7qbSGmyxeLJZqlwAsDaKiUWGMqD107RDiw14kYQ2bHHXLVmdJr MBkfAUD81pggsO5WZAvc0iVMNEGQSWvwtszlJRjgeBxBYVV64A8WSHTOz/Js7ZT2 kWW6gPqwr22Z+vXFrX0jGzTtkIk4mzfCunhoB+/pxQnoE5giKXjS3ea2ZPJ3ay/C NVScZAB+ZFqebL4bSrhPdlAqhbRyYG4zcL6gAn5No1oToym3QqhFs1qGhMTOUMVE +kzdFTZmpyXG4r84WSvqCS0adkRQXaOMpt+bwXQCRGpaqBDBwEyljyqWci4kv1si AT+txweOOJPUAshzVlB1uvoLgsGH10FPRJ6rKLl3WWqr6M8IFVwgbjj4vRaKUJX6 en65bTcGdTysQr3ydQJ+CNKhh5KsBvqQuws1pufKfRnptBo/ptnytHvyJ/6Afqkh /NPmRLOwgbxTnQ7ecXF0yKSigrGBStvalhtYwcdkXVPf8yUFeEe/qSQRmpkbFNdO VK/7wo/KViT/RwfCmIk3XUxI54Epw1Ff5vMZOQhUXXNV/kUEl4Q= =oQMm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IYACgkQ7ZfpDmKq fjQTXQ//ZSpk0iHiwnZqcqujuTh/YWXWvKaWAxRG3sRnz+i6IrrEzsaCrod4yENf 7BSLVrrrNHbAha7S3q/SIIrm2atrEZok/9s7TSa4vIhMASQYY2N+A5DrXcyWYkkE +9SPJH71SKG1MrY2vafr7vgbqXSi9P0LINPjUktUoOj/SS5+DofH6BuMh0f1W6ue VDAnjtlcxxHXVo/lNrKt9xckRNXn7O83QIQmnBTXGh7VhmTBpM2E21DvSk7fmbXG AJ76RxUbz2t0IwSSu6AtP4KrrvoMoltmQM0N0AIWEUt1dcy0q3hIyOB7/J7uJQiQ 0+oDxCBcW1Y2J9X2ZEwzHIZhs1dMvjCRL/PA7aDaSZg5yI6SaovUx8p08/alYUNM fEij8fHcsM4Sy26LDZmd3VHXS5ETY6uRd1jZ+e2X8dZa/oo2wwLsxpxg8cFupc94 vvOHgo/4pQFXAKTNw/bcYi387ixjSrEW9Ap4xNtyZrPUoajhhDMdFlxYhbcg4yGw Mz1G6DJtcAZYn56LfwS2IV9X7bf/0NidzBP+YJrLJ3XTIJHHmsZgypYLgrzd33LZ 7kKx/cT38bPFELKq0OfHttr/Ax7Ed8TEvuVqCjohHodVqxDvWSYpEoYS7gRtmn0p IOPgXEDMuz6ouBKnArE7j4DHGJGX59eoOXIeSbBDbBXmCZ5jxaA= =MSiH -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl+J5IcACgkQ7ZfpDmKq fjQOOA//Q/QmUhD/1nqqdOa4fUedkT6Tqv+J2Y1N87IsWht1P7Hza/xJaEBFVkk0 /10Lo9rxh6rBPjYNPiZExqQsqRhXTHX7oFtHT2q5JMFliePzSBp5fY1xhWSPmzYg vlQn+9jdLTl3lLrGI3H7YU+kBABm5t9dgldpv0hXh9mgvEITV/fUZIeevBiQ4zoh 0a8JT8wD5tOzMfchHJUsoLiveEzOSuy3lDcopubSsZug3QJV7saO0KRpNWpk37bs AFlrEgASLKc1XjWt9XHhkXlB3ZhoaKbQ3lKEZuy93Dx4PZOowVchKrC0M1gd2Cq+ YC8B0yufglSCTpzLRKWx6kyPJaeqzTnteSHiU1hKAvk8jKPi9ZizOf8x+bWg8zHk z4YZ9xJ8VVMAYU5S1pi3toZxpNrPlS0jKwUp2fbuk3KriNftkgu/xBEukAR4KqNH 8HGFQ+yyx7yZ+50EBS6fVryGiqmh8c+Jl5LjkLOifaRk6cHCV5cmRNQ6xbxXqDEU zQvxGRYQJRzHcBqboQPl3GkrdNAdo7hmqyohVWjGM9UxLodHc+VsrKNbWJ9R5Q9C +/ZPRtQy6WPTOsPtU5d5ClcOOdxARoZVZlmZAewiN/zGcQ2GfapWbWT5VK8lTYyw 2B7TzqxhIqAqYLXbmfDIeBVGj0FS8IhUol0dWYF+xHgPCoUK3ps= =ZtIL -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. 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'.

2 1

Re: [tz] Palestine to end summer time on Oct 24th
by Michael H Deckers Oct. 20, 2020

Oct. 20, 2020

On 2020-10-20 18:20, Michael H Deckers wrote: NONSENSE please ignore. Michael Deckers.

1 0

Palestine to end summer time on Oct 24th
by Sharef Mustafa Oct. 20, 2020

Oct. 20, 2020

Hi, As per the palestinian cabinet announcement yesterday , the day light saving shall start on Oct 24th 2020 at 01:00AM by delaying the clock by 60 minutes. http://www.palestinecabinet.gov.ps/portal/Meeting/Details/51584 quote: " . بدء العمل بالتوقيت الشتوي في فلسطين، بتأخير عقارب الساعة 60 دقيقة إلى الوراء، اعتباراً من الساعة الواحدة من صباح يوم السبت الموافق 24/10/2020م. " This covers *Asia/Gaza* & *Asia/Hebron* time zones Thanks Sharef Mustafa

5 8

make rearguard_tarballs fails on macOS
by Deborah Goldsmith Oct. 19, 2020

Oct. 19, 2020

Hi, The change to Makefile for 2020c makes it fail on macOS, as the touch command on Darwin does not have a -d option: > : The dummy pacificnew pacifies TZUpdater 2.3.1 and earlier. > touch -md 2020-10-12T22:53:00Z \ > tzdata2020c-rearguard.dir/pacificnew > touch: illegal option -- d > usage: > touch [-A [-][[hh]mm]SS] [-acfhm] [-r file] [-t [[CC]YY]MMDDhhmm[.SS]] file ... > make[1]: *** [tzdata2020c-rearguard.tar.gz] Error 1 > make: *** [rearguard_tarballs] Error 2 Debbie

4 13

2020c zic code draws complaints from Coverity
by Tom Lane Oct. 18, 2020

Oct. 18, 2020

The Coverity static-analysis tool [1], which is moderately widely used by open-source projects, doesn't much like this: 789 if (bloat == 0) >>> CID 1468262: Incorrect expression (CONSTANT_EXPRESSION_RESULT) >>> "strcmp("slim", "slim")" is always 0 because ""slim"" is compared against itself. 790 bloat = strcmp(ZIC_BLOAT_DEFAULT, "slim") == 0 ? -1 : 1; This is just a bug-finding heuristic, of course, and it won't trouble me that much to ignore the warning. Still, I wonder why it's coded this way and not like, say, #ifndef ZIC_BLOAT_DEFAULT /* Use -1 for slim, +1 for fat */ #define ZIC_BLOAT_DEFAULT (-1) #endif ... if (bloat == 0) bloat = ZIC_BLOAT_DEFAULT; The use of a string doesn't seem to be buying anything in terms of error protection, since the strcmp doesn't distinguish "fat" from "slem" or other misspellings. regards, tom lane [1] https://www.synopsys.com/software-integrity/security-testing/static-analysi…

2 1

[PATCH] tz-link.html: update Oracle Java tzupdater README URL
by Brian Inglis Oct. 18, 2020

Oct. 18, 2020

Oracle Java tzupdater README URL in tz-link.html has been changed and is currently being redirected; update it in case that does not continue: $ curl -I https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html HTTP/2 301 server: Oracle-HTTP-Server location: https://www.oracle.com/java/technologies/javase/tzupdater-readme.html ... --- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 606a83b9..c8c4e82c 100644 --- a/tz-link.html +++ b/tz-link.html @@ -247,7 +247,7 @@ href="http://userguide.icu-project.org/datetime/timezone"><abbr title="International Components for Unicode">ICU</abbr></a>, <a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr></a> and <a -href="https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html">Oracle</a> +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">Oracle</a> Java, <a href="https://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>, and <a @@ -436,7 +436,7 @@ freely available under the <abbr>MIT</abbr> license.</li> <li>Java-based compilers and libraries include: <ul> <li>The <a -href="https://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html">TZUpdater +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">TZUpdater tool</a> compiles <code><abbr>tz</abbr></code> source into the format used by Oracle Java.</li> <li>The <a -- 2.28.0

2 2

[PROPOSED 1/2] Update Danish URLs
by Paul Eggert Oct. 18, 2020

Oct. 18, 2020

* europe: Update Danish URLs since the old ones no longer work. No need to refer to the now-vanished page of poe (Peter Øhrstrøm) since it was a secondary source anyway. --- europe | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/europe b/europe index af6c628..ea23736 100644 --- a/europe +++ b/europe @@ -1029,17 +1029,16 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # Denmark, Faroe Islands, and Greenland # From Jesper Nørgaard Welen (2005-04-26): -# http://www.hum.aau.dk/~poe/tid/tine/DanskTid.htm says that the law -# [introducing standard time] was in effect from 1894-01-01.... -# The page http://www.retsinfo.dk/_GETDOCI_/ACCN/A18930008330-REGL +# the law [introducing standard time] was in effect from 1894-01-01.... +# The page https://www.retsinformation.dk/eli/lta/1893/83 # confirms this, and states that the law was put forth 1893-03-29. # # The EU [actually, EEC and Euratom] treaty with effect from 1973: -# http://www.retsinfo.dk/_GETDOCI_/ACCN/A19722110030-REGL +# https://www.retsinformation.dk/eli/lta/1972/21100 # # This provoked a new law from 1974 to make possible summer time changes # in subsequent decrees with the law -# http://www.retsinfo.dk/_GETDOCI_/ACCN/A19740022330-REGL +# https://www.retsinformation.dk/eli/lta/1974/223 # # It seems however that no decree was set forward until 1980. I have # not found any decree, but in another related law, the effecting DST @@ -1051,7 +1050,7 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # The law is about the management of the extra hour, concerning # working hours reported and effect on obligatory-rest rules (which # was suspended on that night): -# http://www.retsinfo.dk/_GETDOCI_/ACCN/C19801120554-REGL +# https://web.archive.org/web/20140104053304/https://www.retsinformation.dk/F… # From Jesper Nørgaard Welen (2005-06-11): # The Herning Folkeblad (1980-09-26) reported that the night between -- 2.25.1

2 3

Fiji Daylight Saving Time 2020-2021
by Jashneel Kumar Oct. 16, 2020

Oct. 16, 2020

Dear Support, Please note that Fiji Daylight saving Time has been confirmed as follows: DST Start : Sunday, 20 December 2020, 02:00:00 clocks will be turned forward 1 hour to Sunday, 20 December 2020, 03:00:00 local standard time instead. DST End: Sunday, 17 January 2021, 03:00:00 clocks are turned backward 1 hour to Sunday, 17 January 2021, 02:00:00 local standard time instead. Looking forward to your support to reflect the same in the tz database. Regards, Jashneel Kumar Manager Data Networks & Services Mobile: +679 999 8456 Vodafone Fiji PTE Limited 168 Princess Rd, Tamavua Suva Fiji [Vodafone] ________________________________ The content of this email including any attachments is confidential and may contain information that is proprietary and privileged. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify E-mail Administrator on info(a)vodafone.com.fj Please also destroy and delete this message from your system. Vodafone Fiji PTE Limited does not guarantee that this message is free from computer virus or any other defect. The reader accepts full responsibility for taking defensive and counteractive action needed to rectify the computer virus or other defects caused. Vodafone Fiji PTE Limited : Private Mail Bag, Suva, Fiji | Telephone : +679 3312000 | E-Mail : info(a)vodafone.com.fj Please consider your environmental responsibility before printing this e-mail [X] Vodafone Fiji PTE Ltd <https://www.vodafone.com.fj/>

2 1

2020b not updating with java
by Mike Cullinan Oct. 16, 2020

Oct. 16, 2020

I know this is out of the IANA scope but hoping someone listening can help get the tzupdater tool working again. $ ./openjdk/jdk-15.jdk/Contents/Home/bin/java --version openjdk 15 2020-09-15 OpenJDK Runtime Environment (build 15+35-1559) OpenJDK 64-Bit Server VM (build 15+35-1559, mixed mode, sharing) $ $ ./openjdk/jdk-15.jdk/Contents/Home/bin/java -jar tzupdater.jar -l Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Source directory does not contain source file: pacificnew

5 4

Patch for ziguard.awk
by Neil Fuller Oct. 15, 2020

Oct. 15, 2020

I discovered that the ziguard.awk is not entirely reversible: it doesn't switch between vanguard and rearguard data for Namibia data completely in all cases. Attached is a patch with some more explanation and a proposed fix. It's bigger than strictly necessary because I tidied up the Ireland lines rather than applying the same fix there. Low severity / impact and probably not an issue in the normal release workflow : I discovered it because I was stumbling around generating my own tarballs for testing the proposed 2020b changes. That's not something I usually do. As always, thanks for all the work you do. Neil. -- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902

2 2

Ireland considering staying with summer time
by Kevin Lyda Oct. 15, 2020

Oct. 15, 2020

It seems unlikely, but there have been suggestions in Ireland to stay with summer time this year to deal with COVID-19. It's at the tail end of this story: https://www.irishtimes.com/news/health/coronavirus-tighter-restrictions-mul… Out of interest, would a release to support such a change be possible? Kevin

4 3

Re: [tz] Indian Continent
by Guy Harris Oct. 12, 2020

Oct. 12, 2020

On Mon, Oct 12, 2020 at 12:16 PM Bharat Adur <bharatadur(a)gmail.com> wrote: > We find for India there is certain bias taken by some individuals in a country which has such a large population and its Indian Standard Time (IST UT= 5hours 30 minutes), which is accepted by National Physical Laboratory (NPL),New Delhi and Astronomical Society of India. ...and which is the time for the tzdb region with the ID "Asia/Kolkata" - 5 hours 30 minutes ahead of UTC, abbreviation "IST". So the tzdb *does*, in fact, support Indian Standard Time, using the tzdb ID "Asia/Kolkata". > our norm of 1970 cannot be acceptable to Modern India The only "norm" of 1970 is that the tzdb doesn't create new zones for regions that differ *before* 1970. If something changes *after* 1970, we'll add a new zone if necessary. It doesn't mean that the tzdb is inherently out-of-date, with nothing that happened *after* 1970 being supported. > hence its our humble request you to consider IST UT= 5hours 30 minutes. We already considered it and support it, with the tzdb ID "Asia/Kolkata". > and if you desire we can send you at least 50 cities. There are several significant cities in the United States Pacific Time Zone; however, the tzdb has only one entry for that zone, with the ID "America/Los_Angeles". There is no entry with the ID "America/San_Francisco"; even though I live closer to San Francisco than to Los Angeles, this is not a problem for me. There also aren't any entries with the ID "America/San_Diego", "America/Portland", "America/Seattle", etc.. The tzdb does *not* create multiple entries for a given zone so that every city in that zone appears in a tzdb ID for a zone. A good time zone selector will allow the user to specify a city name and will look up the tzdb ID appropriate for that zone, e.g. for Bangalore/Bengaluru, Delhi, Mumbai, etc., it will select Asia/Kolkata.

2 1

Re: [tz] Indian Continent
by Jonathan Leffler Oct. 12, 2020

Oct. 12, 2020

Thank you for your response. I note that your message didn't go to the tz(a)iana.org mailing list. I've copied the list again with this message. I have no official status on the team that maintains TZDB; I'm merely an interested observer. Therefore, anything I say can be overridden by that team. But I believe I'm following the "party line" on the topic. I'm not clear what your response is claiming. Are there 50 different sets of rules for different cities in India for changes in time zone since 1970? Unless there are different time zone rules for different areas of India, one entry does for all of India. Whether I like it or not (and I don't), America/Los_Angeles is the official name for the time zone in all of California, even the bits that would rather Los Angeles didn't exist. To have the remotest chance of success, you will need to persuade those who maintain the TZDB that there are different time rules for different parts of India since 1970-01-01. You can look through the mailing list archives to see other people's request for similar changes that have been denied for similar reasons. Occam's Razor (https://en.wikipedia.org/wiki/Occam%27s_razor) comes into effect: Entia Non Sunt Multiplicanda Praeter Necessitatum (Do not multiply entities unless necessary). Adding more city names would be multiplying entities without good reason. If you wish to create historical information for different time zones in India before 1970-01-01, then you may have some luck, but you'd need to provide the data, with references to official or authoritative sources of information about the different time zones. But that becomes more specialized — it might not make it into the main TZDB distribution because the time zones within India have not diverged by location for the last 50 years or more. On Mon, Oct 12, 2020 at 12:16 PM Bharat Adur <bharatadur(a)gmail.com> wrote: > Dear Sir, > We find for India there is certain bias taken by some individuals in a > country which has such a large population and its Indian Standard Time (IST > UT= 5hours 30 minutes), which is accepted by National Physical Laboratory > (NPL),New Delhi and Astronomical Society of India. our norm of 1970 cannot > be acceptable to Modern India hence its our humble request you to consider > IST UT= 5hours 30 minutes. and if you desire we can send you at least 50 > cities. therein. > With warm Regards > Bharat Adur > > On Mon, Oct 12, 2020 at 10:44 PM Jonathan Leffler < > jonathan.leffler(a)gmail.com> wrote: > >> The way the TZDB works is that if all areas of a country have used the >> same time rules since 1st January 1970, there will be a single time zone >> entry for that country. >> >> Are there any parts of India that have not used the same time rules as >> Asia/Calcutta (Asia/Kolkata?) since 1970-01-01? If not, there is no reason >> to introduce any new zones. If you have an application that wishes to >> provide alternative names, then you may. It is not recommended that the >> names in the database are shown to end users in any case. >> >> This is discussed in the theory.html file distributed with the TZDB data. >> >> >> On Mon, Oct 12, 2020 at 8:47 AM Bharat Adur <bharatadur(a)gmail.com> wrote: >> >>> Dear Sir >>> Indian is very large country with over 130 billion population with 28 >>> states and over fifty major cities including Mumbai. >>> However in your catalog list for India in tz list , we have only as >>> Asia/Calcutta. >>> Can you kindly introduce in python in tz it should locate the place and >>> th local time, >>> with best regards >>> Bharat Adur >>> >> >> >> -- >> Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> >> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org >> "Blessed are we who can laugh at ourselves, for we shall never cease to >> be amused." >> > -- Jonathan Leffler <jonathan.leffler(a)gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2018.1031 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."

1 0

DST changes in Hungary (full historical revision)
by Nyáry Géza Oct. 12, 2020

Oct. 12, 2020

Dear Paul! I examined it all of the Hungary daylight saving time changes. More differences I found what I repaired and I prepared it it source file, which I attach to this letter. I used Library Hungarica online database as a source, where from scanned contemporary ministerial decrees, instructions, newspapers and from other documents it was possible to find the time of the changes concerning the years. https://library.hungaricana.hu I checked the modified changes many times and I considered it right. If it's possible, I ask the exchange the attached modified Hungarian section in global database! Thank you very much! Bets regards, Géza Nyáry

5 11

Indian Continent
by Bharat Adur Oct. 12, 2020

Oct. 12, 2020

Dear Sir Indian is very large country with over 130 billion population with 28 states and over fifty major cities including Mumbai. However in your catalog list for India in tz list , we have only as Asia/Calcutta. Can you kindly introduce in python in tz it should locate the place and th local time, with best regards Bharat Adur

2 1

Bug in tzdata version (2020b)
by westmail24＠yandex.com Oct. 9, 2020

Oct. 9, 2020

Hello, After compiling now I see that tzdata version is "8675a", not is "2020b". It's your bug or bug of "my" program now? (Screenshot in attachment.) Please check/fix it. Thank you. -- Andrew Oct. 9, 2020

4 3

Fiji Day Light Saving
by Raymond Kumar Oct. 8, 2020

Oct. 8, 2020

Hi Paul Please find attached gazette for DST changes in Fiji. It is from December 20th 2020, till 17th January 2021. 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.

4 3

Re: [tz] tz Digest, Vol 109, Issue 8
by Alan Lehotsky Oct. 8, 2020

Oct. 8, 2020

I’m a little tardy in upgrading (last installed 2018g), but this 2020b release has tar files without a root directory, so when I carelessly did a tar -xzf tzcode2020b.tar.gz tar -xzf tzdata2020b.tar.gz they overwrite each others files instead of unloading into respective directories ./tzcode2020b and ./tzdata2020b. Maybe this isn’t a change in behavior and I just forgot that it happened to me back in 2018. Alan Lehotsky https://codegentllc.com

2 1

[tz-announce] 2020b release of tz code and data available
by Paul Eggert Oct. 8, 2020

Oct. 8, 2020

The 2020b 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: Revised predictions for Morocco's changes starting in 2023. Canada's Yukon changes to -07 on 2020-11-01, not 2020-03-08. Macquarie Island has stayed in sync with Tasmania since 2011. Casey, Antarctica is at +08 in winter and +11 in summer. zic no longer supports -y, nor the TYPE field of Rules. Changes to future timestamps Morocco's spring-forward after Ramadan is now predicted to occur no sooner than two days after Ramadan, instead of one day. (Thanks to Milamber.) The first altered prediction is for 2023, now predicted to spring-forward on April 30 instead of April 23. Changes to past and future timestamps Casey Station, Antarctica has been using +08 in winter and +11 in summer since 2018. The most recent transition from +08 to +11 was 2020-10-04 00:01. Also, Macquarie Island has been staying in sync with Tasmania since 2011. (Thanks to Steffen Thorsen.) Changes to past and future time zone abbreviations and DST flags Canada's Yukon, represented by America/Whitehorse and America/Dawson, changes its time zone rules from -08/-07 to permanent -07 on 2020-11-01, not on 2020-03-08 as 2020a had it. This change affects only the time zone abbreviation (MST vs PDT) and daylight saving flag for the period between the two dates. (Thanks to Andrew G. Smith.) Changes to past timestamps Correct several transitions for Hungary for 1918/1983. For example, the 1983-09-25 fall-back was at 01:00, not 03:00. (Thanks to Géza Nyáry.) Also, the 1890 transition to standard time was on 11-01, not 10-01 (thanks to Michael Deckers). The 1891 French transition was on March 16, not March 15. The 1911-03-11 French transition was at midnight, not a minute later. Monaco's transitions were on 1892-06-01 and 1911-03-29, not 1891-03-15 and 1911-03-11. (Thanks to Michael Deckers.) Changes to code Support for zic's long-obsolete '-y YEARISTYPE' option has been removed and, with it, so has support for the TYPE field in Rule lines, which is now reserved for compatibility with earlier zic. These features were previously deprecated in release 2015f. (Thanks to Tim Parenti.) zic now defaults to '-b slim' instead of to '-b fat'. zic's new '-l -' and '-p -' options uninstall any existing localtime and posixrules files, respectively. The undocumented and ineffective tzsetwall function has been removed. Changes to build procedure The Makefile now defaults POSIXRULES to '-', so the posixrules feature (obsolete as of 2019b) is no longer installed by default. Changes to documentation and commentary The long-obsolete files pacificnew, systemv, and yearistype.sh have been removed from the distribution. (Thanks to Tim Parenti.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020b.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020b.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 47311d42a3ad6a8afa95d1f63fa8b6bb2710b16e dated 2020-10-06 18:35:04 -0700 and tagged '2020b' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 04849f196430717962cbeedf11bbba592c304eaff5d67350c936af83dc8e8cb4cedc1c5f461c984aef05124d6c0f13a874789dff77b85a4b399faf80d75537e0 tzcode2020b.tar.gz 27ade698e61881e637ab04834633595cfbdb08fd97177e9731093165d1268a64dffa0570b5e137b9daa4374e6c6827ed01c476074ec61ec0b9a44a7f23479be9 tzdata2020b.tar.gz 475f69b908f8d7d777fcf93f1d223fc4af404a3c8caaa678ca97702a3e9c1ec3e1b5747c8688dfc7b291300bab9ff4804b8ceebfc2de47b505cffe4fa5594abc tzdb-2020b.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HSkACgkQ7ZfpDmKq fjRNrBAApj2R+iRJs5UdW5lIdsANGSz3d9l/dMs48Ryk5SU6qBCVtL4cKavSfw5Q Xh6ZaohNc8GPHF4pGTHBBrKwq6lxQgbemSXswqh+Qi4584wlI5zHr2J7ohLJTnnx ma4EgRCEBplU7XnANa/dQEr69DVG1LkgvOFNGS42oNNcS5zIVcLkeQaJ93MI/tJO seHQTmQn5hiKsZ60S+qrPy4Yu4Cwxzo6Le/BVEXE3leVAFMcXMzRvV4UEooh2TCM b7v2cHnTKKdN7iTzmKyYrXh3Xs1ENVECLS9D9d9mXDT6FViIXcx95StSELXH3i/s eqqpgnAcpPQIb16uIrT+XlzGbJ56HNh2j/axVqaVzkwHlEOKz7b7y7OUfUUNpzD+ vI/uZ/0reUs2rr0IeSHLK3LVRbPvcw/sHQN8EjirSXVDQcfjAr0x72V+YPzDIQ5K fQ6o1ADrrd6cHCa90D1xz94d34DD3sSfUjaOOpNpaLJL7GW5CNsm0CaWIc8my4Dp Agt6T4QtA0WAtsnvupKk3tuPP57rvrlVTQYEvfhpDsPxVkY+R80ir/3+eCMZHrvm 3CZ1uWNGd7kG1m4sfcq0AHUl3bgHapJkLRtyMY4izQJZIm0pGEsrCi8P3+87wDgU eIMcGJUYOjTtE1ELGWxzo066FpOLMoGm9YOwN+FYi+eSjEdjGdg= =BKe9 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HToACgkQ7ZfpDmKq fjT5CQ//W6kd+vP2tAdMbmJnH35sCd0NoAFBC1j00Blg+I6s507w5VjOTjvrvjlE 0RB2G67vNKTOBybPyk7l8cKq+5Xw5IE1xqwqfpN3+DH2BWt4P0AllcBBRRky9iXS oO+z4F51rud9+CD2vbhtx0eT9MWYVfzrncNUHIYm7sDx01vtCp3h5u9ryB2sfHT/ iMKrB5ytFqWkNXZtMiRDj3LZF0y2+JM1/8lfZB/hyxx1Bbvcm07dQvBBz8ljT6KD /BJFsgwvvlpxOZ1P0fFb7BnMPD5v/fB5r/0i/c4ErIY8JPtxDY6ctGdtbC/0H7Xf kjve+Fue08CBg4tXEW75SvWBP8Li1XylSNohIEtnclXj9B1nwu0WArZtATIqhpxl T77J85JkVQoAi5Wh38Msy9QWb54FRoK8/c1drfwb/iMkRYt57mU5zuY9JJvx7mAm S3eVqU3/tX4Ue7gQ1hjW3m9abmS1Hmq4aQ8r1uS0t2cIjbrMY2zaRwYzb2UknT2w VVr5O5bWoPHSFDeqUU7NdGHQzJX+NLvpTlcvJHXONSu7CksC09uhzBVJ2LbkjQS1 zD+jSCTgXZonegcF0/UsfMrxmrizDFVcvwDXnDa4TcRPVSevtdWvM+EXr3Dto0N/ wlI4v2nZE2ZFB3+7iGxc0WwiHUdsVbQVD+fCTIBl4Uh4ViTAsXI= =/O2G -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl99HTsACgkQ7ZfpDmKq fjRCtQ//ZOBneEAY4W08oOJ3UipwG+Xq33arMbZ86yBBBrkjUIfcLFi7ESPGvkn8 zAR28fYpL7kUTQyuzMjwIxdFSDpgmRUpLRtlLn+Vdkx1o/WCbj5A0O3nsqq+M04J yuGr1dYGfTnGi624mvsB5dPxneGw9TCh9YseBKV+hF6FxmhdBkl1Gwxz4fyzAdo9 A4OQhtnKntZo6Peuo8ittfnA6fi6hwVZjeaqjGWMN7qEjSOG79mVAHaKxsOKUs2L Mnre/1iRQX/33c/hJHrleit2+H430WCVJ3WGQ0OjODfnrl5B9tmWv0CFIaJTUq4Q zwOBpa2CvTd0hOmagZiP7PuTI1AXjMpJBd1ISssbw1mPO7lcAjSfjYMYy972xhUQ pig67kaKATh8tfPUTUjE8pEOyLnPkZdT0dbFqz1Sqad2u1y5NmWl1ps8YYZl9hHC a0pzxRD7HIK4o1BYuSMLuvwgfdFFjBeGMbm1/sFOSgRzzrZQ8BIXEmNG5whM+OQF +cfmyG9VZimvAI/vcw2w6xqokJn/l8yrG8D3GJZNA4s3xJTLYXUc6qrY7FpTDa0A Ce2Lj1HZN4q9FyIeEU22YAXKDmP8/7eNCO/Z7I9mrjocbpS09tL2YOWh1EI1Gq/U fqxprHL5w+/AKehKr5YZ7eZA5QXQBH80RIXqntJwFsnkd7pfmYU= =1NiW -----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'.

4 5

Removing systemv, pacificnew, Rule TYPEs, zic -y
by Tim Parenti Oct. 4, 2020

Oct. 4, 2020

I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti

3 3

Converting tz-how-to.html to HTML 5
by Paul Eggert Oct. 4, 2020

Oct. 4, 2020

On 10/3/20 3:49 PM, Tim Parenti wrote: > (the VALIDATE=':' is because my MacBook > doesn't have nsgmls). The VALIDATE stuff in Makefile is needed only because I hadn't bothered to convert tz-how-to.html to HTML 5 with validator.w3.org checking, like the other web pages. I installed the attached proposed patch to do that, removing the need for VALIDATE etc. This is for maintenance convenience; it doesn't change the content of that web page, or its appearance on my Firefox 81 browser.

1 0

Updating zic.c to further match Link line field names
by Tim Parenti Oct. 3, 2020

Oct. 3, 2020

In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti

1 1

Casey time zone change
by Steffen Thorsen Oct. 2, 2020

Oct. 2, 2020

Based on information we have received from the Australian Antarctic Division, Casey station and Macquarie Island station will move to Tasmanian daylight savings time on Sunday 4 October. This will take effect from 0001hrs on Sunday 4 October 2020 and will mean Casey and Macquarie Island will be on the same time zone as Hobart. Some past dates too for this 3 hour time change back and forth between UTC+8 and UTC+11 for Casey: - 2018 Oct 7 4:00 - 2019 Mar 17 3:00 - 2019 Oct 6 3:00 - 2020 Mar 8 3:00 and now - 2020 Oct 4 0:01 Best regards, Steffen - timeanddate.com

2 3

Re: [tz] [IANA #1173666] Time zone change - Yukon Canada
by Andrew.Smith＠gov.yk.ca Sept. 30, 2020

Sept. 30, 2020

Good day. I work for the Government of Yukon in Canada. We are in the process of revising our definition of time to be permanently on UTC -7, no longer observing a twice-annual time change. I was on the hunt for authoritative standards related to time, and saw the IANA come up as caretaker of the time zone database, which appears to be relied on for software and systems. I am contacting you to see if there is any process beyond notification to making this adjustment in your TZ database, and perhaps to know if there are other agencies that should be aware of what Yukon is planning. From what I see now, TZ database names "America/Dawson", "America/Whitehorse" and "Canada/Yukon" would be affected by this change. Our regulation is not yet complete, so it is not law at this time and I am not looking for immediate change. We are aiming for finalization here by November 1, 2020. Hope to hear from you soon. Andrew Andrew G. Smith Intergovernmental Relations Executive Council Office Government of Yukon C: 867-335-6008 -----Original Message----- From: Amanda Baber via RT <iana-questions(a)iana.org> Sent: July 2, 2020 3:48 PM To: Andrew.Smith <Andrew.Smith(a)gov.yk.ca> Subject: [IANA #1173666] Time zone change - Yukon Canada Dear Andrew, Thank you for contacting us. IANA hosts the Time Zone Database, but the database is managed by the Time Zone Coordinator in conjunction with a mailing list. You can find find mailing list information here: https://www.iana.org/time-zones This document should have or point to much of the information you're looking for: https://data.iana.org/time-zones/tz-link.html As is noted at the link above, "If your government plans to change its time zone boundaries or daylight saving rules, inform tz(a)iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%… for examples." Best regards, Amanda Baber Lead IANA Services Specialist On Thu Jul 02 22:20:44 2020, Andrew.Smith(a)gov.yk.ca wrote: > Good day. > > I work for the Government of Yukon in Canada. We are in the process of > revising our definition of time to be permanently on UTC -7, no longer > observing a twice-annual time change. > I was on the hunt for authoritative standards related to time, and saw > the IANA come up as caretaker of the time zone database, which appears > to be relied on for software and systems. I started with ISO 8601, but > couldn't see the full text to know if there are time zone standards > there. I am contacting you to see your TZ database is a widely adopted > and authoritative as it seems, to see if there is any process to > making this adjustment in your TZ database, and perhaps to know if > there are other agencies that should be aware of what Yukon is > planning. > From what I see now, TZ database names "America/Dawson", > "America/Whitehorse" and "Canada/Yukon" would be affected by this > change. > > Our regulation is not yet complete, so it is not law at this time and > I am not looking for immediate change. We are aiming for finalization > here by November 1, 2020. > Hope to hear from you soon. > > Andrew > > > [cid:image003.png@01D65084.40C16690] > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > C 867-335-6008 | Yukon.ca

10 23

Python PEP-615 release eminent
by Matt Johnson-Pint Sept. 21, 2020

Sept. 21, 2020

Just a heads up. Python 3.9.0 is scheduled for release in two weeks on 2020-10-05

3 4

Europe/Kyiv
by Ihor Romanyshyn Sept. 14, 2020

Sept. 14, 2020

Hi there! It's possible to add an alias "Europe/Kyiv" for russian name "Europe/Kiev"? For more information about this please read https://en.wikipedia.org/wiki/KyivNotKiev -- Ihor Romanyshyn Network Administrator *Avenga* 118b Antonovycha Str 79057 Lviv Ukraine office +380 67 670 5051 <+380676705051> mobile +380 93 957 5136 <+380939575136> mail ihor.romanyshyn(a)avenga.com www.avenga.com Avenga - Transforming Industries

2 1

looking for information about changing time zone
by Françoise Kerjouan Sept. 11, 2020

Sept. 11, 2020

Madam, Sir, Im living in New Caledonia; our local government is thinking about changing time zone (from UTC +11 to UTC +12). Could you please tell me how long a lead notice should be to be sure that the international community will get and process the information ? I understood that the ICAN TZ database is widely used, but I didnt catch if it is also used for international transports (by airports for example). Could you please tell me if it is the case? If not, whom should I ask for? Best regards, Françoise Kerjouan

5 6

Question] Regarding Asia/Yerevan timezone abbreviation
by Goun Lee Sept. 10, 2020

Sept. 10, 2020

Hi, I'm Goun from South Korea. I have a question regarding Asia/Yerevan timezone abbreviation When I checked the following line, https://github.com/eggert/tz/blob/master/asia#L127 it's written as 4:00 Armenia +04/+05 As far as I know, Armenia has no DST time, so the abbreviation should +04. isn't it? I'm just wondering if it's correct or not. best regards. Goun

2 1

DST on Twitter :-)
by Sergiusz Wolicki Sept. 9, 2020

Sept. 9, 2020

User Brent Terhune (@BrentTerhune) wrote at 9:55 PM on Sep 9: The guy who invented Daylight Saving was ahead of his time. Or behind, depending on which month it was. (https://twitter.com/BrentTerhune/status/1303784188584300545?s=03) -- Sergiusz

1 0

timezone DB distribution
by Juergen Naeckel Sept. 8, 2020

Sept. 8, 2020

Hey there, First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds. Since I was interested in the repository, I downloaded the “Data only distribution”. I found six files containing the TZ information. And I found 27 files, containing other stuff. Well, there might be three or four files in a grey zone (calendars, backlist…). But I definitely do not consider MAKEFILE and .awk file as part of a “data only distribution”. Maybe move them to a separate folder in the GZ file? Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files. It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing. [cid:image002.png@01D674A5.27F71B60] Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here? And finally here comes my question: In the rules, I see in the column several times denoted with a tailing “u” or “s”. I think I read on one occasion that the times are denoted in “standard time”. I do not recall anymore where that was. But regardless, 1. I don’t understand what that “denoted in standard time” would mean 2. I definitely have no clue would the tailing “u”: would imply. [cid:image003.png@01D674A6.99550F50] Can you shed some light on this? Thank you! Not only for an answer but also for researching and compiling this list. Juergen Juergen Naeckel PRINCIPAL ARCHITECT T 617 766 2381 | C 617 775 3874 naeckel(a)adobe.com [cid:image001.png@01D6749A.D7B33580]

14 36

Iceland stays put on time zone
by Paul Eggert Sept. 7, 2020

Sept. 7, 2020

After more than two years of discussion, Iceland's government decided not to move its time zone back to -01, where it was before daylight saving time was introduced. Currently Iceland is at +00, effectively permanent DST. Proponents of changing back had argued that DST has harmful effects on human health. To counteract DST's health effects, the government decided instead to launch an educational campaign to get Icelanders to sleep more. It is also considering monitoring children's sleep habits and starting school days later. See: Gréta Sigríður Einarsdóttir, Iceland’s Time Zone to Remain Unchanged. Iceland Review. 2020-09-01. https://www.icelandreview.com/sci-tech/icelands-time-zone-to-remain-unchang…

1 0

DST in the news
by Arthur David Olson Aug. 29, 2020

Aug. 29, 2020

"American Academy of Sleep Medicine calls for elimination of daylight saving time" https://aasm.org/american-academy-of-sleep-medicine-calls-for-elimination-o… (Use your browser's vertical scroll bar to move through the article while avoiding an obscuring popup.) Noted on @Twitter by @AASMorg and retweeted by Jef Poskanzer (@JefPosk): https://twitter.com/AASMorg/status/1299334700478201858 @dash dashado

7 9

[PROPOSED] * asia: Cite Barak 2020 on Israeli DST controversy.
by Paul Eggert Aug. 23, 2020

Aug. 23, 2020

--- asia | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/asia b/asia index 106efad..fff9a10 100644 --- a/asia +++ b/asia @@ -1699,6 +1699,10 @@ Zone Asia/Baghdad 2:57:40 - LMT 1890 # Israel +# For more info about the motivation for DST in Israel, see: +# Barak Y. Israel's Daylight Saving Time controversy. Israel Affairs. +# 2020-08-11. https://doi.org/10.1080/13537121.2020.1806564 + # From Ephraim Silverberg (2001-01-11): # # I coined "IST/IDT" circa 1988. Until then there were three -- 2.25.4

1 0

ta and VBA
by Marlon Rosenthal Aug. 22, 2020

Aug. 22, 2020

Hello there, I am working on a private research procedure where I would like to use your database. Unfortunately I am working in Excel/VBA and have not found any link or advice how to use it with VBA. I hope there is something and maybe you can help me with a link? Best regards, Marlon Marlon Rosenthal german voice-over [image: Logo] <http://www.sprecherprofi.de/> sprecherprofi | +49 163 6002666 | marlon(a)sprecherprofi.de [image: Banner] <http://www.sprecherprofi.de/>

2 1

XKCD Comic
by stevejones＠ontimezone.com Aug. 19, 2020

Aug. 19, 2020

While this comic neither represents the strength of the TZ infrastructure or the significant body of persons who contribute to and maintain it, I thought this still provided an amusing way to look at it: https://xkcd.com/2347/ Steve Jones

1 0

Change Request: Europe/Kiev to Europe/Kyiv
by Victor Perov Aug. 16, 2020

Aug. 16, 2020

Dear Sir/Madam, I hope this email finds you well. I'm writing to you with a request to accept proposed changes of correcting the spelling of capital of Ukraine Kyiv in the Time Zone Database. I've found previously closed PR with the same intention. It was about renaming Kyiv and other two cities of Ukraine: Uzhhorod and Zaporizhia. It was closed 4y ago with no changes applied. I am deeply sorry for comments left by their authors in that PR. Those messages were sounding offensive and I understand your decision of closing that PR with no decision made. I agree, 4y ago the usage of Kiev was much wider than nowadays, and believe you will find materials I attached to my PR meaningful. The link to PR I've brought to your attention: https://github.com/eggert/tz/pull/27 I have also attached a patch of the commit to the email. Looking forward to hearing from you. Kind regards, Viktor Perov

5 5

[PROPOSED 1/2] Minor editorial improvements for newstrftime.3
by Paul Eggert Aug. 15, 2020

Aug. 15, 2020

* newstrftime.3: Improve this a bit to have it match POSIX better. Resurrect the BSD manual’s phase-of-the-moon joke. --- newstrftime.3 | 103 ++++++++++++++++++++++++++++++++------------------ 1 file changed, 66 insertions(+), 37 deletions(-) diff --git a/newstrftime.3 b/newstrftime.3 index df38d1a..63842c7 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -50,12 +50,14 @@ strftime \- format date and time .B cc ... \-ltz .fi .SH DESCRIPTION -.ie '\(en'' .ds en \- -.el .ds en \(en .ie '\(lq'' .ds lq \&"\" .el .ds lq \(lq\" .ie '\(rq'' .ds rq \&"\" .el .ds rq \(rq\" +.de c +.ie \n(.g \f(CW\\$1\fP\\$2 +.el \\$1\\$2 +.. .de q \\$3\*(lq\\$1\*(rq\\$2 .. @@ -63,7 +65,7 @@ The .B strftime function formats the information from .I timeptr -into the buffer +into the array pointed to by .I buf according to the string pointed to by .IR format . @@ -72,24 +74,24 @@ The .I format string consists of zero or more conversion specifications and ordinary characters. -All ordinary characters are copied directly into the buffer. +All ordinary characters are copied directly into the array. A conversion specification consists of a percent sign .Ql % and one other character. .PP No more than .I maxsize -characters are placed into the array. -If the total number of resulting characters, including the terminating -null character, is not more than +bytes are placed into the array. +If the total number of resulting bytes, including the terminating +NUL character, is not more than .IR maxsize , .B strftime -returns the number of characters in the array, not counting the -terminating null. -Otherwise, zero is returned. +returns the number of bytes placed into the array, not counting the +terminating NUL. +Otherwise, zero is returned and the array contents are unspecified. .PP Each conversion specification is replaced by the characters as -follows which are then copied into the buffer. +follows which are then copied into the array. .TP %A is replaced by the locale's full weekday name. @@ -105,99 +107,122 @@ is replaced by the locale's abbreviated month name. .TP %C is replaced by the century (a year divided by 100 and truncated to an integer) -as a decimal number (00\*(en99). +as a decimal number [00,99]. .TP %c is replaced by the locale's appropriate date and time representation. .TP %D -is replaced by the date in the format %m/%d/%y. +is equivalent to +.c %m/%d/%y . .TP %d -is replaced by the day of the month as a decimal number (01\*(en31). +is replaced by the day of the month as a decimal number [01,31]. .TP %e -is replaced by the day of month as a decimal number (1\*(en31); +is replaced by the day of month as a decimal number [1,31]; single digits are preceded by a blank. .TP %F -is replaced by the date in the format %Y\*-%m\*-%d. +is equivalent to +.c %Y-%m-%d +(the ISO 8601 date format). .TP %G is replaced by the ISO 8601 year with century as a decimal number. +See also the +.c %V +conversion specification. .TP %g -is replaced by the ISO 8601 year without century as a decimal number (00\*(en99). +is replaced by the ISO 8601 year without century as a decimal number [00,99]. +This is the year that includes the greater part of the week. +(Monday as the first day of a week). +See also the +.c %V +conversion specification. .TP %H -is replaced by the hour (24-hour clock) as a decimal number (00\*(en23). +is replaced by the hour (24-hour clock) as a decimal number [00,23]. .TP %I -is replaced by the hour (12-hour clock) as a decimal number (01\*(en12). +is replaced by the hour (12-hour clock) as a decimal number [01,12]. .TP %j -is replaced by the day of the year as a decimal number (001\*(en366). +is replaced by the day of the year as a decimal number [001,366]. .TP %k -is replaced by the hour (24-hour clock) as a decimal number (0\*(en23); +is replaced by the hour (24-hour clock) as a decimal number [0,23]; single digits are preceded by a blank. .TP %l -is replaced by the hour (12-hour clock) as a decimal number (1\*(en12); +is replaced by the hour (12-hour clock) as a decimal number [1,12]; single digits are preceded by a blank. .TP %M -is replaced by the minute as a decimal number (00\*(en59). +is replaced by the minute as a decimal number [00,59]. .TP %m -is replaced by the month as a decimal number (01\*(en12). +is replaced by the month as a decimal number [01,12]. .TP %n is replaced by a newline. .TP %p -is replaced by the locale's equivalent of either AM or PM. +is replaced by the locale's equivalent of either +.q AM +or +.q PM . .TP %R -is replaced by the time in the format %H:%M. +is replaced by the time in the format +.c %H:%M . .TP %r is replaced by the locale's representation of 12-hour clock time using AM/PM notation. .TP %S -is replaced by the second as a decimal number (00\*(en60). +is replaced by the second as a decimal number [00,60]. +The range of +seconds is [00,60] instead of [00,59] to allow for the periodic occurrence +of leap seconds. .TP %s -is replaced by the number of seconds since the Epoch (see newctime(3)). +is replaced by the number of seconds since the Epoch (see +.BR ctime (3)). .TP %T -is replaced by the time in the format %H:%M:%S. +is replaced by the time in the format +.c %H:%M:%S . .TP %t is replaced by a tab. .TP %U is replaced by the week number of the year (Sunday as the first day of -the week) as a decimal number (00\*(en53). +the week) as a decimal number [00,53]. .TP %u is replaced by the weekday (Monday as the first day of the week) -as a decimal number (1\*(en7). +as a decimal number [1,7]. .TP %V is replaced by the week number of the year (Monday as the first day of -the week) as a decimal number (01\*(en53). If the week containing January +the week) as a decimal number [01,53]. If the week containing January 1 has four or more days in the new year, then it is week 1; otherwise it is week 53 of the previous year, and the next week is week 1. +The year is given by the +.c %G +conversion specification. .TP %W is replaced by the week number of the year (Monday as the first day of -the week) as a decimal number (00\*(en53). +the week) as a decimal number [00,53]. .TP %w is replaced by the weekday (Sunday as the first day of the week) -as a decimal number (0\*(en6). +as a decimal number [0,6]. .TP %X is replaced by the locale's appropriate time representation. @@ -209,7 +234,7 @@ is replaced by the locale's appropriate date representation. is replaced by the year with century as a decimal number. .TP %y -is replaced by the year without century as a decimal number (00\*(en99). +is replaced by the year without century as a decimal number [00,99]. .TP %Z is replaced by the time zone abbreviation, @@ -217,7 +242,7 @@ or by the empty string if this is not determinable. .TP %z is replaced by the offset from the Prime Meridian -in the format +HHMM or \*-HHMM as appropriate, +in the format +HHMM or \*-HHMM (ISO 8601) as appropriate, with positive values representing locations east of Greenwich, or by the empty string if this is not determinable. The numeric time zone abbreviation \*-0000 is used when the time is @@ -231,7 +256,9 @@ time zone abbreviation begins with is replaced by a single %. .TP %+ -is replaced by the date and time in date(1) format. +is replaced by the locale's date and time in +.BR date (1) +format. .SH SEE ALSO date(1), getenv(3), @@ -239,3 +266,5 @@ newctime(3), newtzset(3), time(2), tzfile(5) +.SH BUGS +There is no conversion specification for the phase of the moon. -- 2.17.1

4 15

tz database update on a publication & thank-you.
by Andrew Lyon Aug. 3, 2020

Aug. 3, 2020

Several months ago I posted queries about the tz database to this discussion list as I investigated a series of errors triggered in software used to order and report clinical laboratory tests in our hospital network. Our main software system uses universal time for date& time of birth a recently added peripheral system (based on Android OS, and Java Joda-time that relies on the tz database) that triggered the peripheral system to freeze every few weeks. Investigation revealed that there were 10 years (between 1935 and 1945) in the America/Regina tz time zone data where the transition to daylight saving time occurred at midnight on spring transition dates. If our hospital (which is in the America/Regina time zone) encountered patients born on one of those spring daylight savings time transitions dates 1935-1945, the system froze, because the hour of birth was usually unknown and was assigned to midnight local time by default, and midnight local time on those dates does not map back to universal time. A software patch was quickly developed by the software provider and this susceptibility is now avoided. I understand now that this type of situation is well known to members of this group. I want to pass on a 'thank-you' to the tz database community for their helpful messages as this case was investigated. A description of this investigation was published today in the Journal of Applied Laboratory Medicine: "No Lab Tests" When You Are Born in The Twilight Zone: A Clinical Informatics Case Report. [ https://pubmed.ncbi.nlm.nih.gov/32728691/ | https://pubmed.ncbi.nlm.nih.gov/32728691/ ] best wishes, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan, SK, Canada

8 8

[PATCH] Update Bahrain as per article in The National
by Paul Eggert July 25, 2020

July 25, 2020

* backzone (Asia/Bahrain): Adjust transitions before 1944 to match Ashleigh Stewart’s article in today’s The National (Abu Dhabi). --- backzone | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/backzone b/backzone index 91fa21d..7cf026d 100644 --- a/backzone +++ b/backzone @@ -459,7 +459,22 @@ Zone Asia/Aden 2:59:54 - LMT 1950 3:00 - +03 # Bahrain -Zone Asia/Bahrain 3:22:20 - LMT 1920 # Manamah +# +# From Paul Eggert (2020-07-22): +# Most of this data comes from: +# Stewart A. Why Gulf Standard Time is far from standard: the fascinating story +# behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. +# https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… +# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# others at +0323. Reginald George Alban, a British political agent based in +# Manama, worked to standardize this, and from 1941-07-20 Bahrain was at +# +0330. However, BOAC asked that clocks be moved to gain more light at day's +# end, so Bahrain switched to +04 on 1944-01-01. +# +# We don't know when companies chose +0330 or +0323 before 1940; for now +# assume that there was no real standard in Bahrain before 1941-07-20. +Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah + 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun 3:00 - +03 -- 2.17.1

4 4

Re: [tz] Fwd: DST changes in Hungary (full historical revision)
by Paul Eggert July 25, 2020

July 25, 2020

Thanks for those corrections. I installed the attached patch to the development database on GitHub. It's not exactly what you emailed me, but it should generate equivalent transitions. It'd help if we could list citations for the transitions; are URLs available for each decree etc. that you consulted? We could add them as comments. Thanks again.

9 33

[PROPOSED] * backzone: More commentary re 1940s Bahrain.
by Paul Eggert July 23, 2020

July 23, 2020

--- backzone | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 7cf026d..f2684b4 100644 --- a/backzone +++ b/backzone @@ -460,19 +460,31 @@ Zone Asia/Aden 2:59:54 - LMT 1950 # Bahrain # -# From Paul Eggert (2020-07-22): +# From Paul Eggert (2020-07-23): # Most of this data comes from: # Stewart A. Why Gulf Standard Time is far from standard: the fascinating story # behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. # https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… -# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# Stewart writes that before 1941 some companies in Bahrain were at +0330 and # others at +0323. Reginald George Alban, a British political agent based in # Manama, worked to standardize this, and from 1941-07-20 Bahrain was at # +0330. However, BOAC asked that clocks be moved to gain more light at day's # end, so Bahrain switched to +04 on 1944-01-01. # -# We don't know when companies chose +0330 or +0323 before 1940; for now -# assume that there was no real standard in Bahrain before 1941-07-20. +# Re the 1941 transition, Stewart privately sent me this citation: +# "File 16/53 Enquiries Re: Calculation of Local Time", British Library: India +# Office Records and Private Papers, IOR/R/15/2/1564, in Qatar Digital Library +# https://www.qdl.qa/archive/81055/vdc_100000000282.0x00012b +# It says there was no real standard in Bahrain before 1941-07-20. +# +0330 was used by steamers of the British India Co, by Petroleum Concessions +# and by Cable & Wireless; +0323 was used by the Eastern Bank Ltd, BOAC, and +# Bahrein Petroleum (Bapco), and California Arabian Standard Oil Co (Casoc) +# adopted DST effective 1941-05-24. Alban suggested adopting DST, R.B. Coomb +# of C&W countersuggested +0330, and although C.A. Rodstrom of Casoc (formerly +# of Bapco) stated that Bahrain had formerly used +0330 before Bapco arrived +# but Bapco switched to +0323 because of "constant confusion", the consensus +# was +0330. The government adopted +0330 in 1941-07-20 and companies seem to +# have switched by 08-01. No time of day was given for the 1940s transitions. Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun -- 2.17.1

1 0

Re: [tz] A warning on the tzdb 2020a
by Paul Eggert July 9, 2020

July 9, 2020

On 7/8/20 2:22 PM, Matias Fonzo wrote: > ./zic -d '/usr/src/qi/build/package-tzdb/etc/zoneinfo-leaps' -L leapseconds > tzdata.zi > warning: "leapseconds", line 79: "#expires" is obsolescent; use "Expires" Yes, that's a known warning. You can silence the warning by removing the leapseconds file and then building with 'make EXPIRES_LINE=1'. See the Makefile for details. At some point in the not-too-distant future I plan to fix this by defaulting EXPIRES_LINE=1 in the Makefile; this will change the "#Expires" line to an "Expires" line in the distributed leapseconds file. In reviewing the EXPIRES_LINE=1 code I noticed that it put a wrong comment in its output, which I fixed by installing the attached. I also updated the expires line as noted in <https://mm.icann.org/pipermail/tz/2020-July/029165.html>.

1 0

[PATCH] No leap second on 2020-12-31
by Paul Eggert July 9, 2020

July 9, 2020

* leap-seconds.list: Update file from NIST, retrieved from ftp://ftp.nist.gov/pub/time/leap-seconds.list in ASCII mode. --- leap-seconds.list | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/leap-seconds.list b/leap-seconds.list index ac153da..e897a86 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 C59 -# File expires on: 28 December 2020 +# Updated through IERS Bulletin C60 +# File expires on: 28 June 2021 # -#@ 3818102400 +#@ 3833827200 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h a1c168ae 27c79a7d 9dddcfc3 bcfe616b 2e2c44ea +#h 064356a8 39268b92 76e4d5ef 3e22fae1 0cca529c -- 2.17.1

1 0

Tim Parenti as backup TZ Coordinator?
by Paul Eggert July 9, 2020

July 9, 2020

Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week.

12 13

North Vietnam 1970 to 1975 - Asia/Hanoi belongs into main file
by Alois Treindl July 2, 2020

July 2, 2020

(Corrected subject line) The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

6 14

Re: [tz] Mirmalek on Martian timekeeping
by Paul Eggert June 30, 2020

June 30, 2020

On 6/30/20 2:00 AM, BASTIAN Michelle wrote: > I wondered if you had come across this ethnography of mars working time https://brill.com/view/journals/kron/8/2/article-p159_7.xml?language=en No, I wasn't familiar with Mirmalek's work. I see she turned it into a book published in March. Thanks for the heads-up. I updated theory.html's discussion of Martian timekeeping based on the info you sent, and installed the attached patch. This patch also changes some tenses in the text, as the Mars Exploration Rover mission's second rover bit the dust in 2018 (literally: communications cut off during a planetwide dust storm).

1 0

re SPDX, I'll do the work, if you'll use the tag
by Mark Atwood June 30, 2020

June 30, 2020

I was tagged in to this list because of the discussion about SPDX license tagging. I sit on the SPDX committee (which doesn't mean much, it's similar to an IETF WG, in that anyone who joins the list, joins the calls, and then does needed work is "on the committee"). It may be useful to have an SPDX tag for the TZ database data files. The SPDX makes nearly zero legal assessment about a license. Applying an SPDX tag to an existing project is intended to document reality in a machine readable way, it is not intended to change reality. Having an SPDX tag is mostly for the benefit of systems and companies who are trying to be scrupulously correct when complying with open source licenses. When the SPDX evaluates a license, the things looked for are "does/will it have real users?", "does it have a stable enough text that the matching tools can correctly identify it?", and "is it for content intended for mostly uncontrolled distribution?". We very much do not get into all the arguments about "is this well defined in europe", "is this a license or a public domain declaration", "is copyright even appropriate", "copyleft is theft", etc etc etc. We don't practice law, and we don't want to dictate policy, we just id licenses for people who just want to know they are doing the right thing when using your files, and make suggestions for projects that want to write a policy about it. Looking at the TZ database history, it has a very long history with lots of contributors, its mostly just a collection of facts, it appears to be a public domain declaration, that started out kind of adhoc. Using one of the existing PD declarations in the SPDX database would not be appropriate, because of the need to get the past contributors to assent, lots of work for no value. What does make sense is creating a new tag, something like "TZ-PD". Then you can start putting "# SDPX-License-Identifier: TZ-PD" in your database text source file, and make life easier for a bunch of people who just want to do the right thing with your data. To repeat, adding that SPDX license tag of a new identifer to id an existing stable in the field declaration, like this, does not change any legal obligations or expose anyone to any new legal risks. It's just a machine readable way of saying what's already been said about the copyright status of the TZ database. So, I'm willing to volunteer to do that lift for the TZ community, if you are willing to use the resulting id tag. What say you? ..m Mark Atwood <mark.atwood(a)gmail.com> https://keybase.io/fallenpegasus +1-206-604-2198

4 3

North Vietnam 1970 to 1970 - Asia/Hanoi belongs into main file
by Alois Treindl June 28, 2020

June 28, 2020

The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

1 0

Use or Apply for SPDX Licence
by Brian Inglis June 23, 2020

June 23, 2020

Hi folks, It would be useful to distributions, packagers, and organization licence checkers if the tzcode and tzdata were covered by (a) Public Domain SPDX licence identifier(s) https://spdx.org/licenses/ e.g. CC-PDDC, PDDL, SAX-PD, Unlicense, WTFPL, etc. or applied for it's own e.g. IANA-TZ-PD. -- 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. [Data in IEC units and prefixes, physical quantities in SI.]

10 14

[PROPOSED] zic now defaults to ‘-b slim’
by Paul Eggert June 21, 2020

June 21, 2020

Make zic’s ‘-b slim’ option the default. This option first appeared in tzdb 2019b (2019-07-01), and is already the default in NetBSD 9.0 (2020-02-14) and seems to be working there. Using slim format should help finish off the TZif format’s Y2038 transition that began in tzcode 95f (1995-10-28). * Makefile, NEWS, zic.8: Mention this. * zic.c (ZIC_BLOAT_DEFAULT): Default to "slim". --- Makefile | 10 +++++----- NEWS | 2 ++ zic.8 | 10 ++++------ zic.c | 5 ++--- 4 files changed, 13 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 0da7c3f..8abd4d0 100644 --- a/Makefile +++ b/Makefile @@ -22,6 +22,7 @@ BUGEMAIL= tz(a)iana.org # DATAFORM= main # To wait even longer for new features, use: # DATAFORM= rearguard +# Rearguard users might also want "ZFLAGS = -b fat"; see below. DATAFORM= main # Change the line below for your timezone (after finding the one you want in @@ -249,13 +250,12 @@ LDLIBS= # other than simply getting garbage data # -DUSE_LTZ=0 to build zdump with the system time zone library # Also set TZDOBJS=zdump.o and CHECK_TIME_T_ALTERNATIVES= below. -# -DZIC_BLOAT_DEFAULT=\"slim\" to default zic's -b option to "slim", and -# similarly for "fat". Fat TZif files work around incompatibilities +# -DZIC_BLOAT_DEFAULT=\"fat\" to default zic's -b option to "fat", and +# similarly for "slim". Fat TZif files work around incompatibilities # and bugs in some TZif readers, notably readers that mishandle 64-bit # data in TZif files. Slim TZif files are more efficient and do not # work around these incompatibilities and bugs. If not given, the -# current default is "fat" but this is intended to change as readers -# requiring fat files often mishandle timestamps after 2037 anyway. +# default is "slim". # -DZIC_MAX_ABBR_LEN_WO_WARN=3 # (or some other number) to set the maximum time zone abbreviation length # that zic will accept without a warning (the default is 6) @@ -390,7 +390,7 @@ ZIC= $(zic) $(ZFLAGS) # To shrink the size of installed TZif files, # append "-r @N" to omit data before N-seconds-after-the-Epoch. -# You can also append "-b slim" if that is not already the default; +# To grow the files and work around older application bugs, append "-b fat"; # see ZIC_BLOAT_DEFAULT above. # See the zic man page for more about -b and -r. ZFLAGS= diff --git a/NEWS b/NEWS index bfe02ea..6b9fd43 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,8 @@ Unreleased, experimental changes Changes to code + zic now defaults to '-b slim' instead of to '-b fat'. + zic's new '-l -' and '-p -' options uninstall any existing localtime and posixrules files, respectively. diff --git a/zic.8 b/zic.8 index a431311..8d34368 100644 --- a/zic.8 +++ b/zic.8 @@ -61,15 +61,13 @@ is .BR slim , keep the output files small; this can help check for the bugs and incompatibilities. -Although the default is currently -.BR fat , -this is intended to change in future -.B zic -versions, as software that mishandles the 64-bit data typically +The default is +.BR slim , +as software that mishandles 64-bit data typically mishandles timestamps after the year 2038 anyway. Also see the .B \*-r -option for another way to shrink output size. +option for another way to alter output size. .TP .BI "\*-d " directory Create time conversion information files in the named directory rather than diff --git a/zic.c b/zic.c index c874b04..3aed819 100644 --- a/zic.c +++ b/zic.c @@ -661,8 +661,7 @@ static const char * tzdefault; static const char * yitcommand; /* -1 if the TZif output file should be slim, 0 if default, 1 if the - output should be fat for backward compatibility. Currently the - default is fat, although this may change. */ + output should be fat for backward compatibility. The default is slim. */ static int bloat; static bool @@ -672,7 +671,7 @@ want_bloat(void) } #ifndef ZIC_BLOAT_DEFAULT -# define ZIC_BLOAT_DEFAULT "fat" +# define ZIC_BLOAT_DEFAULT "slim" #endif int -- 2.17.1

1 0

Sudan/Khartoum time zone
by Ubay Abdelgadir June 21, 2020

June 21, 2020

Dears at IANA, Khartoum's time zone is +2 since 1/Nov/2017. I think it is wrong in the IANA database: 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 BR Ubay Abdelgadir

3 2

Formal models and the need for storing original source data
by Michael Kenniston June 21, 2020

June 21, 2020

> > ---------- Forwarded message ---------- > From: Robert Elz <kre(a)munnari.oz.au> > To: Lester Caine <lester(a)lsces.uk> > Cc: tz(a)iana.org > Bcc: > Date: Wed, 03 Jun 2020 19:31:43 +0700 > Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ > database? > Date: Wed, 3 Jun 2020 12:22:32 +0100 > From: Lester Caine <lester(a)lsces.uk> > Message-ID: <3576438c-e0bd-7188-2153-43d80e9054b8(a)lsces.uk> > > There are two kinds of > changes that may be made to a zone. One affects only future timestamps, > and is the common old garden variety "government interference" or however > you think of it. These are far and away the most common changes. While > when we have insufficient notification of a change, it may be applied > retrospectively, when that has happened, everyone tends to be very aware > that there were bad time conversions for a while. In any case, old > historic stored data isn't affected at all by this kind of change, it > is as valid (or not) after the change as it was before. > You can also have data recorded in the past which refers to the future, so even a change that affects only future timestamps can still invalidate existing stored data. > The second kind of change is a correction to historic data. This happens > when > we discover an error in what was present (and these days, almost only ever > affects pre-1970 timestamps). > > In those, if someone had stored the UTC converted form of some local > timestamp, > then after the correction they wouldn't get back the data that was > originally > used to produce it. > > The problem there is having discarded the original data instead of > retaining > it. Always retain the original source data. Then by all means, when > computing, convert timestamps from their various local values to UTC so > they can be more easily correctly ordered (or whatever) but use those > converted values only for transient computations. Store the original. > Always. > > If that is done correctly, then after a correction to old data, the > results might be different than they were before - but that's only because > they were wrong before, and (hopefully) better after the fix. > I agree 100%. I've been struggling for years to really get my head wrapped around this stuff, and finally decided to create a formal model using abstract data types. I'm finding that approach to be quite helpful, so I wrote it up in a couple of essays that folks on this list might find interesting. In fact, the folks on this list may well be the *only* people who would find them interesting. :-) The first is aimed at the general programmer, but it introduces the fundamental concepts: https://drive.google.com/file/d/1WntAyhIawYtbL2k3fPE71cM9EFkVCJGQ/view?usp=… The second is aimed at time geeks and goes much deeper into the underlying theory: https://drive.google.com/file/d/1aOj9YeDFUST0lQFXZiUsCSmxjnzlbIe4/view?usp=… These are still in draft form, but I hope others find some value in them. (Teaser: the model makes no reference to years, days, hours, or seconds. How's that for abstract?) What is rather interesting (and reassuring) is that the formal model ends up telling us pretty much what this thread has been saying: store original data. However, by looking at things in terms of abstract data types, you can easily see *why* you need to do that without having to resort to specific examples, and many seemingly unrelated cases can be seen to be special cases of the same underlying phenomenon. The model also points you to the very specific places in your design and code where you have to watch out for problems. > The only time it makes sense to store timestamps in other than the original > form is when we *know* that the conversion is correct (and hence, no later > correction will change it). For users of tzdata that really only applies > to post-1970 timestamps. > When exactly do we *know* anything, I mean really for sure? Imagine yourself back in 1966. UTC has been chugging along nicely for five years, providing a well-behaved predictable time standard. We know it's never going to change. Now it's 1967. Oops, the name just changed. Well, that doesn't really count, a rose by any other name ... Now it's 1972. Oops again, we just added a leap second, and there are more on the way. Sorry unix time_t, your fundamental assumption was just revoked -- and so for the next 50 years, nearly every computer on the planet will stubbornly refuse to accept the existence of leap seconds. Never say never. > ---------- Forwarded message ---------- > From: Robert Elz <kre(a)munnari.oz.au> > To: Lester Caine <lester(a)lsces.uk> > Cc: tz(a)iana.org > Bcc: > Date: Wed, 03 Jun 2020 23:48:42 +0700 > Subject: Re: [tz] How good is pre-1970 time zone history represented in TZ > database? > Date: Wed, 3 Jun 2020 16:02:45 +0100 > From: Lester Caine <lester(a)lsces.uk> > Message-ID: <3b7f0c78-4dd7-0f2e-a8e3-2b24401e7e1c(a)lsces.uk> > > | I came into this 20 years ago > > I've been involved with it for longer than that - back to my first > unix experience, in '76, where the US tz rules were compiled into the > code, and most people in AU simply adjusted their computer's clock > (their offset from UTC) 4 times a year (when the US switched summer time > on and off, and when AU did - and yes, that meant that the generated GMT > timestamps were wrong, most of the time). From that (a bit later) I was > responsible for the mess that existed until ado invented tzdata (and yes, > I mean the 2nd arg to gettimeofday()). > You make me look like a newbie. I first got into this seriously in 1997 while updating legacy systems to handle Y2K. > >From all of this I have learned that time is hard. Really hard. > > Many people believe that since they learned to tell the time when > they were 4 or 5 years old, and have been doing it ever since, they > know all there is to know. That's sad... > See the discussion of seduction and polar bears in the first essay linked above. > | now while working with a data archive > | which has now been simply dumped because we had no idea what rules were > | used to produce the normalised data. > > That's a pity, byt sometimes past mistakes simply come back to bite, > and sometimes bite hard. Note that the error there was normalising the > data, if that hadn't been done, none of the rest of it would matter, > you'd now have the original data and could manipulate it however seems > best, for now, regardless of what anyone did with it decades ago (and if > you get it all wrong, future generations could cope, because they'd also > still have the original data, and can fix any errors). > > | Nowadays yes it does make sense to > | store both an original time and a normalised time, > > No, it doesn't, just the original, plus ... > > | along with a location, > > yes, something which can be mapped into a timezone - and as accurate > a location as possible. > > | and a record of which version of rules was used to do the > | normalization. > > Don't care about that, since the result won't be being saved. > > | Add to that a flag that indicates if the UTC time is fixed! > > If the UTC time is the authoritative one, that is what is stored. > No need for extra flags. Just the authoritative time - the one > which defines whatever it is that is being recorded. > I second everything Robert Elz said here. - Michael Kenniston

3 2

[PROPOSED 1/2] zic has new ‘-l -’ and ‘-p -’ options
by Paul Eggert June 13, 2020

June 13, 2020

* NEWS, zic.8: Mention this. * zic.c (dolink): If fromfield is "-", simply remove tofield. --- NEWS | 3 +++ zic.8 | 12 ++++++++++++ zic.c | 5 ++++- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 3bcddd0..cdcdbc1 100644 --- a/NEWS +++ b/NEWS @@ -23,6 +23,9 @@ Unreleased, experimental changes Changes to code + zic's new '-l -' and '-p -' options uninstall any existing + localtime and posixrules files, respectively. + The undocumented and ineffective tzsetwall function has been removed. diff --git a/zic.8 b/zic.8 index b1bf437..a431311 100644 --- a/zic.8 +++ b/zic.8 @@ -85,6 +85,12 @@ will act as if the input contained a link line of the form .ti +.5i .ta \w'Link\0\0'u +\w'\fItimezone\fP\0\0'u Link \fItimezone\fP localtime +.sp +If +.I timezone +is +.BR \*- , +any already-existing link is removed. .TP .BI "\*-L " leapsecondfilename Read leap second information from the file with the given name. @@ -109,6 +115,12 @@ and it should not be combined with if .IR timezone 's transitions are at standard time or Universal Time (UT) instead of local time. +.sp +If +.I timezone +is +.BR \*- , +any already-existing link is removed. .TP .BR "\*-r " "[\fB@\fP\fIlo\fP][\fB/@\fP\fIhi\fP]" Reduce the size of output files by limiting their applicability diff --git a/zic.c b/zic.c index 2875b55..c874b04 100644 --- a/zic.c +++ b/zic.c @@ -981,6 +981,7 @@ hardlinkerr(char const *from, char const *to) static void dolink(char const *fromfield, char const *tofield, bool staysymlink) { + bool remove_only = strcmp(fromfield, "-") == 0; bool todirs_made = false; int link_errno; @@ -988,7 +989,7 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) ** We get to be careful here since ** there's a fair chance of root running us. */ - if (itsdir(fromfield)) { + if (!remove_only && itsdir(fromfield)) { fprintf(stderr, _("%s: link from %s/%s failed: %s\n"), progname, directory, fromfield, strerror(EPERM)); exit(EXIT_FAILURE); @@ -1003,6 +1004,8 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) progname, directory, tofield, e); exit(EXIT_FAILURE); } + if (remove_only) + return; link_errno = staysymlink ? ENOTSUP : hardlinkerr(fromfield, tofield); if (link_errno == ENOENT && !todirs_made) { mkdirs(tofield, true); -- 2.17.1

1 1

Re: [tz] URLs for DST changes in Hungary (full historical revision)
by Paul Eggert June 9, 2020

June 9, 2020

On 6/9/20 8:16 AM, Nyáry Géza wrote: > Year to year I enclose the URLs being about the changes, I trimmed away the view part of each URL (to keep the URL short) and installed the attached patch to the tzdb sources so that the transitions for Hungary are now much better documented. Thank you for sending us this detailed info.

1 0

How good is pre-1970 time zone history represented in TZ database?
by Alois Treindl June 4, 2020

June 4, 2020

4 10

Re: [tz] FW: [Ext] The TZ Coordination
by Paul Eggert May 28, 2020

May 28, 2020

On 5/28/20 3:41 AM, EL MAAYATI Afaf wrote: > we need to know if there is a procedure to notify IANA (TZ Coordination) officially, from a governmental source, with the official dates of TZ changes in Morocco. The procedure is to send email to tz(a)iana.org with official citations, preferably with pointers to copies in English since the mailing list is in English. For best results, give one years' notice before the dates of change. For more details, please see: https://data.iana.org/time-zones/tz-link.html#changes

1 0

zdump --version reports "unknown" on OpenSuse 15.1 [2020a]
by listclient＠hayo.de May 28, 2020

May 28, 2020

Hi all, when checking the timezone database version on my OpenSuse 15.1 Linux, I do not get the expected result. hayo@computer:~> sudo zdump --version zdump (tzcode) unknown Installed package: timezone - Time Zone Descriptions Is this a defect of the OpenSuse package or of the IANA code distribution? Regards, Hayo More Details ------------ Technical data: Installierte Version 2020a-lp151.2.9.1 Mo 18 Mai 2020 10:13:45 CEST Sa 23 Mai 2020 20:03:30 CEST System/Base BSD-3-Clause AND SUSE-Public-Domain 1,1 MiB 0 B openSUSE Leap 15.1 openSUSE http://bugs.opensuse.org x86_64 http://www.iana.org/time-zones timezone-2020a-lp151.2.9.1 0 File list: /etc/localtime /usr/bin/tzselect /usr/sbin/zdump /usr/sbin/zic /usr/share/zoneinfo ... Change log: Fr 24 Apr 2020 14:00:00 CEST Marketa Calabkova <mcalabkova(a)suse.com> - timezone update 2020a (bsc#1169582) * Morocco springs forward on 2020-05-31, not 2020-05-24. * Canada's Yukon advanced to -07 year-round on 2020-03-08. * America/Nuuk renamed from America/Godthab. * zic now supports expiration dates for leap second lists.

8 11

Re: [tz] Fwd: TR: Morocco : Time Change
by Semlali Naoufal May 27, 2020

May 27, 2020

Hello, I would like to inform you that the time has been advanced by one hour today on Android Smartphones while the time change should not be made until 31.05.2020 as already reported. Has the patch below been deployed correctly? For iPhone, the time is not changed. Regards, -----Message d'origine----- De : Paul Eggert <eggert(a)cs.ucla.edu> Envoyé : mercredi 15 avril 2020 06:26 À : Semlali Naoufal <N.Semlali(a)iam.ma>; Tim Parenti <tim(a)timtimeonline.com> Cc : Maamar Abdelkader <A.MAAMAR(a)iam.ma>; Time zone mailing list <tz(a)iana.org> Objet : Re: Morocco : Time Change Thanks for the heads-up. A proposed patch is attached. Looks like we'll need a new tzdb release soon, since the current release is wrong for Morocco starting May 24. ________________________________ [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 . ________________________________ 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 .

5 4

Typo in a 1900 date of europe tz file
by josep lladonosa capell May 27, 2020

May 27, 2020

Hello, I was just reading the europe tz file and found a typo. The comment in the file gives the date 26/6/1900 but in fact it was July (7) not June (6). In the same text there is a reference to the official document of 26/7/1900. Attached you will find the patch.

1 0

Re: [tz] Welcome to the "tz" mailing list
by Sundar Sarma May 25, 2020

May 25, 2020

we have used this code to get the IANA tz version. public static String getTimezoneDatabaseIANAVersion() { File readmeFile = new File(ZONEINFO_PATH, "README"); File alternativeReadmeFile = new File(ZONEINFO_PATH, "README.txt"); if (!readmeFile.exists()) { readmeFile = alternativeReadmeFile; } out read me.txt file contain generated by Gradle Based on http://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz means we are using correct tzdata2020a. But still why there is issue? Something wrong with tz db?? regards, sundar On Fri, May 22, 2020 at 9:12 PM Sundar Sarma <gkssarma59(a)gmail.com> wrote: > ZoneRulesProvider.getVersions( String zoneId ). > which gives the version used by Java. > > this above code gives the version used by java. > > that is correct. Bu the above code is java.time > > we are using joda.time in our application. > > So could you please tell me that how to get the version used by java in > joda time?? > > thanks, > sundar > > On Thu, May 21, 2020 at 6:39 PM Michael H Deckers < > michael.h.deckers(a)googlemail.com> wrote: > >> >> On 2020-05-21 12:39, Sundar Sarma wrote: >> >> >> > Still i did not understand why this test case is failing with new 2020a >> tz. >> >> >> The version of the IANA database installed in the operating >> system may well differ from the version used by Java.time. >> The latter can be determined with the method >> ZoneRulesProvider.getVersions( String zoneId ). >> which gives the version used by Java. >> >> HTH. >> >> Michael Deckers. >> >> >> >>

3 4

Re: [tz] Welcome to the "tz" mailing list
by Michael H Deckers May 23, 2020

May 23, 2020

On 2020-05-22 15:42, Sundar Sarma wrote: > So could you please tell me that how to get the version used by java in > joda time?? Joda time uses their own time zone data. I do not think you can ask for the version (but I have not looked into Joda time in ages). You can, however, list the data that Joda time keeps for a time zone by repeatedly calling the method DateTimeZone.nextTransition(instant). HTH Michael Deckers.

1 0

Re: [tz] Welcome to the "tz" mailing list
by Sundar Sarma May 21, 2020

May 21, 2020

Hello team, According to the latest 2020a tz update: Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. We have written a test cases like below for canada yukon timezone. We imported new 2020a tz into our environment. Our code seems correct but test cases are failing. So we found that there is wrong in Iana tz side. Please check and correct us. This is the below code we have written. @Test public void doesNotFallBackToMinus8InDawsonNovember2020() { DateTimeZone timezone = DateTimeZone.forID("America/Dawson"); Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)-------> on 2nd nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)------> on 1 st nov 00:00:00 .withLaterOffsetAtOverlap() .toInstant(); long dayAfterOffset = timezone.getOffset(dayAfter.getMillis()); int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset); long offsetOnDay = timezone.getOffset(day.getMillis()); int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay); assertEquals(hoursOnDay, dayAfterHours); -------> here we are getting error: java.lang.AssertionError: expected:<-7> but was:<-8> } The above test case according to your update (will not fall back on 2020-11-01) is correct. But test case is failing. Could you please clarify us that is there anything wrong from IANA tz. If not how can i write my test case according to that? Regards, Sundar On Wed, May 20, 2020 at 3:51 PM <tz-request(a)iana.org> wrote: > Welcome to the tz(a)iana.org mailing list! > > > --- > > NOTE WELL > > Any submission to the IETF intended by the Contributor for publication > as all or part of an IETF Internet-Draft or RFC and any statement made > within the context of an IETF activity is considered an "IETF > Contribution". Such statements include oral statements in IETF > sessions, as well as written and electronic communications made at any > time or place, which are addressed to: > > * The IETF plenary session * The IESG, or any member thereof on behalf > of the IESG * Any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list functioning > under IETF auspices * Any IETF working group or portion thereof * Any > Birds of a Feather (BOF) session * The IAB or any member thereof on > behalf of the IAB * The RFC Editor or the Internet-Drafts function * > All IETF Contributions are subject to the rules of RFC 5378 and RFC > 3979 (updated by RFC 4879). > > Statements made outside of an IETF session, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not IETF Contributions in the context > of this notice. > > Please consult RFC 5378 and RFC 3979 for details. > > A participant in any IETF activity is deemed to accept all IETF rules > of process, as documented in Best Current Practices RFCs and IESG > Statements. > > A participant in any IETF activity acknowledges that written, audio > and video records of meetings may be made and may be available to the > public. > > --- > > To post to this list, send your email to: > > tz(a)iana.org > > General information about the mailing list is at: > > https://mm.icann.org/mailman/listinfo/tz > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > https://mm.icann.org/mailman/options/tz/gkssarma59%40gmail.com > > You can also make such adjustments via email by sending a message to: > > tz-request(a)iana.org > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe. It is: > > Gks59@smu > > Normally, Mailman will remind you of your iana.org mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. >

5 10

Proper (stable) way to list installed time zones?
by Paul Ganssle May 15, 2020

May 15, 2020

As part of the implementation of IANA time zone support in the Python standard library (which is now accepted <https://www.python.org/dev/peps/pep-0615/> for inclusion in Python 3.9 — many thanks to those who commented on the original proposal), I realized that likely a common feature request is to get the list of time zones installed in the system. I have a candidate implementation <https://github.com/pganssle/zoneinfo/pull/60> for this, which basically walks each potential install directory (there's a "time zone search path" equivalent to PATH) and populates a list of every file installed there which starts with the `TZif` magic string. The problem I'm running into is that tzcode installs `posix/` and `right/` folders, so for each entry in zoneinfo, I get three entries: "Africa/Abidjan", "posix/Africa/Abidjan" and "right/Africa/Abidjan". I'm also seeing a `posixrules` zone in the zoneinfo root. My questions are: 1. Is there a better source for the list of installed time zones (leaving aside `tzdata.zi`, which I don't think I can count on to exist in all environments). 2. Is there any stable and standard way to distinguish between proper zones and other things that are also zone files like posixrules and right/ and posix/? In my own redistribution of the data, I populate a list of zones from `make zonenames`, which I note does /not/ include posix/, right/ or posixrules, but I don't think that information is included in standard distributions of zoneinfo. The closest I can find is `zone1970.tab` and `zone.tab` (which I think is not even always included), and that appears to be only a subset of the output of `make zonenames`. Thanks, Paul

4 5

suggestion: split "backward" into "backward" and "deprecated"
by Andrew Gierth May 6, 2020

May 6, 2020

In a post on this list on Nov 24 last, Garret Wollman said regarding FreeBSD's c.1994 change (now reversed) to not install "backward": >> I chose not to install the "backward" zones in the hope that this >> would more securely deprecate the then-recently-obsoleted old-style >> names like "US/Eastern", and then maybe they could be completely >> removed from the distribution if other downstream consumers (only a >> few operating systems at that point, no language runtimes) would do >> likewise. >> Unfortunately, these ancient compatibility links never got deleted, >> so "backward" now contains a mix of ancient and more recent >> compatibility links, and users are still using them (or being told >> to use them by documentation that should have been updated decades >> ago). The obvious way to resolve this would be to split "backward" into two: one file containing aliases that were once regarded as canonical names (or at least names consistent with current naming theory) but were then renamed (e.g. the recent example of Godthab -> Nuuk), the other containing all the ancient stuff that never conformed to the current style (such as "W-SU", "Poland", "GB-Eire", "US/Eastern" etc.). One way to do this might be to set a cutoff date, for which the 2000a data release seems like a good choice, and retain only the zones changed since then in "backward", moving the remainder to a new "deprecated" category. Another way would be to reserve "backward" for zones that have appeared in zone.tab at any time, and move the rest to "deprecated". It turns out that these two methods give almost exactly the same results, with only two exceptions: America/Ensenada was in "backward" before 2000 going by the SCM history, but existed in zone.tab until 2010; and Asia/Ulan_Bator was added to "backward" and removed from zone.tab in the 2000a release. This suggests that the zone.tab criterion is a slightly better one. (One further exception should be made: the link from Etc/UTC to UTC is in widespread use and should probably be moved to "etcetera" alongside the similar "GMT" link. Otherwise it should stay in "backward". This change already exists in FreeBSD, where all "GMT" defaults have been changed to "UTC" at some point.) Split this way, the list of links in "backward" would become (posted in plain text here for readability, I can submit in patch form if needed) as follows: Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu Link America/Argentina/Catamarca America/Argentina/ComodRivadavia Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba Link America/Tijuana America/Ensenada Link America/Nuuk America/Godthab Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Kentucky/Louisville America/Louisville Link America/Argentina/Mendoza America/Mendoza Link America/Toronto America/Montreal Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Tijuana America/Santa_Isabel Link America/Denver America/Shiprock Link Pacific/Auckland Antarctica/South_Pole Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Shanghai Asia/Chongqing Link Asia/Shanghai Asia/Chungking Link Asia/Dhaka Asia/Dacca Link Asia/Shanghai Asia/Harbin Link Asia/Urumqi Asia/Kashgar Link Asia/Kathmandu Asia/Katmandu Link Asia/Macau Asia/Macao Link Asia/Yangon Asia/Rangoon Link Asia/Ho_Chi_Minh Asia/Saigon Link Asia/Thimphu Asia/Thimbu Link Asia/Makassar Asia/Ujung_Pandang Link Asia/Ulaanbaatar Asia/Ulan_Bator Link Atlantic/Faroe Atlantic/Faeroe Link Europe/Oslo Atlantic/Jan_Mayen Link Etc/UTC Etc/UCT Link Europe/London Europe/Belfast Link Europe/Chisinau Europe/Tiraspol Link Pacific/Honolulu Pacific/Johnston Link Pacific/Pohnpei Pacific/Ponape Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap Link Etc/UTC UTC "deprecated" would contain these links: Link America/Adak America/Atka Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Knox America/Knox_IN Link America/Port_of_Spain America/Virgin Link Asia/Jerusalem Asia/Tel_Aviv Link Australia/Sydney Australia/ACT Link Australia/Sydney Australia/Canberra Link Australia/Lord_Howe Australia/LHI Link Australia/Sydney Australia/NSW Link Australia/Darwin Australia/North Link Australia/Brisbane Australia/Queensland Link Australia/Adelaide Australia/South Link Australia/Hobart Australia/Tasmania Link Australia/Melbourne Australia/Victoria Link Australia/Perth Australia/West Link Australia/Broken_Hill Australia/Yancowinna Link America/Rio_Branco Brazil/Acre Link America/Noronha Brazil/DeNoronha Link America/Sao_Paulo Brazil/East Link America/Manaus Brazil/West Link America/Halifax Canada/Atlantic Link America/Winnipeg Canada/Central Link America/Toronto Canada/Eastern Link America/Edmonton Canada/Mountain Link America/St_Johns Canada/Newfoundland Link America/Vancouver Canada/Pacific Link America/Regina Canada/Saskatchewan Link America/Whitehorse Canada/Yukon Link America/Santiago Chile/Continental Link Pacific/Easter Chile/EasterIsland Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 Link Etc/GMT GMT-0 Link Etc/GMT GMT0 Link Etc/GMT Greenwich Link Asia/Hong_Kong Hongkong Link Atlantic/Reykjavik Iceland Link Asia/Tehran Iran Link Asia/Jerusalem Israel Link America/Jamaica Jamaica Link Asia/Tokyo Japan Link Pacific/Kwajalein Kwajalein Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/Mazatlan Mexico/BajaSur Link America/Mexico_City Mexico/General Link Pacific/Auckland NZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Pago_Pago Pacific/Samoa Link Europe/Warsaw Poland Link Europe/Lisbon Portugal Link Asia/Taipei ROC Link Asia/Seoul ROK Link Asia/Singapore Singapore Link Europe/Istanbul Turkey Link Etc/UTC UCT Link America/Anchorage US/Alaska Link America/Adak US/Aleutian Link America/Phoenix US/Arizona Link America/Chicago US/Central Link America/Indiana/Indianapolis US/East-Indiana Link America/New_York US/Eastern Link Pacific/Honolulu US/Hawaii Link America/Indiana/Knox US/Indiana-Starke Link America/Detroit US/Michigan Link America/Denver US/Mountain Link America/Los_Angeles US/Pacific Link Pacific/Pago_Pago US/Samoa Link Etc/UTC Universal Link Europe/Moscow W-SU Link Etc/UTC Zulu -- Andrew.

10 21

Database available in other formats
by Sergio Bonfiglio May 3, 2020

May 3, 2020

Dear Sirs, First thig first a big THANK YOU for your invaluable work. I was overwhelmed by the complexity of your database, because it requires also external pieces of code to be safely read. I was wondering if does exist the database in different formats that may be larger but more readable and easy usable. An SQL database could be really "for everyone", because can be queried by everything from everywhere by any language. If I may make a humble suggestion, a JD date in floating format that equips any record with the initial and final date of the rule/event could be of great help. With a single query, one could recall all the records that pertain a certain moment in time also with different and overlapping rules. Thanks for any reply and thank for your work that is making me sweat the classical " seven shirts". Stay well Sergio Bonfiglio ITALY

2 6

Re: [tz] tz Digest, Vol 104, Issue 1
by Reece Stewart May 1, 2020

May 1, 2020

Stop sending me should your fucken dogs On Fri., 1 May 2020, 10:00 pm , <tz-request(a)iana.org> wrote: > 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. Database available in other formats (Sergio Bonfiglio) > 2. Re: Database available in other formats (Paul Eggert) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Apr 2020 17:12:55 +0200 > From: Sergio Bonfiglio <bonfiglio.sergio(a)gmail.com> > To: tz(a)iana.org > Subject: [tz] Database available in other formats > Message-ID: > < > CANCwfxiVBnHPUawqZxWEKU+W89PWxL0SNRUXAMLgX1iMTMUF7Q(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Sirs, > > First thig first a big THANK YOU for your invaluable work. > I was overwhelmed by the complexity of your database, because it requires > also external pieces of code to be safely read. > I was wondering if does exist the database in different formats that may be > larger but more readable and easy usable. > An SQL database could be really "for everyone", because can be queried by > everything from everywhere by any language. > If I may make a humble suggestion, a JD date in floating format that equips > any record with the initial and final date of the rule/event could be of > great help. > With a single query, one could recall all the records that pertain a > certain moment in time also with different and overlapping rules. > Thanks for any reply and thank for your work that is making me sweat the > classical " seven shirts". > Stay well > > Sergio Bonfiglio > ITALY >

1 0

[PROPOSED] More Ruthenia replacement
by Paul Eggert May 1, 2020

May 1, 2020

This follows up on an earlier patch in March, which replaced “Ruthenia” with “Transcarpathia” but missed a couple of instances. * europe: Ruthenia→Transcarpathia in commentary here, too. * theory.html: Switch to Europe/Prague as a more easily-understood example. --- europe | 2 +- theory.html | 10 ++++------ 2 files changed, 5 insertions(+), 7 deletions(-) diff --git a/europe b/europe index 5593c60..91949d6 100644 --- a/europe +++ b/europe @@ -3983,7 +3983,7 @@ Zone Europe/Kiev 2:02:04 - LMT 1880 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 E-Eur EE%sT 1995 2:00 EU EE%sT -# Ruthenia used CET 1990/1991. +# Transcarpathia used CET 1990/1991. # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but # "Uzhgorod" is more common in English. Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct diff --git a/theory.html b/theory.html index c0e6f02..ffa3b4d 100644 --- a/theory.html +++ b/theory.html @@ -115,17 +115,15 @@ Each timezone has a name that uniquely identifies the timezone. Inexperienced users are not expected to select these names unaided. Distributors should provide documentation and/or a simple selection interface that explains each name via a map or via descriptive text like -"Ruthenia" instead of the timezone name "<code>Europe/Uzhgorod</code>". +"Czech Republic" instead of the timezone name "<code>Europe/Prague</code>". If geolocation information is available, a selection interface can locate the user on a timezone map or prioritize names that are geographically close. For an example selection interface, see the <code>tzselect</code> program in the <code><abbr>tz</abbr></code> code. -The <a href="http://cldr.unicode.org/">Unicode Common Locale Data +The <a href="http://cldr.unicode.org">Unicode Common Locale Data Repository</a> contains data that may be useful for other selection -interfaces; it maps timezone names like <code>Europe/Uzhgorod</code> -to CLDR names like <code>uauzh</code> which are in turn mapped to -locale-dependent strings like "Uzhhorod", "Ungvár", "Ужгород", and -"乌日哥罗德". +interfaces; it maps timezone names like <code>Europe/Prague</code> to +locale-dependent strings like "Prague", "Praha", "Прага", and "布拉格". </p> <p> -- 2.17.1

1 0

[PROPOSED] Remove tzsetwall
by Paul Eggert April 24, 2020

April 24, 2020

Might as well do this now, while it’s fresh in my mind. * Makefile, NEWS: Update accordingly. * localtime.c (tzset_unlocked, tzsetlcl): Merge, since there’s now only one caller to either. * localtime.c, private.h (tzsetwall): Remove. --- Makefile | 3 +-- NEWS | 8 ++++++++ localtime.c | 20 ++------------------ private.h | 5 ----- 4 files changed, 11 insertions(+), 25 deletions(-) diff --git a/Makefile b/Makefile index 610bf19..107f67e 100644 --- a/Makefile +++ b/Makefile @@ -333,9 +333,8 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ # add # -DSTD_INSPIRED # to the end of the "CFLAGS=" line. This arranges for the functions -# "tzsetwall", "offtime", "timelocal", "timegm", "timeoff", +# "offtime", "timelocal", "timegm", "timeoff", # "posix2time", and "time2posix" to be added to the time conversion library. -# "tzsetwall" is deprecated and is intended to be removed soon; see NEWS. # "offtime" is like "gmtime" except that it accepts a second (long) argument # that gives an offset to add to the time_t when converting it. # "timelocal" is equivalent to "mktime". diff --git a/NEWS b/NEWS index 321e090..ac491e1 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,13 @@ News for the tz database +Unreleased, experimental changes + + Changes to code + + The undocumented and ineffective tzsetwall function has been + removed. + + Release 2020a - 2020-04-23 16:03:47 -0700 Briefly: diff --git a/localtime.c b/localtime.c index 6623eac..d3e406b 100644 --- a/localtime.c +++ b/localtime.c @@ -1355,8 +1355,9 @@ zoneinit(struct state *sp, char const *name) } static void -tzsetlcl(char const *name) +tzset_unlocked(void) { + char const *name = getenv("TZ"); struct state *sp = lclptr; int lcl = name ? strlen(name) < sizeof lcl_TZname : -1; if (lcl < 0 @@ -1377,23 +1378,6 @@ tzsetlcl(char const *name) lcl_is_set = lcl; } -#ifdef STD_INSPIRED -void -tzsetwall(void) -{ - if (lock() != 0) - return; - tzsetlcl(NULL); - unlock(); -} -#endif - -static void -tzset_unlocked(void) -{ - tzsetlcl(getenv("TZ")); -} - void tzset(void) { diff --git a/private.h b/private.h index 8513663..9efcd78 100644 --- a/private.h +++ b/private.h @@ -477,8 +477,6 @@ typedef time_tz tz_time_t; # define tzfree tz_tzfree # undef tzset # define tzset tz_tzset -# undef tzsetwall -# define tzsetwall tz_tzsetwall # if HAVE_STRFTIME_L # undef strftime_l # define strftime_l tz_strftime_l @@ -551,9 +549,6 @@ extern long altzone; */ #ifdef STD_INSPIRED -# if TZ_TIME_T || !defined tzsetwall -void tzsetwall(void); -# endif # if TZ_TIME_T || !defined offtime struct tm *offtime(time_t const *, long); # endif -- 2.17.1

1 0

Re: [tz] [Bug 207345] zdump(8): zdump -c has an opposite behavior, in my xterm: lower bound is inclusive ...
by Paul Eggert April 24, 2020

April 24, 2020

I installed the attached doc patch to tzdb try to clarify things. The documented zdump behavior is kind of weird, but now's not the time to change it as we're about to do a new tzdb release.

2 1

Moroccan DST 2020 Change
by Ali ABDUL HAKEEM (Presta) April 24, 2020

April 24, 2020

Hello, Please note that the Moroccan government decided to activate DST between April 19th at 3am and may 31st at 2am. Hoping that you'll update the tzdata database soon. Regards, Ali Abdul Hakeem, OCM | IT Consultant | Tél: +212 520 475 306 Eurafric-Information | Département Système et bases de données [O_Database12c_Admin_Master_clr][OCM_ODb11gAdmin_clr][OCM_ODb10gAdmin_clr][OCP_MySQL5][RHCSA] [O_Certified Specialist_clr][CertWS_sm] [CertPowerSystems_sm]

2 3

'Australia/Canberra' time zone?
by John Pye April 24, 2020

April 24, 2020

Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-a… Cheers JP

8 19

[tz-announce] 2020a release of tz code and data available
by Paul Eggert April 24, 2020

April 24, 2020

The 2020a 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: Morocco springs forward on 2020-05-31, not 2020-05-24. Canada's Yukon advanced to -07 year-round on 2020-03-08. America/Nuuk renamed from America/Godthab. zic now supports expiration dates for leap second lists. Changes to future timestamps Morocco's second spring-forward transition in 2020 will be May 31, not May 24 as predicted earlier. (Thanks to Semlali Naoufal.) Adjust future-year predictions to use the first Sunday after the day after Ramadan, not the first Sunday after Ramadan. Canada's Yukon, represented by America/Whitehorse and America/Dawson, advanced to -07 year-round, beginning with its spring-forward transition on 2020-03-08, and will not fall back on 2020-11-01. Although a government press release calls this "permanent Pacific Daylight Saving Time", we prefer MST for consistency with nearby Dawson Creek, Creston, and Fort Nelson. (Thanks to Tim Parenti.) Changes to past timestamps Shanghai observed DST in 1919. (Thanks to Phake Nick.) Changes to timezone identifiers To reflect current usage in English better, America/Godthab has been renamed to America/Nuuk. A backwards-compatibility link remains for the old name. Changes to code localtime.c no longer mishandles timestamps after the last transition in a TZif file with leap seconds and with daylight saving time transitions projected into the indefinite future. For example, with TZ='America/Los_Angeles' with leap seconds, zdump formerly reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. zic -L now supports an Expires line in the leapseconds file, and truncates the TZif output accordingly. This propagates leap second expiration information into the TZif file, and avoids the abovementioned localtime.c bug as well as similar bugs present in many client implementations. If no Expires line is present, zic -L instead truncates the TZif output based on the #expires comment present in leapseconds files distributed by tzdb 2018f and later; however, this usage is obsolescent. For now, the distributed leapseconds file has an Expires line that is commented out, so that the file can be fed to older versions of zic which ignore the commented-out line. Future tzdb distributions are planned to contain a leapseconds file with an Expires line. The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the feature, zero otherwise. The configuration macro ALTZONE now has the same values with the same meaning as HAVE_TZNAME and USG_COMPAT. The code's defense against CRLF in leap-seconds.list is now portable to POSIX awk. (Problem reported by Deborah Goldsmith.) Although the undocumented tzsetwall function is not changed in this release, it is now deprecated in preparation for removal in future releases. Due to POSIX requirements, tzsetwall has not worked for some time. Any code that uses it should instead use tzalloc(NULL) or, if portability trumps thread-safety, should unset the TZ environment variable. Changes to commentary The Îles-de-la-Madeleine and the Listuguj reserve are noted as following America/Halifax, and comments about Yukon's "south" and "north" have been corrected to say "east" and "west". (Thanks to Jeffery Nichols.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2020a.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 7aec41a1d9b57c581af086db5de5bf99b165c405 dated 2020-04-23 16:03:47 -0700 and tagged '2020a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 5235d6590e844491df32375857f5f36ba0046f2d21a078375188dff79b125cf9b69136a0a431624de1ecfa9d53b62a232f0e6ee0b734294cec62b670e6265cb2 tzcode2020a.tar.gz 2a2fc2e3ad8a6e4c574242296c847ad582c2c1d86add9c556e65c812d19b9528522e3c4dddb5239017091825d2acc5a2ccaf21dc41b900b6c300ef4264cc5a9d tzdata2020a.tar.gz 6ef3ed39ee379adce421e7964ce9cf3d36361e2ba29de78e43b36d524c5722fd151c11ac60c952130d2623ecea9d8b56b4652f394e60a893a76d2ad769072d9d tzdb-2020a.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9IACgkQ7ZfpDmKq fjQK6BAAgxpJVrK35eNuGheX51np4f7mOAomDzMqXSaYZqYLW2EZCa+JW6VWfrEm eMZYVA/U33WsIGTjyyjfmq5FVwIQj0An+mAtlOR5dd34/ikGddZjd28ChrMW9+56 VFS7dA2pUjMzQp7yGG5sVek5OeGaHajfwxzBptPrsK+JwyNC1RcGetEcrgUwwznX S1iiLFvfzgVhrqnYzthIuoUikLSUkNumkr4/8frsYwywQ0axAzpkLi5rWxOfZAi6 a1MLMXvKmzXeiNCu5oeKl2XfTymBUVyF7K3dzFdkrOto8pSTDR+BbSh88mbe7tct Rt0q/GRq8fityECzdVAzoAqCRUU97t8V4VHNFXSxy32CN99cjsLdRMiVVEGTq+TT A3m9FjQidSCP3apzQe9JDfj536gQFSkUmDlcFwya31zolRoWkIFmxIhmZWIYlm9T Wjqc7y7UnrBNvyDE4pemQ4YYHjk5YLjwoaUIafDJTAiDRfcf53SRlr3tbFcYjAt/ Tql77DWuLmg8PGFtRiyCMqrehboGi0Eu3he2MmYtsJB2ZXFN0yZQmlvDen9fkt1k EqUkKjhHmVBb5WVS5pbl8mGLr1TFtnnedmLw4xULrDzsyJ5tsqzVnkl6Ga/eoIal lLIxpXrYqQLdHNtTpdmJkqZ/89++HDov9JR0uMzU8LxFwH6duQ4= =0y/R -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9MACgkQ7ZfpDmKq fjTb6g/+P/l6Nev5Zv8mUktnT6eNKohtgpNRyHd8nYV92wmTiDSzAArFy7oi5CVV /jMv8sbV1ssq/5rQ6HUQuMDPgEIO405gxmqRWMhE6UwUbRxxa+/HKGUJH0AHY6Dh 1UhVD7QA6fDovs84ip/WgTEZYcYApLr2A3IfC0rDqDo42DiSnErFQDvqRMJQkQS1 p2Pv7YtW/2NZ52wkfq75klSsjlXzlz6CzM5P3/YU/Hylj42sQdbdtbUAyQug3YpD QQ2PiZoP92iiGrcwkKXa5xvXJ6jEZCXqi7HbJKt8OW+XpZ/ZYbTZRq+JvMbTqkOL +XvVufo/pVASgv2V0ynzJu/XRiFUeJaecmEg6QiAiJ74UMTXSGFnK//R32M9dp29 B4p2X2jmW9qjCwjbjQXl1Yl5ddlSyvBk2Lk4s1repQ2t7kphZx2C8P2WyQYGeP7H nZDucfmWK4OSh8cINexBE8xyagmv1T8mC4qEQbVPva6JysaodNBcf9WkKMCgituP tbPsVekSmG1GyN2ixPtpY86Fzjr60mEg1UKqHZIagRmH4kjUwd1gINCJgONaZZxo c1VfBD8ZORBZfG27+V5ISotKrK2UrKtcrSUEU1CC/ibOm1sSPfg0d5uxUVvg4E8+ okdszbMnQ1i0eVKW+L+jY5XOO8kmSLp4YcnrqXDyZabxyWIGMt4= =7U2J -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAl6iH9QACgkQ7ZfpDmKq fjTDQQ//S8WK8/aBHCKOiNvNFL82SHsrwSzsMt/5AyWzTUgkZZdhuhPmCu/qim0M J6Gm+1XUPaq6WKQnHbNk4wrmKjlRX/R1DWIA+2FhVH0iFSAX+qrnc/KUkm0hVXg4 u8aylAUOQvdhDfVX4PafCx21Kf1sk46oleRgi5lr3cSPAIKGsiEQKGR5EMbt/8mt 55zpxYGTj4o8yjY4NqEOBD8SHts0BO0xFq2eh6C71KeTeHKm/SasIFbvhIZug2cO YQyAnBiybfsSwIPXfYZr9ux81BztdzkzS6n1EBgGrHmk/+xrpBbmaknjFDMu+Nln qOPnTQCmp3NBXOYeVnxMAgIy07yEcAR7ReV0FuJFaxrkGYstfV6k5ylhk1iuHnIZ dOPSJa4eD+cIPWJTo0AsOkNx8+xJ6DkP8iudCpGUrEmXFSoMuFr8b5QwOxsRF/eC oIIRVO35gF12xr424DVKE72Z8yELoDGXzfWh8UbY/j0Lasq6RXqF9mrCMrugxlwx 1GofM2zrIkzkgLfMoV5zJfKrPiLPj213uGmrctJNcSggtSEA0DBvSvuhVe8hzolZ /taWc+/gCPBv159s3qedQyQbfHY0/IIkePdezwn4f7DQvh7MTOteE81AwJvqtkmQ fhSp+hz9k5m4CKuY9+71p+Srefc0i8PsBpmVCDYUn6PFqXaXsiA= =dCQ0 -----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

Deprecating tzsetwall
by Paul Eggert April 22, 2020

April 22, 2020

In reviewing the tzdb web pages for bad links and suchlike, I noticed that they're still talking about UNIX SVR2 (superseded since 1988) and tzsetwall. So I looked into tzcode's implementation of tzsetwall, and noticed that it does nothing useful because functions like localtime now call tzset (as POSIX has require for many years), thus undoing tzsetwall's effect. Since nobody evidently cares whether tzsetwall works, we should remove it. Not right away of course, but we can document it as deprecated now without changing the implementation, and remove it in a future tzcode release. So I installed the attached patch to do that. Comments welcome as usual.

4 4

[PATCH] * tz-link.html: Update URLs.
by Paul Eggert April 22, 2020

April 22, 2020

--- tz-link.html | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 90cc9bd..1f893f6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -82,11 +82,12 @@ 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="https://mariadb.org">MariaDB</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 title="Web Operating System">webOS</abbr></a>, -<a href="https://ibm.com/aix"><abbr +<a href="https://en.wikipedia.org/wiki/IBM_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 @@ -168,7 +169,8 @@ then <samp>za</samp> through <samp>zz</samp>, then <samp>zza</samp> through <samp>zzz</samp>, and so on). Since version 2016h, each release has contained a text file named "<samp>version</samp>" whose first (and currently only) line is the version. -The releases are also available in an +Older releases are <a href="https://ftp.iana.org/tz/releases/">archived</a>, +and are also available in an <a href="ftp://ftp.iana.org/tz/releases/"><abbr title="File Transfer Protocol">FTP</abbr> directory</a> via a less-secure protocol.</p> @@ -827,10 +829,10 @@ zones and daylight saving time</a>.</dd> Chile's official time (in Spanish)</a>.</dd> <dt>China</dt> <dd>The Hong Kong Observatory maintains a -<a href="https://www.hko.gov.hk/gts/time/Summertime.htm">history of +<a href="https://www.hko.gov.hk/en/gts/time/Summertime.htm">history of summer time in Hong Kong</a>, and Macau's Meteorological and Geophysical Bureau maintains a <a -href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm">similar +href="https://www.smg.gov.mo/en/subpage/224/page/174">similar history for Macau</a>. Unfortunately the latter is incomplete and has errors.</dd> <dt>Czech Republic</dt> @@ -866,7 +868,7 @@ href="https://www.dia.govt.nz/Daylight-Saving-History">History of Daylight Saving</a>.</dd> <dt>Singapore</dt> <dd><a id="Singapore" -href="http://www.math.nus.edu.sg/~mathelmr/teaching/timezone.html">Why +href="https://web.archive.org/web/20190822231045/http://www.math.nus.edu.sg/~math…">Why is Singapore in the "Wrong" Time Zone?</a> details the history of legal time in Singapore and Malaysia.</dd> <dt>United Kingdom</dt> @@ -881,7 +883,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.gub.uy/sohma/index.php/servicios/datos-astronomicos" hreflang="es">almanac +href="http://sohma.armada.mil.uy/index.php/servicios/datos-astronomicos" hreflang="es">almanac (in Spanish)</a>.</dd> </dl> </section> -- 2.17.1

1 0

Re: [tz] Errors in man pages, here: tzfile(5): Typo?
by Paul Eggert April 21, 2020

April 21, 2020

On 4/20/20 10:52 PM, Michael Kerrisk (man-pages) wrote: > --- a/man5/tzfile.5 > +++ b/man5/tzfile.5 > @@ -41,6 +41,7 @@ in order: > .TP > .I tzh_ttisgmtcnt > The number of UT/local indicators stored in the file. > +(UT is Universal Time.) Thanks. I looked for similar problems elsewhere and found one in zic.8, so I installed the attached patch. This should appear in the next tzdb release, which is due soon.

2 2

Data for China timezones in backzone
by Phake Nick April 15, 2020

April 15, 2020

First of all, for some reason there is a Vietnamese timezone which got sandwiched between time zone of China in the backzone file, I think that should be reordered for better clarity Second, the historical timezone data for those China zones seems to be incorrect. The transition to GMT+8 date given there for these zones were 1980 which also contradict the file description that they do not disagree with normal zone after 1970. According to sources that have also been cited in the asia file, except Xinjiang and Tibet, they should have adopted the Beijing Time from around 1949/1950 depends on exactly when each of those cities were taken over by the communist army. And they should also follow the DST setting of Asia/Shanghai after that point of time. In addition, http://gaz.ncl.edu.tw/detail.jsp?sysid=E1091792 the document from Chongqing Nationalist government say in year 1945 all of China should adopt summer time due to the war (not sure whether it continued after WWII ends)(Probably only enforced in area under their rule at the time?) The Asia/Harbin's 1932 and 1940 entry should also be incorrect. As per sources recorded at https://wiki.suikawiki.org/n/%E6%BA%80%E5%B7%9E%E5%9B%BD%E3%81%AE%E6%A8%99%… , in 1932 Harbin should have adopted UTC+8:00 instead of data currently listed in the tz database according to official announcement from Manchuko. And they should have adopted GMT+9 in 1937 January 1st according to official announcement at the time being cited on the webpage.

2 1

Asia/Shanghai timezone history and other information
by Phake Nick April 15, 2020

April 15, 2020

1. According to This news report: http://news.sina.com.cn/c/2004-09-01/19524201403.shtml , on April 11, 1919, newspaper in Shanghai said clocks in Shanghai will spring forward for an hour starting from midnight of that Saturday. The report did not mention what happened in Shanghai thereafter, but it mentioned that a similar trial in Tianjin which ended at October 1st as citizens are told to recede the clock on September 30 from 12:00pm to 11:00pm. The trial at Tianjin got terminated in 1920. 2. For the history of time in Shanghai between 1940-1942, the situation is actually slightly more complex than the table included in the tz database now. At the time, there were three different authorities in Shanghai, including Shanghai International Settlement, a settlement established by western countries with its own westernized form of government, Shanghai French Concession, similar to the international settlement but is controlled by French, and then the rest of the city of Shanghai, which have already been controlled by Japanese force through a puppet local government (Wang Jingwei regime) It was additionally complicated by the circumstances that, according to the 1940s Shanghai summer time essay cited in the database, some departments/businesses/people in the Shanghai city itself during that time period, refused to change their clock and instead only changed their opening hours. For example, as quoted in the article, in 1940, other than the authority itself, power, tram, bus companies, cinema, department stores, and other public service organizations have all decided to follow the summer time and spring forward the clock. On the other hand, the custom office refused to spring forward the clock because of worry on mechanical wear to the physical clock, postal office refused to spring forward because of disruption to business and log-keeping, although they did changed their office hour to match rest of the city. So is travel agents, and also weather observatory. It is said both time standards had their own supporters in the city at the time, those who prefer new time standard would have moved their clock while those who prefer the old time standard would keep their clock unchange, and there were different clocks that use different time standard in the city at the time for people who use different time standard to adjust their clock to their preferred time. 2.a. For the 1940 May 31 spring forward, the essay claim that it was coordinared between the international settlement authority and the French concession authority and have gathered support from Hong Kong and Xiamen, that it would spring forward an hour from May 31 "midnight", and the essay claim "Hong Kong government implemented the spring forward in the same time on the same date as Shanghai". 2.b. For the 1940 fall back, it was said that they initially intended to do so on September 30 00:59 at night, however they postponed it to October 12 after discussion with relevant parties. However schools restored to the original schedule ten days earlier. 2.c. For the 1941 spring forward, it is said to start from March 15 "following the previous year's method", and in addition to that the essay cited an announcement in 1941 from the Wang regime which said the Special City of Shanghai under Wang regime control will follow the DST rule set by the Settlements, irrespective of the original DST plan announced by the Wang regime for other area under its control(April 1 to September 30). (no idea to situation before that announcement) 2.d. For the 1941 fall back, it was said that the fall back would occurs at the end of September (A newspaper headline cited by the essay, published on October 1, 1941, have the headlines which said "French Concession would rewind to the old clock this morning), but it ultimately didn't happen due to disagreement between the international settlement authority and the French concession authority, and the fall back ultimately occurred on November 1. 2.e. In 1941 December, Japan have officially started war with the United States and the United Kingdom, and in Shanghai they have marched into the international settlement, taken over its control 2.f. For the 1942 spring forward, the essay said that the spring forward started on January 31. It said this time the custom office and postal department will also change their clocks, unlike before. 2.g. The essay itself didn't cover any specific changes thereafter until the end of the war, it quoted a November 1942 command from the government of the Wang regime, which claim the daylight saving time applies year round during the war. However, the essay ambiguously said the period is "February 1 to September 30", which I don't really understand what is the meaning of such period in the context of year round implementation here.. More researches might be needed to show exactly what happened during that period of time. 3. According to a Japanese tour bus pamphlet in Nanjing area believed to be from around year 1941: http://www.tt-museum.jp/tairiku_0280_nan1941.html , the schedule listed was in the format of Japanese time. Which indicate some use of the Japanese time (instead of syncing by DST) might have occurred in the Yangtze river delta area during that period of time although the scope of such use will need to be investigated to determine. ---- Other information: i. The HKO link reference link in Asia/HongKong have already become inaccessible probably due to site update. The link can now be accessed from https://www.hko.gov.hk/en/gts/time/Summertime.htm

2 1

Morocco : Time Change
by Semlali Naoufal April 15, 2020

April 15, 2020

Hello, Following the announcement by the Moroccan government, the switch to GMT time will take place on Sunday, April 19, 2020 from 3 a.m. and the return to GMT+ 1 time will take place on Sunday, May 31, 2020 at 2 a.m. and not Sunday May 24, 2020 as described at the TMZ base. To this end, thank you for updating the TMZ database to take this change into account. Attached the official decision of the government. https://maroc-diplomatique.net/maroc-le-retour-a-lheure-gmt-est-prevu-diman… http://aujourdhui.ma/actualite/gmt1-retour-a-lheure-normale-dimanche-procha… Best Regards, De : Tim Parenti <tim(a)timtimeonline.com<mailto:tim@timtimeonline.com>> Envoyé : lundi 30 septembre 2019 17:05 À : Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> Cc : Paul Eggert <eggert(a)cs.ucla.edu<mailto:eggert@cs.ucla.edu>>; Maamar Abdelkader <A.MAAMAR(a)iam.ma<mailto:A.MAAMAR@iam.ma>>; Time zone mailing list <tz(a)iana.org<mailto:tz@iana.org>> Objet : Re: [tz] Morocco Time must stay at GMT+1 We updated Morocco with year-round UTC+1 (except during Ramadan) about a year ago in these commits: https://github.com/eggert/tz/commit/80de44ca0f2349c0f42f12caa943ced8685c3b67 https://github.com/eggert/tz/commit/8539a448ebc8897e40d62f16dc4d0ada3f07b3ca If there are still errors in tz for Morocco in 2018g or later, please let us know. Otherwise, it sounds like you need to update your time zone definitions with a more recent version. -- Tim Parenti On Mon, 30 Sep 2019 at 11:40, Naoufal Semlali <N.Semlali(a)iam.ma<mailto:N.Semlali@iam.ma>> wrote: 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<mailto:eggert@cs.ucla.edu>> 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? 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 <http://www.iam.ma> .

2 2

Morocco Ramadan 2020
by Milamber April 14, 2020

April 14, 2020

Hello, The Government of Kingdom of Morocco have publish the changes of time for next Ramadan month (2020) [1] : Google Translation: The Ministry of Economy, Finance and Administration Reform - Department of Administration Reform - announces that on the holy month of Ramadan, the Kingdom of Morocco will return to legal time of the Kingdom (GMT) by delaying the time by 60 minutes and this on Sunday April 19 at 03:00 am In accordance with article II of the decree n ° 2.18.855 (October 26, 2018) relating to the legal time of the Kingdom, and to the decision of the Head of Government No. 3.25.20 (published on April 13, 2020) concerning the legal time. The Kingdom of Morocco will return to the schedule (GMT +1) by adding sixty (60) minutes to legal time on Sunday, May 31, 2020 at 2:00 a.m. Actually, the tzdata show (Debian 10) tzdata 2019c-0+deb10u1 : # zdump -v /usr/share/zoneinfo/Africa/Casablanca | grep 2020 /usr/share/zoneinfo/Africa/Casablanca Sun Apr 19 01:59:59 2020 UT = Sun Apr 19 02:59:59 2020 +01 isdst=0 gmtoff=3600 /usr/share/zoneinfo/Africa/Casablanca Sun Apr 19 02:00:00 2020 UT = Sun Apr 19 02:00:00 2020 +00 isdst=1 gmtoff=0 /usr/share/zoneinfo/Africa/Casablanca Sun May 24 01:59:59 2020 UT = Sun May 24 01:59:59 2020 +00 isdst=1 gmtoff=0 /usr/share/zoneinfo/Africa/Casablanca Sun May 24 02:00:00 2020 UT = Sun May 24 03:00:00 2020 +01 isdst=0 gmtoff=3600 thanks for update. Regards, Milamber * [1] https://www.mmsp.gov.ma/fr/actualites.aspx?id=1940

1 0

DST in Morocco
by Magnus Fromreide April 14, 2020

April 14, 2020

Hello. It seems as if Morocco have decided that Ramadan ends on 2020-05-31, not 2020-05-24 which is what was previously assumed. Source (in arabic): http://www.sgg.gov.ma/Portals/1/BO/2020/B.O_6873_Ar.pdf?ver=2020-04-14-1321… Especially page 2082 (page 4 of the document) /MF

1 0

DB incoherence
by Américo Mendes April 7, 2020

April 7, 2020

Hi, Was trying to use your DB and I found what I think it's a data incoherence... When you list the rules, i suppose that they must be in chronological order, I'm assuming that* (X) rule start date always smaller than (X+1) rule start date*, for instance: R Q 1967 o - Ap 8 0 1 D R Q 1967 1968 - S Su>=8 0 0 S R Q 1968 o - Ap 14 0 1 D R Q 1969 1977 - Ap lastSu 0 1 D R Q 1969 1971 - O lastSu 0 0 S R Q 1972 1974 - O 8 0 0 S R Q 1975 1977 - O lastSu 0 0 S I fund in the Haiti rules the following section: R HT 1983 o - May 8 0 1 D R HT 1984 1987 - Ap lastSu 0 1 D R HT 1983 1987 - O lastSu 0 0 S According to my assumption, to keep DB coherence, we should have, in 2nd position something like: R HT 1983 o - O lastSu 0 0 S Am I right or is it some particularity that I didn't understand? Best Regards. Américo Mendes <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Sem vírus. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

3 2

Most of Mexico to spring forward tomorrow, as scheduled
by Paul Eggert April 4, 2020

April 4, 2020

Although most of Mexico is scheduled to spring forward tomorrow at 02:00, earlier this week Claudia Reyes Montiel, representing the caucus of the Mexican Party of the Democratic Revolution (PRD), asked Mexican president Andrés Manuel López Obrador (AMLO) to cancel or suspend DST in the light of the COVID-19 pandemic. AMLO has punted on this for now, saying that he first wants a technical opinion from the Ministry of Energy. One never knows with AMLO though, and it might be good to keep an eye out for sudden changes to Mexico's civil-time rules. My source: Horario de Verano 2020: Diputados del PRD le piden a AMLO eliminar el cambio. La Verdad. 2020-04-02. https://laverdadnoticias.com/politica/Horario-de-Verano-2020-Diputados-del-…

2 1

TZ Data Base Questions
by Dustin J. Dirth April 2, 2020

April 2, 2020

Hello, A group of developers including myself has been charged with dealing with time zones in our database. We have been looking into using the IANA TZ Database as our source. In order to create utilities to get historical data correctly, and to future proof our code as much as possible, there were a couple of questions we have been trying to find the answers to. * If an entity breaks off from a current time zone, does the data base fork the current time zone(A) and add a new time zone(B) with time zone B having all the historical data of A? * In the INANA time zone database, the file "europe" contains information for Time Zone Europe/Dublin. There are three lines that are proceeded with the comment "# These three lines are for when SAVE values are always nonnegative." These lines are also preceded by comment Delimiter (Please see below). Since the data follows the Comment Delimiter it is ignored on load. Is database supposed to load this information? What is the purpose of these comments? # These three lines are for when SAVE values are always nonnegative. # 1:00 - IST 1971 Oct 31 2:00u # 0:00 GB-Eire GMT/IST 1996 # 0:00 EU GMT/IST

5 6

Israel DST -- Stay Tuned
by Ephraim Silverberg March 23, 2020

March 23, 2020

Due to the current Corona Lockdown of the State of Israel that is expected to get more strict, the government is considering delaying the start of DST that was supposed to start this Friday morning: https://www.jpost.com/Breaking-News/Litzman-Health-Ministry-considering-pos… No final decision has been taken though so, meanwhile, the original switchover time is still in effect. I will try to update if and when changes take place.

5 6

FYI (no action necessary): Utah permanent DST
by Dave DeLong March 23, 2020

March 23, 2020

Hi all, This is a heads up that in the last legislative session, Utah passed a bill that would move the state on to permanent Mountain Daylight Time (bill: https://le.utah.gov/~2020/bills/static/SB0059.html <https://le.utah.gov/~2020/bills/static/SB0059.html>). However, this bill does not take effect until two conditions are met: Congress enacts legislation to amend 15 U.S.C. Sec. 260a to authorize states to observe daylight saving time year-round and At least four western states (not including Utah) also move to year-round daylight time (western states are defined as Arizona, California, Colorado, Idaho, Montana, Nevada, New Mexico, Oregon, Utah, Washington, and Wyoming) If this ends up getting actually triggered (one can hope!) then I will email the list again with the notice. Cheers, Dave DeLong

2 1

Israel DST -- Stay Tuned
by Eytan Schulman March 23, 2020

March 23, 2020

Israeli media has reported and confirmed that DST will not be postponed. "After announcing last night that daylight saving time will be delayed to prevent an extra hour of evening daylight and encourage people to stay home, Interior Minister Aryeh Deri says the move won’t be possible after all." "Deri’s office says in a statement that the National Security Council has advised against making the postponement, and that daylight saving time will begin as planned later this week, during the night between March 26 and March 27." https://www.timesofisrael.com/liveblog_entry/daylight-saving-time-wont-be-d…

1 0

Daylight saving in Israel likely postponed
by Kurt Alfred Kluever March 22, 2020

March 22, 2020

https://www.jpost.com/Breaking-News/Litzman-Health-Ministry-considering-pos… https://www.timesofisrael.com/liveblog_entry/attorney-general-okays-potenti… Neither of these articles seem to constitute an official announcement, but this situation should be monitored closely, as it would be a very last minute change. Cheers, -- kak

1 0

zdump with version 1 files
by Paul Ganssle March 22, 2020

March 22, 2020

Howdy, As part of the implementation of the new zoneinfo module for the Python standard library, I have been attempting to generate some version 1 files for test purposes (in the sadly likely event that some people only have version 1 TZif files deployed). I have done this by taking existing TZif files, truncating them at the second TZif header, and changing the version number in the truncated file. I notice, however, that with the 2019c version of zdump, the files generated this way are considered invalid: $ zdump --version zdump (tzcode) 2019c $ zdump -i -c2038,2039 $(realpath .)/America/Los_Angeles /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument $ zdump -i -c2010,2011 $(realpath .)/America/Los_Angeles /tmp/zoneinfon3c1bcna/v1/America/Los_Angeles: Invalid argument Interestingly, if I /do not/ truncate the file and just change the version to "1" (in both the first *and* second header), it will read the file /and/ it will clearly use the version 2/3 data: $ file Australia/Sydney Australia/Sydney: timezone data, version 1, no gmt time flags, 5 std time flags, no leap seconds, 142 transition times, 5 abbreviation chars $ zdump -i -c2200,2201 $(realpath .)/Australia/Sydney TZ="/tmp/zoneinfot3h5_eyf/v1/Australia/Sydney" - - +11 AEDT 1 2200-04-06 02 +10 AEST 2200-10-05 03 +11 AEDT 1 So I guess my question is: does zdump support well-formed version 1 files, and I am failing to create well-formed version 1 files, or does 2019c's zdump have no support for version 1 files? I'll note that this whole thing came up because I was wondering what zdump does for times after the last transition in a version 1 file. RFC 8536 indicates that this behavior is undefined - I was planning to hold the value of the offset after the last transition, but I figured I might as well check what zdump does. Thanks, Paul

5 10

Re: [tz] zdump with version 1 files
by Hal Murray March 21, 2020

March 21, 2020

eggert(a)cs.ucla.edu said: > As far as I can recall, only Android limits itself to 32-bit timestamps > (expiring in 2039) among current operating systems, even the 32-bit OSes. I assume you mean time_t when you say "timestamps". 32 bit Debian, Raspberian, and FreeBSD/Intel have 32 bit time_t. 32 bit FreeBSD/ARM has a 64 bit time_t 32 bit Fedora had it too, but they dropped support for i386. I haven't tried their 32 bit ARM version. -- These are my opinions. I hate spam.

2 1

[PATCH] Fix warning message with non-alphanumerics
by Paul Ganssle March 21, 2020

March 21, 2020

Hi folks, I have noticed a minor issue with the warning issued by zdump when passed non-alphanumerics in a TZ string. If the TZ string, in quoted or unquoted form, contains a non-alphanumeric within the first 3 characters, the message erroneously says that the abbreviation has fewer than 3 characters: $ zdump '<AE)ST>5' <AE)ST>5 Fri Mar 20 09:11:05 2020 AE_ST zdump: warning: zone "<AE)ST>5" abbreviation "AE_ST" has fewer than 3 characters $ zdump '<AES)T>5' <AES)T>5 Fri Mar 20 09:11:09 2020 AES_T zdump: warning: zone "<AES)T>5" abbreviation "AES_T" has characters other than ASCII alphanumerics, '-' or '+' $ zdump 'AE)ST5' AE)ST5 Fri Mar 20 09:09:41 2020 AE_ST zdump: warning: zone "AE)ST5" abbreviation "AE_ST" has fewer than 3 characters $ zdump 'AES)T5' AES)T5 Fri Mar 20 09:09:51 2020 AES_T zdump: warning: zone "AES)T5" abbreviation "AES_T" has characters other than ASCII alphanumerics, '-' or '+' I've attached a patch that I believe fixes this issue, as evidenced by this check run in my local directory: $ ./zdump "<AT>5" <AT>5 Fri Mar 20 09:35:09 2020 AT ./zdump: warning: zone "<AT>5" abbreviation "AT" has fewer than 3 characters $ ./zdump "<AE)ST>5" <AE)ST>5 Fri Mar 20 09:35:24 2020 AE_ST ./zdump: warning: zone "<AE)ST>5" abbreviation "AE_ST" has characters other than ASCII alphanumerics, '-' or '+' Thanks! Paul P.S. git send-email didn't work for me because I haven't set up git to send e-mails directly, so hopefully attaching the .patch file manually is OK.

2 1

Maryland permanent DST?
by Arthur David Olson March 18, 2020

March 18, 2020

"Maryland could spring forward permanently with Daylight Saving Time bill." https://wtop.com/maryland/2020/03/maryland-could-spring-forward-permanently… State Senate action is set for tomorrow; stay tuned. @dashdashado

3 8

Yukon to move to year-round PDT
by Tim Parenti March 10, 2020

March 10, 2020

The government of Yukon announced today the cessation of seasonal time changes. "After clocks are pushed ahead one hour on March 8, the territory will remain on 'Pacific Daylight Saving Time'. ... [The government] found 93 per cent of respondents wanted to end seasonal time changes and, of that group, 70 per cent wanted 'permanent Pacific Daylight Saving Time.'" https://www.cbc.ca/news/canada/north/yukon-end-daylight-saving-time-1.54863… Government press release: https://yukon.ca/en/news/yukon-end-seasonal-time-change Interestingly, in the report <https://yukon.ca/sites/yukon.ca/files/engage/engage-eco-seasonal-time-chang…> released with today's action, 57% of respondents said that "maintain[ing] time relationships with other jurisdictions" was either very or somewhat important, while only 26% said it was not very or not at all important. Perhaps this might be better treated as "MST", like Arizona, as that is more similar to Saskatchewan's existing use of CST. However, since the press release expresses a preference for "PDT", attached is a proposed patch which calls it that, implemented as UTC-08 +1 hour DST year-round. Since this change doesn't affect timestamps until 2020-11-01, we have a bit of time to determine the preferred representation and/or wait for the relevant legal wording before this necessitates a new release. -- Tim Parenti

10 23

Update Ukrainian Timezones Names
by bebyx March 10, 2020

March 10, 2020

Hi, maintainers of tz, This file was requested by [eggert](https://github.com/eggert/tz/pull/26#issuecomment-595995177). I hope you apply this patch, cause those fantasy names you have on the project now are a real confusion for Ukrainians who are probably 99% of users of Ukrainian timezones. My initial comment: Default timezone names for Ukraine, e.g. Europe/Kiev, are more understandable and correct than ridiculous fantasy style, e.g. Ruthenia. Previous names cause confusion, misunderstanding and are considered inappropriate. Proofs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198822, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=47468, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244644. Thanks!

4 7

Manitoba Canada not observing DST
by Marketa Calabkova March 5, 2020

March 5, 2020

There was a new law that was passed this year in Canada that Manitoba will not observe DST change, instead remaining in Central Standard Time. Reference link : https://web2.gov.mb.ca/bills/41-4/b205e.php Our customer is requesting the fix before the March 8th when DST begins. The bug has been reported today. Could you please fix it or point me to the existing fix? Thanks a lot! Cheers, Marketa

3 3

Support for the IANA database in the Python standard library
by Paul Ganssle Feb. 26, 2020

Feb. 26, 2020

Hey folks, Just thought I'd draw your attention to my recent proposal to add IANA (e.g. /usr/share/zoneinfo) time zone support to Python's standard library: PEP 615 ( https://www.python.org/dev/peps/pep-0615/ ). I sent out the proposal today, discussion is happening on the Python discourse: https://discuss.python.org/t/3468 There is a reference implementation for the proposed module here (in Python): https://github.com/pganssle/zoneinfo Any feedback on the proposal would be very welcome -- as many of you can imagine, it can sometimes be hard to get too much feedback on time zone and datetime-related proposals because a great many people (probably rightly so) are just happy that someone /else/ is thinking about it so they don't have to. The discourse is the canonical location for the discussion, so commenting there would be best, but beggars can't be choosers, so I'll happily pass on comments made on this list or sent to me personally. Thanks! Paul

5 9

Time Zone Database: Update of DST settings for Morocco based on actual announcement by local government
by De Feo, Gary Feb. 25, 2020

Feb. 25, 2020

Dear all, We are currently realizing a project in Morocco where we would need to consider the local DST definition which is not fixed but, according to information provided by our customer, defined each year by the local government on a rather short term basis. Is your organization reflecting these short term definitions in your database? Thank you very much for your support. With best regards, Gary De Feo Siemens AG Smart Infrastructure Digital Grid Project Management SI DG GC D PM Humboldtstr. 59 90459 Nuernberg, Germany Tel.: +49 911 433-7385 Fax: +49 911 433-7896 Mobile: +49 151 54444318 mailto:gary.de_feo@siemens.com www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife> [cid:image001.gif@01D5EBB5.F2B9F9E0] Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

2 1

Do Yukoners care about DST more than cannabis?
by Paul Eggert Feb. 20, 2020

Feb. 20, 2020

The Yukon government recently surveyed its citizens for their opinion whether Yukon should stay on PST all year, stay on MST all year, or continue the current practice of PST in winter and PDT in summer. The survey closed Sunday, and the government says it got more than 4800 responses, which is a new record. The previous mark of nearly 3200 responses was set by Yukon's 2017 survey on legalization of marijuana. See: Croft D. Spring forward, fall back survey sets Yukon record. CBC News. 2020-02-19. https://www.cbc.ca/news/canada/north/yukon-seasonal-time-change-survey-reco…

1 0

Change to TZ
by Max Kachur Feb. 19, 2020

Feb. 19, 2020

Hi. My name is Max. I want to suggest you new correction to timezone name. Old name is "Europe/Kiev", new one is "Europe/Kyiv". This name was officially changed recently. Here is more details. Thank you for attention!

3 2

More on EU/UK/Brexit clock changes
by Chris Woodbury Feb. 15, 2020

Feb. 15, 2020

The "Time Lords" subcommittee has released yet another study. Find it at: https://publications.parliament.uk/pa/ld5801/ldselect/ldeucom/15/15.pdf Article on Yahoo News: https://www.yahoo.com/news/eu-clock-changes-uk-implications-164042321.html

5 5

leap smear redux
by scs+ls＠eskimo.com Feb. 12, 2020

Feb. 12, 2020

[crossposted to three lists -- beware if replying] For your amusement: https://xkcd.com/2266/ (I think Randall Munroe is a closet time nut.)

2 1

XKCD of the day
by Guy Harris Feb. 11, 2020

Feb. 11, 2020

https://xkcd.com/2266/

2 1

Re: [tz] tzdb data for North and Central America
by Paul Eggert Feb. 6, 2020

Feb. 6, 2020

Thanks for your email. I installed the attached, which adds it as comment to the western Ontario zones.

1 0

tzdb data for North and Central America
by Jeffery Nichols Jan. 24, 2020

Jan. 24, 2020

Hello. You might want to note that the America/Halifax timezone also applies to Îles-de-la-Madeleine and the Listuguj reserve in Quebec. Officially, this came into effect on January 1, 2007 (*Legal Time Act*, CQLR c T-5.1), but the legislative debates surrounding that bill say that it is "accommodating the customs and practices" of those regions, which suggests that they have always been in-line with Halifax. Also, you call America/Whitehorse "south Yukon" and America/Dawson "north Yukon", but the divide is actually between east and west, at the 138th meridian. -- *Jeffery Nichols*, JD, MPA, MA

8 11

Leap year bugs
by Matt Johnson-Pint Jan. 24, 2020

Jan. 24, 2020

Hello Time People! Apologies in advance, as I know this is a bit off-topic being not about time zones, but I know that many of you are invested in date and time programming, and I'd appreciate some peer discussion. I've been invested in the last many months on preventative measures against leap year bugs, both in my day job at Microsoft and in the public space. Some of my recent posts: https://stackoverflow.com/questions/57530882/what-are-some-examples-of-leap… https://codeofmatt.com/on-the-life-cycle-of-a-leap-year-bug/ And from last leap year: https://codeofmatt.com/list-of-2016-leap-day-bugs/ https://azure.microsoft.com/en-us/blog/is-your-code-ready-for-the-leap-year/ Sometimes I feel like I'm overreacting, but then I remember the infamous 2012 Azure cloud leap day outage, and all the many other things across the industry that were impacted in 2016 (see my list above). My question for the community is this: Why are Y2K and Y2038 bugs such a hot topic when they are/were one-time events, but yet leap year bugs are rarely discussed even though they are recurring and can have critical impact? People seem to remember 20 years ago, but not 4 or 8 years back. Why? Are any of you working on leap year related issues? Have you checked your date math for leap year bugs? If not, why? Thanks, Matt

5 10

Re: [tz] Leap year bugs
by Hal Murray Jan. 24, 2020

Jan. 24, 2020

> [really hassles of being born on the leap day!] Many years ago, I got a "Congratulations for 10 years service" type certificate from a large corporation. It was dated Feb 29th. -- These are my opinions. I hate spam.

1 0

[PATCH] Cite Frumer on pre-1873 Japan timekeeping
by Paul Eggert Jan. 19, 2020

Jan. 19, 2020

* asia: Add a comment on timekeeping in Japan from the 7th to the 19th century. --- asia | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/asia b/asia index 590c05b..11a1726 100644 --- a/asia +++ b/asia @@ -1828,6 +1828,16 @@ Zone Asia/Jerusalem 2:20:54 - LMT 1880 # '9:00' and 'JST' is from Guy Harris. +# From Paul Eggert (2020-01-19): +# Starting in the 7th century, Japan generally followed an ancient Chinese +# timekeeping system that divided night and day into six hours each, +# with hour length depending on season. In 1873 the government +# started requiring the use of a Western style 24-hour clock. See: +# Yulia Frumer, "Making Time: Astronomical Time Measurement in Tokugawa Japan" +# <https://www.worldcat.org/oclc/1043907065>. As the tzdb code and +# data support only 24-hour clocks, its tables model timestamps before +# 1873 using Western-style local mean time. + # From Hideyuki Suzuki (1998-11-09): # 'Tokyo' usually stands for the former location of Tokyo Astronomical # Observatory: 139° 44' 40.90" E (9h 18m 58.727s), 35° 39' 16.0" N. -- 2.24.1

1 0

New leapseconds.awk doesn't work on macOS
by Chris Woodbury Jan. 17, 2020

Jan. 17, 2020

"leapseconds.awk" no longer has a CRLF problem per se. That is, just as long as we don't do something silly like printing strings with CRs in them (which we used to do but don't do now). At the time I reported the CRLF problem on 2019-07-27 at 05:47:10 UTC, leapseconds.awk was still using the comments as data to print the date of the zic "leap" directives it generates. (https://mm.icann.org/pipermail/tz/2019-July/028382.html) We don't do that anymore. The actual NTP timestamp datum is now being used to create the necessary date string thanks to Dr. Eggert's implementation of Dennis C. Ferguson's sstamp_to_ymdhMs() AWK function. (https://mm.icann.org/pipermail/tz/2019-September/028495.html) The two remaining string variables we use with CRs in them, the update and expiry NTP timestamps, are processed arithmetically before their values are printed. This eliminates the CRs as an issue with them. I still think it would be a good idea to use int() or strtonum() when they are read because the CRs *are* there. There are no leading zeroes to preserve (which was the primary objection I heard for not using int()). (https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10…) (Seven thousand nine hundred and eighty years from now...? This is farther in the future than the discovery of agriculture is in the past...) The sub() on $0 is unnecessary (and possibly bad practice). (I could argue on either side of the issue.) $ git diff leapseconds.awk diff --git a/leapseconds.awk b/leapseconds.awk index 924ade9..0e3eb1a 100755 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -71,15 +71,13 @@ BEGIN { sstamp_init() } -# In case the input has CRLF form a la NIST. -{ sub(/\r$/, "") } - /^#[ \t]*[Uu]pdated through/ || /^#[ \t]*[Ff]ile expires on/ { last_lines = last_lines $0 "\n" } -/^#[$][ \t]/ { updated = $2 } -/^#[@][ \t]/ { expires = $2 } +# In case the input has CRLF form a la NIST. +/^#[$][ \t]/ { updated = int( $2 ) } +/^#[@][ \t]/ { expires = int( $2 ) } /^[ \t]*#/ { next }

2 1

[PROPOSED 1/3] Fix leap second bug after last explicit transition
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

The client code mishandled timestamps after the last explicit transition in a TZif file that had both leap seconds and daylight saving time transitions projected into the indefinite future. When interpreting the TZ string embedded at the end of the TZif file, the code neglected to adjust the corresponding DST transitions for leap seconds, which meant the DST transitions were calculated to occur too early. For example, with TZ set to '.../zoneinfo-leaps/America/Los_Angeles', zdump reported a DST transition on 2038-03-14 from 01:59:32.999... to 02:59:33 instead of the correct transition from 01:59:59.999... to 03:00:00. * NEWS: Mention this. * localtime.c (tzloadbody): Apply leap second corrections to transitions derived from the trailing TZ string in a TZif file. (leapcorr) [!STD_INSPIRED]: Define in this case too, since tzloadbody now uses it. --- NEWS | 8 ++++++++ localtime.c | 35 +++++++++++++++++++---------------- 2 files changed, 27 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 961aa08..72e5c04 100644 --- a/NEWS +++ b/NEWS @@ -13,6 +13,14 @@ Unreleased, experimental changes Changes to code + localtime.c no longer mishandles timestamps after the last + transition in a TZif file with leap seconds and with daylight + saving time transitions projected into the indefinite future. + For example, with TZ='America/Los_Angeles' with leap seconds, + zdump formerly reported a DST transition on 2038-03-14 + from 01:59:32.999... to 02:59:33 instead of the correct transition + from 01:59:59.999... to 03:00:00. + The configuration macros HAVE_TZNAME and USG_COMPAT should now be set to 1 if the system library supports the feature, and 2 if not. As before, these macros are nonzero if tzcode should support the diff --git a/localtime.c b/localtime.c index d3f8fc7..6623eac 100644 --- a/localtime.c +++ b/localtime.c @@ -158,6 +158,7 @@ static struct tm *gmtsub(struct state const *, time_t const *, int_fast32_t, struct tm *); static bool increment_overflow(int *, int); static bool increment_overflow_time(time_t *, int_fast32_t); +static int_fast64_t leapcorr(struct state const *, time_t); static bool normalize_overflow32(int_fast32_t *, int *, int); static struct tm *timesub(time_t const *, int_fast32_t, struct state const *, struct tm *); @@ -641,11 +642,13 @@ tzloadbody(char const *name, struct state *sp, bool doextend, for (i = 0; i < ts->timecnt; i++) if (sp->timecnt == 0 - || sp->ats[sp->timecnt - 1] < ts->ats[i]) + || (sp->ats[sp->timecnt - 1] + < ts->ats[i] + leapcorr(sp, ts->ats[i]))) break; while (i < ts->timecnt && sp->timecnt < TZ_MAX_TIMES) { - sp->ats[sp->timecnt] = ts->ats[i]; + sp->ats[sp->timecnt] + = ts->ats[i] + leapcorr(sp, ts->ats[i]); sp->types[sp->timecnt] = (sp->typecnt + ts->types[i]); sp->timecnt++; @@ -2239,20 +2242,6 @@ timeoff(struct tm *tmp, long offset) #endif /* defined STD_INSPIRED */ -/* -** XXX--is the below the right way to conditionalize?? -*/ - -#ifdef STD_INSPIRED - -/* -** IEEE Std 1003.1 (POSIX) says that 536457599 -** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which -** is not the case if we are accounting for leap seconds. -** So, we provide the following conversion routines for use -** when exchanging timestamps with POSIX conforming systems. -*/ - static int_fast64_t leapcorr(struct state const *sp, time_t t) { @@ -2268,6 +2257,20 @@ leapcorr(struct state const *sp, time_t t) return 0; } +/* +** XXX--is the below the right way to conditionalize?? +*/ + +#ifdef STD_INSPIRED + +/* +** IEEE Std 1003.1 (POSIX) says that 536457599 +** shall correspond to "Wed Dec 31 23:59:59 UTC 1986", which +** is not the case if we are accounting for leap seconds. +** So, we provide the following conversion routines for use +** when exchanging timestamps with POSIX conforming systems. +*/ + NETBSD_INSPIRED_EXTERN time_t time2posix_z(struct state *sp, time_t t) { -- 2.24.1

3 7

Y2K quick-fix crick? Y2K20 bitten by 1970 + 50 year wrap
by Brian Inglis Jan. 15, 2020

Jan. 15, 2020

https://www.theregister.co.uk/2020/01/13/y2k_dvla/ https://gothamist.com/news/y2k20-parking-meter-software-glitch-causes-cityw… https://www.freightwaves.com/news/trimble-requests-extension-to-fmcsa-repai… -- 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

Re: [tz] Leap Second Support Interval Field Request - RFC8536
by Paul Eggert Jan. 15, 2020

Jan. 15, 2020

On 12/4/19 1:04 PM, Michael Veth wrote: > The NIST leapsecond bulletin includes an expiration time which serves to > indicate the maximum validity interval for use of UTC time. In order to > safely use UTC timestamps, the user needs to be aware of this maximum > validity time or they could be unknowingly introducing timing errors. > > I was not able to find this field in the TZif (Feb 19) ICD. Would it be > possible to add a field to the TZdb that would represent this expiration > time? The TZif file format does provide for truncated files (see Internet RFC 8536 section 5.1), and one can generate files truncated to the current UTC expiration time (2020-06-28 00:00:00 UTC) with a command like this: zic -r /@1593302427 -L leapseconds tzdata.zi However, it's awkward that one must count the number of seconds since 1970-01-01 00:00:00 UTC (including leap seconds) by hand to get the numeric timestamp (1593302427 in this case) to pass to zic. We could add support to zic to do this sort of thing in a more-natural way. A downside of the abovementioned approach is that it generates a TZif file that omits all DST and time zone transitions after the UTC expiration time. We could change the TZif format to represent UTC expiration time separately from the truncation time. One possibility would be to append a leap-second record with an "occur" value equal to the expiration time and a "corr" value equal to the previous record's "corr" value. Strictly speaking this would violate RFC 8536 section 3.2 "leap-second records" - though I doubt whether many clients would care - and so I suppose we'd need to increment the TZif format version number from 3 to 4. On the other hand, any files generated by this method would continue to be "incorrect" in that they'd continue to predict timestamps past the maximum leap second validity, so perhaps it wouldn't be worth going to all this work to generate "incorrect" files. I'll cc this to tz(a)iana.org and tzdist-bis(a)ietf.org to see whether anybody there cares to comment.

4 6

New leapseconds.awk doesn't work on macOS
by Deborah Goldsmith Jan. 11, 2020

Jan. 11, 2020

Hi, I just noticed that starting with 2019c, leapseconds.awk is producing a damaged leapseconds file on macOS, e.g.: > # All leap-seconds are Stationary (S) at the given UTC time. > # The correction (+ or -) is made at the given time, so in the unlikely > # event of a negative leap second, a line would look like this: > # Leap YEAR MON DAY 23:59:59 - S > # Typical lines look like this: > # Leap YEAR MON DAY 23:59:60 + S > > # POSIX timestamps for the data in this file: > #updated -2208988800 (1900-01-01 00:00:00 UTC) > #expires -2208988800 (1900-01-01 00:00:00 UTC) > It turns out that having a regex in RS is a gawk feature and is not supported in Darwin awk. Commenting out the definition of RS in leapseconds.awk fixed the problem. I don’t know how many customers of TZ will be using versions of awk that don’t support regexes in RS. I don’t know about FreeBSD, OpenBSD, etc. Thanks, Debbie

6 8

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

There is a new NIST leap-seconds.list (thanks to Dr. Judah Levine). diff --git a/leap-seconds.list b/leap-seconds.list index a1bc5a7..529dc4a 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -62,7 +62,7 @@ # Terry Quinn, "The BIPM and the Accurate Measurement # of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, # July, 1991. <http://dx.doi.org/10.1109/5.84965> -# reprinted in: +# reprinted in: # Christine Hackman and Donald B Sullivan (eds.) # Time and Frequency Measurement # American Association of Physics Teachers (1996) @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C58 -# File expires on: 28 June 2020 +# Updated through IERS Bulletin C59 +# File expires on: 28 December 2020 # -#@ 3802291200 +#@ 3818102400 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h f28827d2 f263b6c3 ec0f19eb a3e0dbf0 97f3fa30 +#h a1c168ae 27c79a7d 9dddcfc3 bcfe616b 2e2c44ea \ No newline at end of file

2 1

new NIST leap-seconds.list
by Chris Woodbury Jan. 10, 2020

Jan. 10, 2020

> On Fri, 10 Jan 2020 13:57:17 -0500, John Hawkinson <jhawk(a)alum.mit.edu> wrote: > Has this diff been hand-edited? There does not appear to be a difference at line 65 (middle of the first hunk)? > Or maybe something was lost though a copy/paste to email? A space was lost in cut/paste (mi culpa). In line 65, the extra space ("Reprinted in: ") was eliminated by Dr. Levine. $ sed -n -e 65p a/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000022 $ sed -n -e 65p b/leap-seconds.list | od -c 0000000 # \t \t r e p r i n t e d i n : 0000020 \n 0000021

1 0

Request RE: academic research question re: TZ database
by Andrew Lyon Jan. 10, 2020

Jan. 10, 2020

Hello. I am a clinical biochemist and not well versed in handling the TZ database. I am investigating a software problem related to hospital patient data management that appears to be triggered when the software encounters a patient record with a date-of-birth that coincides with a historic daylight saving time Spring transition date. Through this investigation I have learned many details about the history of daylight saving time, but I often question the reliability of sources of information. It appears that many use the tz database as a source of truth. I am seeking assistance to query the tz database to determine the entries in the database for Area /Location America/Regina to determine the (1) daylight saving time Spring transition date and (2) daylight saving time Spring transition hour from 1900 to 1966. I understand there were 10 years between 1930 and 1941 when the hour of Spring daylight saving transition was 0000 (midnight) to 0100. I would like to confirm these entries are in the tz database. I have numerous references that daylight saving time was also observed in America/Regina during world war ONE ( 1914-1918) and I am uncertain if those entries are in the tz database or the hour of those transitions. I am uncertain if it is appropriate to ask for this type of assistance on this discussion group. Thank-you very much, regards, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan

6 10

Some inconsistency in times during the transitions between DST and non-DST times...
by Alan Lehotsky Jan. 9, 2020

Jan. 9, 2020

I’m supporting a “port” of the tz code where I’ve selectively embedded pieces of localtime.c into an application , so this may be something I’ve broken, but I’ve looked fairly carefully at my implementation. There seems to be a problem with the binary search to find the nearest transition times, when you are within the “fall-behind” transition. If I am in the Europe/London timezone and have a time like "2019-10-27 01:16:46” converting it to UTC is producing the same time (because it ends up finding the non-DST range. But ONE second earlier ends up thinking it’s within the DST range, so "2019-10-27 01:16:45” ends up reporting “2019-10-2 00:16:45” I tried to use the gnu date command to see if I could reproduce this in a clean tz environment using the -u -d flags, and couldn’t duplicate the problems I’m seeing, so there’s a possibility that this is something I’m doing wrong. But the following experimental change in localsub makes it consistently pick the non-dst representation of the time. } else { int lo = 1; int hi = sp->timecnt; while (lo < hi) { int mid = (lo + hi) >> 1; if (t < sp->ats[mid]) hi = mid; else lo = mid + 1; } i = (int) sp->types[lo - 1]; // Check if this is a dst setting AND 't' is within the magic hour that // replays when we fall behind. In this case we always treat a time as // not in the dst. // if (sp->ttis[i].tt_isdst && (t - sp->ttis[i].tt_gmtoff) > sp->ats[lo-1]) i = (int) sp->types[lo]; } ttisp = &sp->ttis[i]; Does this make any sense?

2 1

Updated Eggert leap-seconds.list
by Chris Woodbury Jan. 8, 2020

Jan. 8, 2020

On the occasion of a new IERS Bulletin C, I present an updated version of a public domain leap-second.list file. # -=*( 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> (down) # <ftp://cddis.gsfc.nasa.gov/pub/products/iers/leapsec.dat> (backup) # Updated using information from IERS Bulletin C 59 (7 Jan 2020) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # IERS Bulletin C 59 did not announce a new leap-second. # # The last leap-second occurred on 1 Jan 2017 (3692217600) # which was announced in IERS Bulletin C 52 on 6 July 2016. # # -=<*>=- # # 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. # # The generation of this file was at the behest of Dr. Eggert # on the occasion of a US government shutdown which resulted # in a lack of an NIST 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 de facto basis for # legal time for much of the world since 1 Jan 1972 0h. # # [Le] Bureau International des Poids et Mesures (BIPM) tracks # TAI, UT1, TE, UTC, etc. 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: ftp://maia.usno.navy.mil/ser7/ser7.dat (down) # ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat (backup) # # 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/> # # Also note that Annex 1, Section 2.1 of this document contradicts # the comments in Bulletin C regarding as to when a leap-second # may be applied. i.e. As the last second of any UTC month. # Preference is given to June and December and, secondarily, in # March and September. (All have been in June or December.) # # 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] # #$ 3787382231 # # 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 (#@). # # Updated through IERS Bulletin C 59 (7 Jan 2020) # File expires on: 28 Jul 2020 # #@ 3818102400 # # 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. # # 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) # #h 85073416 421bdd85 47662775 e154160c 4f1a3070

1 0

Bulletin C 59
by Chris Woodbury Jan. 8, 2020

Jan. 8, 2020

Phoo, my pasteinig into my e-mail program munged the URL of where to find the IERS Bulletin A at NASA's Goldstone Space Flight Center. It's: ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat

2 1

Bulletin C 59
by Chris Woodbury Jan. 7, 2020

Jan. 7, 2020

> Steve Allen sla at ucolick.org wrote on Tue Jan 7 20:15:38 UTC 2020 > In the middle of last year the Earth's crust accelerated such that we > were rotating faster than 200 years ago. The value of Delta T > decreased during a few weeks. The Length of Day (LoD), as Dr. Allen knows better than I, is effected by many factors. Having picked a length for the atomic SI second where 86,400 of them add up to a day shorter than the mean Solar day by milliseconds, we have been playing "catch up" since UTC was defined. The tides slowing down the crustal rotation, along with torque applied directly on the Earth oblate spheroid by Sol and other celestial bodies, along with other factors, change the rate at which the LoD changes. I have been fascinated by the fact that Bulletin A projections of UT1-UTC have put the point where it reaches -0.4 (which is typically when IERS inserts a leap-second) further and further into to future. Recently, every week, the MJD where it gets to -0.3 (currently at -0.29480 on 2021-01-01) gets a week farther away. It has been proposed that the latest oddities are caused by angular momentum being transferred from the Earth's rotating solid core to the liquid surround it, the semi-solid mantle and, finally, to the crust. Not something instantaneous by any means. My favorite thought on the matter involves wondering about conservation of angular momentum as megatons of ice, melting at altitude, unaffected by friction, flows down hill to (a rising) sea-level. Much of that ice is miles in the air.... lots of potential energy realized into actual rotation by a change of position. (Think of it as an spinning ice skater pulling in her/his arms.) Change of spin would be effected by closeness of the ice to the spin axis/poles as well as height of sea level at the equator. One more thing to worry about....

1 0

Hour 26? (was: Chaning time zone for Unix based tasks)
by Paul Gilmartin Jan. 7, 2020

Jan. 7, 2020

(cross-posting to tz and IBM-MAIN) Hi, TZData, On a Linux system, I see: 1043 $ uname -a Linux Bunsen5-PG 4.9.0-11-686-pae #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11) i686 GNU/Linux 1044 $ cat /usr/share/zoneinfo/Asia/Tel_Aviv | tail -1 IST-2IDT,M3.4.4/26,M10.5.0 1045 $ ... This would seem to be Month 3, Week 4, Day 4, hour 26. 26? Is that supposed to be 02:00 the next day? But POSIX says: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#ta… ... The hour shall be between zero and 24, and the minutes (and seconds) -if present-between zero and 59. The result of using values outside of this range is unspecified. z/OS (which supports only POSIX format) seems to ignore that TZ (as allowed by "unspecified") and use UTC0: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r… (It doesn't specify.) Ouch! -- gil

3 4

Bulletin C 59
by Chris Woodbury Jan. 7, 2020

Jan. 7, 2020

Bulletin C 59 has been released on 2020-01-07 at 12:50:44 by IERS and there will be no leap-second in June 2020. There are also a new IERS leap-seconds list file (leap-seconds.3787382231) and Leap_Second.dat file (touched but unchanged). Visit ftp://hpiers.obspm.fr/iers/bul/bulc/ By all indications, there will be an unusually long interval before the next leap-second (July 2021 or later). See IERS Bulletin A at ftp://cddis.gsfc.nasa.gov/pub/products/iers/ser7.dat. (USNO's FTP sites are under construction.)

2 1

Fake UK news
by Lester Caine Dec. 31, 2019

Dec. 31, 2019

Or rather another proposal for changes to time zones that did not happen - SDST https://www.bbc.co.uk/news/uk-50950961 -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk

1 0

Timekeeping in the news
by Arthur David Olson Dec. 27, 2019

Dec. 27, 2019

"Boeing Starliner Ends Up In Wrong Orbit After Clock Problem." https://www.nytimes.com/2019/12/20/science/boeing-starliner-launch.html @dashdashado

7 9

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 19, 2019

Dec. 19, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

2 1

[PATCH] * asia: Correct Hong Kong section name.
by Jimmy Yuen Ho Wong Dec. 18, 2019

Dec. 18, 2019

There are no records of Hong Kong being referred to as Xianggang, in the past or currently. The Pinyin romanization scheme of the Mandarin pronunciation of 香港 is not officially recognized or even mentioned in official documents. https://www.basiclaw.gov.hk/en/basiclawtext/chapter_1.html https://www.elegislation.gov.hk/hk/cap5 --- asia | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/asia b/asia index cca004f..4f19d14 100644 --- a/asia +++ b/asia @@ -572,7 +572,7 @@ Zone Asia/Urumqi 5:50:20 - LMT 1928 6:00 - +06 -# Hong Kong (Xianggang) +# Hong Kong # Milne gives 7:36:41.7; round this. -- 2.24.0

1 0

isdst bug Europe/Dublin (tzdb-2019c)
by Stefan Rueger Dec. 16, 2019

Dec. 16, 2019

Looks like zdump claims Dublin has DST during winter, not summer: $ ./zdump -i -c2020,2021 Europe/Dublin TZ="Europe/Dublin" - - +00 GMT 1 2020-03-29 02 +01 IST 2020-10-25 01 +00 GMT 1 Compare with the output for London, which is as I would expect: $ ./zdump -i -c2020,2021 Europe/London TZ="Europe/London" - - +00 GMT 2020-03-29 02 +01 BST 1 2020-10-25 01 +00 GMT Generally, I think it's neater if the time stretches with the larger GMT values are considered DST. This is almost always true, except for Europe/Dublin, Eire, Africa/Casablanca and Africa/El_Aaiun. Morocco (and Western Sahara) change the time to have shorter fasts during Ramadan, so to speak to *not* save daylight. I would therefore still argue that the time outside Ramadan should be considered DST and the time during Ramadan the non-DST time. I am aware that the view "DST means larger GMT value" is not a precise definition (a region that change times zones in quick succession might easily accrue more than two GMT values within a few years). It's therefore not a great candidate for implementation in zic/zdump. However, I hold that periodic *future* annual back-and-forth switches should adopt that principle. Anyway, over to you Stefan PS: You are providing an *amazing* service - many thanks for that!

11 37

(no subject)
by Misty HICKMAN Dec. 16, 2019

Dec. 16, 2019

Yes . MistY 18months now . Very clear you know. The cAlEndAr Y ear ? Remember the TeaCUp ..

1 0

Re: [tz] Anticipated strategy for handling US state DST rule changes
by Paul Eggert Dec. 12, 2019

Dec. 12, 2019

On 12/12/19 7:39 AM, David Braverman wrote: > Can we use America/New_York_State/Buffalo, for example? That would work, yes. But let's hope Buffalo stays aligned.

1 0

EU and Brexit Time Borders
by Brian Inglis Dec. 12, 2019

Dec. 12, 2019

EU member states get to decide whether to stay on summer or standard time: https://www.independent.ie/business/brexit/meps-vote-to-end-daylight-saving… What will Ireland do, and will Ulster follow Irish or UK time? https://www.independent.co.uk/news/uk/politics/brexit-irish-border-time-clo… Will UK follow, staying on GMT or BST, or keep switching? https://www.rospa.com/media/documents/road-safety/consultation-responses/di… "Under the new legislation, governments opting to make summer-time permanent would adjust their clocks for the last time on the last Sunday in March 2021. For those choosing permanent standard time, known as permanent winter-time, the final clock change would be on the last Sunday of October 2021." -- 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

Anticipated strategy for handling US state DST rule changes
by Marc Sackeli Dec. 12, 2019

Dec. 12, 2019

I apologize if this is a repeat question, but this question pertains specifically to how the tz database might change if individual US states start adhering to their own DST rules. There has been a wave of legislation <https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#201…> coming from individual states trying to shift towards a year-round DST model. While several states have successfully passed this legislation, their ability to shift is reliant on federal approval. Arizona has been able to drum to their own beat on DST, and I don't think it's far fetched to think other states might be allowed to do so in the future as well. If this is a potential outcome, is there an idea of how the tz database would adapt to this change? My guess is that new entries would be created to allow us to delineate between these states. We are currently covered if California decides to change thanks to America/Los_Angeles, but what if Oregon or Tennessee decides they want to change? Does this mean America/Portland and America/Nashville would be created? Or perhaps America/Oregon and America/Tennessee? Any thoughts would be appreciated. -Marc

3 5

Iceland may move from +00 to -01
by Paul Eggert Dec. 11, 2019

Dec. 11, 2019

Since 1968 Reykjavík has been about 1.5 hours ahead of mean solar time. The government of Iceland recently asked people which of three things they wanted to do about this, and the survey results were: 4% - educational campaign to encourage people to go to bed earlier 37% - leave the clocks alone 56% - change from +00 to -01 The prime minister's office is drafting a bill to implement the majority opinion: this would undo the 1968 change from -01/+00 (with DST) to permanent +00, and would revert to permanent -01, which was observed 1908-1916 and 1922-1938. Although I've seen many proposals from around the world to change the clocks, this bill seems to have a real chance of passing so I thought I'd give the list a heads-up. My source: Fontaine A. Most Icelanders support changing Iceland’s time zone. Reykjavík Grapevine. 2019-12-11. https://grapevine.is/news/2019/12/11/most-icelanders-support-changing-icela…

1 0

incorrect timezone info from tar files
by Benjamin Weiser Dec. 8, 2019

Dec. 8, 2019

Hello, I'd like to report your downloads for the following Time Zones from this URL on your site are out of date: https://www.iana.org/time-zones For instance Europe/Istanbul moved to UTC 3 permanently in September of 2016 and no longer follow DST. I will place the correct times first, and then the incorrect IANA times second. Highlighted in orange have the incorrect time zone information (0 means there is no DST, 1 means they follow DST) TimeZone UTC Offset ObservesDST IANA_UTC_offset: IANA_ObservesDST: America/Campo_Grande -4 0 -4 1 America/Sao_Paulo -3 0 -3 1 America/St_Johns -3.5 1 -3 1 Asia/Sakhalin 11 0 10 0 Australia/Adelaide 9.5 1 9 1 Australia/Darwin 9.5 0 9 0 Australia/Lord_Howe 10.5 1 10 1 Europe/Istanbul 3 0 2 1 Indian/Cocos 6.5 0 6 0 Pacific/Chatham 12.75 1 12 1 Thanks.

8 12

Link Suggestion for your Website Resources page
by LISA - Unit Converter Dec. 7, 2019

Dec. 7, 2019

Dear Webmaster, As I’m sure you’re quite busy, I’ll be quick. I just check out your resource page https://data.iana.org/time-zones/code/tz-link.html. I love your posting. Great stuff! I wanted to share some of my work with you. We have developed a site https://unitconverter.net/time-converter. Almost we cover all kinds of time conversion and calculation. I'm sure our tool is fit for your resource page. I am hoping you will consider our tool, it will be a great appreciation for us. Please add our tag as " Time Converter". Feel free to reach out. And as always, I will continue to visit your website and stay current with your business. Also Please let me know if I can do anything in the future... Kind Regards, Lisa Grace.

3 2

Howard Hinnant's Time Zone Database Parser
by Scott Nelson Dec. 4, 2019

Dec. 4, 2019

I didn’t see a mention of Howard Hinnant’s Time Zone Database Parser (https://howardhinnant.github.io/date/tz.html) did I miss it or is it something worthwhile to add to your list on tz-link.html? -- Scott

5 5

Re: [tz] Unnecessary time zones in Ukraine territory
by Mikhail Gribanov Dec. 4, 2019

Dec. 4, 2019

Ping. Please fix the time zones of Ukraine. Or at least reply me. пт, 27 сент. 2019 г. в 20:21, Mikhail Gribanov <mikhail.gribanov(a)gmail.com>: > > Hi. Many Linux distributions use time zones from tz database. But I > noticed that in Ukraine there are two unnecessary time zones. This is > noticeable in the Linux distributions installers when choosing a time > zone. There is only one time zone in Ukraine: > https://uk.wikipedia.org/wiki/Час_в_Україні (Europe/Kiev in tz > database) > > Unnecessary time zones: > Europe/Uzhgorod > Europe/Zaporozhye > > Can you explain why they were added? I did not find any evidence of > the existence of events "Ruthenia used CET 1990/1991" (comment in tz > database). > And if it really existed is it possible to somehow mark them as > inactive time zones? Because many programs (for example, Linux > distribution installers, which I mentioned above) offer to select them > as active, which is incorrect.

4 6

Help on Updating Java Time ZOne
by Santos, Cosme Dec. 3, 2019

Dec. 3, 2019

Hi, I am from brazil and I am trying to fix na issue with java, We used the command Execute C:\Program Files\Java\jdk1.8.0_161\bin>java -jar tzupdater.jar -v -f -l file:c:\temp\tzdata2019c-rearguard.tar.gz (via cmd) And restarted all the Java application, however, some parts of the application are with the correct time, others are not. I have found this link and I am trying to get a fix for this, but I'd like to as for ehlp. What is tzcode and tzdb, should I update them to? Also, the Brazil Timezone change, 2019 we won't have it, so a friend sent me the tzdata2019c-rearguard.tar.gz (is this a good file?) [cid:image001.png@01D5A608.A1816A60] Best Regards, Cosme Santos Services & Support Analyst | South America E-Mail: c.santos(a)asctechnologies.com<mailto:c.santos@asctechnologies.com> I Phone: +55 11 4040-4500 | + 55 11 9 8555-0408 [cid:image002.jpg@01D0FABE.B417E720] ASC WFO Solutions do Brasil Ltda. I Av. Brig. Faria Lima, 1912 - 11° Andar - Cj 11 G I 01451-907 - São Paulo I http://www.asctechnologies.com.br<http://www.asctechnologies.com.br/> Privacy and legal statements can be found at http://asctechnologies.com/english/asc_impressum.html Please follow us on [Emailsignatur_FB]<https://www.facebook.com/ASC.cloud> [Emailsignatur_TW] <https://twitter.com/ASCTechnologies> [Emailsignatur_XG] <https://www.xing.com/company/asctechnologiesag> [Emailsignatur_LIn] <https://www.linkedin.com/company/465821> All statutory information can be found at http://www.asc.de/english/asc_impressum.html

3 2

USG_COMPAT and POSIX and XOPEN macros
by Andras Farkas Dec. 3, 2019

Dec. 3, 2019

I've noticed that USG_COMPAT shouldn't be replaced by XOPEN macros since it's clear USG_COMPAT is meant to be something users of tzcode can toggle. However, if someone has an application where they set _XOPEN_SOURCE to 700 or another value, I wonder if there should be something equivalent to the following in private.h #ifndef USG_COMPAT # ifndef _XOPEN_VERSION # define USG_COMPAT 0 # else # define USG_COMPAT 1 # endif #endif But using _XOPEN_SOURCE instead. (while also retaining the block of code using _XOPEN_VERSION too. I think in cases where both macros are involved, priority should be given to _XOPEN_SOURCE since it's explicitly what an application programmer has asked for) Right now, the code only reads _XOPEN_VERSION (from the OS) but not _XOPEN_SOURCE (from the application) This possibly could also apply to how only _POSIX_VERSION is currently used, but not _POSIX_C_SOURCE (nor the obsolete _POSIX_SOURCE, but that's been superseded for a long time now) This topic originates in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html

3 7

Addition to tz-art.html
by Arthur David Olson Dec. 3, 2019

Dec. 3, 2019

This lament about the difficulty of time calculation peaked at number 7 on the U. S. Billboard chart. @dashdashado *** old/tz-art.html Sun Dec 1 14:12:32 2019 --- new/tz-art.html Sun Dec 1 14:28:34 2019 *************** *** 458,463 **** --- 458,472 ---- <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> + <tr><td> </td><td></td></tr> + <tr><td>Artist</td><td>Chicago</td></tr> + <tr><td>CD</td><td>Chicago Transit Authority</td></tr> + <tr><td>Copyright Date</td><td>1969</td></tr> + <tr><td>Label</td><td>Columbia</td></tr> + <tr><td>ID</td><td>64409</td></tr> + <tr><td>Total Time</td><td>1:16:20</td></tr> + <tr><td><a href=" https://www.allmusic.com/album/chicago-transit-authority-mw0000189364">AMG Rating</a></td><td>4 stars</td></tr> + <tr><td>Notes</td><td>Includes the song "Does Anybody Really Know What Time It Is?"</td></tr> </table> <h2>Comics</h2> <ul>

2 1

tz-art.html playlist
by Arthur David Olson Dec. 1, 2019

Dec. 1, 2019

A playlist of 22 of the tunes noted in tz-art.html is now available at... https://open.spotify.com/playlist/681bJSY7FY7ppzLOcmYPdh Nerdiest. Party. Ever. @dashdashado

1 0

Time zone name tangent
by Arthur David Olson Nov. 24, 2019

Nov. 24, 2019

Having read a bit on the United States Board on Geographic Names... https://en.wikipedia.org/wiki/United_States_Board_on_Geographic_Names <https://en.m.wikipedia.org/wiki/United_States_Board_on_Geographic_Names> ...and their best known actions (the renaming of Cape Canaveral to Cape Kennedy and back)... https://www.straightdope.com/columns/read/613/why-did-they-change-the-name-… ...I'm of two minds on the wisdom of having a Board of Time Zone Names.-S @dashdashado

1 0

[PATCH 1/2] * NEWS: Fix release typo in Nuuk change.
by Paul Eggert Nov. 24, 2019

Nov. 24, 2019

--- NEWS | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index c28905b..92bff58 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,17 @@ News for the tz database +Unreleased, experimental changes + + Briefly: + America/Nuuk renamed from America/Godthab. + + Changes to timezone identifiers + + To reflect current usage in English better, America/Godthab has + been renamed to America/Nuuk. A backwards-compatibility link + remains for the old name. + + Release 2019c - 2019-09-11 08:59:48 -0700 Briefly: @@ -55,12 +67,6 @@ Release 2019c - 2019-09-11 08:59:48 -0700 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 timezone identifiers - - To reflect current usage in English better, America/Godthab has - been renamed to America/Nuuk. A backwards-compatibility link - remains for the old name. - Changes to code leapseconds.awk now relies only on its input data, rather than -- 2.17.1

1 1

Question about bug seen in OpenBSD and FreeBSD related to tzname
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

Hello! Earlier this month, I noticed bugs in OpenBSD and FreeBSD related to tzname's values. https://marc.info/?l=openbsd-bugs&m=157379849727998&w=2 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241978 I noticed that both those OSes share relevant code with tzcode. How would I best test this stuff out with a recent release of tzcode? (i.e. how to make sure I'm including headers only from the 2019c tarball and not from my OS, when possible)

7 15

FreeBSD and USG_COMPAT
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

FreeBSD doesn't support the int daylight or long timezone in time.h itself. tzcode supports them on OSes which already support them, like OpenBSD. I'm trying to figure out if it should be possible to compile tzcode to support daylight and timezone even on OSes which don't support them. I've saved the output of make (both stdout and stderr) when CFLAGS is set to -DUSG_COMPAT=1 alone into usgcompat.txt I've saved the output of make (both stdout and stderr) when CFLAGS is set to '-DUSG_COMPAT=1 -DHAVE_POSIX_DECLS=0' into both.txt What I'm seeing is that the OS's time.h is being included, under both configurations. This topic originated in this thread: http://mm.icann.org/pipermail/tz/2019-November/028596.html http://mm.icann.org/pipermail/tz/2019-November/thread.html

1 1

Question (potential issue) about tzselect.ksh
by Andras Farkas Nov. 23, 2019

Nov. 23, 2019

I noticed tzselect.ksh, despite its filename, uses #!/bin/bash as its shebang. Should the filename be renamed or shebang be switched to ksh? That said, both ksh93 -n and shellcheck don't complain. (other than for `` being used instead of $(), which is a warning rather than an error) This isn't urgent at all, though.

2 2

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

Nov. 20, 2019

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

14 26

Antarctica/Troll time
by Phake Nick Nov. 18, 2019

Nov. 18, 2019

In the Antarctica file of tz database, some rules for Antarctica/Troll have been commented out, with the description of it saying "uncomment them when 2014b is more prevalent". Is it still not prevalent enough to uncomment them now?

4 3

UK Lords "Discontinuing seasonal changes of time" publications
by Paul Eggert Nov. 14, 2019

Nov. 14, 2019

The EU Internal Market Sub-Committee of the UK House of Lords has published oral and written comments on proposals to abolish DST transitions in the UK, and are preparing a report. The main comment that caught my eye was from Google's Jonathan Skeet <https://data.parliament.uk/writtenevidence/committeeevidence.svc/evidencedo…>. Skeet underscores the utility of announcing changes long in advance. He goes into considerable detail about "Europe/London" and other tzdb names, negative DST in the Republic of Ireland, "permanent" DST, "BST" and other time zone labels, and so forth. The complete list of published comments can be found here. This list contains a copy of the comment that I circulated on the tz mailing list on August 5. https://www.parliament.uk/business/committees/committees-a-z/lords-select/e…

1 0

uptodate data
by Jean Nov. 14, 2019

Nov. 14, 2019

6 8

Change DTS and time zone for Morocco
by liuchao (CR) Nov. 12, 2019

Nov. 12, 2019

In the past, Morocco observed four clock changes per year. Like in most other countries with seasonal time changes, the DST period in Morocco started in the spring and ended in the fall (autumn). However, clocks were turned back to standard time during the Islamic month of Ramadan to make it easier to observe the daytime fast. The Kingdom of Morocco now remains permanently set to UTC+01:00 instead of following an earlier plan to return to UTC+00:00 on October 28, 2018. But the data in Africa doesn't change. There still are four clock changes in 2018, which causes isdst flag error in 2019. https://support.microsoft.com/en-us/help/4468323/dst-and-time-zone-changes-… https://www.timeanddate.com/news/time/morocco-abolishes-time-changes.html Before change, [cid:image001.png@01D59979.EB9BDA90] on May 5 2019, the time jumps from 02:59:59 to 02:00:00, the isdst flag should change from 1 to 0. After change, [cid:image002.png@01D59979.EB9BDA90] When dataform is rearguard, it is fixed via ziguard.awk, [cid:image003.png@01D5997A.49F01BB0] However, I don't understand why it's only changed in rearguard format.

2 1

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