- tz - lists.iana.org

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

July 5, 2019

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

5 4

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

July 5, 2019

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

2 3

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

July 4, 2019

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

3 7

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

July 4, 2019

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

2 1

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

July 4, 2019

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

3 4

Golan Heights and Quneitra
by Alois Treindl July 4, 2019

July 4, 2019

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

2 1

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

July 3, 2019

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

5 7

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

July 2, 2019

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

2 1

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

July 2, 2019

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

1 0

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

July 1, 2019

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

2 1

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

June 29, 2019

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

3 2

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

June 28, 2019

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

2 1

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

June 28, 2019

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

1 0

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

June 27, 2019

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

2 1

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

June 27, 2019

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

35 150

Minor clerical fixes
by Tim Parenti June 27, 2019

June 27, 2019

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

2 1

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

June 26, 2019

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

6 7

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

June 26, 2019

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

2 1

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

June 26, 2019

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

1 0

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

June 26, 2019

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

7 10

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

June 25, 2019

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

6 5

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

June 25, 2019

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

1 1

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

June 23, 2019

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

9 12

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

June 23, 2019

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

2 1

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

June 22, 2019

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

1 0