- tz - lists.iana.org

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

Jan. 25, 2019

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

4 4

[PROPOSED] Put “North” before “Macedonia”
by Paul Eggert Jan. 25, 2019

Jan. 25, 2019

* backzone, europe, iso3166.tab: Put “North” before “Macedonia” in commentary and metadata. Might as well do it now, since the name change appears to be a done deal. This does not affect time data. --- backzone | 2 +- europe | 4 ++-- iso3166.tab | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 97792b1..c464ce6 100644 --- a/backzone +++ b/backzone @@ -625,7 +625,7 @@ Zone Europe/Sarajevo 1:13:40 - LMT 1884 1:00 - CET 1982 Nov 27 1:00 EU CE%sT -# Macedonia +# North Macedonia Zone Europe/Skopje 1:25:44 - LMT 1884 1:00 - CET 1941 Apr 18 23:00 1:00 C-Eur CE%sT 1945 May 8 2:00s diff --git a/europe b/europe index 587f7b0..b735a48 100644 --- a/europe +++ b/europe @@ -1855,7 +1855,7 @@ Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 1:00 Belgium CE%sT 1977 1:00 EU CE%sT -# Macedonia +# North Macedonia # See Europe/Belgrade. # Malta @@ -3359,7 +3359,7 @@ Zone Europe/Belgrade 1:22:00 - LMT 1884 Link Europe/Belgrade Europe/Ljubljana # Slovenia Link Europe/Belgrade Europe/Podgorica # Montenegro Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina -Link Europe/Belgrade Europe/Skopje # Macedonia +Link Europe/Belgrade Europe/Skopje # North Macedonia Link Europe/Belgrade Europe/Zagreb # Croatia # Slovakia diff --git a/iso3166.tab b/iso3166.tab index c2e0f8e..98fb988 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -166,7 +166,7 @@ ME Montenegro MF St Martin (French) MG Madagascar MH Marshall Islands -MK Macedonia +MK North Macedonia ML Mali MM Myanmar (Burma) MN Mongolia -- 2.17.1

1 0

Metlakatla
by TechOps Jan. 22, 2019

Jan. 22, 2019

Hello. The Metlakatla community in Alaska has decided not to change its clock back an hour starting on November 4th, 2018 (day before yesterday). They will be gmtoff=-28800 year-round. I'm told this is the list to send this information to. Any assistance or advice on getting this updated in the database is appreciated. https://www.facebook.com/141055983004923/photos/pb.141055983004923.-2207520… [image: MIC time change.jpg] - Ryan _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ AKTechOps <http://serrc.org/techops> | techops(a)serrc.org | *(907) 523-7290* *| Brian 523-7248 | Michaela 523-7258 | Nate 523-7275 | Nick 523-7291 | Ryan 523-7272 | SERRC 586-6806 |*

7 13

Re: [tz] Bulletin C number 57
by Hal Murray Jan. 20, 2019

Jan. 20, 2019

eggert(a)cs.ucla.edu said: > but I worry that the format change will also mess up downstream programs too > (notably NTP-related) Worked OK for ntpsec. There is a checksum in the file, but it only covers the non-comment digits in the file. (so white space changes are OK) The payload lines must start on column 1 - no leading white space. -- These are my opinions. I hate spam.

3 2

Conrad Maldives Rangali Island resort
by Deborah Goldsmith Jan. 20, 2019

Jan. 20, 2019

Apparently, this resort in the Maldives has its own time zone and observes GMT+06 year round, unlike Male at GMT+05. It looks like we’d need a new zone for this. Source: Internal reports and: http://conradglobalmediacenter.com/assets/CNRD/docs/FactSheets/ConradMaldiv… (search for “Local Time”) I wasn’t able to find any source contradicting this information. Apparently it’s a known issue that Maldives resort islands have their own (unofficial) time zones: https://www.timeanddate.com/time/zone/maldives At the moment, users need to find a time zone that has the same GMT offset (in this case Indian/Chagos works) and use that instead. Thanks, Debbie

11 15

Some rules in tz specification files seem to be applied (by zic) outside of their declared period of applicability
by Parsifal Herzog Jan. 19, 2019

Jan. 19, 2019

In the example shown below, copied from from tzdata2018i Africa file, the last Zone line, referencing the Namibia rule, should start at 1990 March 21 2:00 am. There are no Namibia transitions defined from that start, until 1994. However zic does create a transition using the second Namibia rule at the start time, as shown in the zdump output below. There are many other cases like this, where an UNTIL specification ends well before the next applicable rule of the following zone line. I am trying to read the zic manual page as a specification, and I do not understand why zic inserts that transition. It seems to me that either the last Zone line (SAST) would remain in effect until 1994, as there is no other transition defined, or that period is in an undefined state, as the SAST transition is not in effect after1990 March 21. Can someone correct my understanding? ------- Specification extract # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S # Vanguard section, for zic and other parsers that support negative DST. Rule Namibia 1994 only - Mar 21 0:00 -1:00 WAT Rule Namibia 1994 2017 - Sep Sun>=1 2:00 0 CAT Rule Namibia 1995 2017 - Apr Sun>=1 2:00 -1:00 WAT # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Windhoek 1:08:24 - LMT 1892 Feb 8 1:30 - +0130 1903 Mar 2:00 - SAST 1942 Sep 20 2:00 2:00 1:00 SAST 1943 Mar 21 2:00 2:00 - SAST 1990 Mar 21 # independence # Vanguard section, for zic and other parsers that support negative DST. 2:00 Namibia %s ------ Zicdump output: $ zdump -v -c 1892,1996 Africa/Windhoek Africa/Windhoek -9223372036854775808 = NULL Africa/Windhoek -9223372036854689408 = NULL Africa/Windhoek Sun Feb 7 22:51:35 1892 UT = Sun Feb 7 23:59:59 1892 LMT isdst=0 gmtoff=4104 Africa/Windhoek Sun Feb 7 22:51:36 1892 UT = Mon Feb 8 00:21:36 1892 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:29:59 1903 UT = Sat Feb 28 23:59:59 1903 +0130 isdst=0 gmtoff=5400 Africa/Windhoek Sat Feb 28 22:30:00 1903 UT = Sun Mar 1 00:30:00 1903 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sat Sep 19 23:59:59 1942 UT = Sun Sep 20 01:59:59 1942 SAST isdst=0 gmtoff=7200 Africa/Windhoek Sun Sep 20 00:00:00 1942 UT = Sun Sep 20 03:00:00 1942 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 22:59:59 1943 UT = Sun Mar 21 01:59:59 1943 SAST isdst=1 gmtoff=10800 Africa/Windhoek Sat Mar 20 23:00:00 1943 UT = Sun Mar 21 01:00:00 1943 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 21:59:59 1990 UT = Tue Mar 20 23:59:59 1990 SAST isdst=0 gmtoff=7200 Africa/Windhoek Tue Mar 20 22:00:00 1990 UT = Wed Mar 21 00:00:00 1990 CAT isdst=0 gmtoff=7200 <------ zic inserted the 1994 "CAT" transition. How was this chosen? Africa/Windhoek Sun Mar 20 21:59:59 1994 UT = Sun Mar 20 23:59:59 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Mar 20 22:00:00 1994 UT = Sun Mar 20 23:00:00 1994 WAT isdst=1 gmtoff=3600 <----- first applicable rule in 1994. Africa/Windhoek Sun Sep 4 00:59:59 1994 UT = Sun Sep 4 01:59:59 1994 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 4 01:00:00 1994 UT = Sun Sep 4 03:00:00 1994 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sat Apr 1 23:59:59 1995 UT = Sun Apr 2 01:59:59 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek Sun Apr 2 00:00:00 1995 UT = Sun Apr 2 01:00:00 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 00:59:59 1995 UT = Sun Sep 3 01:59:59 1995 WAT isdst=1 gmtoff=3600 Africa/Windhoek Sun Sep 3 01:00:00 1995 UT = Sun Sep 3 03:00:00 1995 CAT isdst=0 gmtoff=7200 Africa/Windhoek 9223372036854689407 = NULL Africa/Windhoek 9223372036854775807 = NULL -------

6 6

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

Jan. 19, 2019

On Tue Jan 8 01:32:04 UTC 2019, Paul Eggert wrote:> In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST.Your wish is my command.... # -=*( This file is in the public domain )*=- # This NTP leap-second file was created with data obtained from # the United States Naval Observatory (USNO) MAIA FTP server. # # Find it at: <ftp://maia.usno.navy.mil/ser7/leapsec.dat> # Updated using information from IERS Bulletin C 57 (7 Jan 2019) # Found at <ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat> # # This file is not a forgery, per se, but it is created # by some one/thing other than a national metrology lab. # It is necessitated by a current US government shutdown # and the resulting lack of an NIST generated file. # # UTC is a time scale based upon standard international (SI) # seconds and derived from Temps Atomique International (TAI). # # 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. # # These 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 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-Regulation (ITU-R) # 460-6, Annex 1, Section 2. # # <http://www.itu.int/rec/R-REC-TF.460-6-200202-I/> # # 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. It should be updated whenever a new IERS Bulletin C # is issued. # #$ 3755808000 # # 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 (#@). # #@ 3786480000 # # 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 # excluded 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 sign 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 ffee5390 2e3cf253 e15b646e 01768a18 e83785c3

2 1

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

Jan. 17, 2019

On Tue Jan 8 01:32:04 UTC 2019 Paul Eggert <eggert(a)cs.ucla.edu> wrote: > In the meantime perhaps we could forge the NIST leap-seconds.list file > (including a comment that it's a forgery and why we're doing the > forgery), and then substitute the real thing whenever it shows up. I'd > rather have a script to do that than do it by hand, though. We'd need > that script anyway if we start basing our distribution on the IERS file, > as so many users now grab the NIST file from us rather than from the NIST. Your wish is my command. See attachment.

1 0

Brasil DST changes
by Dedeco Balaco Jan. 15, 2019

Jan. 15, 2019

Hello, last year, the DST automatic adjust for my recently installed system was wrong. It is a Debian 9 install. I adjusted it manually in the start and end or the period. It was not done according to what was defined by our State sometime before. Please note that it was not something done close to the change date. My friends and I looked around a bit, and we found that this change should have passed here somehow. Next year, I do not know how it will be. Who is responsible for this kind of information or update?

3 3

Notice Lead Time Tracking
by Brian Inglis Jan. 13, 2019

Jan. 13, 2019

Given some recent last minute end of year announcements, could I please suggest creating a new document to formally track metadata about every time change notice's lead time from 2019, as a basis for stats, info, distributor/vendor additions and enhancements, walls of shame, etc. as this has never yet been suggested AFAIR. I could see vendors like Apple, Google, Microsoft, Oracle dev groups adding columns to local copies to track their own responses, and using those to prod government officials to do better. The document could be a text file containing an HTML document with a table tracking: CC, announcement date[/time], effective date[/time], lead time in years-months-days [hours:minutes:seconds], tzdb release date[/time], tzdb release lead time +/- in years-months-days [hours:minutes:seconds], whether change affects STD, whether change affects DST, number of zones impacted, list of zones impacted, comments about missing details etc.; with dates[/times] in ISO formats (and perhaps also Unix format metadata attributes, allowing for JS HTML text display customization and sorting by third party users); times only specified when useful or notice is days, and times are available and accurate. If anyone has been doing this already, perhaps they could contribute their data; and anyone with interest and time could backfill data from mailing list posts. -- 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.

5 6

Bulletin C 57: No leap second
by Kurt Roeckx Jan. 7, 2019

Jan. 7, 2019

Bulletin C 57 was sent today, and contained: NO leap second will be introduced at the end of June 2019. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Kurt

1 0

[tz-announce] 2018i release of tz code and data available
by Paul Eggert Jan. 5, 2019

Jan. 5, 2019

The 2018i release of the tz code and data is available. It reflects the following change, which was circulated on the tz mailing list: Briefly: São Tomé and Príncipe switches from +01 to +00 on 2019-01-01. Changes to future timestamps Due to a change in government, São Tomé and Príncipe switches back from +01 to +00 on 2019-01-01 at 02:00. (Thanks to Vadim Nasardinov and Michael Deckers.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018i.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018i.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018i.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 388b0a55116099360a99cc9973d75ae6ec63d939 dated 2018-12-30 11:05:43 -0800 and tagged '2018i' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 1a3d53043f20b8252f7598f547d78e7294d9e0cf1fcdd2159354d9769f824c8c8a03cef9cbb7fa579345fdb41372335117d2ef782ecd9c107dd0526e59492d9d tzcode2018i.tar.gz 6afcacb377842190648ed26f01abcf3db37aa2e7c63d8c509c29b4bc0078b7ff2d4e5375291b9f53498215b9e2f04936bc6145e2f651ae0be6d8166d8d336f6a tzdata2018i.tar.gz 1bdab8ce6a2fc17e9b9d88baa7423b44254811255c82ccce0031725cd316b0ac14a696451f98c72559186270de54e8f467afdb788b2b501427f72fb4ea49d145 tzdb-2018i.tar.lz Here are the GPG checksums for the release files::n -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB4ACgkQ7ZfpDmKq fjTyAw/9EA6VzQop7iRV9GA3UQa6w4Rm/P6gJwF3gkz7hlAf39A6Tueulzzwk6F8 K2oIJQ/MlVGNw5yzkGHR2NTY1W3yhSJTKR5X4k2E5f/7vGnTf3USJx2Fs2Itolyn UoGSIRHWesr3tmbNUCT4LImfNyeW2MrW4q8yw1ZS7uZ34TMxDmJ+DTbomSPVhiMu yn3Y9KEqId6z3SsV8yjcDDd4J8B0zuh2WWrhSkPLXjCtGfHdiT9YaTo8y8Ayinwr xzofREicLEj1YX+3Hx0ErUCiWbtEzByOlkSX7CXfABI6EcaNaJzUsiHvrw7TTFoy u1rrJgarkrNj7YXX8Dj4PoAp4cIH4++AwNbZKfZp5PNRlzydKYX0APpuYUwmS5Qv yXqcvsOGHau/wkDb6ZPQwUwu5g7BmZQ42Yvp8tisoeGeCNnm3zu5cKyCMy2LRKyy dELRyxKEpOSOzjYqIl06yPGtQf4xgXh4r/zKCSS1bEBEpzTIV4BvoxB1R9x26hc1 IJwcuYEeU9NAq17Njcs5jyts4SnNfryxX8+RvwtJnxnmoTc1whaMHR8CMka11XI2 bJ1FlJCQr5dBA5M5cstLJZVkreoMp1bNLiVwCL+8cdAHWGXQ6SPUDuQYyUj+wKBp EX6dfVjrX/CYQVe65HnXiqxYJpDamGk2J4suSc4SG6EF8TVtQCw= =eLXg -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIyBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB8ACgkQ7ZfpDmKq fjTMog/3YJT5eFuwlijuTDxlt+VMTaAEaDaSUfzmQhaTDuHPKVDXxCaWq+tcO4J8 gzzecRj40Xc/jZId7MREq2S3uyUu7D6tJR7kRMw8BeTYVkhf+wX4Xmfh+6bVB9bO 34GNTSK9BXoieio68AkaCziVhBy6KynKhzUS4d1sqEDUxhS7r3ir6jTiU4UGAf54 PKWh2YKYITuYww4XnseG9rQsKbVKK4GUm/e7OmV3zf5pI9lhf/TQh1XZXKFbKK70 gDmFPUDAyuiFBCxkA7YsGolAnkscVmuF301brsNg+VKPy1qgMbxY/vF0lo/f7xRw dzi8+ek6/pKCIUmVRWCsg68wUDh1j3pAh9MLT8zhMtxOc42Kh+4b1BNq0x45zVbQ 693ufcf056654Y27bCexy1JbGBNEd6UUGUv/Ou9EGrl6nfrfMSmUneqmBEnl8NY+ 6/cge/JOr+rVbmEku+nuC9kLZx63lSy4BXJ8+vv4DgzE6/3906V30+w/oJUGaImx PjE9tjm6biIWdRi6bZRdFcg0mktBEyzJuAuurX0ZRgcaNkrhNd4zw2Q3yuKDcD67 aM5wUA4JVLX5v6P+s5j5Y+B+OY4sVk8fFzev8BJX+wRulqEmchVertypir17PUSr oqRUAww6oaYwenZNE+6dN0OWtpLDdBUv7+pesiYcaJRrXDCLAA== =ttI4 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGCEACgkQ7ZfpDmKq fjRrfA//ZeU5yiKc9WOW9kco9zXoBvlHgqpxO3qI3ESgUxslFAIpeVA/26JRbEc8 AJaEEEfmKFNFtO0Wev8WAhRT6qayaxlR30qWlhQl73F+F4xVmTuCojf02HlzUS5B QpReCDZecEMXp3SmEHrog3gMtGtT6dbofUbFjXoJtwm8OpjXzlY1LdAwO33eiOKH SKr7r7q4dm/3ZVhdFP2b/OPqiF/ezhywAoYqxIUdglroGyCGtlHECEDyYIHAHlwT /hwRk96a3/ghQiEyVbqREzwBMWydTbeo+MptCtgpA1p1vmVLxLhY/3SUaOdEBIqC mYhDuLMy9SKIVtkLBc537RnUBWyCfX3p9XZ90q2YqcpqzxX47+55IKmZ8MeWEvgU OvPUV6kYVtWCO/7bNVz4I0XaJdK/tA1vhNyk8jXaMW4duCgZZsCDn5uD3oQCKJE4 O+QZqf7k5pGWT3NWFln4vv6/mahAeoV0OxpHpn1qdA6+CAa/DVdU5ZTcaleNsTSy lAd0Zt2UBCb/rycnckgT87RrAtvjUUVq4onHSaTmtOdBYfMLr5BKtD+UClAcudvd jb15tHpErlXpZ/02Bn1yfynd5xFndGA1Rj3xIRCV31/EY+pxYl4i8ZNc9lWvtLa8 PV9bGewU6EsFohzm5/1CnJbT/gKYoFVoYkdQ7/Bc+mtNjYIAYxM= =ehq4 -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018i/tzdata2018i-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018i/tzdata2018i-rearguard.tar.… with the following SHA-512 and GPG checksums: 55ec0bc2504eddc72187c80c24c80ac7a2ec4c9e5b5a4cee583dcd2f97a648b35674e1eb2e390151e689f9d4eb237615d2f0f3c64b2209672e762f0bc4c580e2 tzdata2018i-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwpGB8ACgkQ7ZfpDmKq fjT/yw/9HUQnV+LGYkiQRE840qJ02XqH5K0l2R7n9OiUKsZnI+PEg5y23bUGd4+A gWwNAvC7629m+La8yiIRMO9fdNX3qHCHAXn7eUBH9nfJLcPML4t5i8kFT+NYvXwT JuauEAHDRqVQw6s0Sjeh3wsz/4Iq0c6AOuPqYC5Nnh8OgXZUsG8sNlJfB6x2Hbfe 85UimkXX+xSizN6gMxrP4Y5adoQaJRcCkvjZLm4TwGvMOTFQLNsERtl9KeiJOD3Z qEnt03Wx+kpOK2nIepe+ZgS2TtgK1uRntiu+L7MmRPmNriegCE+SCQVZhl5Kbm4a HHORTs/97B9ec6tiNreL0lg35Z/0vKA4KUdcpBGCaylGNvXNmz4TnHWHpdOWgueD 3O8E87edCTAUvQ8rAoEcqmg6CPrr2p/gfn+96w1EBfBqVJCjsZ/6KaDhbb6/LBAr oHd3TVtHMxpxrkxGXCyZwwpHEQtdnKeWPAyyc5kKd9LqUM1YQLQhQ44aN0SBeO8n spAFJLQm03GA+1aw1ETVrid474PMLTGKQj4iOg0XY/91E/L5p+Pf15ztMBo8asie lo07vW+o0ED3N0p60EXIdZxnokm/hPLo9yqbrCGpXE6wHcSFOgiK/Q5wOahrA/y0 LVI5yJt9Bc+hHLcQnwIPQei2P50ixVVDq8k2hTiM+2PN3iIcoGY= =fOhE -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

5 10

Timezone change for Asia/Qyzylorda
by Zhanbolat Raimbekov Jan. 3, 2019

Jan. 3, 2019

Hi, Starting 21 December 2018 00:00, Qyzylorda oblast, Kazakhstan (Asia/Qyzylorda) has moved back from +6 to +5. Link: http://adilet.zan.kz/rus/docs/P1800000817 -- Zhanbolat Raimbekov, Rochester Institute of Technology '12

9 15

[PROPOSED] Cite Shanks & Pottenger better
by Paul Eggert Dec. 30, 2018

Dec. 30, 2018

* tz-link.html: Provide library URLs for Shanks and Pottenger’s now out-of-print atlases, since their publisher no longer maintains web pages. Link to ANS on these atlases as sources for much of the older tz data. Use <abbr> a bit more often. --- tz-link.html | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/tz-link.html b/tz-link.html index 4f456ef..924227a 100644 --- a/tz-link.html +++ b/tz-link.html @@ -551,8 +551,8 @@ Java</a> contains a copy of a subset of a recent Java-specific format.</li> <li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone Master</a> is a Microsoft Windows clock program that can automatically -download, compile and use <code>tz</code> releases. The Basic version -is free.</li> +download, compile and use <code><abbr>tz</abbr></code> releases. +The Basic version is free.</li> <li><a href="http://veladg.com/velaterra.html">VelaTerra</a> is a macOS program. Its developers @@ -563,10 +563,16 @@ licenses</a> to <code><abbr>tz</abbr></code> contributors.</li> <ul> <li><a href="https://www.astro.com/atlas">Time-zone Atlas</a> is Astrodienst's Web version of Shanks and Pottenger's out-of-print -time zone history atlases now published in <a +time zone history atlases +<a href="https://www.worldcat.org/oclc/468828649">for the US</a> and +<a href="https://www.worldcat.org/oclc/76950459">for the world</a>, +now published in <a href="https://astrocom.com/astrology-products/software/acs-atlas-software">software</a> form by <a href="https://astrocom.com">ACS-Starcrafts</a>. -These atlases are extensive but unreliable, as Shanks appears to have +Although these extensive atlases +<a href="https://astrologynewsservice.com/opinion/how-astrologers-contributed-to-the…">were +sources for much of the older <code><abbr>tz</abbr></code> data</a>, +they are unreliable as Shanks appears to have guessed many <abbr>UT</abbr> offsets and transitions. The atlases cite no sources and do not indicate which entries are guesswork.</li> <li><a href="https://en.wikipedia.org/wiki/HP-UX">HP-UX</a> has a database in @@ -856,14 +862,14 @@ href="https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html"><abbr title="International Earth Rotation and Reference Systems Service">IERS</abbr> Bulletins</a> contains official publications of the International Earth Rotation and Reference Systems Service, which decides when leap -seconds occur. The <code>tz</code> code and data support leap seconds +seconds occur. The <code><abbr>tz</abbr></code> code and data support leap seconds via an optional "<code>right</code>" configuration, as opposed to the default "<code>posix</code>" configuration.</li> <li><a href="https://developers.google.com/time/smear">Leap Smear</a> discusses how to gradually adjust <abbr>POSIX</abbr> clocks near a leap second so that they disagree with <abbr>UTC</abbr> by at most a half second, even though every <abbr>POSIX</abbr> minute has exactly -sixty seconds. This approach works with the default <code>tz</code> +sixty seconds. This approach works with the default <code><abbr>tz</abbr></code> "<code>posix</code>" configuration, is <a href="http://bk1.ntp.org/ntp-stable/README.leapsmear">supported</a> by the <abbr>NTP</abbr> reference implementation, and is used by major -- 2.17.1

1 0

São Tomé and Príncipe tz change (Jan 1, 2019)
by Vadim Nasardinov Dec. 30, 2018

Dec. 30, 2018

São Tomé and Príncipe is about to do the following on Jan 1, 2019: http://www.stp-press.st/2018/12/05/governo-jesus-ja-decidiu-repor-hora-lega… “O Conselho de Ministros, relativamente a hora legal de São Tomé e Príncipe, decidiu que a partir de 1 de Janeiro de 2019 será reposta a nossa hora secular” I don't read Portuguese but this sounds like a change. Old news? I don't see any discussion of this in https://mm.icann.org/pipermail/tz/2018-December/thread.html

4 4

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

Dec. 29, 2018

The 2018h 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: Qyzylorda, Kazakhstan moved from +06 to +05 on 2018-12-21. New zone Asia/Qostanay because Qostanay, Kazakhstan didn't move. Metlakatla, Alaska observes PST this winter only. Guess Morocco will continue to adjust clocks around Ramadan. Add predictions for Iran from 2038 through 2090. Changes to future timestamps Guess that Morocco will continue to fall back just before and spring forward just after Ramadan, the practice since 2012. (Thanks to Maamar Abdelkader.) This means Morocco will observe negative DST during Ramadan in main and vanguard formats, and in rearguard format it stays in the +00 timezone and observes ordinary DST in all months other than Ramadan. As before, extend this guesswork to the year 2037. As a consequence, Morocco is scheduled to observe three DST transitions in some Gregorian years (e.g., 2033) due to the mismatch between the Gregorian and Islamic calendars. The table of exact transitions for Iranian DST has been extended. It formerly cut off before the year 2038 in a nod to 32-bit time_t. It now cuts off before 2091 as there is doubt about how the Persian calendar will treat 2091. This change predicts DST transitions in 2038-9, 2042-3, and 2046-7 to occur one day later than previously predicted. As before, post-cutoff transitions are approximated. Changes to past and future timestamps Qyzylorda (aka Kyzylorda) oblast in Kazakhstan moved from +06 to +05 on 2018-12-21. This is a zone split as Qostanay (aka Kostanay) did not switch, so create a zone Asia/Qostanay. Metlakatla moved from Alaska to Pacific standard time on 2018-11-04. It did not change clocks that day and remains on -08 this winter. (Thanks to Ryan Stanley.) It will revert to the usual Alaska rules next spring, so this change affects only timestamps from 2018-11-04 through 2019-03-10. Change to past timestamps Kwajalein's 1993-08-20 transition from -12 to +12 was at 24:00, not 00:00. I transcribed the time incorrectly from Shanks. (Thanks to Phake Nick.) Nauru's 1979 transition was on 02-10 at 02:00, not 05-01 at 00:00. (Thanks to Phake Nick.) Guam observed DST irregularly from 1959 through 1977. (Thanks to Phake Nick.) Hong Kong observed DST in 1941 starting 06-15 (not 04-01), then on 10-01 changed standard time to +08:30 (not +08). Its transition back to +08 after WWII was on 1945-09-15, not the previous day. Its 1904-10-30 change took effect at 01:00 +08 (not 00:00 LMT). (Thanks to Phake Nick, Steve Allen, and Joseph Myers.) Also, its 1952 fallback was on 11-02 (not 10-25). This release contains many changes to timestamps before 1946 due to Japanese possession or occupation of Pacific/Chuuk, Pacific/Guam, Pacific/Kosrae, Pacific/Kwajalein, Pacific/Majuro, Pacific/Nauru, Pacific/Palau, and Pacific/Pohnpei. (Thanks to Phake Nick.) Assume that the Spanish East Indies was like the Philippines and observed American time until the end of 1844. This affects Pacific/Chuuk, Pacific/Kosrae, Pacific/Palau, and Pacific/Pohnpei. Changes to past tm_isdst flags For the recent Morocco change, the tm_isdst flag should be 1 from 2018-10-27 00:00 to 2018-10-28 03:00. (Thanks to Michael Deckers.) Give a URL to the official decree. (Thanks to Matt Johnson.) Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018h.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018h.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018h.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 7db91b70ae4ce85c7520960840fc957541a3bdb0 dated 2018-12-23 17:59:32 -0800 and tagged '2018h' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: e30ee77432a07a4f206f7a494bd3b4ed16805017d9907fa42bfc8b952332a3c63e2c344b99ef6b32cae70b0ba25c2068b69f65afec3378f9ce56194d85df1ef8 tzcode2018h.tar.gz 2c72fc2737b896f60c96cd2df80ede19c0fa80c4cd2fac350d13c673e851aac54c6cc7c8a865edb3f325fc0139b850b4b98a29d97967b643bbfaa7e8fa9b4937 tzdata2018h.tar.gz 5c64b894033d81a82d11177b991dbe93b5ab596453cf7c0f29dcab527c5d061dd56e03460091f938d9685d200c4c79bf082dc557eaf7b8ab370dfad9e43fe4e1 tzdb-2018h.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpIACgkQ7ZfpDmKq fjTNyRAAlGlcaHLrGaiGgr8sKAI3Hd53zu53BUhTJjS8FO9WF2OxgDKkj0Yqrzuo CHz3eUuIIYJ2X7BLuCAKY842K2je5goS20jqEirlbEhg1Pd0uU/8FtC4L80l68y8 8LxKEMcYY7Ec9tTraZYNIKmFxL3s9v1vXwiF94FbiPftNALNUnYS2SvvBaVybo66 Tr1DUHz00qRDzZpi9+90FllpOcMOU4PHsds/QpsGd3Q5d7lnQpUCFNN3pxORN4/T LxCJVyBjxJ5zl+G1FVxVjJL1Hrh3VpQkV3MyplmDG9eBwOXBbwLITqvL66i1slpX o9rN0cSNlte1yoxZwcvWKV+2mDGeGJ2P4Hbzq11ZNZ+ZhKZMdu6mMd48hhcCCQqy 5BkIPLEI++8IGZUyoIWEa/wW2djmym1p5a1jUxmI2L/LfwztVnZz+qtPB0khFP8a lqIDXRSXv/ScGpL7TWaL7Rmc5V755/0lGy6s44pCYWS9SBhW29VRFsEkMRl8yAKM R/cRkWbiCvDvgDiZwdtQvCdKPB+HBebIMnyJb7IDKKYpqYRkdfpuXp2lq8xRtfoZ OhZKPYG8D9LC9ovFiRhsdYUde6Oou1DYUPayXZ8/zVXTVnswMaVh4cIoxU9pecUY hYqyE3iwCc0YpWTU47DzruY/sXSmaITxFPF0c24DbQkAhpkRKUk= =NHCF -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpIACgkQ7ZfpDmKq fjT95BAAifCqZHNjQ+Rm8nG3PXu9+FYuqn8+ezIH5vjhcfdQepYDsC5q91+Echx3 2OQpkOB4sjBiHSeeYzu4j6ULm8bvMj+FNGVQz+LXR6AUfnMwGhLM5pyGtHo3VJDh uSUfyzLb505FxT54NyINlr2gPuV5CSP98IQQRAqzjUIxRRC78GDXA+brOjObB/d3 A0apTx0IKu/KiepbSQ2wetM9d92Brb366iPnp1aZQKuiuC4k2nGSC5zo3Jr4HLzA CYL6YVTQuqc1UMyhqBy5yJJExsmheo3Uuz2Vh6bi6FYFNxNiOMLfIfgVZyeNBAk/ 0I9Y3wWh65d4+GJwyOEdNACKqWBfWfHgOwGtheCXBMM1DDypIh7+GQsKo9zOs0n6 Kn7byx4/YMLpqPpd3J7PF5cWJtocVJUivi9RTe7n2zRAoqCT1+vM6YcXsdwbPn1g yI/iBvjvzo10k5fU2dtkRjyKO97kn+KXALVYEnsaUsAHtO3KlppSDYtsxZo37k3B y7ZWmfrFkSLI5U5xKszziLYF362FnEeRKVzNOPOGjs2kJpiu/alGpdxHJKDAtpms paszof0NglEzO+jx9OOcxNHZOGjWRKRxv5BSZw1io8q87xV+eyiGR38zFCLnG/9L udZRijZ5tp7JlxJ6XrqUKPrwDwnlPGCO5G+W2sVsQyEQYKiZZOo= =J8dK -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpQACgkQ7ZfpDmKq fjRaOhAAphyNU0lclXv7YaLXm9SusHp8ElpMN/Okh2BK5dwSfHtECVow5hzKccXA 8TC9srW5DDAUEa08Qv20FNODYTk5ukpphk2IDiUMrjzy+99gkzPd5e9sBC8PHsUU HoiFMIHvsge0WhZMpNalrrdO8tjkRRL4sPui+pvO87cNGNOGJruNUA7BHh/tjugr EP2sDBsB+0tfpDAVzKnf3bvS/ZT/vS4imHRZ+TH5szRgSHWrZYt1IH26b4TmRr1y xfeUS2UsfgiEtTt8/CKwChGHh/ZB+Rp+P7iWQjG15fLrtd7+Of7thRi2BxKsCT1a EXRaBfRkn1HSeYL+a5qSGNrZX4ZKzfWuRlJWCZhoogyZ1tyd2XVnJ5XneKwMaAKH bqdo+wscYB7YwGZXL3LX7tXJzggkXjxljggUHs0eotsLjfxaHVr/tcK8nuz8DNVK gTEmczpQ8ygsycVvkH2Cseh7ETMLjazTD+NTh69jLWCG1At9kGNwoekeJb+Rf7we ErDGPOE0+rp3AXQAxnu8FaWBBwCfqsvH8cls5/v3jBwtN75GM0b8Ui+HfleejTS1 SyoQsQMqVdvtXuZG/qM+FQyIXAkZ+WR+36FotL55GPT58hZhBJL+WlgyL6B30HUI VNBAfdkOdgwN30D20guM68JRGs5dqMr+gg+sajOPgMnl2xk7F30= =Lqgu -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018h/tzdata2018h-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018h/tzdata2018h-rearguard.tar.… with the following SHA-512 and GPG checksums: 73ed819507ed966ea962a6adb5fbaeff4f416036573757b893d29f7c62f5c9b04c5cebea7e52cd0f502cd49195499719ca76f57e9883bb4de6dadeb87b51ca71 tzdata2018h-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlwgPpMACgkQ7ZfpDmKq fjRcUw//UnGM+2HY12mtu6AJ2aYb1PjzUv0X6FADua7YDOyXjz5i0sXXi7D2EPa0 qeZuk4x0Zr2EN8vt3Xy9jHuhpLr8bAJn8cwb71sNm+tSdDvKLoJJcokj7QKjBWr9 MTprLgI0guOhOdinSFFnHaumPtXzhOjrYJiy40Qw4RMZH1sTZhPWrSK3kZlpJj+t zGYbskaJtXB1LhlQbUtgepxyV5AaJfz4owYIbYh+Uv0gGqDzJc94BCVxM89LN52l CCHzt3zrsMicBle4QhyRo1qk6D4DDGVq2+AXLMyq8oMQvNvtzFpw34CbsYLaNL9X 3kdCqV723lbTwpqKEcivRhCCc3m2i/0rt1X1nkReXdzior3AJpAtG48pcb/F3/l4 Hc2Af8uohIhYBpw0Tm+x6YL2u1+ZR52rJtzt5UVcWV3ToyJJw1tTCijxxEHd/xoh 6xhtvYVPKkKabQqHUQnp0YKqV6DF83pMeQ4MLtSp7LPrNbxL9y5WvjAMhjzeQAB9 8qtDUQ9tPlSgMvs7EO7LCfUuPji5pPXoWn4caYn3KkFQPYSS0FYTv+RvBlZVjaAJ 84KTx87fD6ren0/XEyIYhtN30TxNng/KODFcmM4KM2+Jk5eVKktrY7N3uZZBEpQ8 H9i/8giTDGPE/hlI3LN1E15FPuC6o0PGYaDUT8Mkk4CjazJEPA8= =9v4P -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Time zone offset changed in Qyzylorda, Kazakhstan
by Askar Timirgazin Dec. 29, 2018

Dec. 29, 2018

Hello there, please consider that according to https://legalacts.egov.kz/npa/view?id=2000931 time offset for zone Asia/Qyzylorda from 21 Dec 2018 must be set to UTC+5 instead of UTC+6 -- Best regards, Askar Timirgazin

2 1

Update with rearguard not refreshed version of tzdata info
by Joel da Rosa Dec. 28, 2018

Dec. 28, 2018

Hello! I executed the steps: 1 - java -jar tzupdater.jar -f -l https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.… 2 - java -jar tzupdater.jar -V Result of step 2: "tzupdater version 2.2.0-b01 JRE tzdata version: tzdata2018g tzupdater tool would update with tzdata version: tzdata2018g" It's correct? My environment: Linux Ubuntu 64 java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) -- Att, JOEL DA ROSA

2 1

America/Mexico_City incorrect DST end time for 2018.
by demxic Dec. 28, 2018

Dec. 28, 2018

I would like to draw your attention to the fact that Mexico's City Daylight time ended on October 28 2018 03:00 AM local time. That is the exact moment when clocks moved backward to 02:00 AM. Somehow your database marks DST end at 02:00 AM moving clocks backward to 01:00 AM. Please note that this is incorrect. Is it possible to correct for this? -- *My country is the world and my religion is to do good. *Thomas Paine

3 6

1932 IAU Commission on Time: abolish Summer Time
by Steve Allen Dec. 28, 2018

Dec. 28, 2018

Bulletin Horaire, vol. 4, no. 70 has a synopsis of time-related activities at the 4th General Assembly of the IAU at Cambridge Massachusetts in 1932. Page 399 has the end of the Commission 31 (Time) meeting where Kiyofuso Sotome, director of Tokyo Astronomical Observatory, proposed two items not on the printed agenda. Item 2 was "Immediate abolition of the Summer Time." The commission deemed that it could not take any action on this. http://adsbit.harvard.edu//full/1932BuBIH...4..391./0000427.000.html The same text is found in Transactions of the IAU vol. 4 page 253. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

1 0

[PATCH 1/2] * tz-art.html: Add a few IMDb URLs and standardize format.
by Paul Eggert Dec. 24, 2018

Dec. 24, 2018

--- tz-art.html | 27 +++++++++++++-------------- 1 file changed, 13 insertions(+), 14 deletions(-) diff --git a/tz-art.html b/tz-art.html index c98e9c4..edddae0 100644 --- a/tz-art.html +++ b/tz-art.html @@ -36,19 +36,15 @@ there is a reference to British Double Summer Time. The time does not play a large part in the plot; it's just a passing reference to the time when one of the characters was supposed to have died (but didn't). -The IMDb page is at -<a href="http://us.imdb.com/title/tt0038733/"> -http://us.imdb.com/title/tt0038733/ -</a>. (Dave Cantor) +(<a href="http://us.imdb.com/title/tt0038733/">IMDb entry.</a>) +(Dave Cantor) <li> The 1953 railway comedy movie <em>The Titfield Thunderbolt</em> includes a play on words on British Double Summer Time. Valentine's wife wants him to leave the pub and asks him, "Do you know what time it is?" And he, happy where he is, replies: "Yes, my love. Summer double time." -IMDb page: -<a href="http://us.imdb.com/title/tt0046436/"> -http://us.imdb.com/title/tt0046436/ -</a>. (Mark Brader, 2009-10-02) +(<a href="http://us.imdb.com/title/tt0046436/">IMDb entry.</a>) +(Mark Brader, 2009-10-02) </li> <li> The premise of the 1999 caper movie <em>Entrapment</em> involves computers @@ -60,10 +56,8 @@ a gigantic computerized theft. To achieve this, at one location the crooks interfere with the microwave system supplying time signals to the computer, advancing the time by 0.1 second each minute over the last hour of 1999. (So this movie teaches us that 0.1 × 60 = 10.) -IMDb page: -<a href="http://us.imdb.com/title/tt0137494/"> -http://us.imdb.com/title/tt0137494/ -</a>. (Mark Brader, 2009-10-02) +(<a href="http://us.imdb.com/title/tt0137494/">IMDb entry.</a>) +(Mark Brader, 2009-10-02) </li> <li> One mustn't forget the @@ -79,12 +73,15 @@ Cube," first aired 1958-02-24, had Superman convincing the controllers of the Arlington Time Signal to broadcast ahead of actual time; doing so got a crook trying to be declared dead to emerge a bit too early from the titular enclosure. +(<a href="https://www.imdb.com/title/tt0506628/">IMDb entry</a>.) </li> <li> -"The Chimes of Big Ben", <em>The Prisoner</em>, episode 2, ITC, 1967-10-06. +"<a href="https://en.wikipedia.org/wiki/The_Chimes_of_Big_Ben">The Chimes +of Big Ben</a>", <em>The Prisoner</em>, episode 2, ITC, 1967-10-06. Our protagonist tumbles to the fraudulent nature of a Poland-to-England escape upon hearing "Big Ben" chiming on Polish local time. +(<a href="https://www.imdb.com/title/tt0679185/">IMDb entry.</a>) </li> <li> "The Susie", <em>Seinfeld</em>, season 8, episode 15, NBC, 1997-02-13. @@ -196,7 +193,9 @@ Nick Enright, <em>Daylight Saving</em>, 1989. A fast-paced comedy about love and loneliness as the clocks turn back. </li> <li> -Umberto Eco, <em>The Island of the Day Before</em> +Umberto Eco, +<a href="https://en.wikipedia.org/wiki/The_Island_of_the_Day_Before"><em>The +Island of the Day Before</em></a> (<em>L'isola del giorno prima</em>), 1994. "...the story of a 17th century Italian nobleman trapped near an island on the International Date Line. Time and time zones play an integral -- 2.19.2

1 1

Time zone Asia/Qyzylorda
by Alexander Konzurovski Dec. 20, 2018

Dec. 20, 2018

Dear maintainers of the Time Zone Database! I would like to inform you that Qyzyolrda Region (Asia/Qyzylorda) is changing its time zone from UTC+6 to UTC+5 effective December 21st, 2018. The legal document is located here: http://adilet.zan.kz/rus/docs/P1800000817 (russian language). Accordingly resolution the time zone must be changed on December 20 18:00 UTC. -- Alexander Konzurovski

3 5

Time zones in the news
by Arthur David Olson Dec. 20, 2018

Dec. 20, 2018

"Time Lords: a history of authoritarian time changes" by Elena Goukassian in Lapham's Quarterly. (Thanks to Nikita S--@singareddynm on Twitter--for the pointer.) https://www.laphamsquarterly.org/roundtable/time-lords ---ado

2 1

[PROPOSED] Metlakatla goes back to Alaska time next year
by Paul Eggert Dec. 17, 2018

Dec. 17, 2018

* NEWS: Mention this. * northamerica (America/Metlakatla): Go back to Alaska time next year at the first opportunity. --- NEWS | 6 ++++-- northamerica | 8 +++++++- 2 files changed, 11 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index abc6094..667cec7 100644 --- a/NEWS +++ b/NEWS @@ -25,8 +25,10 @@ Unreleased, experimental changes Changes to past and future timestamps Metlakatla moved from Alaska to Pacific standard time on 2018-11-04. - It did not change clocks that day and is now on -08 indefinitely, - reverting to its form before fall 2015. (Thanks to Ryan Stanley.) + It did not change clocks that day and remains on -08 this winter. + (Thanks to Ryan Stanley.) It will revert to the usual Alaska + rules next spring, so this change affects only timestamps + from 2018-11-04 through 2019-03-10. Change to past timestamps diff --git a/northamerica b/northamerica index 17597e2..faaf979 100644 --- a/northamerica +++ b/northamerica @@ -605,6 +605,11 @@ Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02 # They will be gmtoff=-28800 year-round. # https://www.facebook.com/141055983004923/photos/pb.141055983004923.-2207520… +# From Paul Eggert (2018-12-16): +# In a 2018-12-11 special election, Metlakatla voted to go back to +# Alaska time (including daylight saving time) starting next year. +# https://www.krbd.org/2018/12/12/metlakatla-to-follow-alaska-standard-time-a… + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Juneau 15:02:19 - LMT 1867 Oct 19 15:33:32 -8:57:41 - LMT 1900 Aug 20 12:00 @@ -632,7 +637,8 @@ Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 19 15:44:55 -8:00 US P%sT 1983 Oct 30 2:00 -8:00 - PST 2015 Nov 1 2:00 -9:00 US AK%sT 2018 Nov 4 2:00 - -8:00 - PST + -8:00 - PST 2019 Mar Sun>=8 3:00 + -9:00 US AK%sT Zone America/Yakutat 14:41:05 - LMT 1867 Oct 19 15:12:18 -9:18:55 - LMT 1900 Aug 20 12:00 -9:00 - YST 1942 -- 2.17.1

1 0

FW: [Bug time/23976] trunk/timezone/zdump.c:811: missing call to va_end ?
by David Binderman Dec. 14, 2018

Dec. 14, 2018

Hello there, Forwarded bug report ________________________________________ https://sourceware.org/bugzilla/show_bug.cgi?id=23976 --- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- This code is imported from external sources and not modified locally in glibc. Please report your concern to tz(a)iana.org, not here. -- You are receiving this mail because: You reported the bug.

3 3

Error in the Time Zone Database
by serhii.demediuk＠cyberpolice.gov.ua Dec. 7, 2018

Dec. 7, 2018

Cyberpolice Department of National Police of Ukraine presents its compliments and wish to inform your organization regarding the following recent change. Information posted at https://www.iana.org/time-zones suggests that the latest release of the time zone database (version from 10/26/2018), states that Crimea (Ukrainian Autonomous Republic of Crimea) belongs to the time zone "MSK" and is marked with the country code "RU". This information was found in the archive, which contains the full description of the data, codes and applications, and is located at https://data.iana.org/time-zones/releases/tzdb-2018g.tar.lz. Information about the code of Crimea was found in the file "zone.tab" within the specified archive. We consider it necessary to draw your attention to the fact that Crimea is a temporarily occupied part of Ukraine. This fact is generally acknowledged by the international community, which is confirmed by a number of international legal document, including UN General Assembly resolution. Thus, by referring Crimea with the country code "RU", your organization actually accepts and supports the aggressive actions of the Russian Federation who’s armed forces annexed this part of Ukraine. Such recognition may be considered as a criminal offense by the Ukrainian criminal law and we will be obliged to start formal criminal proceedings as it is stipulated in article 110 of the Criminal Code of Ukraine "Infringement of territorial integrity of Ukraine". As you probably know, the aggression of the Russian Federation against Ukraine is still ongoing and any ambiguous decision by countries or international organizations is used by the authorities of the aggressor country to justify their actions. We would like to add that there are Ukrainian citizens still living in Crimea and adhere to the legislation of Ukraine. For their beliefs, such citizens are persecuted by the authorities of Russian Federation. International support for Ukrainian citizens in their aspiration to renew the territorial integrity of Ukraine is extremely important, and in this case your organization can play a positive role. We understand the apolitical status of your organization and respect the existing rules for determining of the actual time zone, but considering the international legal status of Crimea, which is part of Ukraine, we propose to correct this mistake and to change the current version of the time zone database in order to determine that the country code of Crimea is «UA». Best regards, Head of the Cyberpolice Department of the National Police of Ukraine Serhii Demediuk tel.: +380443743738 e-mail: serhii.demediuk(a)cyberpolice.gov.ua Ukraine, Kyiv

3 3

posix for asia/tehran is wrong
by Mark Nov. 30, 2018

Nov. 30, 2018

I've been adding DST time zone to espurna (https://github.com/xoseperez/espurna/pull/1295) All dst entries but asia/tehran, use Mm.n.d format to specify dst dates. The Tehran use 'Jn': "Asia/Tehran","<+0330>-3:30<+0430>,J80/0,J264/0" When I implement this 'J' format, I came out a day short. From https://en.wikipedia.org/wiki/Iran_Standard_Time: The Iranian DST starts on March 22 and ends on September 22 each year with the exception of leapyears in which the DST starts and ends one day prior. Year DST Start Date and Time DST End Date and Time *2014* Sat, Mar 22, 0:00 AM Mon, Sep 22, 0:00 AM *2015* Sun, Mar 22, 0:00 AM Tue, Sep 22, 0:00 AM *2016* Mon, Mar 21, 0:00 AM Wed, Sep 21, 0:00 AM *2017* Wed, Mar 22, 0:00 AM Fri, Sep 22, 0:00 AM *2018* Thu, Mar 22, 0:00 AM Sat, Sep 22, 0:00 AM This mean Tehran should be "Asia/Tehran","<+0330>-3:30<+0430>,80/0,264/0". The 'n' format, which counts 29 Feb, and starts count from 0, so would not come up a day short on non-leap years.

4 5

[PROPOSED] * northamerica: Herbert Copeland stops time.
by Paul Eggert Nov. 30, 2018

Nov. 30, 2018

--- northamerica | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/northamerica b/northamerica index e590a30..17597e2 100644 --- a/northamerica +++ b/northamerica @@ -792,6 +792,22 @@ Zone America/Boise -7:44:49 - LMT 1883 Nov 18 12:15:11 # For a map of Indiana's time zone regions, see: # https://en.wikipedia.org/wiki/Time_in_Indiana # +# From Paul Eggert (2018-11-30): +# A brief but entertaining history of time in Indiana describes a 1949 debate +# in the Indiana House where city legislators (who favored "fast time") +# tussled with farm legislators (who didn't) over a bill to outlaw DST: +# "Lacking enough votes, the city faction tries to filibuster until time runs +# out on the session at midnight, but rural champion Rep. Herbert Copeland, +# R-Madison, leans over the gallery railing and forces the official clock +# back to 9 p.m., breaking it in the process. The clock sticks on 9 as the +# debate rages on into the night. The filibuster finally dies out and the +# bill passes, while outside the chamber, clocks read 3:30 a.m. In the end, +# it doesn't matter which side won. The law has no enforcement powers and +# is simply ignored by fast-time communities." +# How Indiana went from 'God's time' to split zones and daylight-saving. +# Indianapolis Star. 2018-11-27 14:58 -05. +# https://www.indystar.com/story/news/politics/2018/11/27/indianapolis-indian… +# # From Paul Eggert (2007-08-17): # Since 1970, most of Indiana has been like America/Indiana/Indianapolis, # with the following exceptions: -- 2.17.1

1 0

Timezone history for some Pacific Islands.
by Phake Nick Nov. 30, 2018

Nov. 30, 2018

>From a Japanese wiki site https://wiki.suikawiki.org/n/南洋群島の標準時 there are some time change history about Pacific Islands that are not included in the tz database. Mainly, the history of time used in those islands during, before and after Japanese administration, and also DST used in Guam during 1960s and 1970s. For "Southern Islands" (modern region of Mariana + Palau + Federation of Micronesia + Marshall Islands): * A 1906 Japanese magazine shown the Caroline Islands and Mariana Islands who was occupied by Germany at the time as GMT+10, together with the like of German New Guinea. However there is a marking saying it have not been implemented (yet). No further information after that were found. * Japan invaded those islands in 1914, and records shows that they were instructed to use JST at the time * 1915 January telecommunication record on the Jaluit Atoll shows they use the meridian of 170E as standard time (GMT+11:20), which is similar to the longitude of the atoll. * 1915 February record say the 170E standard time is to be used until February 9 noon, and after February 9 noon they are to use JST. * However these are time used within the Japanese Military at the time and probably does not reflect the time used by local resident at the time (that is if they keep their own time back then) * In January 1919 the occupying force issued a command that split the area into three different timezone with meridian of 135E, 150E, 165E (JST+0, +1, +2), and the command was to become effective from February 1 of the same year. Despite the target of the command is still only for the occupying force itself, further publication have described the time as the standard time for the occupied area and thus it can probably be seen as such. ** Area that use meridian of 135E: Palau and Yap civil administration area (Southern Islands Western Standard Time) ** Area that use meridian of 150E: Truk(Chuuk) and Saipan civil administration area (Southern Islands Central Standard Time) ** Area that use meridian of 165E: Ponape(Pohnpei) and Jaluit civil administration area. (Southern Islands Eastern Standard Time) ** In the next few years Japanese occupation of those islands have been formalized via League of Nation Mandate (South Pacific Mandate) and formal governance structure have been established, these district [become subprefectures] and timezone classification have been inherited as standard time of the area. ** Saipan subprefecture include Mariana islands (exclude Guam which was occupied by America at the time), Palau and Yap subprefecture rule the Western Caroline Islands with 137E longitude as border, Truk and Ponape subprefecture rule the Eastern Caroline Islands with 154E as border, Ponape subprefecture also rule part of Marshall Islands to the west of 164E starting from (1918?) and Jalnuit subprefecture rule the rest of the Marshall Islands. * And then in year 1937, an announcement was made to change the time in the area into 2 timezones: ** Area that use meridian of 135E: area administered by Palau, Yap and Saipan subprefecture (Southern Islands Western Standard Time) ** Area that use meridian of 150E: area administered by Truk(Chuuk), Ponape(Pohnpei) and Jaluit subprefecture (Southern Islands Eastern Standard Time) * Another announcement issued in 1941 say that on April 1 that year, standard time of the Southern Islands would be changed to use the meridian of 135E (GMT+9), and thus abolishing timezone different within the area. * Then Pacific theater of WWII started and Japan slowly lose control on the island. The webpage I linked above contain no information during this period of time. Guam Island was briefly annexed by Japan during this period of time [year 1941-1944], however there are no detailed information about what time it use during that period. It would probably be reasonable to assume Guam use GMT+9 during that period of time like the surrounding area. * After the end of WWII, in 1946 February, a document written by the (former?) Japanese military personnel describe there are 3 hours time different between Caroline islands time/Wake island time and the Chungking time, which would mean the time being used there at the time was GMT+10. * After that, the area become Trust Territories of the Pacific Islands under American administration from year 1947. The site listed some American/International books/maps/publications about time used in those area during this period of time but they doesn't seems to be reliable information so it would be the best if someone know where can more reliable information can be found. * The site also pointed out that currently tzdata say Pacific/Kwajalein switched from GMT+11 to GMT-12 in 1969 October without explanation, however an 1993 article from NYT say it synchorized its day with US mainland about 40 years ago and thus the switch should occur at around 1950s instead. * Also, the NYT article linked in that website say the jump from GMT-12 to GMT+12 in year 1993 skipped Saturday that day, however the comment in tz database from that year say it skipped Friday. That seems to be an inconsistency that should be investigated, and the comment should probably be annotated accordingly if the comment was not accurate ANd then additional note for Bonin Islands: While not part of the Southern Islands, in the period of time during 1952-1968, Bonin Islands were placed under American administration. It would probably be worth investigating whether they're following the Japanese time or the Mariana time or some other time standard at the time. And then for Guam: * Currently tz database say Guam stopped using local mean time at 1901 but a 1902 earthquake report on Guam seems to be using LMT in the report when compares to the time the earthquake recorded on the Philippines (the site note that it take times for earthquake wave to transmit and thus the time different between records in different place would not be identical to the time different) ** The site say Shanks used 1901 end date for LMT time for a number of places around the world, probably using them as placeholder. Maybe those 1901 end date should be nuked from tz database? * A Japanese magazine in 1906 say Guam's time is "1.5 hours earlier than Japan" and "use 145 degree E meridian" which are contradictory to each other as 145E meridian mean GMT+9:40 and that is not 1.5 hours earlier than Japan. * And then there are some different records about Guam used GMT+9:30 at the time but each of those documents seems to give different transition time for when they give up :30 time different and move to GMT+10. But it most likely occurred before 1927 as a map published by US Navy that year shows Guam as using GMT+10, which appears to be credible as Guam was under US Military administration at the time. * As mentioned above, Guam was invaded by Japan during year 1941-1944. It's unclear about did they shifted the clock to match the surrounding islands during this period of time. * Then in year 1959 there's a daylight saving time act passed for Guam. There is a table on the site that include list an link to time and order for implementation and cancellation of DST at Guam but the implementation time seems to be all over the place according to the list. The last time the DST was implemented in Guam according to the table seems to be 1977 although I am not sure about the completeness of the table. If so then maybe a new zone for CNI would need to be created as it's after 1970 and the DST should be applicable to Guam only?

3 3

Question about the UNTIL fields
by Marcos Passos Nov. 29, 2018

Nov. 29, 2018

Hello everyone, I'm working on a TZDB parser for a PHP project and reading the zic8.txt I came across with the following information: The month, day, and time of day have the same format as the IN, ON, and AT > fields of a rule However, I could not find any Zone line in the latest version of the TZDB containing relative dates, such as "lastSun" or "sun>=5", but only absolute dates. Is this a mistake in the documentation or are relative dates actually supported on those lines but have never been used? - Marcos

3 6

Stop
by The OneCloud Nov. 29, 2018

Nov. 29, 2018

Stop

2 1

query regarding issue will updating open JDK timezone info with tzdata2018g
by Dhanusha, Pb (Nokia - IN/Bangalore) Nov. 27, 2018

Nov. 27, 2018

Hi, We are facing issues while updating open JDK timezone with tzdata2018g with the below error. #/usr/bin/java -jar /root/tzupdater.jar -l file:/root/tzdata2018g.tar.gz Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:212) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:226) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:780) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Could you please help us with this. Regards, Dhanusha

4 4

Help - Morocco timezone wrong since 28 Oct 2018
by Heidi Hendry Nov. 25, 2018

Nov. 25, 2018

Hi, Based on this version of the TZ values: http://twiki.org/cgi-bin/xtra/tzdate?tz=Africa/Casablanca the Africa/Casablanca timezone is wrong. Morocco abruptly changed the timezone (see this BBC article: https://www.bbc.com/news/world-africa-45995634 ) and Android phones and other UX distributions appear to be wrong every since. Africa/Casablanca is +1 GMT now, and there is NO daylight savings any more. Please, please could you fix this in TZ so that it distributes out for other updates? Regards Heidi Hendry

2 1

Correcting daylight-savings time for central Missouri prior to 1967
by Jane Eisenstein Nov. 24, 2018

Nov. 24, 2018

I was born and raised in central Missouri and know most of Missouri did not observe daylight-savings time prior to 1967. Areas close to Kansas City or St. Louis did observe daylight-savings time prior to 1967. I’ve also attached supporting scans of Missouri daylight-savings time information from the 1991 revision of Time Changes in the U.S.A. by Doris Chase Doane. The timezones database appears to assume all Missouri observed daylight savings whenever Chicago, Illinois did. I would like to correct this mistake, but am not clear how to go about doing so. Can the daylight-savings time be set at the state level, then overridden for particular communities? Best regards, Jane Eisenstein

9 25

Nauru Time history
by Phake Nick Nov. 19, 2018

Nov. 19, 2018

* Currently, the tz database say Nauru use LMT until 1921, and then switched to GMT+11:30 for the next two decades. * However, a number of timezone map published in America/Japan back then showed its timezone as GMT+11 per https://wiki.suikawiki.org/n/ナウルの標準時 * And it would also be nice if the 1921 transition date could be sourced. * The tz database currently show Nauru use GMT+9 within the time of 1942 Mar 15 and 1944 Aug 15, however the correspondence is not exact as Nauru was still under Japanese rule until year 1945. And I don't think it's likely for such switch to occur during WWII so it's probably an error. * Currently tz database shows the +11:30 -> +12 transition date as 1979 May, however the "Nauru Standard Time Act 1978 Time Change" http://ronlaw.gov.nr/nauru_lpms/files/gazettes/4b23a17d2030150404db7a5fa587… based on "Nauru Standard Time Act 1978 Time Change" http://www.paclii.org/nr/legis/num_act/nsta1978207/ defined that "Nauru Alternative Time" (GMT+12) should be in effect from 1979 Feb. Thus it appears that the current tz database transition time might be incorrect.

3 2

Hong Kong time 1941
by Phake Nick Nov. 18, 2018

Nov. 18, 2018

Today I went to check microfilm records stored at Hong Kong Public Library and found following situation that are inconsistent with tz database record. * Around April 1 1941, there're no news about DST on various newspapers that I checked. Time given for sunrise/sunset around the period are also continuous (as in they're minutes within each others on those days, indicating there are no change to time standard around 1941 April 1. * I have subsequently checked Hong Kong Observatory's site and the site now list the 1941 DST start date for Hong Kong as June 15. (url is same as the one in tz file but content is different from when the 2009 comment was made) I have not tried validating the info from those newspapers as I wasn't aware of the table's current content until I stopped using the library. * And then, on September 30 1941, according to Ta Kung Pao (Hong Kong edition), it was stated that fallback would occur on the next day (the 1st)'s "03:00 am (Hong Kong Time 04:00 am)" and the clock will fall back for a half hour. (03:00 probably refer to the time commonly used in mainland China at the time given the paper's background), after it was spring forward for an hour months ago. I cannot find out record of English newspaper from that day, but the sunrise/sunset time given by South China Morning Post for October 1st was indeed moved by half an hour compares to before. * After that, in December, the battle to capture Hong Kong started and the library doesn't seems to have any record stored about press during that period of time. Some media resumed publication soon after that within the same month, but there were not much information about time there. Later they started including a radio program guide when they restored radio service, explicitly mentioning it use Tokyo standard time, and later added a note saying it's half an hour ahead of the old Hong Kong standard time, and it also seems to indicate that Hong Kong was not using GMT+8 when it was captured by Japan. * Image of related sections on newspaper: 1941 September 30, Ta Kung Pao (Hing Kong) , "Winter Time starr tomorrow": https://i.imgur.com/6waY51Z.jpg (Chinese) 1941 September 29, South China Morning Post, Information on sunrise/sunset time and other things for September 30 and October 1: https://i.imgur.com/kCiUR78.jpg 1942 February 5, The Hong Kong News, Radio Program Guide: https://i.imgur.com/eVvDMzS.jpg

7 19

Higgins Time and TZ DB c.1886
by Brian Inglis Nov. 18, 2018

Nov. 18, 2018

Links to an interesting article and artifact referenced in comments on: https://www.jwz.org/blog/2018/08/higgins-time/ Arabian Flying Is Confusing article - Port Angeles Evening News, March 10, 1965, p. 4: https://newspaperarchive.com/port-angeles-evening-news-mar-10-1965-p-4/ Kendal & Dent's Time Chart of the World c.1886 - Evanion Catalogue - BL: https://www.bl.uk/catalogues/evanion/FullImage.aspx?EvanID=024-000002349&Im… -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.

2 2

Korean DST 1940s-1960s and other aspects of Korean Standard Time and other aspects of tz database
by Phake Nick Nov. 17, 2018

Nov. 17, 2018

1. According to official announcement from Korean government, the DST end date in South Korea should be 1955-09-08 without specifying time http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1956-09-29 without specifying time http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1957-09-21 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1958-09-20 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1959-09-19 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… 1960-09-17 24 o'clock http://theme.archives.go.kr/next/common/viewEbook.do?singleData=N&archiveEv… Contradicting the current tz database record that shows their end date as 00:00 of the next days. The effect should be same in almost all cases, but to be literally reflect the rule in tz database probably an update might be desirable. [Information via Suikawiki] 2. Regarding history of Korean time, there is a Korean wiki site https://namu.wiki/w/대한민국%20표준시 that say when Korea was using GMT+8:30 as standard time, the international aviation/marine/meteorological industry in the country refused to follow and continues to use GMT+9:00 for interoperability. Did the phenomenon actually occured back then and is there any further details about it? 3. Back in 2014 when Korean time history in tz database was discussed, the reliability of The International Atlas by Shanks was also being discussed. I checked the book on amazon.com and there's a review saying that the International Atlas say they've make up some information to fill holes in their research and use them to advance copyright claims to temporarily force tzinfo offline. I am not sure what happened back then in the year of 2011 when the comment was posted, but if that's true then tz database should probably be more actively removing anything related to Shanks from the database as those information are not fact and thus subject to copyright claims and thus cannot be released as public domain according to the license of tz database? Not to mention the accuracy of those data.

2 1

[PATCH] * tz-link.html: Mention Time4A.
by Paul Eggert Nov. 17, 2018

Nov. 17, 2018

--- tz-link.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tz-link.html b/tz-link.html index 956af52..3a3c96b 100644 --- a/tz-link.html +++ b/tz-link.html @@ -372,10 +372,12 @@ and time <abbr>API</abbr></a> contains a class Java 8 <code>java.time</code>, which its users should migrate to once they can assume Java 8 or later. It is available under the <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache License</a>.</li> -<li><a href="https://github.com/MenoData/Time4J/">Time4J – -Advanced date, time and interval library for Java</a> contains a class -<code>net.time4j.tool.TimezoneRepositoryCompiler</code> that compiles -<code><abbr>tz</abbr></code> source into a binary format. Time4J is +<li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and +time library for Android</a> and +<a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, +time and interval library for Java</a> compile +<code><abbr>tz</abbr></code> source into a binary format. +Time4A is available under the Apache License and Time4J is available under the <a href="https://www.gnu.org/copyleft/lesser.html"><abbr>GNU</abbr> Lesser General Public License (<abbr title="Lesser General Public -- 2.17.1

1 0

Re: [tz] Was there a 1971-12-31 23:59:60?
by Levine, Judah Dr. (Fed) Nov. 13, 2018

Nov. 13, 2018

Applying a time stamp to an event in an end-user application with nanosecond accuracy or precision is very difficult because of the problems of measuring the transmission delay from the source to the end-user and the latency in the end-user application. These problems are generally at least as large as knowing the accuracy of the source with respect to UTC or UTC(lab). Although all of these things can be characterized statistically, that is not of much use for a single event which cannot benefit from averaging. Note that post-processing may not be of much help in determining the jitter in the processing latency. The data in Circular T are what they are because of the administrative and processing delays in computing UTC. The UTC(lab) is now and will probably always be an extrapolation, which is limited by the flicker and random-walk processes of the laboratory time scale. Although the publication of UTCr has decreased the processing delay, it is a provisional scale and is not of much use at the nanosecond level. Judah Levine Time and Frequency Division NIST Boulder On: 10 November 2018 22:24, "Steve Allen" <sla(a)ucolick.org<mailto:sla@ucolick.org>> wrote: On Sat 2018-11-10T19:54:11+0000 Levine, Judah Dr. (Fed) hath writ: > It is quite challenging to compute time intervals in the pre-1972 > era. That depends on the required precision. It is still challenging to compute intervals to nanoseconds. That requires grabbing all the relevant issues of BIPM Circular T and similar publications of the particular source of time if they are not members of the BIPM atomic clock club. One hundred years ago it was challenging to compute intervals to centiseconds, and that was the reason for the creation of BIH. When Anna Stoyko retired from the BIH in 1965 she published one final analysis of all the BIH data from 1922 to 1963. She produced plots showing how the time services of observatories had improved. Those plots are reproduced here https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ucolick.… In order to gather these data the BIH had been monitoring the arrival times of radio broadcast time signals since 1922. The volumes of Bulletin Horaire have the numbers that show many ways that various national observatories and time services messed up (and messed around with) the time they were providing. The data in the issues of Bulletin Horaire are the nightmare of the tzdb because taken to the absurd limit they would require that tzdb encode the millisecond-scale differences between the legal civil times of every nation whose transmitters were monitored by BIH. > Different timing laboratories had slightly different values for this > final time step. The goal was to bring all of the real-time > realizations of UTC to the same time. Well, much closer than before, but if they were the same then the subsequent issues of BIH Bulletin Horaire and now BIPM Circular T would be much terser publications. -- Steve Allen <sla(a)ucolick.org<mailto:sla@ucolick.org>> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.ucolick.o… Hgt +250 m

1 0

CalConnect Public Time Zone Workshop on February 5 in Zurich, Switzerland
by Dave.Thewlis＠calconnect.org Nov. 12, 2018

Nov. 12, 2018

Please note that this is NOT an IETF event. CalConnect <http://www.calconnect.org/> will host a Public Time Zone Workshop on Tuesday afternoon, February 5th, during its conference at Google in Zürich, Switzerland <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019>. The Time Zone Workshop will be Tuesday February 5th from 13:30 to 17:30 at the Google facility <http://www.calconnect.org/events/calconnect-xliv-february-4-8-2019#location>. This workshop will be focussed on the potential impact of EU Summer Time changes and how the changes might be mitigated; please see our news release <http://www.calconnect.org/news/2018/10/30/calconnect-calls-eu-reconsider-ti…>. The workshop is open to the public but you must register in advance. There is no fee to attend the workshop. Attendees are invited to stay for a Welcome Reception following the workshop. More information will be provided as planning continues. The workshop is intended for anyone who needs to plan and prepare for this and other TZ/DST changes, in particular representatives from governments, industries affected by tz changes (travel, financial, health, device manufacturers, etc.), organizations deploying tz data, and organizations maintaining and updating tz data. Please register for this event at https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets… <https://www.eventbrite.com/e/eu-dst-timezone-change-public-workshop-tickets…>. We invite anyone who is interested in or concerned by the pending changes and how time zone change information might better be distributed and implemented to attend. Dave Thewli -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org <http://www.calconnect.org/> | Dave.Thewlis(a)calconnect.org <mailto:Dave.Thewlis@calconnect.org>

2 1

Re: [tz] Epic fail for DST fallback in hospital health records
by Hal Murray Nov. 12, 2018

Nov. 12, 2018

eggert(a)cs.ucla.edu said: > Gawande A. Why doctors hate their computers. The New Yorker. 2018-11-12. > https://www.newyorker.com/magazine/2018/11/12/why-doctors-hate-their-comput… Thanks for the heads up. In case anybody doesn't recognize the name, the A is Atul. He's a surgeon, and a very good writer. His first two books are collections of his New Yorker articles. My reading on this whole mess is that the medical community doesn't take testing software seriously. It may be as simple as senior executives with budget problems aren't willing to pay for testing because they don't understand that you have to do lots of it if you expect your systems to work reliably. For background, I highly recommend Gawande's Checklist Manifesto. He led a WHO project to get airplane style checklists used in hospital operating rooms. Not much about software, lots about checklists and the pilot/cockpit culture. For info about medical software, I recommend Robert Wachter's Digital Doctor. It's the study of a screwup at UCSF hospital that almost killed a kid. Lots of info about software and UIs and testing. https://www.goodreads.com/book/show/23131174-the-digital-doctor -- These are my opinions. I hate spam.

6 9

Re: [tz] Was there a 1971-12-31 23:59:60?
by Levine, Judah Dr. (Fed) Nov. 11, 2018

Nov. 11, 2018

Hello, The current integer leap second system did not exist before 1972. There were a number of fractional-second adjustments and there were also frequency adjustments starting in the 1950s, when the length of the cesium second was defined. The final time adjustment at the start of 1972 was intended to incorporate the integral of the previous frequency steps, since the frequency of UTC was set equal to the SI second at that time. It is quite challenging to compute time intervals in the pre-1972 era. Different timing laboratories had slightly different values for this final time step. The goal was to bring all of the real-time realizations of UTC to the same time. Judah Levine On: 09 November 2018 22:29, "Steve Allen" <sla(a)ucolick.org<mailto:sla@ucolick.org>> wrote: On Fri 2018-11-09T22:04:35-0700 Paul Gilmartin via tz hath writ: > Subject: [tz] Was there a 1971-12-31 23:59:60? No. There was a step of 0.107758 seconds in UTC(BIH) at 1972-01-01. This was the final sub-second step in coordinated broadcast time signals. for the step that was applied to UTC(USNO) see Time Service Announcement series 14 number 8 (1971-10-08) at https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fwww.ucolick.… -- Steve Allen <sla(a)ucolick.org<mailto:sla@ucolick.org>> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 &nb

2 1

Julian calendar
by Arthur David Olson Nov. 10, 2018

Nov. 10, 2018

Alas, while the current tz package can get the day-skipping part of the Julian-to-Gregorian calendar transition right, it gets pre-transition weekdays worng. (Getting them right would require special casing for big offsets from standard time in localtime.c) @dashdashado Script started on Sat, Nov 10, 2018 6:47:15 PM $ cat fake Zone America/Somewhere -268:56:02 - LMT 1752 Sep 3 -4:56:02 - LMT $ ./zic fake $ ./zdump -v America/Somewhere America/Somewhere -9223372036854775808 = NULL America/Somewhere -9223372036854689408 = NULL America/Somewhere Thu Sep 14 04:56:01 1752 UT = Sat Sep 2 23:59:59 1752 LMT isdst=0 gmtoff=-968162 America/Somewhere Thu Sep 14 04:56:02 1752 UT = Thu Sep 14 00:00:00 1752 LMT isdst=0 gmtoff=-17762 America/Somewhere 9223372036854689407 = NULL America/Somewhere 9223372036854775807 = NULL $ exit exit Script done on Sat, Nov 10, 2018 6:47:36 PM

1 0

Was there a 1971-12-31 23:59:60?
by Paul Gilmartin Nov. 10, 2018

Nov. 10, 2018

Hello, Judah Levine, I get unexpected results on Linux with TZ=right/Universal. I downloaded https://data.iana.org/time-zones/releases/tzdata2018g.tar.gz to try to find an explanation. There, I find, in: leap-seconds.list ... # # Updated through IERS Bulletin C56 # File expires on: 28 June 2019 # #@ 3770668800 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 2303683200 12 # 1 Jan 1973 2335219200 13 # 1 Jan 1974 2366755200 14 # 1 Jan 1975 ... I tend to believe this, but in: leapseconds ... # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist. # The correction (+ or -) is made at the given time, so lines # will typically look like: # Leap YEAR MON DAY 23:59:60 + R/S # or # Leap YEAR MON DAY 23:59:59 - R/S # If the leap second is Rolling (R) the given time is local time (unused here). Leap 1972 Jun 30 23:59:60 + S Leap 1972 Dec 31 23:59:60 + S Leap 1973 Dec 31 23:59:60 + S Leap 1974 Dec 31 23:59:60 + S ... Well, it's consistent with itself. 1971-12-31 23:59:60 is *before* 1972. But "leap-seconds.list" shows one more leap second that "leapseconds". I'm confused. Thanks, gil

3 2

Re: [tz] zdump bug?
by Paul Eggert Nov. 8, 2018

Nov. 8, 2018

On 10/28/18 9:23 PM, Paul Eggert wrote: > 'zdump New_York' is treated differently from 'zdump ./New_York'. It > might make sense for the code to try harder to treat only ".." > components differently. I installed the attached first patch to try to do that. The second attached patch silences a warning when running "make CFLAGS='$(GCC_DEBUG_FLAGS)' GCC_INSTRUMENT=" on my platform (I updated GCC recently).

3 5

Fwd:DST in Isral 1980 and 1984
by Astrodienst Team Nov. 7, 2018

Nov. 7, 2018

I received this document, which claims DST from 2 August 1980 - 13 Sept 1980 and 5 May 1984 - 25 August 1984. These two periods are not contained in the current TZ database, which has Rule Zion 1974 only - Jul 7 0:00 1:00 D Rule Zion 1974 only - Oct 13 0:00 0 S Rule Zion 1975 only - Apr 20 0:00 1:00 D Rule Zion 1975 only - Aug 31 0:00 0 S Rule Zion 1985 only - Apr 14 0:00 1:00 D Rule Zion 1985 only - Sep 15 0:00 0 S Rule Zion 1986 only - May 18 0:00 1:00 D Rule Zion 1986 only - Sep 7 0:00 0 S -------- Forwarded Message -------- Subject: Hello to astro system Date: Tue, 18 Sep 2018 03:18:57 +0300 From: Israel Tzaig <israheal(a)gmail.com> To: order(a)astro.ch <order(a)astro.ch> My name is Israel Sagi and I wanted to update you about daylight saving time in Israel. In 1980 there was a summer time from 3.8 to 13.9. This clock is not updated on your maps. Attached is a page from the Ministry of Interior for daylight saving time in Israel Thank you and hope you will use the information here. For a double check, I went to the archives of Yedioth Ahronoth (the most popular newspaper in Israel) in 1980 to make sure that there was a daylight saving time. I would be happy to send you a photo of the relevant articles (in Hebrew of course) נשלח מהאפליקציה 'דואר <https://go.microsoft.com/fwlink/?LinkId=550986>' עבור Windows 10

3 4

Epic fail for DST fallback in hospital health records
by Paul Eggert Nov. 6, 2018

Nov. 6, 2018

Sydney Lupkin reports in today's Kaiser Health News that Epic Systems, a leading system used for hospital health records, cannot handle DST fallbacks such as Sunday's fallback in the US. Lupkin writes: 'Carol Hawthorne-Johnson, an ICU nurse in California, said her hospital doesn’t shut down the Epic system during the fall time change. But she’s come to expect that the vitals she enters into the system from 1 a.m. to 2 a.m. will be deleted when the clock falls back to 1 a.m. One hour’s worth of electronic record-keeping “is gone,” she said.' Apparently competing systems have similar problems. Lupkin writes that many hospitals plan for Cerner (another major system) to be down after a DST fallback as well. Dr. Steven Stack, past president of the American Medical Association, said these DST glitches are "unacceptable", considering that Apple and Google seem to have dealt with seasonal time changes long ago. Although Lupkin didn't say so, credit should be given to the design for the Unix operating system that is the basis for these successes of Apple and Google, as Unix standardized on UTC in the early 1970s; apparently Epic and Cerner (both founded 1979) did not get the message. The moral of this story seems to be: arrange for your medical emergencies to occur some time other than early Sunday in the US. Source: Lupkin S. Like Clockwork: How Daylight Saving Time Stumps Hospital Record Keeping. Kaiser Health News. 2018-11-03. https://khn.org/news/like-clockwork-how-daylight-saving-time-stumps-hospita…

9 17

tzdata2018g.tar.gz failing to install in Java 8
by Carter, Tom Nov. 6, 2018

Nov. 6, 2018

Iana team: I am getting the following when trying to install tzdata2018g.tar.gz using the latest tzupdater.jar (2.2.0) for Java 8. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp_5/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) ... 5 more Please advise when will this be fixed? Thanks, Tom L Carter Principal Architect: CS/BW, American Airlines Work#: (817) 963-7640 Cell: (972) 849-1416 Coordinates: 4N-5A-53@HDQ2 Meeting Room<https://americanairlines.webex.com/join/Tom.Carter> NOTICE: This email and any attachments are for the exclusive and confidential use of the intended recipient(s). If you are not an intended recipient, please do not read, distribute, or take action in reliance upon this message. If you have received this in error, please notify me immediately by return email and promptly delete this message and its attachments from your computer.

7 10

[tz-announce] 2018g release of tz code and data available
by Joel da Rosa Nov. 5, 2018

Nov. 5, 2018

Hello! Fail on parser asia TZ (Japan Rule) persist: Using https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz as source for tzdata bundle. Failed: java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file '/tmp/tz.tmp/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:377) at tools.tzdb.TzdbZoneRulesCompiler.compile(TzdbZoneRulesCompiler.java:191) at tools.tzdb.TzdbZoneRulesCompiler.<init>(TzdbZoneRulesCompiler.java:307) at com.sun.tools.tzupdater.ExternalModule.compileToJSRBinary(ExternalModule.java:153) at com.sun.tools.tzupdater.TimezoneUpdater.run(TimezoneUpdater.java:230) at com.sun.tools.tzupdater.TimezoneUpdater.main(TimezoneUpdater.java:634) Caused by: tools.tzdb.DateTimeException: Invalid value for SecondOfDay value: 90000 at tools.tzdb.ChronoField.checkValidValue(ChronoField.java:173) at tools.tzdb.LocalTime.ofSecondOfDay(LocalTime.java:210) at tools.tzdb.TzdbZoneRulesCompiler.parseMonthDayTime(TzdbZoneRulesCompiler.java:475) at tools.tzdb.TzdbZoneRulesCompiler.parseRuleLine(TzdbZoneRulesCompiler.java:399) at tools.tzdb.TzdbZoneRulesCompiler.parseFile(TzdbZoneRulesCompiler.java:354) My environment: Linux Ubuntu 16.04 java version "1.8.0_191" Java(TM) SE Runtime Environment (build 1.8.0_191-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode) -- Atenciosamente, Joel da Rosa

2 1

Re: [tz] [tz-announce] 2018f release of tz code and data available
by Paul Eggert Nov. 2, 2018

Nov. 2, 2018

On 10/18/18 8:14 AM, Christos Zoulas wrote: > My folks are reporting that java does not like it: > > ERROR: Failed: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - SepSat>=8 25:00 0 S' > ERROR: java.lang.Exception: Failed while parsing file > '/tmp/tz.tmp_2/asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' > Thanks for the heads-up; please try the attached patch. Is there some way your folks can try the development version on GitHub every now and then? That "25:00" has been in the development version since last month and was explicitly called out when the patch was circulated on the mailing list <https://mm.icann.org/pipermail/tz/2018-September/026891.html>. It'd have been nice to catch the glitch before 2018f came out.

14 31

Re: [tz] Time zone confusion in Morocco
by Hicham Boushaba Nov. 2, 2018

Nov. 2, 2018

We Moroccans didn't know about the change also before Friday, our government didn't take the time to neither study nor discuss the matter with us. And the real issue, is that Android devices (maybe iOS devices, I'm not sure) update the tzdb only via a system upgrade/patch, and we know that Android OEMs rarely update their devices, so Moroccans will stay impacted for a long time, and non-tech people don't have the necessary skills to change the timezone manually.

9 12

[PROPOSED] Bring back attribute_pure for getzname
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

* localtime.c (getzname, getqzname): Bring back ATTRIBUTE_PURE. I was mistaken about GCC not needing this any more, as it’s still needed with GCC 8.2.1 when building with ‘make GCC_INSTRUMENT= CFLAGS='$(GCC_DEBUG_FLAGS)'’. --- localtime.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/localtime.c b/localtime.c index 7b72f9c..ac3790a 100644 --- a/localtime.c +++ b/localtime.c @@ -789,7 +789,7 @@ static const int year_lengths[2] = { ** Return a pointer to that character. */ -static const char * +static ATTRIBUTE_PURE const char * getzname(register const char *strp) { register char c; @@ -810,7 +810,7 @@ getzname(register const char *strp) ** We don't do any checking here; checking is done later in common-case code. */ -static const char * +static ATTRIBUTE_PURE const char * getqzname(register const char *strp, const int delim) { register int c; -- 2.19.1

1 0

Will Morocco switch from +01 to +00 during Ramadan next year?
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

Maamar Abdelkader wrote: > The 2019 Ramadan period is supposed to be from May 5th to June 4th. > We usually move clocks back the previous week end and come back to the +1 the week end after. > So it supposed to be sunday april 28 and sunday june 12. > > The government does not announce yet the decision about this temporarily change. > > But it s 99% sure that it will be the case, as the previous years. > > A non official survey was done these days, showing that 64% of asked peopke are ok for moving from +1 to +0 during Ramadan. > > https://leconomiste.com/article/1035870-enquete-l-economiste-sunergia-64-de… > > I will share the official decision once it s published. Thanks for the info. I installed the attached patches into the development version on GitHub to implement this. This patch doesn't exactly agree with the dates you specified (for 2019 it guesses falling back Sunday, May 5 and springing forward Sunday, June 9), but these dates are approximate until an official announcement and a methodical guess is better than no guess at all. Java users, please note that this patch uses negative DST in the main and vanguard formats; in rearguard format Morocco stays in the +00 timezone (instead of moving to +01 last weekend) and observes positive DST in every month but Ramadan.

2 2

Time zone confusion in Morocco
by Paul Eggert Nov. 1, 2018

Nov. 1, 2018

Since 2012 Morocco has been switching from +01 (DST) to +00 (standard time) for Ramadan. In an article in today's Morocco World News, Safaa Kasraoui implies (but does not explicitly state) that Morocco will continue this practice even after its time zone switch last weekend from +00 to +01, and thus that Morocco will switch from +01 (standard time) to +00 (presumably DST) during Ramadan next year. If so, we'll have to change tzdb again, this would be another use of negative DST, and I'll bring back my Emacs-based predictions of Ramadan for Morocco. Kasraoui also reports that MP Abdellatif Ouahbi has called on the Moroccan government to release the study that the government said it had conducted on time change. My guess is that no real study was conducted, that the government knew the change would be controversial, and that it announced the change with so little notice because it didn't want controversy to derail the change. The government's main argument for not using DST was the confusion and "tensions and diseases" of switchover, and its main argument for adopting +01 instead of +00 appears to be to smooth out peaks in electricity consumption, though it appears that there is no data to support either argument. As part of the time zone change, the government also changed school timetables so that schools will start at 09:00 instead of 08:00, effectively canceling the time zone change for schools. It said it will make further measures regarding DST, without giving details. Kasraoui reports, "Clocks set by the internet with Moroccan cities selected as the time zone returned to GMT on Sunday and, as of Wednesday, are still showing the wrong time." Presumably this mostly refers to Android and iOS phones; although my US-baseed Android 9 phone is not updated, the Ubuntu desktop that I'm typing this message on is updated. Ubuntu is downstream from Debian which in turn is downstream from tzdb, and the timeline for my desktop update was as follows (all times UTC): 2018-10-27 05:22:45 2018g timestamped 2018-10-27 05:23:38 2018g committed to development version 2018-10-27 12:10:11 2018g available from iana.org 2018-10-27 13:14:23 2018g created for Debian sid 2018-10-27 15:55:08 2018g announced on tz-announce(a)iana.org 2018-10-28 02:00:00 rule change takes effect in Morocco 2018-10-28 21:51:08 2018g created for Ubuntu bionic 2018-10-30 05:23:27 2018g updated on my desktop The update on my desktop was part of routine maintenance. Although Ubuntu is about as good as it gets in this area for a consumer-facing OS, we should be able to even better. Debian beat the deadline but Ubuntu (downstream from Debian) did not, my desktop had the wrong Morocco time for over two days, and my guess is that almost all cell phones and computers in Morocco still have the wrong data for Morocco. Reference: Kasraoui S. Benabdelkader: 68% of Moroccans Wanted an End to Time Changes. Morocco World News. 2018-10-31 13:44 +01. https://www.moroccoworldnews.com/2018/10/256539/

1 0

[PROPOSED] Fix Volgograd label in zone1970.tab
by Paul Eggert Oct. 31, 2018

Oct. 31, 2018

(Reported by Gleb Popov.) * zone.tab, zone1970.tab: Volgograd is now MSK+01. --- zone.tab | 2 +- zone1970.tab | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/zone.tab b/zone.tab index dcb6e1d..368a52d 100644 --- a/zone.tab +++ b/zone.tab @@ -332,9 +332,9 @@ RS +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area RU +4457+03406 Europe/Simferopol MSK+00 - Crimea -RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan +RU +4844+04425 Europe/Volgograd MSK+01 - Volgograd RU +5134+04602 Europe/Saratov MSK+01 - Saratov RU +5420+04824 Europe/Ulyanovsk MSK+01 - Ulyanovsk RU +5312+05009 Europe/Samara MSK+01 - Samara, Udmurtia diff --git a/zone1970.tab b/zone1970.tab index 7c86fb6..2729e6e 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -289,9 +289,9 @@ RS,BA,HR,ME,MK,SI +4450+02030 Europe/Belgrade RU +5443+02030 Europe/Kaliningrad MSK-01 - Kaliningrad RU +554521+0373704 Europe/Moscow MSK+00 - Moscow area RU +4457+03406 Europe/Simferopol MSK+00 - Crimea -RU +4844+04425 Europe/Volgograd MSK+00 - Volgograd RU +5836+04939 Europe/Kirov MSK+00 - Kirov RU +4621+04803 Europe/Astrakhan MSK+01 - Astrakhan +RU +4844+04425 Europe/Volgograd MSK+01 - Volgograd RU +5134+04602 Europe/Saratov MSK+01 - Saratov RU +5420+04824 Europe/Ulyanovsk MSK+01 - Ulyanovsk RU +5312+05009 Europe/Samara MSK+01 - Samara, Udmurtia -- 2.17.1

1 0

EU abolition of DST could be pushed back to 2021
by John Wilcock Oct. 30, 2018

Oct. 30, 2018

https://www.bbc.com/news/world-europe-46017347 > "If we aim to do this in 2019, as the [European] Commission suggested, > this will not be supported by the majority of member states," said > Austrian Transport Minister Norbert Hofer, who hosted his 27 EU > counterparts in Graz. > > Allowing until 2021 would help ensure the EU's three existing time > zones did not become a more complicated patchwork, Mr Hofer said. > -- John

1 0

zdump bug?
by Matt Johnson Oct. 29, 2018

Oct. 29, 2018

I notice when I run zdump like this: zdump /usr/share/zoneinfo/America/New_York The output is normal: America/New_York Sun Oct 28 18:23:35 2018 EDT But if I change to the America directory... cd /usr/share/zoneinfo/America zdump ./New_York The output is missing the abbreviation: ./New_York Sun Oct 28 22:23:48 2018 Is this expected? Seems like a subtle bug to me. The abbreviations are also missing with -v output. (Ran on Ubuntu Linux 16.04.5 LTS) Thanks, Matt

5 6

[tz-announce] 2018g release of tz code and data available
by Paul Eggert Oct. 29, 2018

Oct. 29, 2018

The 2018g 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 switches to permanent +01 on 2018-10-27. Changes to future timestamps Morocco switches from +00/+01 to permanent +01 effective 2018-10-27, so its clocks will not fall back on 2018-10-28 as previously scheduled. (Thanks to Mohamed Essedik Najd and Brian Inglis.) Changes to code When generating TZif files with leap seconds, zic no longer uses a format that trips up older 32-bit clients, fixing a bug introduced in 2018f. (Reported by Daniel Fischer.) Also, the zic workaround for QTBUG-53071 now also works for TZif files with leap seconds. The translator to rearguard format now rewrites the line "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". This caters to zic before 2007 and to Oracle TZUpdater 2.2.0 and earlier. (Reported by Christos Zoulas.) Changes to past time zone abbreviations Change HDT to HWT/HPT for WWII-era abbreviations in Hawaii. This reverts to 2011h, as the abbreviation change in 2011i was likely inadvertent. Changes to documentation tzfile.5 has new sections on interoperability issues. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018g.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018g.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 19e2701f468d5f9548a650144edeaf659766b1ea dated 2018-10-26 22:22:45 -0700 and tagged '2018g' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 58f89b7323bfe795c5f13039f7527d18b15c9e37fce6e9fa1a402ce2689bf5c772cf1ffb86f23309814a563f9f429da472df1229818b07b1e04f16bdedb21484 tzcode2018g.tar.gz 92e9bbd61f51be8f2cf7ec9491691e5e2f97803914dbad77b7fb8b6600ed68fc3b98450fc808bb2d4c6c835df5f9eb7bf4529d059d9b1370f2ab4c12e7f1adfa tzdata2018g.tar.gz bd681d6d635cf58a5a111f158b80c8d040a2700e11970f8c94433a7009f8d2113ad7ff665ef6681200e6f63758a6f2183897f5a17fb5c6098a3e96ae0b3fa96e tzdb-2018g.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvT+u0ACgkQ7ZfpDmKq fjRxJA//fwP+H4oNXlOYDUrDlPjDF5tKhouAkZ3FTy85cagjyfd6g6oFo8RIYyYV QqFR+mZd35W1xoWTf5cDcFLrmbX2PyrwBagDjQM9kf3xQ92pyfaGVm4C9kJOJ42q gYEIzO2LS25ybYaSt0OnguvkcghNG/bL27ivnwsxpq0Hv1J6Z2xSsH2rXh5dtGAZ gjQhYRoi6nWJXxOW+zHxNjEin/d2xaRTFa1UIjovQu+f01+9CWwpvSWrA61NlWcI IVnboUT7nrTRQE05TqkKtzL8Yoc1gnxLpIDJ6FwOhdPLcQy4keU4SnxuA8mCDcir tBsR/5K/JU6EgVCoylR+c2GyncPV+9jpXzfImW9EFjNFga32ZwcVud1hXM6/iRKc oDyTp95cRJpemSkt5EqiMfPgokhd4ZiHrN9y7hn25hPcO5UhfmiJSA0tquIJq/Q5 ryhYZJltdI5ASdnr2YpFhwyHUT1xW5uzF1l/XszydT5UXSgLTd+RiPY7MC+mKn+i rglUUpQ6vbcZvHeeab6k3ZDuGv3N1CR0u+jaEU6Ih6IThxHYD9EjoT7YwCVAjbcR SsT32TAIcGd6RfRdnqUAytzhgqgBvF4jmQGIk56yQ08woH1bZjjGRcdqHUe96y7R giUOVmIch9/vcAOIFkazqMnQupY+mA3Bd/pCfRPrLF3jk4t4xco= =hWDq -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvT+vsACgkQ7ZfpDmKq fjSOeQ/+KHzhT6GWZeqOAKj/AjyKK9KnL4gPh4MhsiI+V3z3/y+4ECvvee7ixbHI NQ33B4gRBzlbWWYnHw4Yq6Fm9RihnHOVj8XT/BM56YFESdfTQxOHsqsY+n3byGND Q+luSH0YC/S4mLxqS/vxHyT+nU2D4sS6UCmMIzW62fixJX5S2HAC3s7WoQkRXRDg ItaQvU42r9qs67C4M8q2+A9H7anUIhIE5KqZcPKmF7AMAdGnY4ZWpKb/uyxwzi58 pctIhzSGkB8im2m8QgDTrYsflOgADw3j/dKuYnyu4J0aniWC3qp7nJFPr5uTDaW7 TsWtaZCaUhytlsg+E0zebTURV2ziVNf52X58U9K3kUnnZqOxxZUeQWACmdjCc0kO yg9P1idYz1XTC4c0oik/YTt5OMkpkyFNqTaueSSQ3dpD0vc63GbGrDbMSPfa6bOx EOHvR/IqcNKCewfnv7a8h7y+5JX52gijL5hZjkpAU/XBCMdA3Pd/vZ5n3UaSbnC1 MNmZgsnJjBKVgaK8KHTuhCGigtDFc6TQethUQlKKWLr41P5RWrdmrhmMZIP0VBt5 4X0Kf7mKK2X/lsI33FCpzUbtnV093L1bLe6Vt74r01JBWUxeEy2BHdn+KM/CqHkH LTj0FmVFUWzvG7kqzrRgjJ5CnLUSnf/T1Gl6PgeKzMePChptyQE= =kUHt -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvT+v4ACgkQ7ZfpDmKq fjRapQ//ZMnPbJRPLzi5z9QPNpw/+m4PXGOXkheAf7htyiFBTmjE76C3JZ3LKjM9 /PZw4Izda4fYORfc6S1AeKxtRw7X0JIbM4bqhfugywOpjkfsEEGbmkD9uH3nPzgz +AIU9t13nTck5ScqM7ad/3ENaXHzNT48yskJTEiaxfd9T9xXGH+ErsM94x3xAsKz bbHyLM9xt8sDFDVNH7krV3vAvs5HqkrSHZuYYM7e/CTYTgMNaQqKEPX9aKCcp+2O lmQGcUnCL1jGGIiPfaVHgdtLVw41kttZfIhcEhRNrPvIWIJNuf8fdydNKXKxGZLo VfXj+cVPlD2+2OAVvXoYZHNFqNbbS19HGYr9D+5gUbMnUIJ0B/0oS8H/bpocxExL HVuCkrRUFpl0NubP2wnsWLLXK/KF9sYLaB7epwG9YblDs8TUTt6yxlP/46KJNofD yKUdXxZ0MtfKAoxtvmdUXG4Qb8rxTTQhjU7/CMENRkp4aU0lQg2T5Pj+NSg+f9Xj ILe1CYfUMFCdzIv2uBYKa25S2DqYPctWplnsOAG79pb4zDkRryzvfBUx7fyoxAmv sJadBvgIRcPez8jtCyrsj03z//6Q3rvPuaj3WBvv0n+DVwa1NKi8s4PUGkMp0Gfy jJz5AFH30nPhyb+a9Qjz1C/pp2COeQUfcU6DUKu48c0T2Zcear0= =N4bH -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018g/tzdata2018g-rearguard.tar.… with the following SHA-512 and GPG checksums: f92a4f64ddf723389344bbba4350c418d0111c73170b70f891dc72d78e560e24431658ab1a8457e9f4fa69c4dc8138def8783302b6b0ddef7615153e05da47c7 tzdata2018g-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvT+vwACgkQ7ZfpDmKq fjSndw//ZcWi/XOuXXq7MfNV7WU1YgPcWxs/jBWgRwbn7jvvvWMyNc+PWyUsV6Zb oNDPm+zcJGY/Pod/NHAgaf/rBJOPDwv+QTuO6ftjCKEYAETYi1cVH7XvSEwiJ0cc NNYTmZwgjUxPUWoc+13LfHGvhPyXyulZCwusRnaHtZh+15gbLDav7GwzS65UD6yY vNd/0tQRgh1mDt5rri33ls5//NDC4ocTjmJQgecDS3tpoUjI1dbXLywvXmicnkOJ ZYuNh1BRASyps2wsOr0lK2yBc1FmUFArRbZ1cxGCLtQko531FB+p7XbzGuAP3Sd1 +vTlitREJ/v1/u31Eak4joc1oFjF16AkA/O5hiJv2JB9rOImYKFHQjSiefU6qzOV K8bV9xee3WPMKVydPDMZqHs2pOEod9HWAOawyJHJc7+jMhdq00LnCqeq/HFnG2As Ff/CSTiy2ojBN3GDwmfnKL1I8U7WrG6fZmq1P4wa0qJYIHjvuoWSKSieCfknn/vh 1W+PKKa/V95P/UvpnlD8YM9HzY/zBjkr/ZiD9payOk4fkWv9oY814Oj3xZeHPTwX oqMpVww0/JSVZCt+BvYHg4R9AAkW/0iPDh4S3BXM7fu9Rdk/37wHPp3D7QOi3yk8 IYQ+kQfKDEMQgTBh2So2iYpIfMUj4Buyxu1KxKbT2hvzYZe4aSo= =Ricp -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

3 3

[PATCH] Support building zic.exe and zdump.exe natively on Windows with Visual Studio nmake.
by Manuela Friedrich Oct. 28, 2018

Oct. 28, 2018

Provide getopt() implementation for Windows as per ftp://ftp.es.ele.tue.nl/pub/users/jos/poster/getopt.c In localtime.c use native localtime(), gmtime(), ctime() and mktime(). Also use int or __int64 respectively for ssize_t type and check for Windows drive letters in tzloadbody(). In private.h and zdump.c define strotimax depending on Visual Studio version. It needs to be strtol for up to VS 2010 and stroll for higher versions. In zdump.c need prototype for gmtime_r() to suffice return type requirements. Also use __time64_t variables on Windows instead of time_t. In main() variable declarations had to be moved to the top to avoid compile errors. In zic.c dolink() need to have an extra mkdirs() call for Windows as we don't have link support here and the previous mkdirs() calls wouldn't have been called therefore. Also itsdir() needs separate Windows part to check for directory flag as the namesslashdot Linux alternative alway returns directory on Windows. Add nmake specific Makefile.nmake based on existing Makefile. It uses different object, library and executable extensions, sets CC and CFLAGS for 64 and 32bit Windows build. Target root has been added to build zdump and zic. Version and version.h rules were changed to batch. --- Makefile.nmake | 934 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ getopt.c | 110 +++++++ localtime.c | 23 ++ private.h | 4 + zdump.c | 47 ++- zic.c | 14 + 6 files changed, 1128 insertions(+), 4 deletions(-) create mode 100644 Makefile.nmake create mode 100644 getopt.c diff --git a/Makefile.nmake b/Makefile.nmake new file mode 100644 index 0000000..730523e --- /dev/null +++ b/Makefile.nmake @@ -0,0 +1,934 @@ +# This file is in the public domain, so clarified as of +# 2009-05-17 by Arthur David Olson. + +# This file supports building zic.exe and zdump.exe with Visual Studio nmake + +# Package name for the code distribution. +PACKAGE= tzcode + +# Version number for the distribution, overridden in the 'tarballs' rule below. +VERSION= unknown + +# Email address for bug reports. +BUGEMAIL= tz(a)iana.org + +# Change the line below for your time zone (after finding the zone you want in +# the time zone files, or adding it to a time zone file). +# Alternately, if you discover you've got the wrong time zone, you can just +# zic -l rightzone +# to correct things. +# Use the command +# make zonenames +# to get a list of the values you can use for LOCALTIME. + +LOCALTIME= GMT + +# If you want something other than Eastern United States time as a template +# for handling POSIX-style time zone environment variables, +# change the line below (after finding the zone you want in the +# time zone files, or adding it to a time zone file). +# (When a POSIX-style environment variable is handled, the rules in the +# template file are used to determine "spring forward" and "fall back" days and +# times; the environment variable itself specifies UT offsets of standard and +# summer time.) +# Alternately, if you discover you've got the wrong time zone, you can just +# zic -p rightzone +# to correct things. +# Use the command +# make zonenames +# to get a list of the values you can use for POSIXRULES. +# If you want POSIX compatibility, use "America/New_York". + +POSIXRULES= America/New_York + +# Also see TZDEFRULESTRING below, which takes effect only +# if the time zone files cannot be accessed. + + +# Installation locations. +# +# The defaults are suitable for Debian, except that if REDO is +# posix_right or right_posix then files that Debian puts under +# /usr/share/zoneinfo/posix and /usr/share/zoneinfo/right are instead +# put under /usr/share/zoneinfo-posix and /usr/share/zoneinfo-leaps, +# respectively. Problems with the Debian approach are discussed in +# the commentary for the right_posix rule (below). + +# Destination directory, which can be used for staging. +# 'make DESTDIR=/stage install' installs under /stage (e.g., to +# /stage/etc/localtime instead of to /etc/localtime). Files under +# /stage are not intended to work as-is, but can be copied by hand to +# the root directory later. If DESTDIR is empty, 'make install' does +# not stage, but installs directly into production locations. +DESTDIR = + +# Everything is installed into subdirectories of TOPDIR, and used there. +# TOPDIR should be empty (meaning the root directory), +# or a directory name that does not end in "/". +# TOPDIR should be empty or an absolute name unless you're just testing. +TOPDIR = + +# The default local time zone is taken from the file TZDEFAULT. +TZDEFAULT = $(TOPDIR)/etc/localtime + +# The subdirectory containing installed program and data files, and +# likewise for installed files that can be shared among architectures. +# These should be relative file names. +USRDIR = usr +USRSHAREDIR = $(USRDIR)/share + +# "Compiled" time zone information is placed in the "TZDIR" directory +# (and subdirectories). +# TZDIR_BASENAME should not contain "/" and should not be ".", ".." or empty. +TZDIR_BASENAME= zoneinfo +TZDIR = $(TOPDIR)\\$(USRSHAREDIR)\\$(TZDIR_BASENAME) + +# The "tzselect" and (if you do "make INSTALL") "date" commands go in: +BINDIR = $(TOPDIR)/$(USRDIR)/bin + +# The "zdump" command goes in: +ZDUMPDIR = $(BINDIR) + +# The "zic" command goes in: +ZICDIR = $(TOPDIR)/$(USRDIR)/sbin + +# Manual pages go in subdirectories of. . . +MANDIR = $(TOPDIR)/$(USRSHAREDIR)/man + +# Library functions are put in an archive in LIBDIR. +LIBDIR = $(TOPDIR)/$(USRDIR)/lib + + +# Types to try, as an alternative to time_t. int64_t should be first. +TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t + +# If you want only POSIX time, with time values interpreted as +# seconds since the epoch (not counting leap seconds), use +# REDO= posix_only +# below. If you want only "right" time, with values interpreted +# as seconds since the epoch (counting leap seconds), use +# REDO= right_only +# below. If you want both sets of data available, with leap seconds not +# counted normally, use +# REDO= posix_right +# below. If you want both sets of data available, with leap seconds counted +# normally, use +# REDO= right_posix +# below. POSIX mandates that leap seconds not be counted; for compatibility +# with it, use "posix_only" or "posix_right". Use POSIX time on systems with +# leap smearing; this can work better than unsmeared "right" time with +# applications that are not leap second aware, and is closer to unsmeared +# "right" time than unsmeared POSIX time is (e.g., 0.5 vs 1.0 s max error). + +REDO= posix_right + +# To install data in text form that has all the information of the binary data, +# (optionally incorporating leap second information), use +# TZDATA_TEXT= tzdata.zi leapseconds +# To install text data without leap second information (e.g., because +# REDO='posix_only'), use +# TZDATA_TEXT= tzdata.zi +# To avoid installing text data, use +# TZDATA_TEXT= + +TZDATA_TEXT= leapseconds tzdata.zi + +# For backward-compatibility links for old zone names, use +# BACKWARD= backward +# If you also want the link US/Pacific-New, even though it is confusing +# and is planned to be removed from the database eventually, use +# BACKWARD= backward pacificnew +# To omit these links, use +# BACKWARD= + +BACKWARD= backward + +# If you want out-of-scope and often-wrong data from the file 'backzone', use +# PACKRATDATA= backzone +# To omit this data, use +# PACKRATDATA= + +PACKRATDATA= + +# The name of a locale using the UTF-8 encoding, used during self-tests. +# The tests are skipped if the name does not appear to work on this system. + +UTF8_LOCALE= en_US.utf8 + +# Since "." may not be in PATH... + +YEARISTYPE= ./yearistype + +# Non-default libraries needed to link. +LDLIBS= + +# Add the following to the end of the "CFLAGS=" line as needed to override +# defaults specified in the source code. "-DFOO" is equivalent to "-DFOO=1". +# -DBIG_BANG=-9999999LL if the Big Bang occurred at time -9999999 (see zic.c) +# -DDEPRECATE_TWO_DIGIT_YEARS for optional runtime warnings about strftime +# formats that generate only the last two digits of year numbers +# -DEPOCH_LOCAL if the 'time' function returns local time not UT +# -DEPOCH_OFFSET=N if the 'time' function returns a value N greater +# than what POSIX specifies, assuming local time is UT. +# For example, N is 252460800 on AmigaOS. +# -DHAVE_DECL_ASCTIME_R=0 if <time.h> does not declare asctime_r +# -DHAVE_DECL_ENVIRON if <unistd.h> declares 'environ' +# -DHAVE_DIRECT_H if mkdir needs <direct.h> (MS-Windows) +# -DHAVE_GENERIC=0 if _Generic does not work +# -DHAVE_GETTEXT if 'gettext' works (e.g., GNU/Linux, FreeBSD, Solaris) +# -DHAVE_INCOMPATIBLE_CTIME_R if your system's time.h declares +# ctime_r and asctime_r incompatibly with the POSIX standard +# (Solaris when _POSIX_PTHREAD_SEMANTICS is not defined). +# -DHAVE_INTTYPES_H if you have a non-C99 compiler with <inttypes.h> +# -DHAVE_LINK=0 if your system lacks a link function +# -DHAVE_LOCALTIME_R=0 if your system lacks a localtime_r function +# -DHAVE_LOCALTIME_RZ=0 if you do not want zdump to use localtime_rz +# localtime_rz can make zdump significantly faster, but is nonstandard. +# -DHAVE_POSIX_DECLS=0 if your system's include files do not declare +# functions like 'link' or variables like 'tzname' required by POSIX +# -DHAVE_SNPRINTF=0 if your system lacks the snprintf function +# -DHAVE_STDBOOL_H if you have a non-C99 compiler with <stdbool.h> +# -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h> +# -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l +# -DHAVE_STRDUP=0 if your system lacks the strdup function +# -DHAVE_SYMLINK=0 if your system lacks the symlink function +# -DHAVE_SYS_STAT_H=0 if your compiler lacks a <sys/stat.h> +# -DHAVE_SYS_WAIT_H=0 if your compiler lacks a <sys/wait.h> +# -DHAVE_TZSET=0 if your system lacks a tzset function +# -DHAVE_UNISTD_H=0 if your compiler lacks a <unistd.h> +# -Dlocale_t=XXX if your system uses XXX instead of locale_t +# -Dssize_t=long on hosts like MS-Windows that lack ssize_t +# -DTHREAD_SAFE to make localtime.c thread-safe, as POSIX requires; +# not needed by the main-program tz code, which is single-threaded. +# Append other compiler flags as needed, e.g., -pthread on GNU/Linux. +# -Dtime_tz=\"T\" to use T as the time_t type, rather than the system time_t +# This is intended for internal use only; it mangles external names. +# -DTZ_DOMAIN=\"foo\" to use "foo" for gettext domain name; default is "tz" +# -DTZ_DOMAINDIR=\"/path\" to use "/path" for gettext directory; +# the default is system-supplied, typically "/usr/lib/locale" +# -DTZDEFRULESTRING=\",date/time,date/time\" to default to the specified +# DST transitions if the time zone files cannot be accessed +# -DUNINIT_TRAP if reading uninitialized storage can cause problems +# 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_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) +# $(GCC_DEBUG_FLAGS) if you are using recent GCC and want lots of checking +# Select instrumentation via "make GCC_INSTRUMENT='whatever'". +GCC_INSTRUMENT = \ + -fsanitize=undefined -fsanitize-address-use-after-scope \ + -fsanitize-undefined-trap-on-error -fstack-protector +GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ + $(GCC_INSTRUMENT) \ + -Wall -Wextra \ + -Walloc-size-larger-than=100000 -Warray-bounds=2 \ + -Wbad-function-cast -Wcast-align -Wdate-time \ + -Wdeclaration-after-statement -Wdouble-promotion \ + -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ + -Winit-self -Wjump-misses-init -Wlogical-op \ + -Wmissing-declarations -Wmissing-prototypes -Wnested-externs \ + -Wold-style-definition -Woverlength-strings -Wpointer-arith \ + -Wshadow -Wshift-overflow=2 -Wstrict-prototypes -Wstringop-overflow=5 \ + -Wsuggest-attribute=const -Wsuggest-attribute=format \ + -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ + -Wtrampolines -Wundef -Wuninitialized -Wunused \ + -Wvariadic-macros -Wvla -Wwrite-strings \ + -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ + -Wno-type-limits -Wno-unused-parameter +# +# If your system has a "GMT offset" field in its "struct tm"s +# (or if you decide to add such a field in your system's "time.h" file), +# add the name to a define such as +# -DTM_GMTOFF=tm_gmtoff +# to the end of the "CFLAGS=" line. If not defined, the code attempts to +# guess TM_GMTOFF from other macros; define NO_TM_GMTOFF to suppress this. +# Similarly, if your system has a "zone abbreviation" field, define +# -DTM_ZONE=tm_zone +# and define NO_TM_ZONE to suppress any guessing. These two fields are not +# required by POSIX, but are widely available on GNU/Linux and BSD systems. +# +# The next batch of options control support for external variables +# exported by tzcode. In practice these variables are less useful +# than TM_GMTOFF and TM_ZONE. However, most of them are standardized. +# # +# # To omit or support the external variable "tzname", add one of: +# # -DHAVE_TZNAME=0 +# # -DHAVE_TZNAME=1 +# # to the "CFLAGS=" line. "tzname" is required by POSIX 1988 and later. +# # If not defined, the code attempts to guess HAVE_TZNAME from other macros. +# # Warning: unless time_tz is also defined, HAVE_TZNAME=1 can cause +# # crashes when combined with some platforms' standard libraries, +# # presumably due to memory allocation issues. +# # +# # To omit or support the external variables "timezone" and "daylight", add +# # -DUSG_COMPAT=0 +# # -DUSG_COMPAT=1 +# # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by +# # Unix Systems Group code and are required by POSIX 2008 (with XSI) and later. +# # If not defined, the code attempts to guess USG_COMPAT from other macros. +# # +# # To support the external variable "altzone", add +# # -DALTZONE +# # to the end of the "CFLAGS=" line; although "altzone" appeared in +# # System V Release 3.1 it has not been standardized. +# +# If you want functions that were inspired by early versions of X3J11's work, +# add +# -DSTD_INSPIRED +# to the end of the "CFLAGS=" line. This arranges for the functions +# "tzsetwall", "offtime", "timelocal", "timegm", "timeoff", +# "posix2time", and "time2posix" to be added to the time conversion library. +# "tzsetwall" is like "tzset" except that it arranges for local wall clock +# time (rather than the time specified in the TZ environment variable) +# to be used. +# "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". +# "timegm" is like "timelocal" except that it turns a struct tm into +# a time_t using UT (rather than local time as "timelocal" does). +# "timeoff" is like "timegm" except that it accepts a second (long) argument +# that gives an offset to use when converting to a time_t. +# "posix2time" and "time2posix" are described in an included manual page. +# X3J11's work does not describe any of these functions. +# Sun has provided "tzsetwall", "timelocal", and "timegm" in SunOS 4.0. +# These functions may well disappear in future releases of the time +# conversion package. +# +# If you don't want functions that were inspired by NetBSD, add +# -DNETBSD_INSPIRED=0 +# to the end of the "CFLAGS=" line. Otherwise, the functions +# "localtime_rz", "mktime_z", "tzalloc", and "tzfree" are added to the +# time library, and if STD_INSPIRED is also defined the functions +# "posix2time_z" and "time2posix_z" are added as well. +# The functions ending in "_z" (or "_rz") are like their unsuffixed +# (or suffixed-by-"_r") counterparts, except with an extra first +# argument of opaque type timezone_t that specifies the time zone. +# "tzalloc" allocates a timezone_t value, and "tzfree" frees it. +# +# If you want to allocate state structures in localtime, add +# -DALL_STATE +# to the end of the "CFLAGS=" line. Storage is obtained by calling malloc. +# +# NIST-PCTS:151-2, Version 1.4, (1993-12-03) is a test suite put +# out by the National Institute of Standards and Technology +# which claims to test C and Posix conformance. If you want to pass PCTS, add +# -DPCTS +# to the end of the "CFLAGS=" line. +# +# If you want strict compliance with XPG4 as of 1994-04-09, add +# -DXPG4_1994_04_09 +# to the end of the "CFLAGS=" line. This causes "strftime" to always return +# 53 as a week number (rather than 52 or 53) for January days before +# January's first Monday when a "%V" format is used and January 1 +# falls on a Friday, Saturday, or Sunday. + +!IF "$(CPU)" == "AMD64" +CFLAGS=/Zi -DHAVE_SYS_WAIT_H=0 -DHAVE_UNISTD_H=0 -DHAVE_INTTYPES_H=0 -DHAVE_POSIX_DECLS=0 -DHAVE_LINK=0 -DHAVE_SYMLINK=0 -DTYPECHECK=1 -DHAVE_DECL_ASCTIME_R=0 +!ELSE +CFLAGS=/Zi -DHAVE_SYS_WAIT_H=0 -DHAVE_UNISTD_H=0 -DHAVE_INTTYPES_H=0 -DHAVE_POSIX_DECLS=0 -DHAVE_LINK=0 -DHAVE_SYMLINK=0 -DSTD_INSPIRED -DTYPECHECK=1 -DHAVE_DECL_ASCTIME_R=0 +!ENDIF + +# Linker flags. Default to $(LFLAGS) for backwards compatibility +# to release 2012h and earlier. + +LDFLAGS= $(LFLAGS) + +# For leap seconds, this Makefile uses LEAPSECONDS='-L leapseconds' in +# submake command lines. The default is no leap seconds. + +LEAPSECONDS= + +# The zic command and its arguments. + +zic= ./zic.exe +ZIC= $(zic) $(ZFLAGS) + +ZFLAGS= + +# How to use zic to install tz binary files. + +ZIC_INSTALL= $(ZIC) -d '$(DESTDIR)$(TZDIR)' $(LEAPSECONDS) + +# The name of a Posix-compliant 'awk' on your system. +AWK= awk + +# The full path name of a Posix-compliant shell, preferably one that supports +# the Korn shell's 'select' statement as an extension. +# These days, Bash is the most popular. +# It should be OK to set this to /bin/sh, on platforms where /bin/sh +# lacks 'select' or doesn't completely conform to Posix, but /bin/bash +# is typically nicer if it works. +KSHELL= /bin/bash + +# The path where SGML DTDs are kept and the catalog file(s) to use when +# validating. The default should work on both Debian and Red Hat. +SGML_TOPDIR= /usr +SGML_DTDDIR= $(SGML_TOPDIR)/share/xml/w3c-sgml-lib/schema/dtd +SGML_SEARCH_PATH= $(SGML_DTDDIR)/REC-html401-19991224 +SGML_CATALOG_FILES= \ + $(SGML_TOPDIR)/share/doc/w3-recs/html/www.w3.org/TR/1999/REC-html401-19991224/HTML4.cat:$(SGML_TOPDIR)/share/sgml/html/4.01/HTML4.cat + +# The name, arguments and environment of a program to validate your web pages. +# See <http://openjade.sourceforge.net/doc/> for a validator, and +# <https://validator.w3.org/source/> for a validation library. +# Set VALIDATE=':' if you do not have such a program. +VALIDATE = nsgmls +VALIDATE_FLAGS = -s -B -wall -wno-unused-param +VALIDATE_ENV = \ + SGML_CATALOG_FILES='$(SGML_CATALOG_FILES)' \ + SGML_SEARCH_PATH='$(SGML_SEARCH_PATH)' \ + SP_CHARSET_FIXED=YES \ + SP_ENCODING=UTF-8 + +# This expensive test requires USE_LTZ. +# To suppress it, define this macro to be empty. +CHECK_TIME_T_ALTERNATIVES = check_time_t_alternatives + +# SAFE_CHAR is a regular expression that matches a safe character. +# Some parts of this distribution are limited to safe characters; +# others can use any UTF-8 character. +# For now, the safe characters are a safe subset of ASCII. +# The caller must set the shell variable 'sharp' to the character '#', +# since Makefile macros cannot contain '#'. +# TAB_CHAR is a single tab character, in single quotes. +TAB_CHAR= ' ' +SAFE_CHARSET1= $(TAB_CHAR)' !\"'$$sharp'$$%&'\''()*+,./0123456789:;<=>?@' +SAFE_CHARSET2= 'ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\^_`' +SAFE_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~' +SAFE_CHARSET= $(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3) +SAFE_CHAR= '[]'$(SAFE_CHARSET)'-]' + +# OK_CHAR matches any character allowed in the distributed files. +# This is the same as SAFE_CHAR, except that multibyte letters are +# also allowed so that commentary can contain people's names and quote +# non-English sources. For non-letters the sources are limited to +# ASCII renderings for the convenience of maintainers whose text editors +# mishandle UTF-8 by default (e.g., XEmacs 21.4.22). +OK_CHAR= '[][:alpha:]'$(SAFE_CHARSET)'-]' + +# SAFE_LINE matches a line of safe characters. +# SAFE_SHARP_LINE is similar, except any OK character can follow '#'; +# this is so that comments can contain non-ASCII characters. +# OK_LINE matches a line of OK characters. +SAFE_LINE= '^'$(SAFE_CHAR)'*$$' +SAFE_SHARP_LINE='^'$(SAFE_CHAR)'*('$$sharp$(OK_CHAR)'*)?$$' +OK_LINE= '^'$(OK_CHAR)'*$$' + +# Flags to give 'tar' when making a distribution. +# Try to use flags appropriate for GNU tar. +GNUTARFLAGS= --numeric-owner --owner=0 --group=0 --mode=go+u,go-w --sort=name +TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ + then echo $(GNUTARFLAGS); \ + else :; \ + fi` + +# Flags to give 'gzip' when making a distribution. +GZIPFLAGS= -9n + +############################################################################### + +#MAKE= make + +cc= cl +CC= $(cc) -DTZDIR=\"$(TZDIR)\" + +AR= lib + +# ':' on typical hosts; 'ranlib' on the ancient hosts that still need ranlib. +RANLIB= : + +TZCOBJS= zic.obj getopt.obj +TZDOBJS= zdump.obj localtime.obj asctime.obj getopt.obj strftime.obj +DATEOBJS= date.obj localtime.obj strftime.obj asctime.obj +LIBSRCS= localtime.c asctime.c difftime.c +LIBOBJS= localtime.obj asctime.obj difftime.obj +HEADERS= tzfile.h private.h +NONLIBSRCS= zic.c zdump.c +NEWUCBSRCS= date.c strftime.c +SOURCES= $(HEADERS) $(LIBSRCS) $(NONLIBSRCS) $(NEWUCBSRCS) \ + tzselect.ksh workman.sh +MANS= newctime.3 newstrftime.3 newtzset.3 time2posix.3 \ + tzfile.5 tzselect.8 zic.8 zdump.8 +MANTXTS= newctime.3.txt newstrftime.3.txt newtzset.3.txt \ + time2posix.3.txt \ + tzfile.5.txt tzselect.8.txt zic.8.txt zdump.8.txt \ + date.1.txt +COMMON= calendars CONTRIBUTING LICENSE Makefile \ + NEWS README theory.html version +WEB_PAGES= tz-art.html tz-how-to.html tz-link.html +DOCS= $(MANS) date.1 $(MANTXTS) $(WEB_PAGES) +PRIMARY_YDATA= africa antarctica asia australasia \ + europe northamerica southamerica +YDATA= $(PRIMARY_YDATA) etcetera +NDATA= systemv factory +TDATA_TO_CHECK= $(YDATA) $(NDATA) backward pacificnew +TDATA= $(YDATA) $(NDATA) $(BACKWARD) +ZONETABLES= zone1970.tab zone.tab +TABDATA= iso3166.tab $(TZDATA_TEXT) $(ZONETABLES) +LEAP_DEPS= leapseconds.awk leap-seconds.list +TZDATA_ZI_DEPS= zishrink.awk version $(TDATA) $(PACKRATDATA) +DATA= $(TDATA_TO_CHECK) backzone iso3166.tab leap-seconds.list \ + leapseconds yearistype.sh $(ZONETABLES) +AWK_SCRIPTS= checklinks.awk checktab.awk leapseconds.awk zishrink.awk +MISC= $(AWK_SCRIPTS) zoneinfo2tdf.pl +TZS_YEAR= 2050 +TZS= to$(TZS_YEAR).tzs +TZS_NEW= to$(TZS_YEAR)new.tzs +TZS_DEPS= $(PRIMARY_YDATA) asctime.c localtime.c \ + private.h tzfile.h zdump.c zic.c +ENCHILADA= $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) $(TZS) tzdata.zi + +# Consult these files when deciding whether to rebuild the 'version' file. +# This list is not the same as the output of 'git ls-files', since +# .gitignore is not distributed. +VERSION_DEPS= \ + calendars CONTRIBUTING LICENSE Makefile NEWS README \ + africa antarctica asctime.c asia australasia \ + backward backzone \ + checklinks.awk checktab.awk \ + date.1 date.c difftime.c \ + etcetera europe factory iso3166.tab \ + leap-seconds.list leapseconds.awk localtime.c \ + newctime.3 newstrftime.3 newtzset.3 northamerica \ + pacificnew private.h \ + southamerica strftime.c systemv theory.html \ + time2posix.3 tz-art.html tz-how-to.html tz-link.html \ + tzfile.5 tzfile.h tzselect.8 tzselect.ksh \ + workman.sh yearistype.sh \ + zdump.8 zdump.c zic.8 zic.c \ + zone.tab zone1970.tab zoneinfo2tdf.pl + +# And for the benefit of csh users on systems that assume the user +# shell should be used to handle commands in Makefiles. . . + +SHELL= /bin/sh + +root: zic.exe zdump.exe + +ALL: root date $(ENCHILADA) + +install: root $(DATA) $(REDO) $(MANS) + mkdir $(DESTDIR)$(ETCDIR) $(DESTDIR)$(TZDIR) \ + $(DESTDIR)$(LIBDIR) \ + $(DESTDIR)$(MANDIR)/man3 $(DESTDIR)$(MANDIR)/man5 \ + $(DESTDIR)$(MANDIR)/man8 + $(ZIC_INSTALL) -l $(LOCALTIME) -p $(POSIXRULES) \ + -t '$(DESTDIR)$(TZDEFAULT)' + cp -f $(TABDATA) $(DESTDIR)$(TZDIR)/. + cp tzselect $(DESTDIR)$(BINDIR)/. + cp zdump.exe $(DESTDIR)$(ZDUMPDIR)/. + cp zic.exe $(DESTDIR)$(ZICDIR)/. + cp libtz.lib $(DESTDIR)$(LIBDIR)/. + $(RANLIB) $(DESTDIR)$(LIBDIR)/libtz.lib + cp -f newctime.3 newtzset.3 $(DESTDIR)$(MANDIR)/man3/. + cp -f tzfile.5 $(DESTDIR)$(MANDIR)/man5/. + cp -f tzselect.8 zdump.8 zic.8 $(DESTDIR)$(MANDIR)/man8/. + +INSTALL: ALL install date.1 + mkdir -p $(DESTDIR)$(BINDIR) $(DESTDIR)$(MANDIR)/man1 + cp date $(DESTDIR)$(BINDIR)/. + cp -f date.1 $(DESTDIR)$(MANDIR)/man1/. + +# for version get first token of git describe (e.g. 2018a from 2018a-5-g4a132ae) or $(VERSION) +# if version file is already present, i.e. downloaded from ftp, skip recreating it +version: $(VERSION_DEPS) +!IF [git describe > nul 2>&1] == 0 + if not exist version for /f "delims=-" %%a in ('git describe') do echo %%a > $@ +!ELSE + if not exist version echo $(VERSION) > $@ +!ENDIF + +# This file can be tailored by setting BACKWARD, PACKRATDATA, etc. +tzdata.zi: $(TZDATA_ZI_DEPS) + version=`sed 1q version` && \ + LC_ALL=C $(AWK) -v version="$$version" -f zishrink.awk \ + $(TDATA) $(PACKRATDATA) >$@.out + mv $@.out $@ + +version.h: version + echo static char const PKGVERSION[]="($(PACKAGE)) "; >$@ + for /F %%H in ('type version') do echo static char const TZVERSION[]="%%H"; >> $@ + echo static char const REPORT_BUGS_TO[]="$(BUGEMAIL)"; >>$@ + +zdump.exe: $(TZDOBJS) + $(CC) $(CFLAGS) $(LDFLAGS) $(TZDOBJS) $(LDLIBS) /link /out:$@ + +zic.exe: $(TZCOBJS) + $(CC) $(CFLAGS) $(LDFLAGS) $(TZCOBJS) $(LDLIBS) /link /out:$@ + +yearistype: yearistype.sh + cp yearistype.sh yearistype + chmod +x yearistype + +leapseconds: $(LEAP_DEPS) + $(AWK) -f leapseconds.awk leap-seconds.list >$@.out + mv $@.out $@ + +# Arguments to pass to submakes of install_data. +# They can be overridden by later submake arguments. +INSTALLARGS = \ + BACKWARD='$(BACKWARD)' \ + DESTDIR='$(DESTDIR)' \ + LEAPSECONDS='$(LEAPSECONDS)' \ + PACKRATDATA='$(PACKRATDATA)' \ + TZDEFAULT='$(TZDEFAULT)' \ + TZDIR='$(TZDIR)' \ + YEARISTYPE='$(YEARISTYPE)' \ + ZIC='$(ZIC)' + +# 'make install_data' installs one set of tz binary files. +install_data: zic.exe leapseconds yearistype tzdata.zi + $(ZIC_INSTALL) tzdata.zi + +posix_only: + $(MAKE) $(INSTALLARGS) LEAPSECONDS= install_data + +right_only: + $(MAKE) $(INSTALLARGS) LEAPSECONDS='-L leapseconds' \ + install_data + +# In earlier versions of this makefile, the other two directories were +# subdirectories of $(TZDIR). However, this led to configuration errors. +# For example, with posix_right under the earlier scheme, +# TZ='right/Australia/Adelaide' got you localtime with leap seconds, +# but gmtime without leap seconds, which led to problems with applications +# like sendmail that subtract gmtime from localtime. +# Therefore, the other two directories are now siblings of $(TZDIR). +# You must replace all of $(TZDIR) to switch from not using leap seconds +# to using them, or vice versa. +right_posix: right_only + rm -fr '$(DESTDIR)$(TZDIR)-leaps' + ln -s '$(TZDIR_BASENAME)' '$(DESTDIR)$(TZDIR)-leaps' || \ + $(MAKE) $(INSTALLARGS) TZDIR='$(TZDIR)-leaps' right_only + $(MAKE) $(INSTALLARGS) TZDIR='$(TZDIR)-posix' posix_only + +posix_right: posix_only + rm -fr '$(DESTDIR)$(TZDIR)-posix' + ln -s '$(TZDIR_BASENAME)' '$(DESTDIR)$(TZDIR)-posix' || \ + $(MAKE) $(INSTALLARGS) TZDIR='$(TZDIR)-posix' posix_only + $(MAKE) $(INSTALLARGS) TZDIR='$(TZDIR)-leaps' right_only + +# This obsolescent rule is present for backwards compatibility with +# tz releases 2014g through 2015g. It should go away eventually. +posix_packrat: + $(MAKE) $(INSTALLARGS) PACKRATDATA=backzone posix_only + +zones: $(REDO) + +$(TZS_NEW): tzdata.zi zdump zic + mkdir -p tzs.dir + $(zic) -d tzs.dir tzdata.zi + $(AWK) '/^L/{print "Link\t" $$2 "\t" $$3}' \ + tzdata.zi | LC_ALL=C sort >$@.out + wd=`pwd` && \ + zones=`$(AWK) -v wd="$$wd" \ + '/^Z/{print wd "/tzs.dir/" $$2}' tzdata.zi \ + | LC_ALL=C sort` && \ + ./zdump -i -c $(TZS_YEAR) $$zones >>$@.out + sed 's,^TZ=".*tzs\.dir/,TZ=",' $@.out >$@.sed.out + rm -fr tzs.dir $@.out + mv $@.sed.out $@ + +# If $(TZS) does not already exist (e.g., old-format tarballs), create it. +# If it exists but 'make check_tzs' fails, a maintainer should inspect the +# failed output and fix the inconsistency, perhaps by running 'make force_tzs'. +$(TZS): + $(MAKE) force_tzs + +force_tzs: $(TZS_NEW) + cp $(TZS_NEW) $(TZS) + +libtz.lib: $(LIBOBJS) + del $@ + $(AR) $@ $(LIBOBJS) + $(RANLIB) $@ + +date: $(DATEOBJS) + $(CC) -o $@ $(CFLAGS) $(LDFLAGS) $(DATEOBJS) $(LDLIBS) + +tzselect: tzselect.ksh version + VERSION=`cat version` && sed \ + -e 's|#!/bin/bash|#!$(KSHELL)|g' \ + -e 's|AWK=[^}]*|AWK=$(AWK)|g' \ + -e 's|$PKGVERSION$=.*|\1='\''($(PACKAGE)) '\''|' \ + -e 's|$REPORT_BUGS_TO$=.*|\1=$(BUGEMAIL)|' \ + -e 's|TZDIR=[^}]*|TZDIR=$(TZDIR)|' \ + -e 's|$TZVERSION$=.*|\1='"$$VERSION"'|' \ + <$@.ksh >$@.out + chmod +x $@.out + mv $@.out $@ + +check: check_character_set check_white_space check_links \ + check_name_lengths check_sorted \ + check_tables check_web check_zishrink check_tzs + +check_character_set: $(ENCHILADA) + test ! '$(UTF8_LOCALE)' || \ + ! printf 'A\304\200B\n' | \ + LC_ALL='$(UTF8_LOCALE)' grep -q '^A.B$$' >/dev/null 2>&1 || { \ + LC_ALL='$(UTF8_LOCALE)' && export LC_ALL && \ + sharp='#' && \ + ! grep -Env $(SAFE_LINE) $(MANS) date.1 $(MANTXTS) \ + $(MISC) $(SOURCES) $(WEB_PAGES) \ + CONTRIBUTING LICENSE Makefile README \ + version tzdata.zi && \ + ! grep -Env $(SAFE_SHARP_LINE) $(TDATA_TO_CHECK) backzone \ + leapseconds yearistype.sh zone.tab && \ + ! grep -Env $(OK_LINE) $(ENCHILADA); \ + } + +check_white_space: $(ENCHILADA) + patfmt=' \t|[\f\r\v]' && pat=`printf "$$patfmt\\n"` && \ + ! grep -En "$$pat" $(ENCHILADA) + ! grep -n '[[:space:]]$$' \ + $$(ls $(ENCHILADA) | grep -Fvx leap-seconds.list) + +PRECEDES_FILE_NAME = ^(Zone|Link[[:space:]]+[^[:space:]]+)[[:space:]]+ +FILE_NAME_COMPONENT_TOO_LONG = \ + $(PRECEDES_FILE_NAME)[^[:space:]]*[^/[:space:]]{15} + +check_name_lengths: $(TDATA_TO_CHECK) backzone + ! grep -En '$(FILE_NAME_COMPONENT_TOO_LONG)' \ + $(TDATA_TO_CHECK) backzone + +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 + +check_links: checklinks.awk $(TDATA_TO_CHECK) + $(AWK) -f checklinks.awk $(TDATA_TO_CHECK) + $(AWK) -f checklinks.awk tzdata.zi + +check_tables: checktab.awk $(PRIMARY_YDATA) $(ZONETABLES) + for tab in $(ZONETABLES); do \ + $(AWK) -f checktab.awk -v zone_table=$$tab $(PRIMARY_YDATA) \ + || exit; \ + done + +check_tzs: $(TZS) $(TZS_NEW) + diff -u $(TZS) $(TZS_NEW) + +# This checks only the HTML 4.01 strict page. +# To check the the other pages, use <https://validator.w3.org/>. +check_web: tz-how-to.html + $(VALIDATE_ENV) $(VALIDATE) $(VALIDATE_FLAGS) tz-how-to.html + +# Check that tzdata.zi generates the same binary data that its sources do. +check_zishrink: tzdata.zi zic leapseconds $(PACKRATDATA) $(TDATA) + for type in posix right; do \ + mkdir -p time_t.dir/$$type time_t.dir/$$type-shrunk && \ + case $$type in \ + right) leap='-L leapseconds';; \ + *) leap=;; \ + esac && \ + $(ZIC) $$leap -d time_t.dir/$$type $(TDATA) && \ + $(AWK) '/^Rule/' $(TDATA) | \ + $(ZIC) $$leap -d time_t.dir/$$type - $(PACKRATDATA) && \ + $(ZIC) $$leap -d time_t.dir/$$type-shrunk tzdata.zi && \ + diff -r time_t.dir/$$type time_t.dir/$$type-shrunk || exit; \ + done + rm -fr time_t.dir + +clean_misc: + del core *.obj *.out \ + date tzselect version.h zdump.exe zic.exe yearistype libtz.lib +clean: clean_misc + del *.dir tzdata.zi $(TZS_NEW) + +maintainer-clean: clean + @echo 'This command is intended for maintainers to use; it' + @echo 'deletes files that may need special tools to rebuild.' + rm -f leapseconds version $(MANTXTS) $(TZS) *.asc *.tar.* + +names: + @echo $(ENCHILADA) + +public: check check_public $(CHECK_TIME_T_ALTERNATIVES) \ + tarballs signatures + +date.1.txt: date.1 +newctime.3.txt: newctime.3 +newstrftime.3.txt: newstrftime.3 +newtzset.3.txt: newtzset.3 +time2posix.3.txt: time2posix.3 +tzfile.5.txt: tzfile.5 +tzselect.8.txt: tzselect.8 +zdump.8.txt: zdump.8 +zic.8.txt: zic.8 + +$(MANTXTS): workman.sh + LC_ALL=C sh workman.sh `expr $@ : '$.*$\.txt$$'` >$@.out + mv $@.out $@ + +# Set the time stamps 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. +# Also, set the timestamp of each prebuilt file like 'leapseconds' +# to be the maximum of the files it depends on. +set-timestamps.out: $(ENCHILADA) + rm -f $@ + if (type git) >/dev/null 2>&1 && \ + files=`git ls-files $(ENCHILADA)` && \ + touch -md @1 test.out; then \ + rm -f test.out && \ + for file in $$files; do \ + if git diff --quiet $$file; then \ + time=`git log -1 --format='tformat:%ct' $$file` && \ + touch -cmd @$$time $$file; \ + else \ + echo >&2 "$$file: warning: does not match repository"; \ + fi || exit; \ + done; \ + fi + touch -cmr `ls -t $(LEAP_DEPS) | sed 1q` leapseconds + for file in `ls $(MANTXTS) | sed 's/\.txt$$//'`; do \ + touch -cmr `ls -t $$file workman.sh | sed 1q` $$file.txt || \ + exit; \ + done + touch -cmr `ls -t $(TZDATA_ZI_DEPS) | sed 1q` tzdata.zi + touch -cmr `ls -t $(TZS_DEPS) | sed 1q` $(TZS) + touch -cmr `ls -t $(VERSION_DEPS) | sed 1q` version + touch $@ + +# The zics below ensure that each data file can stand on its own. +# We also do an all-files run to catch links to links. + +check_public: + $(MAKE) maintainer-clean + $(MAKE) CFLAGS='$(GCC_DEBUG_FLAGS)' ALL + mkdir -p public.dir + for i in $(TDATA_TO_CHECK) tzdata.zi; do \ + $(zic) -v -d public.dir $$i 2>&1 || exit; \ + done + $(zic) -v -d public.dir $(TDATA_TO_CHECK) + rm -fr public.dir + +# Check that the code works under various alternative +# implementations of time_t. +check_time_t_alternatives: + if diff -q Makefile Makefile 2>/dev/null; then \ + quiet_option='-q'; \ + else \ + quiet_option=''; \ + fi && \ + wd=`pwd` && \ + zones=`$(AWK) '/^[^#]/ { print $$3 }' <zone1970.tab` && \ + for type in $(TIME_T_ALTERNATIVES); do \ + mkdir -p time_t.dir/$$type && \ + $(MAKE) clean_misc && \ + $(MAKE) TOPDIR="$$wd/time_t.dir/$$type" \ + CFLAGS='$(CFLAGS) -Dtime_tz='"'$$type'" \ + REDO='$(REDO)' \ + install && \ + diff $$quiet_option -r \ + time_t.dir/int64_t/etc \ + time_t.dir/$$type/etc && \ + diff $$quiet_option -r \ + time_t.dir/int64_t/usr/share \ + time_t.dir/$$type/usr/share && \ + case $$type in \ + int32_t) range=-2147483648,2147483647;; \ + uint32_t) range=0,4294967296;; \ + int64_t) continue;; \ + *u*) range=0,10000000000;; \ + *) range=-10000000000,10000000000;; \ + esac && \ + echo checking $$type zones ... && \ + time_t.dir/int64_t/usr/bin/zdump -V -t $$range $$zones \ + >time_t.dir/int64_t.out && \ + time_t.dir/$$type/usr/bin/zdump -V -t $$range $$zones \ + >time_t.dir/$$type.out && \ + diff -u time_t.dir/int64_t.out time_t.dir/$$type.out \ + || exit; \ + done + rm -fr time_t.dir + +tarballs traditional_tarballs signatures traditional_signatures: version + VERSION=`cat version` && \ + $(MAKE) VERSION="$$VERSION" $@_version + +tarballs_version: traditional_tarballs_version tzdb-$(VERSION).tar.lz +traditional_tarballs_version: \ + tzcode$(VERSION).tar.gz tzdata$(VERSION).tar.gz +signatures_version: traditional_signatures_version tzdb-$(VERSION).tar.lz.asc +traditional_signatures_version: \ + tzcode$(VERSION).tar.gz.asc tzdata$(VERSION).tar.gz.asc \ + +tzcode$(VERSION).tar.gz: set-timestamps.out + LC_ALL=C && export LC_ALL && \ + tar $(TARFLAGS) -cf - \ + $(COMMON) $(DOCS) $(SOURCES) | \ + gzip $(GZIPFLAGS) >$@.out + mv $@.out $@ + +tzdata$(VERSION).tar.gz: set-timestamps.out + LC_ALL=C && export LC_ALL && \ + tar $(TARFLAGS) -cf - $(COMMON) $(DATA) $(MISC) | \ + gzip $(GZIPFLAGS) >$@.out + mv $@.out $@ + +tzdb-$(VERSION).tar.lz: set-timestamps.out + rm -fr tzdb-$(VERSION) + mkdir tzdb-$(VERSION) + ln $(ENCHILADA) tzdb-$(VERSION) + touch -cmr `ls -t tzdb-$(VERSION)/* | sed 1q` tzdb-$(VERSION) + LC_ALL=C && export LC_ALL && \ + tar $(TARFLAGS) -cf - tzdb-$(VERSION) | lzip -9 >$@.out + mv $@.out $@ + +tzcode$(VERSION).tar.gz.asc: tzcode$(VERSION).tar.gz + gpg --armor --detach-sign $? + +tzdata$(VERSION).tar.gz.asc: tzdata$(VERSION).tar.gz + gpg --armor --detach-sign $? + +tzdb-$(VERSION).tar.lz.asc: tzdb-$(VERSION).tar.lz + gpg --armor --detach-sign $? + +typecheck: + $(MAKE) clean + for i in "long long" unsigned; \ + do \ + $(MAKE) CFLAGS="-DTYPECHECK -D__time_t_defined -D_TIME_T \"-Dtime_t=$$i\"" ; \ + ./zdump -v Europe/Rome ; \ + $(MAKE) clean ; \ + done + +zonenames: tzdata.zi + @$(AWK) '/^Z/ { print $$2 } /^L/ { print $$3 }' tzdata.zi + +asctime.obj: private.h tzfile.h +date.obj: private.h +difftime.obj: private.h +localtime.obj: private.h tzfile.h +strftime.obj: private.h tzfile.h +zdump.obj: version.h +zic.obj: private.h tzfile.h version.h +getopt.obj: +msvcrt.lib: + +.KEEP_STATE: + +.PHONY: ALL INSTALL root +.PHONY: check check_character_set check_links +.PHONY: check_public check_sorted check_tables +.PHONY: check_time_t_alternatives check_tzs check_web check_white_space +.PHONY: check_zishrink +.PHONY: clean clean_misc force_tzs +.PHONY: install install_data maintainer-clean names +.PHONY: posix_only posix_packrat posix_right +.PHONY: public right_only right_posix signatures signatures_version +.PHONY: tarballs tarballs_version typecheck +.PHONY: zonenames zones diff --git a/getopt.c b/getopt.c new file mode 100644 index 0000000..9608eae --- /dev/null +++ b/getopt.c @@ -0,0 +1,110 @@ +/* transcript/src/getopt.c + * + * public domain getopt from mod.sources + * RCSID: $Header: getopt.c,v 2.1 85/11/24 11:49:10 shore Rel $ + */ + +/* +** This is a public domain version of getopt(3). +** Bugs, fixes to: +** Keith Bostic +** ARPA: keith@seismo +** UUCP: seismo!keith +** Added NO_STDIO, opterr handling, Rich $alz (mirror!rs). +*/ + +#include <stdio.h> +#include <string.h> + +/* +** Error macro. Maybe we want stdio, maybe we don't. +** The (undocumented?) variable opterr tells us whether or not +** to print errors. +*/ + +#ifdef NO_STDIO + +#define tell(s) \ + if (opterr) \ + { \ + char ebuf[2]; \ + (void)write(2, nargv, (unsigned int)strlen(nargv)); \ + (void)write(2, s, (unsigned int)strlen(s)); \ + ebuf[0] = optopt; \ + ebuf[1] = '\n'; \ + (void)write(2, ebuf, 2); \ + } + +#else + +#define tell(s) \ + if (opterr) \ + (void)fputs(*nargv, stderr), \ + (void)fputs(s,stderr), \ + (void)fputc(optopt, stderr), \ + (void)fputc('\n', stderr) + +#endif + + +/* Global variables. */ +static char EMSG[] = ""; +int opterr = 1; /* undocumented error-suppressor*/ +int optind = 1; /* index into argv vector */ +int optopt; /* char checked for validity */ +char *optarg; /* arg associated with option */ + + + +getopt(nargc, nargv, ostr) + int nargc; + char **nargv; + char *ostr; +{ + static char *place = EMSG; /* option letter processing */ + register char *oli; /* option letter list index */ + + if (!*place) /* update scanning pointer */ + { + if (optind >= nargc || *(place = nargv[optind]) != '-' || !*++place) + return(EOF); + if (*place == '-') /* found "--" */ + { + optind++; + return(EOF); + } + } + /* option letter okay? */ + if ((optopt = *place++) == ':' || (oli = strchr(ostr, optopt)) == NULL) + { + if (!*place) + optind++; + tell(": illegal option -- "); + goto Bad; + } + if (*++oli != ':') /* don't need argument */ + { + optarg = NULL; + if (!*place) + optind++; + } + else /* need an argument */ + { + if (*place) + optarg = place; /* no white space */ + else + if (nargc <= ++optind) + { + place = EMSG; + tell(": option requires an argument -- "); + goto Bad; + } + else + optarg = nargv[optind]; /* white space */ + place = EMSG; + optind++; + } + return(optopt); /* dump back option letter */ +Bad: + return('?'); +} \ No newline at end of file diff --git a/localtime.c b/localtime.c index 9b8266a..06243dd 100644 --- a/localtime.c +++ b/localtime.c @@ -58,6 +58,14 @@ static void unlock(void) { } #define OPEN_MODE O_RDONLY #endif /* !defined O_BINARY */ +#ifdef _WIN32 +#ifdef _WIN64 +typedef unsigned __int64 ssize_t; +#else +typedef unsigned int ssize_t; +#endif +#endif + #ifndef WILDABBR /* ** Someone might make incorrect use of a time zone abbreviation: @@ -401,6 +409,13 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (name[0] == ':') ++name; doaccess = name[0] == '/'; +#ifdef _WIN32 + /* + ** DOS drive specifier? + */ + if (isalpha(name[0]) && name[1]==':' && name[2] == '\\') + doaccess = true; +#endif if (!doaccess) { size_t namelen = strlen(name); if (sizeof lsp->fullname - sizeof tzdirslash <= namelen) @@ -1529,11 +1544,13 @@ localtime_tzset(time_t const *timep, struct tm *tmp, bool setname) return tmp; } +#ifndef _WIN32 struct tm * localtime(const time_t *timep) { return localtime_tzset(timep, &tm, true); } +#endif struct tm * localtime_r(const time_t *timep, struct tm *tmp) @@ -1575,11 +1592,13 @@ gmtime_r(const time_t *timep, struct tm *tmp) return gmtsub(gmtptr, timep, 0, tmp); } +#ifndef _WIN32 struct tm * gmtime(const time_t *timep) { return gmtime_r(timep, &tm); } +#endif #ifdef STD_INSPIRED @@ -1724,6 +1743,7 @@ timesub(const time_t *timep, int_fast32_t offset, return NULL; } +#ifndef _WIN32 char * ctime(const time_t *timep) { @@ -1736,6 +1756,7 @@ ctime(const time_t *timep) struct tm *tmp = localtime(timep); return tmp ? asctime(tmp) : NULL; } +#endif char * ctime_r(const time_t *timep, char *buf) @@ -2155,6 +2176,7 @@ mktime_z(struct state *sp, struct tm *tmp) #endif +#ifndef _WIN32 time_t mktime(struct tm *tmp) { @@ -2169,6 +2191,7 @@ mktime(struct tm *tmp) unlock(); return t; } +#endif #ifdef STD_INSPIRED diff --git a/private.h b/private.h index 2e8415e..d460ca3 100644 --- a/private.h +++ b/private.h @@ -266,7 +266,11 @@ typedef int int_fast32_t; #ifndef INTMAX_MAX # ifdef LLONG_MAX typedef long long intmax_t; +# if _MSC_VER <= 1600 +# define strtoimax strtol +# else # define strtoimax strtoll +# endif # define INTMAX_MAX LLONG_MAX # define INTMAX_MIN LLONG_MIN # else diff --git a/zdump.c b/zdump.c index 60a027e..fc90662 100644 --- a/zdump.c +++ b/zdump.c @@ -4,6 +4,9 @@ */ #include "version.h" +#ifdef _WIN32 +#include <stdlib.h> +#endif /* ** This code has been made independent of the rest of the time @@ -22,6 +25,12 @@ #include "private.h" #include <stdio.h> +#if _MSC_VER <= 1600 +# define strtoimax strtol +#else +# define strtoimax strtoll +#endif + #ifndef HAVE_SNPRINTF # define HAVE_SNPRINTF (199901 <= __STDC_VERSION__) #endif @@ -181,6 +190,9 @@ gmtime_r(time_t *tp, struct tm *tmp) return r; } +#endif +#ifdef _WIN32 +struct tm * gmtime_r(time_t *tp, struct tm *tmp); #endif /* Platforms with TM_ZONE don't need tzname, so they can use the @@ -198,7 +210,11 @@ gmtime_r(time_t *tp, struct tm *tmp) # undef localtime_r # define localtime_r zdump_localtime_r static struct tm * +#ifdef _WIN32 +localtime_r(__time64_t *tp, struct tm *tmp) +#else localtime_r(time_t *tp, struct tm *tmp) +#endif { struct tm *r = localtime(tp); if (r) { @@ -212,7 +228,11 @@ localtime_r(time_t *tp, struct tm *tmp) # undef localtime_rz # define localtime_rz zdump_localtime_rz static struct tm * +#ifdef _WIN32 +localtime_rz(timezone_t rz, __time64_t *tp, struct tm *tmp) +#else localtime_rz(timezone_t rz, time_t *tp, struct tm *tmp) +#endif { return localtime_r(tp, tmp); } @@ -421,10 +441,22 @@ main(int argc, char *argv[]) register bool Vflag; register char * cutarg; register char * cuttimes; +#ifdef _WIN32 + register __time64_t cutlotime; + register __time64_t cuthitime; + __time64_t now; + __time64_t t; + __time64_t newt; +#else register time_t cutlotime; register time_t cuthitime; time_t now; + time_t t; + time_t newt; +#endif + struct tm * newtmp; bool iflag = false; + bool newtm_ok; cutlotime = absolute_min_time; cuthitime = absolute_max_time; @@ -531,7 +563,6 @@ main(int argc, char *argv[]) for (i = optind; i < argc; ++i) { timezone_t tz = tzalloc(argv[i]); char const *ab; - time_t t; struct tm tm, newtm; bool tm_ok; if (!tz) { @@ -562,12 +593,12 @@ main(int argc, char *argv[]) } } while (t < cuthitime) { - time_t newt = ((t < absolute_max_time - SECSPERDAY / 2 + newt = ((t < absolute_max_time - SECSPERDAY / 2 && t + SECSPERDAY / 2 < cuthitime) ? t + SECSPERDAY / 2 : cuthitime); - struct tm *newtmp = localtime_rz(tz, &newt, &newtm); - bool newtm_ok = newtmp != NULL; + newtmp = localtime_rz(tz, &newt, &newtm); + newtm_ok = newtmp != NULL; if (tm_ok != newtm_ok || (tm_ok && (delta(&newtm, &tm) != newt - t || newtm.tm_isdst != tm.tm_isdst @@ -605,11 +636,19 @@ main(int argc, char *argv[]) return EXIT_SUCCESS; } +#ifdef _WIN32 +static __time64_t +#else static time_t +#endif yeartot(intmax_t y) { register intmax_t myy, seconds, years; +#ifdef _WIN32 + register __time64_t t; +#else register time_t t; +#endif myy = EPOCH_YEAR; t = 0; diff --git a/zic.c b/zic.c index 304410f..11120ee 100644 --- a/zic.c +++ b/zic.c @@ -897,6 +897,11 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) mkdirs(tofield, true); symlink_errno = symlink(contents, tofield) == 0 ? 0 : errno; } +#ifdef _WIN32 + /* there is no link support on Windows */ + if (symlink_errno == ENOTSUP && !todirs_made) + mkdirs(tofield, true); +#endif free(linkalloc); if (symlink_errno == 0) { if (link_errno != ENOTSUP) @@ -986,6 +991,14 @@ itsdir(char const *name) if (res == 0) return S_ISDIR(st.st_mode) != 0; #endif +#ifdef _WIN32 + if (res == 0 ) { + if ((st.st_mode & 0170000) == 0040000) + return 1; + else + return 0; + } +#else if (res == 0 || errno == EOVERFLOW) { size_t n = strlen(name); char *nameslashdot = emalloc(n + 3); @@ -996,6 +1009,7 @@ itsdir(char const *name) free(nameslashdot); return dir; } +#endif return false; } -- 2.15.1.windows.2

4 16

Morocco stays on GMT+1 / UTC+1 perpetually.
by Mohamed Essedik Najd Oct. 28, 2018

Oct. 28, 2018

Hello, Today, a Moroccan government council approved the perpetual addition of 60 minutes to the regular Moroccan timezone. And thus, Morocco is going to remain on perpetual DST. Source: (french): http://fr.le360.ma/politique/officiel-le-conseil-gouvernement-adopte-le-pro… (arabic): https://www.hespress.com/societe/409985.html (english): https://www.moroccoworldnews.com/2018/10/256071/shocking-morocco-to-stay-on… Regards. -- *Mohamed Essedik Najd* Software Engineer

5 6

Daylight saving change for morocco
by Imad Bidaoui Oct. 28, 2018

Oct. 28, 2018

Dear all, The Moroccan government approved a decision to maintain DST all the year. So Morocco will maintain GMT (Utc+01:00). And we are facing problems with our platforms. It will be great to add this change in your database. Best regards.

2 1

The Death and Life of the 13-Month Calendar
by Soner Gönül Oct. 27, 2018

Oct. 27, 2018

Interesting article. https://www.citylab.com/life/2014/12/the-world-almost-had-a-13-month-calend… -- Soner Gönül http://sonergonul.net http://twitter.com/sonergonul

3 2

Fwd: Timezone for East Asian traditional calendar
by Phake Nick Oct. 27, 2018

Oct. 27, 2018

---------- Forwarded message --------- From: Phake Nick <c933103(a)gmail.com> Date: 2018年10月27日週六上午7:15 Subject: Re: [tz] Timezone for East Asian traditional calendar To: Paul Eggert <eggert(a)cs.ucla.edu> I am not talking about recording information of each of those calendar, instead is to record the time standard (and change to those standard) that are being used to calculate the calendar. For instance the time being used to calculate the lunar calendar for coastal China would be using Beijing Mean Solar Time during year 1914-1928, and then use GMT+8 starting from the year of 1929, ignoring a period of time during Japanese invasion where GMT+9-based calendar might have also been printed.

2 1

Timezone for East Asian traditional calendar
by Phake Nick Oct. 26, 2018

Oct. 26, 2018

Because computation of East Asian traditional calendar depends on time when various astronomical phenomenon occur, especially nowadays when almost all places that are still using the old calendar have switched to use the actual observed/predicted time for those astronomical phenomenon to occur based on modern scientific prediction methodology, yet the time standard being used to compute those traditional calendar differ in each regions and there are multiple occasions in different countries that the time used to compute the traditional calendar, do not directly correspond to the time when the standard time were changed. Is it viable to record such information in another region within tz database? Having such a region could also remind vendors in East Asia area that the world have more than one timezone when computing traditional East Asian calendar and also remind vendors outside East Asia that there are not just Chinese-time-based-Chinese-calendar when computing days, especially when it come to computing festivals based on the traditional East Asian calendars like Lunar New Year, Double Nine Festival, Winter Solstice and Mid-Autumn Festival.

2 1

Morocco decided to stay in UTC+1
by Mounir EL MOKHTARI Oct. 26, 2018

Oct. 26, 2018

Hi, It's official. Morocco has decided to stay in UTC+1. http://www.mapnews.ma/en/top-news/general/morocco-will-stay-summer-time Thanks. Mounir El Mokhtari

1 0

Re: [tz] 2018e Morocco
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

On 10/23/18 7:53 AM, Brian Basarich wrote: > I understand the need for a rule that supports 2038 and beyond, but instead of having overlapping rules, why not create the rules like this: Because that would be more complicated to maintain. > I realize in 2038 the DST end date will likely be in September, and the 2038-max rule would have to be adjusted as future DST end date rules are added. But I don't see how the above is any different than leaving the 2013-max rule. Exactly. What we have for Morocco has the same effect as the rules you suggested, except it's easier to maintain. > And aren't you eventually going to cap the 2013 rule end rule at 2035 down the road? Nobody knows. It's possible Morocco will cancel DST entirely next year and that this will all be moot. > Does this happen elsewhere in the database? That is, where multiple rules apply to the same year, but one rule operationally supersedes the other? I think so, yes.

3 3

Bad 32 bit data in 2018f
by Daniel Fischer Oct. 25, 2018

Oct. 25, 2018

Hi, I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps. The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset: Indian/Christmas Indian/Cocos Atlantic/South_Georgia Pacific/Port_Moresby Pacific/Chuuk Pacific/Yap Pacific/Wallis Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Wake Pacific/Pohnpei Pacific/Truk Pacific/Tarawa The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones. The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). For example, zdump with a break added after /old file/ in localtime.c: $ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo/Atlantic/South_Georgia Tue Oct 23 12:31:33 2018 -02 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Tue Oct 23 12:04:58 2018 LMT $ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 [..] .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sun Jan 1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768 I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use. The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/: 1) y2038_boundary-1 transition is added (== INT32_MAX) 2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX 3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0 4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either 5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files. This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.) I'm unfortunately not familiar enough with the tz database to suggest a complete fix. Danny -- Daniel Fischer ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603 Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher NL

2 4

[PROPOSED] * northamerica: El Paso time zone rebellion.
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

--- northamerica | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/northamerica b/northamerica index fb0103f..9d5bad2 100644 --- a/northamerica +++ b/northamerica @@ -439,6 +439,19 @@ Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 # western South Dakota, far western Texas (El Paso County, Hudspeth County, # and Pine Springs and Nickel Creek in Culberson County), Utah, Wyoming # +# From Paul Eggert (2018-10-25): +# On 1921-03-04 federal law placed all of Texas into the central time zone. +# However, El Paso ignored the law for decades and continued to observe +# mountain time, on the grounds that that's what they had always done +# and they weren't about to let the federal government tell them what to do. +# Eventually the federal government gave in and changed the law on +# 1970-04-10 to match what El Paso was actually doing. Although +# that's slightly after our 1970 cutoff, there is no need to create a +# separate zone for El Paso since they were ignoring the law anyway. See: +# Long T. El Pasoans were time rebels, fought to stay in Mountain zone. +# El Paso Times. 2018-10-24 06:40 -06. +# https://www.elpasotimes.com/story/news/local/el-paso/2018/10/24/el-pasoans-… +# # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER Rule Denver 1920 1921 - Mar lastSun 2:00 1:00 D Rule Denver 1920 only - Oct lastSun 2:00 0 S -- 2.17.1

1 0

[PROPOSED] Add interoperability sections to tzfile.5
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

This change consists of text that I contributed to https://tools.ietf.org/html/draft-murchison-tzdist-tzif-15 and that should be useful generally. * NEWS, tzfile.5: New sections. --- NEWS | 4 ++ tzfile.5 | 192 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 195 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 943db3e..68f826e 100644 --- a/NEWS +++ b/NEWS @@ -16,6 +16,10 @@ Unreleased, experimental changes This reverts to 2011h, as the abbreviation change in 2011i was likely inadvertent. + Changes to documentation + + tzfile.5 has new sections on interoperability issues. + Release 2018f - 2018-10-18 00:14:18 -0700 diff --git a/tzfile.5 b/tzfile.5 index 79b19bf..bbdccfc 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -9,6 +9,8 @@ tzfile \- timezone information .de q \\$3\*(lq\\$1\*(rq\\$2 .. +.ie \n(.g .ds - \f(CW-\fP +.el ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like @@ -186,8 +188,196 @@ from 0 through 24. Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. -.PP +.SS Interoperability considerations Future changes to the format may append more data. +.PP +Version 1 files are considered a legacy format and +should be avoided, as they do not support transition +times after the year 2038. +Readers that only understand Version 1 must ignore +any data that extends beyond the calculated end of the version +1 data block. +.PP +Writers should generate a version 3 file if +TZ string extensions are necessary to accurately +model transition times. +Otherwise, version 2 files should be generated. +.PP +The sequence of time changes defined by the version 1 +header and data block should be a contiguous subsequence +of the time changes defined by the version 2+ header and data +block, and by the footer. +This guideline helps obsolescent version 1 readers +agree with current readers about timestamps within the +contiguous subsequence. It also lets writers not +supporting obsolescent readers use a +.I tzh_timecnt +of zero +in the version 1 data block to save space. +.PP +Time zone designations should consist of at least three (3) +and no more than six (6) ASCII characters from the set of +alphanumerics, +.q "-", +and +.q "+". +This is for compatibility with POSIX requirements for +time zone abbreviations. +.PP +When reading a version 2 or 3 file, readers +should ignore the version 1 header and data block except for +the purpose of skipping over them. +.PP +Readers should calculate the total lengths of the +headers and data blocks and check that they all fit within +the actual file size, as part of a validity check for the file. +.SS Common interoperability issues +This section documents common problems in reading or writing TZif files. +Most of these are problems in generating TZif files for use by +older readers. +The goals of this section are: +.IP * 2 +to help TZif writers output files that avoid common +pitfalls in older or buggy TZif readers, +.IP * +to help TZif readers avoid common pitfalls when reading +files generated by future TZif writers, and +.IP * +to help any future specification authors see what sort of +problems arise when the TZif format is changed. +.PP +When new versions of the TZif format have been defined, a +design goal has been that a reader can successfully use a TZif +file even if the file is of a later TZif version than what the +reader was designed for. +When complete compatibility was not achieved, an attempt was +made to limit glitches to rarely-used timestamps, and to allow +simple partial workarounds in writers designed to generate +new-version data useful even for older-version readers. +This section attempts to document these compatibility issues and +workarounds, as well as to document other common bugs in +readers. +.PP +Interoperability problems with TZif include the following: +.IP * 2 +Some readers examine only version 1 data. +As a partial workaround, a writer can output as much version 1 +data as possible. +However, a reader should ignore version 1 data, and should use +version 2+ data even if the reader's native timestamps have only +32 bits. +.IP * +Some readers designed for version 2 might mishandle +timestamps after a version 3 file's last transition, because +they cannot parse extensions to POSIX in the TZ-like string. +As a partial workaround, a writer can output more transitions +than necessary, so that only far-future timestamps are +mishandled by version 2 readers. +.IP * +Some readers designed for version 2 do not support +permanent daylight saving time, e.g., a TZ string +.q "EST5EDT,0/0,J365/25" +denoting permanent Eastern Daylight Time (\*-04). +As a partial workaround, a writer can substitute standard time +for the next time zone east, e.g., +.q "AST4" +for permanent Atlantic Standard Time (\*-04). +.IP * +Some readers ignore the footer, and instead predict future +timestamps from the time type of the last transition. +As a partial workaround, a writer can output more transitions +than necessary. +.IP * +Some readers do not use time type 0 for timestamps before +the first transition, in that they infer a time type using a +heuristic that does not always select time type 0. +As a partial workaround, a writer can output a dummy (no-op) +first transition at an early time. +.IP * +Some readers mishandle timestamps before the first +transition that has a timestamp not less than -2**31. +Readers that support only 32-bit timestamps are likely to be +more prone to this problem, for example, when they process +64-bit transitions only some of which are representable in 32 +bits. +As a partial workaround, a writer can output a dummy +transition at timestamp \*-2**31. +.IP * +Some readers mishandle a transition if its timestamp has +the minimum possible signed 64-bit value. +Timestamps less than \*-2**59 are not recommended. +.IP * +Some readers mishandle POSIX-style TZ strings that +contain +.q "<" +or +.q ">". +As a partial workaround, a writer can avoid using +.q "<" +or +.q ">" +for time zone abbreviations containing only alphabetic +characters. +.IP * +Many readers mishandle time zone abbreviations that contain +non-ASCII characters. +These characters are not recommended. +.IP * +Some readers may mishandle time zone abbreviations that +contain fewer than 3 or more than 6 characters, or that +contain ASCII characters other than alphanumerics, +.q "-", +and +.q "+". +These abbreviations are not recommended. +.IP * +Some readers mishandle TZif files that specify +daylight-saving time UT offsets that are less than the UT +offsets for the corresponding standard time. +These readers do not support locations like Ireland, which +uses the equivalent of the POSIX TZ string +.q "IST\*-1GMT0,M10.5.0,M3.5.0/1", +observing standard time +(IST, +01) in summer and daylight saving time (GMT, +00) in winter. +As a partial workaround, a writer can output data for the +equivalent of the POSIX TZ string +.q "GMT0IST,M3.5.0/1,M10.5.0", +thus swapping standard and daylight saving time. +Although this workaround misidentifies which part of the year +uses daylight saving time, it records UT offsets and time zone +abbreviations correctly. +.PP +Some interoperability problems are reader bugs that +are listed here mostly as warnings to developers of readers. +.IP * 2 +Some readers do not support negative timestamps. +Developers of distributed applications should keep this +in mind if they need to deal with pre-1970 data. +.IP * +Some readers mishandle timestamps before the first +transition that has a nonnegative timestamp. +Readers that do not support negative timestamps are likely to +be more prone to this problem. +.IP * +Some readers mishandle time zone abbreviations like +.q "-08" +that contain +.q "+", +.q "-", +or digits. +.IP * +Some readers mishandle UT offsets that are out of the +traditional range of \*-12 through +12 hours, and so do not +support locations like Kiritimati that are outside this +range. +.IP * +Some readers mishandle UT offsets in the range [\*-3599, \*-1] +seconds from UT, because they integer-divide the offset by +3600 to get 0 and then display the hour part as +.q "+00". +.IP * +Some readers mishandle UT offsets that are not a multiple +of one hour, or of 15 minutes, or of 1 minute. .SH SEE ALSO .BR time (2), .BR localtime (3), -- 2.17.2

1 0

[PROPOSED] * NEWS: Improve recent entries.
by Paul Eggert Oct. 25, 2018

Oct. 25, 2018

--- NEWS | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 4eb313f..943db3e 100644 --- a/NEWS +++ b/NEWS @@ -7,12 +7,14 @@ Unreleased, experimental changes The translator to rearguard format now rewrites the line "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S". - This caters to zic before 2007 and to at least one Java-based zi - compiler of uncertain vintage. (Reported by Christos Zoulas.) + This caters to zic before 2007 and to Oracle TZUpdater 2.2.0 + and earlier. (Reported by Christos Zoulas.) Changes to past time zone abbreviations Change HDT to HWT/HPT for WWII-era abbreviations in Hawaii. + This reverts to 2011h, as the abbreviation change in 2011i was + likely inadvertent. Release 2018f - 2018-10-18 00:14:18 -0700 -- 2.17.2

1 0

Bad 32 bit data in 2018f
by Daniel Fischer Oct. 24, 2018

Oct. 24, 2018

Hi, I'm getting bad data in the 32 bit section of some of the compiled files in zoneinfo-leaps. The affected time zones are zones that only transition before 1901, usually from LMT to some UTC offset: Indian/Christmas Indian/Cocos Atlantic/South_Georgia Pacific/Port_Moresby Pacific/Chuuk Pacific/Yap Pacific/Wallis Pacific/Funafuti Pacific/Palau Pacific/Ponape Pacific/Wake Pacific/Pohnpei Pacific/Truk Pacific/Tarawa The files in zoneinfo-leaps contain no transitions, and only the offset used before the transition. This causes applications that only read the 32 bit section to use LMT for these zones. The 64 bit section, and both sections in the zoneinfo version of these files, contain >=2 transitions and offsets (e.g. one real transition and one in 2038). For example, zdump with a break added after /old file/ in localtime.c: $ ./zdump $PWD/TZ/usr/share/zoneinfo*/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo/Atlantic/South_Georgia Tue Oct 23 12:31:33 2018 -02 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Tue Oct 23 12:04:58 2018 LMT $ ./zdump -V $PWD/TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:00 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sat Jul 1 00:00:01 1972 UT = Fri Jun 30 21:33:52 1972 LMT isdst=0 gmtoff=-8768 [..] .../TZ/usr/share/zoneinfo-leaps/Atlantic/South_Georgia Sun Jan 1 00:00:27 2017 UT = Sat Dec 31 21:33:52 2016 LMT isdst=0 gmtoff=-8768 I found that before commit 83c119f4d ("Remove Big Bang hack"), the one offset present in the leaps version was the correct one. The structural difference is older; it just didn't affect my application because the offset was the one currently in use. The cause appears to be this sequence of events starting at zic.c /Work around QTBUG-53071/: 1) y2038_boundary-1 transition is added (== INT32_MAX) 2) leap seconds are added to all times, pushing the 2038 transition above INT32_MAX 3) affected zones again only have transition times outside the 32 bit range => timecnt32 is 0 4) because timecnt32 is 0, timei32 is also 0, and the INT32_MIN transition isn't output either 5) because of omittype[defaulttype] = false, the oldest offset is always output regardless of the above The workaround could probably be moved to after the leap seconds are added, especially if it's supposed to apply to the 32 bit leaps files. This will also fix this bug, because the code that determines the 32 bit limits assumes there's at least one time after 1901, and the workaround provides one. (This is why the non-leaps version is correct.) I'm unfortunately not familiar enough with the tz database to suggest a complete fix. Danny -- Daniel Fischer ORACLE Deutschland B.V. & Co. KG, Riesstr. 25, 80992 München - HRA MUC 95603 Komplementaer: ORACLE DE Verw.B.V., Hertogswetering 163/167, 3543 AS Utrecht Geschaeftsfuehrer: Alexander van der Ven, Jan Schultheiss, Val Maher NL

1 0

South Korea timezone history
by Phake Nick Oct. 24, 2018

Oct. 24, 2018

On Korean Wikipedia article for DST https://ko.wikipedia.org/wiki/%EC%9D%BC%EA%B4%91_%EC%A0%88%EC%95%BD_%EC%8B%… , I saw the following lines (with machine translation): >In Korea, the standard meridian of the time was 127° 30' in Tokyo during the period of 1955 to 1960, so it was 30 minutes earlier than it is today. This information is different from what's currently described in tz database and should be investigated. Also, given the example of DST transaction in Japan, it might also worth investigating what did the "00:00[start]-00:00[end]" in Korean DST transaction mean at the time.

1 1

[PROPOSED] * tz-link.html: Update Windows details and links
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..8593ba6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -524,11 +524,10 @@ clock (intclock)</a> is a clock that displays multiple time zones on under the <abbr>GPL</abbr>.</li> <li>Microsoft Windows 8.1 and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr> -data (mentioned <a href="#CLDR">below</a>) used by the -<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> / -<a href="https://en.wikipedia.org/wiki/Universal_Windows_Platform">Universal Windows Platform</a> classes -<a href="https://docs.microsoft.com/uwp/api/Windows.Globalization.DateTimeFormatting…"><code>DateTimeFormatter</code></a> and -<a href="https://docs.microsoft.com/uwp/api/windows.globalization.calendar"><code>Calendar</code></a>. +data (mentioned <a href="#CLDR">below</a>) used by +<a href="https://en.wikipedia.org/wiki/Windows_Runtime">Windows Runtime</a> +classes such as <a +href="https://msdn.microsoft.com/en-us/library/windows/apps/windows.globalization…"><code>DateTimeFormatter</code></a>. <a id="System.TimeZoneInfo" href="https://blogs.msdn.microsoft.com/bclteam/2007/06/07/exploring-windows-time-…">Exploring Windows Time Zones with <code>System.TimeZoneInfo</code></a> describes

2 2

Re: [tz] [PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

On 10/23/18 12:07 PM, Michael H Deckers wrote: > You might want to add HWT and HPT to the list in theory.html as well. Thanks, good catch. Also the NEWS file. I installed the attached.

2 2

DST time zone Amercia/Sao_Paulo
by Júnior Didoné Oct. 23, 2018

Oct. 23, 2018

Greetings, I would like to inform you that DST is *active* for America / Sao_Paulo and Brazil/East Time Zones, since yesterday. However, the *correct* date for activation is *November 4, 2018*, the Brazilian government changed it in February 2018. This is causing errors in Oracle Databases in Amazon Web Services. Please, correct as soon as possible. Thank you, Júnior Didoné

3 2

2018f tzdb released with bug
by Laurenti, Leandro Oct. 23, 2018

Oct. 23, 2018

A/C Mr. Paul Eggert Hi, After several years, the DST start time was changed in Brazil. Until the last year, it was set to start in the 3rd weekend of October. In this year, it will start on November 4th. So, we were instructing our customers to run the tzupdater tool , from oracle, that relies on the "tzdata-latest.tar.gz" file from IANA. However, when the customers are trying to update java, they are getting the following error: https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8212684?filter=allope… Failed: java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S' java.lang.Exception: Failed while parsing file 'C:\Users\ME928~1.SYR\AppData\Local\Temp\tz.tmp_5\asia' on line 1655 'Rule Japan 1948 1951 - S Sat>=8 25:00 0 S' So it seems to be a problem with 2018f version of the tzdb file... It seems the 2018e version is working fine. Not sure if someone from Brazil or any other country already have contacted you... Since this is a very critical problem, we hope this to be fixed asap. Thank you in advance. Best Regards, Leandro Laurenti Support Engineer CA Technologies | Av. Dr. Chucri Zaidan, 1240 26º e 27º andares, Golden Tower | Sao Paulo, SP 04711-130 Office: +80353 | Leandro.Laurenti(a)ca.com <mailto:Leandro.Laurenti@ca.com>[CA]<http://www.ca.com/us/default.aspx>[Twitter]<http://twitter.com/CAInc>[Slideshare]<http://www.slideshare.net/cainc>[Facebook]<https://www.facebook.com/CATechnologies>[YouTube]<http://www.youtube.com/user/catechnologies>[LinkedIn]<http://www.linkedin.com/company/1372?goback=.cps_1244823420724_1>[Google+]<https://plus.google.com/+CATechnologies>[Google+]<http://www.ca.com/us/rss.aspx?intcmp=footernav>

2 6

[PROPOSED] * tz-link.html: Mention TimeZoneConverter and ICU for tz<->windows mappings
by Matt Johnson Oct. 23, 2018

Oct. 23, 2018

diff --git a/tz-link.html b/tz-link.html index b5870d3..f959f93 100644 --- a/tz-link.html +++ b/tz-link.html @@ -541,6 +541,8 @@ Tzid table</a> or <a href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml"><abbr>XML</abbr> file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs to <code><abbr>tz</abbr></code> names. +These mappings can be performed programmatically via the <a href="https://github.com/mj1856/TimeZoneConverter">TimeZoneConverter</a> .NET library, +or the ICU Java and C++ libraries mentioned <a href="#ICU">above</a>. <li><a href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent

1 0

America/Sao_Paulo file.
by Vitor Vieira Andrade Oct. 23, 2018

Oct. 23, 2018

Hi Guis, I've downloaded the tzdata and compiled the Sao_Paulo rulefile. After run the zdump command, the output shows : The daylight saving time should change at Sun 4 Nov, how do i re-compile it on the correct day. Regards, ibm-brasil-100 VITOR VIEIRA ANDRADE IT Specialist - Unix/Linux. E-mail: vitorv(a)br.ibm.com IBM Rua Tutoia 1157 Sao Paulo, SP 04007-900 Brazil

2 1

[PROPOSED] Be consistent about WWII abbreviations in Hawaii
by Paul Eggert Oct. 23, 2018

Oct. 23, 2018

* northamerica (Pacific/Honolulu): Use abbreviations HWT and HPT for consistency with other US abbreviations during World War II. --- northamerica | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/northamerica b/northamerica index 88c0f6f..fb0103f 100644 --- a/northamerica +++ b/northamerica @@ -708,9 +708,7 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00 -10:30 - HST 1933 Apr 30 2:00 -10:30 1:00 HDT 1933 May 21 12:00 - -10:30 - HST 1942 Feb 9 2:00 - -10:30 1:00 HDT 1945 Sep 30 2:00 - -10:30 - HST 1947 Jun 8 2:00 + -10:30 US H%sT 1947 Jun 8 2:00 -10:00 - HST # Now we turn to US areas that have diverged from the consensus since 1970. -- 2.17.2

1 0

2018e Morocco
by Kiley Walbom Oct. 20, 2018

Oct. 20, 2018

Paul, We are in the process of revamping our extraction programs and noticed an anomaly in Morocco The current rules look like this: v2018e Africa lines 893, 916, and 917 Rule Morocco 2013 max - Oct lastSun 3:00 0 - Rule Morocco 2036 only - Oct 19 3:00 0 - Rule Morocco 2037 only - Oct 4 3:00 0 - Our new program "thinks" there is an overlap in the end dates. After looking at the rules we believe the end date for line 893 should look like this: Rule Morocco 2013 2035 - Oct lastSun 3:00 0 - If the European Commission proposal becomes official, your proposal will fix this issue. Thank you for your time. Kiley

2 1

Chile changes dates for DST from 2019
by Juan Correa Oct. 18, 2018

Oct. 18, 2018

As of moments ago, the Ministry of Energy in Chile has announced the new schema for DST. >From 2019, Chile will end DST (jump from UTC -3 to UTC -4) on the first sunday of April (2019-04-07T03:00:00Z); and will start DST (from UTC -4 to UTC -3) the first sunday of September (2019-09-08T04:00:00Z) Also, the Ministry (Susana Jimenez) announced this decision will stick until 2021; and that Magallanes will keep its own time zone (but there will be meetings to talk about this) Announcement in video (in spanish): https://twitter.com/MinEnergia/status/1029000399129374720 -- Juan Correa Poblete PS Labs (http://www.pslabs.cl)

5 5

Another change on Brazilian DST time
by Fábio Gomes Oct. 18, 2018

Oct. 18, 2018

Hi, The brazilian president just announced a new change on this year DST. It was scheduled to start on November 4th and it was changed to November 18th. How long does it takes to update tzdata with this new information? We, IT professionals, are very upset with this change since most of us had already updated our files. And now we have a very shourt window to apply this new update. Thank you

15 35

[tz-announce] 2018f release of tz code and data available
by Paul Eggert Oct. 18, 2018

Oct. 18, 2018

The 2018f 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 moves from +03 to +04 on 2018-10-28. Fiji ends DST 2019-01-13, not 2019-01-20. Most of Chile changes DST dates, effective 2019-04-06. Changes to future timestamps Volgograd moves from +03 to +04 on 2018-10-28 at 02:00. (Thanks to Alexander Fetisov and Stepan Golosunov.) Fiji ends DST 2019-01-13 instead of the 2019-01-20 previously predicted. (Thanks to Raymond Kumar.) Adjust future predictions accordingly. Most of Chile will end DST on the first Saturday in April at 24:00 mainland time, and resume DST on the first Saturday in September at 24:00 mainland time. The changes are effective from 2019-04-06, and do not affect the Magallanes region modeled by America/Punta_Arenas. (Thanks to Juan Correa and Tim Parenti.) Adjust future predictions accordingly. Changes to past timestamps The 2018-05-05 North Korea 30-minute time zone change took place at 23:30 the previous day, not at 00:00 that day. China's 1988 spring-forward transition was on April 17, not April 10. Its DST transitions in 1986/91 were at 02:00, not 00:00. (Thanks to P Chan.) Fix several issues for Macau before 1992. Macau's pre-1904 LMT was off by 10 s. Macau switched to +08 in 1904 not 1912, and temporarily switched to +09/+10 during World War II. Macau observed DST in 1942/79, not 1961/80, and there were several errors for transition times and dates. (Thanks to P Chan.) The 1948-1951 fallback transitions in Japan were at 25:00 on September's second Saturday, not at 24:00. (Thanks to Phake Nick.) zic turns this into 01:00 on the day after September's second Saturday, which is the best that POSIX or C platforms can do. Incorporate 1940-1949 Asia/Shanghai DST transitions from a 2014 paper by Li Yu, replacing more-questionable data from Shanks. Changes to time zone abbreviations Use "PST" and "PDT" for Philippine time. (Thanks to Paul Goyette.) Changes to code zic now always generates TZif files where time type 0 is used for timestamps before the first transition. This simplifies the reading of TZif files and should not affect behavior of existing TZif readers because the same set of time types is used; only their internal indexes may have changed. This affects only the legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. Because of the type 0 change, zic no longer outputs a dummy transition at time -2**59 (before the Big Bang), as clients should no longer need this to handle historical timestamps correctly. This reverts a change introduced in 2013d and shrinks most TZif files by a few bytes. zic now supports negative time-of-day in Rule and Leap lines, e.g., "Rule X min max - Apr lastSun -6:00 1:00 -" means the transition occurs at 18:00 on the Saturday before the last Sunday in April. This behavior was documented in 2018a but the code did not entirely match the documentation. localtime.c no longer requires at least one time type in TZif files that lack transitions or have a POSIX-style TZ string. This future-proofs the code against possible future extensions to the format that would allow TZif files with POSIX-style TZ strings and without transitions or time types. A read-access subscript error in localtime.c has been fixed. It could occur only in TZif files with timecnt == 0, something that does not happen in practice now but could happen in future versions. localtime.c no longer ignores TZif POSIX-style TZ strings that specify only standard time. Instead, these TZ strings now override the default time type for timestamps after the last transition (or for all time stamps if there are no transitions), just as DST strings specifying DST have always done. leapseconds.awk now outputs "#updated" and "#expires" comments, and supports leap seconds at the ends of months other than June and December. (Inspired by suggestions from Chris Woodbury.) Changes to documentation New restrictions: A Rule name must start with a character that is neither an ASCII digit nor "-" nor "+", and an unquoted name should not use characters in the set "!$%&'()*,/:;<=>?@[\]^`{|}~". The latter restriction makes room for future extensions (a possibility noted by Tom Lane). tzfile.5 now documents what time types apply before the first and after the last transition, if any. Documentation now uses the spelling "timezone" for a TZ setting that determines timestamp history, and "time zone" for a geographic region currently sharing the same standard time. The name "TZif" is now used for the tz binary data format. tz-link.htm now mentions the A0 TimeZone Migration utilities. (Thanks to Aldrin Martoq for the link.) Changes to build procedure New 'make' target 'rearguard_tarballs' to build the rearguard tarball only. This is a convenience on platforms that lack lzip if you want to build the rearguard tarball. (Problem reported by Deborah Goldsmith.) tzdata.zi is now more stable from release to release. (Problem noted by Tom Lane.) It is also a bit shorter. tzdata.zi now can contain comment lines documenting configuration information, such as which data format was selected, which input files were used, and how leap seconds are treated. (Problems noted by Lester Caine and Brian Inglis.) If the Makefile defaults are used these comment lines are absent, for backward compatibility. A redistributor intending to alter its copy of the files should also append "-LABEL" to the 'version' file's first line, where "LABEL" identifies the redistributor's change. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018f.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018f.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 7c97eb855432c3557a8d84727a685fcd2fdb2bff dated 2018-10-18 00:14:18 -0700 and tagged '2018f' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: d4270918fbd8eb786e6f5cec9f06df6a850bbf1ec278f60ce493b6b7e10e2ad1388383edcd869f07bc78b9d99a123d6f54e74105cdd3d5cb6c98e11d3f043727 tzcode2018f.tar.gz f876729419d45e2b861e564ec7d5940f34fab38c3fedc18852bb800010428c12506f71bde1f20feb23859065118ad4658d97efe89af6f4305cea2beafc515aeb tzdata2018f.tar.gz 4cdc6e2fc3b84c25ba4ac99329cfa7c507bb9be22cab00604bfab65944d225fc605a842e8b0a05e258f6f42eddf8b68273729a211ed78b0172afc2788ae1f29c tzdb-2018f.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjSnMRAAr/pLmohlfPzhkcc+Yw4FbpBOYUsj9XeExKd5WDp4nsjgOwLfLJcwT7oo VSp3tiv+jGh+/ZnSZWSTHT/YfBdmRjVmj42FBWZgjYwr70373HGP/vIwHgUrv5Kk wUse5BUX4nwQK0xcuaOzKF5+uUG0MoKDo6sRzrYoS8JMP/mVlLtkZt1GHs99Kkaj Gnn6lyLOTChxrLU2UP1lra0h/t7T/dtTgGHf0biN7onNLYFiRL+La9pJKNVuvljW mjSaPw1Pl+1tCFMo6Rcm8Rkq/cazJaQY2Pdw/CGEvK+a9tjGBf+vvxWhIiLZimAH eygVfg6XCfn7gfjTn6fZHM3+lgGF6W4uQ429jEOR/OUCymb4gOPWB5emSVFms3vy XkHsazZa3UwAD/dzGJ1Y0CXiwggiNqe6xqn41bzqaLgtSg64gK17CIeu42soniZe 5SCXVl45tsURx/z50pQ8Q5I+JK8DvYkkhmP5l8CI6OhYUr8DY+bLdK0+fao8coT9 JXee8U+2ARx7UxgP+yytx+iDzHiRgnnF1is0SkUw9Ksnp61iY9sgpTIuzcr6SOs3 ZLeAT3c6Zmuq+Wikm7u1qVTyR5QcbEmuTspY+4wG9Tn7DrzWnSFj76B1P4+8bENY 28AW/Ca8cqMfcKYv0PVoHhVH3lb1h/zOLV8B06hIWcOErGTGPd4= =9tf8 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjRDfg//ciH78cevDN3GyghrxtdY6diUwqaw4qvAngDxeygWS6Hcm8JnExAS7EfZ Mcp1SwDog47Bv+9p11twd0SvdkFPXzrQ4S77ZXIddgTEmZ+a7fVLMtvwn/9w61gL wmEUgSE4yECabGG2mGLMbGaPGmhjCi5Gh3ErmhcmS0xuEvfkyAPcN2KYvLlFt2+H DLvYzYIWhf5O910twzySiIDEpuOsYf60BV9v5/NeEa7Q9kAAytomkhU4WWAeazgU DUFMyWrN9pcn4eWrKFFcRxbXyzSTRdx0E6kgEcVfSjxx75SwNAmWLb5wWarrKV5F MqPRlzVA3favvGNsBGZMdGh2E7Q+qVBGlTxftv2scYX/9I9tP6zMC7/yTl3ys2Hb tNZd5D/99az2VBMxSkaJW8AwwqfHqX5c3GO7p1e5zKy4p5lEMvHtbA1j8GWmy8mQ C1T0pi4JDkq4it/YJyJm8m6eYhUV/v3ftHNPgRIbcoFfMPy+n+wtFAwjY0ml4wKd oUi2x/05u3zoPwGU59aUw09re8LKvbBiu7EuI8p4ZUVaXgkatAqw0T/4jF69hEMx 6X7fY2It1sSg59X5ApWL9JlX8/lK2R5g6MKRqv99HPh60zQ+et8tI6rBY+lX4wx6 2XSOr1OwCNG0l7qLHRx6HVZ7Ce/pX0Mn5TgxonWTKVBh7Jb9Tac= =6cRa -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAUACgkQ7ZfpDmKq fjR7Ag//XMMJj6ZeiWZokr3NEKLNKWwEGo8j/l1XH3tq74KUOINnJqar/d/EPNoi 6mpZHiZ9r03md6TZ/D4Fx2X6lXkdzHnwGiSWY7GzaJSpTqZxzgyWaaZDE9dxGC+5 FB/f96/BSx6oRqZ4dZRBV0vgsjuluo3k9vMotNbUA5lMbIu94QnD4WJ602hNaFbe odI8EXtnr6EQyLBvSFfdbxYLq02cndWPqYTE9cbmNXZ4LnufB/uKmNRYfHIkCOF+ 4ZZNghRbUsC/sUnoSNXaDUV/l43juEPN6RUMKsodOZpAhWyAgRMWw5lbrkCwRMvI dIvpdfynPvQznUuDbq+cyGZefFah9TMPPFZQdGtUejC4hrbWsaP3myTj/jVgvIKC 5qHMb2qD1MebUZtQq2dGZw7/SdyxVmaz8HLINkwrNvfpfGc6+weGmvnPVthPrQxK 4IwQQvzyi4UbPnZLiDuAJZ09OgJ+HgM3CkkIETcUfIXvkYcxFFL4uY+6pHGedoBX KyfPeW3Jc/LivBvy52AOjqYzTjdddQVUymzOQ64rAAzgnBNGdIraCwWEwuBVjHkG hUQFpfjMEkD7kQfxzTxH/LbsT1ifjBBkzxWjeuL8ewhgwykeuwVTeixujH5HKcfx HL2C8e5yY+Zo9eQkyc6YpkUmlnNhsrFLdEoFoAJSrku1dHssw4s= =FA6n -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets, this particular release's data entries are also available in a rearguard-format tarball and signature that does not contain such offsets. This is intended to be a temporary transition aid for these parsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018f/tzdata2018f-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018f/tzdata2018f-rearguard.tar.… with the following SHA-512 and GPG checksums: 7c6105cda6bc81217d7740201133d9ccf0d4ca0f5f3e6248fa071c676976c28f06cf7c2240e455d1948f5b2ef5f8e359aca8b5206beddbd6af79c3a7070ba301 tzdata2018f-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAlvINAMACgkQ7ZfpDmKq fjQM0RAAi56P17pHUDukQ81drgNlRCliqRe1x0047jxCtkrBvIDdJb7lnrTolhrH P78E/f36r4PTAKjGjO9FZvvs61si3YSiHcNdBGzzf41Mhwvbsk14a6ybeU6vRJrj AWUNj/LYg+PK1fUjeY/CrViFWmXPtndPpew9G1cyL3H8HvGQlPm6Ey9JDv6rVVi5 mSkBKXcN5w8VfMzMx2UDLFfRgSnTa4bjbuv/I8HXoAJjtzBR+53G/6oGeXiZ9Fnd hwZa8DbAZ+H4YdsPIdUo/Oz/mU/cfvTZcLkTy7rBciEWk7ylXMddlqdc7+blToga 95eeNGinB6b+8pEpdg0BJTCq7VW4TBjG6W4Zu5RsS3ZJOa8TeMyKVR2S0ZV6zCmN +SvFUHWZ9dqKR7jppxbIsoKSeexpY7WPGJJBwjgZEaIudN0HWok+mw0iLG0U6D2q va3cIEuVG4pitb9uQmuM3hVPuO0Bndxm6ws3hSxvRmTuluJIL4tXErhVJqqZsCJ1 XvqcFlCSD7rtcwP7YzNCKgxzCfMXMvf1Nwfylq8ZWhfaWGk/lBm+eH18zKPHBIe2 OMU9uNxF12KlVNmNknod+AaLTHcXan21vgbR7Syar+fGLofcuPyDOu2frB1FxDaW eotUedxfia9p4gbH5qjMeBHPf2ca8yCf0Dnfmxv174NWVLkOmnE= =OEcz -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

[PROPOSED] * tz-link.html, theory.html: Remove outdated info, fix links and dates.
by Paul Eggert Oct. 18, 2018

Oct. 18, 2018

--- theory.html | 2 +- tz-link.html | 12 +++--------- 2 files changed, 4 insertions(+), 10 deletions(-) diff --git a/theory.html b/theory.html index 6e4a14e..8dd58db 100644 --- a/theory.html +++ b/theory.html @@ -1339,7 +1339,7 @@ Sources for time on other planets: Matt Williams, "<a href="https://www.universetoday.com/37481/days-of-the-planets/">How long is a day on the other planets of the solar system?</a>" - (2017-04-27). + (2016-01-20). </li> </ul> </section> diff --git a/tz-link.html b/tz-link.html index eef7b63..8593ba6 100644 --- a/tz-link.html +++ b/tz-link.html @@ -35,8 +35,6 @@ including C Library</a> (used in <a href="https://en.wikipedia.org/wiki/Linux"><abbr>GNU</abbr>/Linux</a>), <a href="https://www.android.com">Android</a>, -<a href="https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS">B2G -<abbr title="Operating System">OS</abbr></a>, <a href="https://www.freebsd.org">Free<abbr title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://netbsd.org">Net<abbr>BSD</abbr></a>, @@ -68,8 +66,7 @@ name of the largest city within the region containing the clocks. For example, <code>America/New_York</code> represents most of the <abbr title="United States">US</abbr> eastern time zone; <code>America/Phoenix</code> represents most of Arizona, which -uses mountain time without daylight saving time (<abbr -title="daylight saving time">DST</abbr>); +uses mountain time without daylight saving time (<abbr>DST</abbr>); <code>America/Detroit</code> represents most of Michigan, which uses eastern time but with different <abbr>DST</abbr> rules in 1975; and other entries represent smaller regions like Starke County, @@ -548,7 +545,7 @@ href="https://www.oracle.com/java/index.html">Oracle Java</a> contains a copy of a subset of a recent <code><abbr>tz</abbr></code> database in a Java-specific format.</li> -<li><a href="https://www.relativedata.com/time-zone-master">Time Zone +<li><a href="https://relativedata.com/page/Time-Zone-Master">Time Zone Master</a> is a Microsoft Windows clock program that can automatically download, compile and use <code>tz</code> releases. The Basic version is free.</li> @@ -574,9 +571,6 @@ its own <code>tztab</code>(4) format.</li> <a href="#System.TimeZoneInfo">above</a>.</li> <li><a href="https://www.worldtimeserver.com">World Time Server</a> is another time zone database.</li> -<li><a href="http://tycho.usno.navy.mil/tzones.html">World Time Zones</a> -contains data from the Time Service Department of the -<abbr>US</abbr> Naval Observatory.</li> <li>The <a href="https://www.iata.org/publications/store/Pages/standard-schedules-informatio…">Standard Schedules Information Manual</a> of the @@ -762,7 +756,7 @@ href="ftp://ftp.cs.huji.ac.il/pub/tz/announcements" hreflang="he">announcements (in Hebrew)</a>.</dd> <dt>Italy</dt> <dd>The National Institute of Metrological Research maintains a -<a href="http://www.nanospin.eu/res/tf/ora_legale_i.shtml">table of civil time +<a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml">table of civil time (in Italian)</a>.</dd> <dt>Macau</dt> <dd>The Meteorological and Geophysical Bureau maintains a -- 2.17.1

1 0

[TZDB for Delphi] Encountered issue using TBundledTimezone on LINUX
by Jean Frauciel Oct. 17, 2018

Oct. 17, 2018

Hello, I'm working on the development of a software that uses the TZDB for Delphi to deal with the timezones' management, and I'd like to have your opinion about a problem that we are facing. In a procedure, in order to decompose the periods of a timezone, we have to know the timezone's year of a UTC DateTime. To do so, we are using these commands : thisBundledTimezone := TBundledTimeZone.GetTimeZone('America/Los_Angeles'); timeZoneYear := YearOf(IncMinute(aUTCDateTime, Round(thisBundledTimezone.UtcOffset.TotalMinutes))); This is fine if the program is running on Windows, but it crashes on Linux. The error occurs when we're trying to get the UtcOffset. The TBundledTimeZone can't read the FPeriods[I] in the function GetPeriodAndRule. The thing is that FPeriods is a TList that is not typed (with TCompiledPeriod) and Delphi can't use it this way with Linux. We can by the way see a warning when compiling a project that includes TZDB.pas, telling that TList is deprecated. We have solved the problem by modifying the TZDB.pas unit, but it seems weird to have to do this. We are also using the Decomposer.pas unit, but it doesn't have any problem with Linux because it is already working with typed TLists (function Decompose). Do you have any idea about this issue ? You can check the attachment to see our changes. Thank you in advance for your answer, Best regards, Jean FRAUCIEL Développeur Moteur jfrauciel(a)kiamo.fr +33 5 47 48 33 20 <33547483320> | [image: logo web] <http://www.conecteo.fr/> [image: logo linkedin] <https://www.linkedin.com/company/conecteo> <https://twitter.com/Conecteo> <https://www.facebook.com/conecteo> Chers clients et partenaires, rejoignez votre espace communautaire <https://my.kiamo.fr/welcome>

2 1

Palestine 2018 summer time end
by Sharef Mustafa Oct. 17, 2018

Oct. 17, 2018

Hi, As per the Palestinian cabinet decision announced Oct 16th 2018, the summer time for the state of Palestine will end on Sat, Oct 27th 2018 , the clock shall be returned by 60 minutes at 01:00 o'clock (as per the announcement ) Here is a link to the cabinet announcement (in Arabic) : http://palestinecabinet.gov.ps/Website/AR/ViewDetails?ID=42494 Also another link from a local news portal (in Arabic): https://www.maannews.net/Content.aspx?id=964375 Unfortunately I did not find an English source. Please note that this change affects Gaza & Hebron time zones BR Sharef Also

2 1

Wrong spelling of a city in a timezone name
by Igor Oct. 16, 2018

Oct. 16, 2018

Hello. Currently, in your timezone files Ukrainian capital is spelled incorrectly. Kyiv is the correct spelling as decided by UNCSGN (United Nations Conferences on the Standardization of Geographical Names) and UNGEGN (United Nations Group of Experts on Geographical Names)."Kiev" is transliteration from Russian and as Ukraine, which is an independent country, has only one official language, which is Ukrainian, using transliteration from Russian is offending and incorrect. I saw in your files that you understand that Kyiv is correct spelling and you reason that Kiev is more common, alas that argument is wrong. It's only more common because it's been mistakingly used for a long period of time. Ukrainian government is currently running a campaign called Kyiv Not Kiev to raise awareness of international community and it already has results, many companies, like Microsoft, BBC, Google, Facebook and others have already fixed their spelling. I suggest IANA follows this example and fixes this incorrect spelling. Regards, Igor

8 10

Another change on Brazilian DST time
by Raphael Bastos Oct. 16, 2018

Oct. 16, 2018

Yo, Please, abort this change: https://g1.globo.com/politica/noticia/2018/10/15/planalto-informa-que-nao-h… Att, Raphael Bastos aka Tyresix *====================================================* *Wiki Hackstore* - https://wiki.hackstore.com.br <http://wiki.hackstore.com.br/> *Área 31 Hackerspace* - https://www.area31.net.br <http://www.area31.net.br> *====================================================*

1 0

Brazil DST called out
by Rodrigo Freire Oct. 16, 2018

Oct. 16, 2018

Government decided to abandon the announced second DST change. So it will start in November 4. https://g1.globo.com/politica/noticia/2018/10/15/planalto-informa-que-nao-h… - RF Sent from a mobile device

1 0

Ethiopia local time
by admin＠afocha.com Oct. 13, 2018

Oct. 13, 2018

Greetings, Although Ethiopia is officially in East Africa Time (UTC +3:00), the local time used in the country adopts a different system where 6:00 AM is interpreted as 12:00 and socially used as such. People will see a clock with the time at 1:30, and they will say this is 7:30. The local time is used by businesses in the country and by government offices. Everyone generally does this conversion in their heads, so at times, someone who is unfamiliar with this system can end up inadvertently scheduling meetings for the wrong time. This method of time tracking was developed and maintained with the premise of associating the clock's starting point of 12:00 with sunrise, which is roughly taking place around 6:00 AM every day. So East Africa Time - 6:00 is the working time used by the vast majority of Ethiopians. Here's an article discussing this time system: https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-bet… Is it possible to include Ethiopia's local time system into the time zone database? If so, what are the requirements for submitting a new time zone? Thanks for your consideration. Regards, Khalid Duri

17 48

Re: [tz] Europe/Volgograd change from UTC+3 to UTC+4 from 28oct2018
by Paul Eggert Oct. 11, 2018

Oct. 11, 2018

Alexander Fetisov wrote: > Volgograd region in southern Russia (Europe/Volgograd) change timezone from > UTC+3 to UTC+4 from 28oct2018. > > http://sozd.parliament.gov.ru/bill/452878-7 Thanks for the heads-up and the URL. Its supporting info says the transition occurs at 02:00 that day, the usual practice in that region. That web page says "Находится на рассмотрении" which Google Translate renders as "Is pending", and it later says "Срок представления поправок 10.10.2018" which Google Translate renders as "Term for the submission of amendments 10/10/2018", so it sounds like the bill is under consideration but is not yet law and might be amended. Am I correct? If so, we need to know if and when the proposed change becomes definite. If we're pretty sure the law will go in as-is, we might want to update tzdb before October 10 since this is not much notice for downstream users.

3 9

FW: State of Palestine Time zone - need to update
by maysa＠mtit.gov.ps Oct. 10, 2018

Oct. 10, 2018

Dear Sir, I'm contacting you in regard to the time zone data base the field related to the state of Palestine, it's known that Palestine is recognized as a state and it has the Following ISO and Alpha codes, English short name (upper/lower case) Alpha-2 code <https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_e lements> Alpha-3 code <https://en.wikipedia.org/wiki/ISO_3166-1_alpha-3#Officially_assigned_code_e lements> Numeric code <https://en.wikipedia.org/wiki/ISO_3166-1_numeric#Officially_assigned_code_e lements> Link to ISO 3166-2 <https://en.wikipedia.org/wiki/ISO_3166-2> subdivision codes <https://en.wikipedia.org/wiki/State_of_Palestine> State of Palestine <https://en.wikipedia.org/wiki/State_of_Palestine> Palestine, State of <https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#PS> PS PSE 275 <https://en.wikipedia.org/wiki/ISO_3166-2:PS> ISO 3166-2:PS PS-JEM Jerusalem <https://en.wikipedia.org/wiki/Jerusalem_Governorate> Al Quds 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 +3:00 Instead of the following data : PS Palestinian Territory <https://timezonedb.com/time-zones/Asia/Gaza> Asia/Gaza UTC +03:00 PS Palestinian Territory <https://timezonedb.com/time-zones/Asia/Hebron> Asia/Hebron UTC +03:00 Kindly advise if any supporting documents, information or procedures are needed from our side. BR Maysa Monayer Telecom Administration - Deputy General Director Ministry of Telecom and IT (State of Palestine) Mobile: +970-562500044

2 3

Re: [tz] tz Digest, Vol 85, Issue 19 Summer time of Brazil
by Daniel Soares de Oliveira Oct. 9, 2018

Oct. 9, 2018

1 0

Apple Watch Series 4 reboot loop on day of Australian spring-forward transition
by Paul Eggert Oct. 8, 2018

Oct. 8, 2018

Benjamin Mayo reports in 9to5Mac that last weekend's spring-forward clock transition in Australia caused the Apple Watch Series 4 to go into a reboot loop when displaying the day's timeline in the Activity complication on the Infograph Modular face. The watch reboots, attempts to display the timeline again, and reboots again, over and over. Apparently the application has trouble with a 23-hour day. Apple solved the problem by - doing nothing yet. After 23 hours of rebooting, an Australian user's watch (if it still has power left) reboots, sees a new day with 24 hours, and displays a nice 24-hour timeline again. Mayo writes, "Obviously, Apple will need to release a bug-fix software update to stop this problem from happening again." There's no word yet on what the current Apple software will do when faced with a 25-hour day. Mayo B. Some Apple Watch Series 4 models repeatedly crashing and rebooting due to daylight saving time bug. 9to5Mac. 2018-10-07 04:31 -07. https://9to5mac.com/2018/10/07/apple-watch-series-4-crash-loop-bug/

1 0

Re: [tz] [PROPOSED] Improve leapseconds support
by Hal Murray Oct. 7, 2018

Oct. 7, 2018

eggert(a)cs.ucla.edu said: > * NEWS, leapseconds.awk: Add support for leap seconds at the ends of months > other than June and December. A leap second other than June or December is probably an error in the input data. I would leave the check and add a big comment. Maybe write the code so that it is a simple edit to disable the check. I think there is provision for an intermediate stage between Jun/Dec and every month. Apr/Jun/Sep/Dec. -- These are my opinions. I hate spam.

5 7

[PROPOSED] Improve leapseconds support
by Paul Eggert Oct. 6, 2018

Oct. 6, 2018

(Inspired by a suggestion from Chris Woodbury.) * NEWS, leapseconds.awk: Add support for leap seconds at the ends of months other than June and December. --- NEWS | 5 +++-- leapseconds.awk | 34 +++++++++++++++++++++++++--------- 2 files changed, 28 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index e9f5366..9780cc8 100644 --- a/NEWS +++ b/NEWS @@ -86,8 +86,9 @@ Unreleased, experimental changes transition (or for all time stamps if there are no transitions), just as DST strings specifying DST have always done. - leapseconds.awk now outputs "#updated" and "#expires" comments. - (Inspired by a suggestion from Chris Woodbury.) + leapseconds.awk now outputs "#updated" and "#expires" comments, + and supports leap seconds at the ends of months other than June + and December. (Inspired by suggestions from Chris Woodbury.) Changes to documentation diff --git a/leapseconds.awk b/leapseconds.awk index 6b069b3..ea0567c 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -35,9 +35,25 @@ BEGIN { 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 "# If the leap second is Stationary (S) the given time is UTC." - print "" - print "# Leap YEAR MONTH DAY HH:MM:SS CORR R/S" + + monthabbr[ 1] = "Jan" + monthabbr[ 2] = "Feb" + monthabbr[ 3] = "Mar" + monthabbr[ 4] = "Apr" + monthabbr[ 5] = "May" + monthabbr[ 6] = "Jun" + monthabbr[ 7] = "Jul" + monthabbr[ 8] = "Aug" + monthabbr[ 9] = "Sep" + monthabbr[10] = "Oct" + monthabbr[11] = "Nov" + monthabbr[12] = "Dec" + for (i in monthabbr) { + monthnum[monthabbr[i]] = i + monthlen[i] = 31 + } + monthlen[2] = 28 + monthlen[4] = monthlen[6] = monthlen[9] = monthlen[11] = 30 } /^#\tUpdated through/ || /^#\tFile expires on:/ { @@ -62,14 +78,14 @@ BEGIN { } else { sign = "23:59:59\t-" } - if (month == "Jan") { + m = monthnum[month] - 1 + if (m == 0) { year--; - month = "Dec"; - day = 31 - } else if (month == "Jul") { - month = "Jun"; - day = 30 + m = 12 } + month = monthabbr[m] + day = monthlen[m] + day += m == 2 && year % 4 == 0 && (year % 100 != 0 || year % 400 == 0) printf "Leap\t%s\t%s\t%s\t%s\tS\n", year, month, day, sign } old_TAI_minus_UTC = TAI_minus_UTC -- 2.17.1

1 0

Rename Ukrainian cities to their official transliterated names
by Volodymyr Kostyrko Oct. 5, 2018

Oct. 5, 2018

Hello. This is my first attempt on patching tz database. Hope I did everything right. Included patch renames Kiev to Kyiv, Uzhgorod to Uzhhorod and Zaporozhye to Zaporizhzhia according to official transliteration rules that came in effect 2014. According to Google search most sites are already using Uzhhorod and Zaporizhzhia to name cities, while with Kyiv it's a little bit complicated, as it's the capital so it's name was appearing on a huge list of sites throughout years... I'm just trying to bring a little bit of lawful sanity… Thanks in advance. -- Sphinx of black quartz judge my vow.

16 31

[PROPOSED] Improve leapseconds.awk commentary
by Paul Eggert Oct. 5, 2018

Oct. 5, 2018

(Inspired by a suggestion by Chris Woodbury.) * NEWS: Mention this. * leapseconds.awk: Improve commentary in output file. Output "#updated" and "#expires" comments that reproduce the updated and expiry timestamps in the input file. --- NEWS | 3 +++ leapseconds.awk | 36 +++++++++++++++++++++++++----------- 2 files changed, 28 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index 395d9a8..e9f5366 100644 --- a/NEWS +++ b/NEWS @@ -86,6 +86,9 @@ Unreleased, experimental changes transition (or for all time stamps if there are no transitions), just as DST strings specifying DST have always done. + leapseconds.awk now outputs "#updated" and "#expires" comments. + (Inspired by a suggestion from Chris Woodbury.) + Changes to documentation New restrictions: A Rule name must start with a character that diff --git a/leapseconds.awk b/leapseconds.awk index 66eb64d..6b069b3 100644 --- a/leapseconds.awk +++ b/leapseconds.awk @@ -8,21 +8,25 @@ BEGIN { print "# This file is in the public domain." print "" print "# This file is generated automatically from the data in the public-domain" - print "# leap-seconds.list file, which is copied from:" - print "# ftp://ftp.nist.gov/pub/time/leap-seconds.list" + print "# leap-seconds.list file, which can be copied from" + print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>" + print "# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>" + print "# or <ftp://tycho.usno.navy.mil/pub/ntp/leap-seconds.list>." print "# For more about leap-seconds.list, please see" print "# The NTP Timescale and Leap Seconds" - print "# https://www.eecis.udel.edu/~mills/leap.html" + print "# <https://www.eecis.udel.edu/~mills/leap.html>." print "" 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); see" - print "# Levine J. Coordinated Universal Time and the leap second." + print "# (which measures the true angular orientation of the earth in space)" + print "# and publishes leap second data in a copyrighted file" + print "# <https://hpiers.obspm.fr/iers/bul/bulc/Leap_Second.dat>." + print "# See: Levine J. Coordinated Universal Time and the leap second." print "# URSI Radio Sci Bull. 2016;89(4):30-6. doi:10.23919/URSIRSB.2016.7909995" - print "# http://ieeexplore.ieee.org/document/7909995/" + print "# <https://ieeexplore.ieee.org/document/7909995>." print "# There were no leap seconds before 1972, because the official mechanism" print "# accounting for the discrepancy between atomic time and the earth's rotation" - print "# did not exist until the early 1970s." + print "# did not exist." print "" print "# The correction (+ or -) is made at the given time, so lines" print "# will typically look like:" @@ -30,18 +34,19 @@ BEGIN { print "# or" print "# Leap YEAR MON DAY 23:59:59 - R/S" print "" - print "# If the leapsecond is Rolling (R) the given time is local time." - print "# If the leapsecond is Stationary (S) the given time is UTC." + print "# If the leap second is Rolling (R) the given time is local time (unused here)." + print "# If the leap second is Stationary (S) the given time is UTC." print "" print "# Leap YEAR MONTH DAY HH:MM:SS CORR R/S" } -/^ *$/ { next } - /^#\tUpdated through/ || /^#\tFile expires on:/ { last_lines = last_lines $0 "\n" } +/^#[$][ \t]/ { updated = $2 } +/^#[@][ \t]/ { expires = $2 } + /^#/ { next } { @@ -71,5 +76,14 @@ BEGIN { } END { + # The difference between the NTP and POSIX epochs is 70 years + # (including 17 leap days), each 24 hours of 60 minutes of 60 + # seconds each. + epoch_minus_NTP = ((1970 - 1900) * 365 + 17) * 24 * 60 * 60 + + print "" + print "# POSIX timestamps for the data in this file:" + printf "#updated %s\n", updated - epoch_minus_NTP + printf "#expires %s\n", expires - epoch_minus_NTP printf "\n%s", last_lines } -- 2.17.1

1 0

Re: [tz] [PROPOSED] Allow some IPA symbols in commentary
by Paul Eggert Oct. 4, 2018

Oct. 4, 2018

On 10/4/18 9:23 AM, Paul.Koning(a)dell.com wrote: > I wonder if the Unicode standard says so, or if this is a Linux bug. I looked into it, and it's arguably a bug in the glibc regular expression matcher: it does not recognize u̯ as alphabetic because it's composed of U+0075 U+032F and the latter is not alphabetic. Let's add a comment to that effect and remove ɪ from the macro since it works OK. Proposed further patch attached.

1 0

[PROPOSED] Allow some IPA symbols in commentary
by Paul Eggert Oct. 4, 2018

Oct. 4, 2018

This for the [ˈkɪjiu̯] recently added to Kiev comments. * Makefile (UNUSUAL_OK_LATIN_1, UNUSUAL_OK_IPA): New macros. (UNUSUAL_OK_CHARSET): Use them. (check_character_set): Broaden list of exempt lines. --- Makefile | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 3d06d93..39da17e 100644 --- a/Makefile +++ b/Makefile @@ -418,10 +418,14 @@ SAFE_CHARSET3= 'abcdefghijklmnopqrstuvwxyz{|}~' SAFE_CHARSET= $(SAFE_CHARSET1)$(SAFE_CHARSET2)$(SAFE_CHARSET3) SAFE_CHAR= '[]'$(SAFE_CHARSET)'-]' +# These characters are Latin-1, and so are likely to be displayable +# even in editors with limited character sets. +UNUSUAL_OK_LATIN_1 = «°±»½¾× +# IPA symbols are OK in commentary despite being non-alphabetic. +UNUSUAL_OK_IPA = ɪu̯ # Non-ASCII non-letters that OK_CHAR allows, as these characters are -# useful in commentary. These all came from Latin-1, and so are likely -# to be displayable even in editors with limited character sets. -UNUSUAL_OK_CHARSET= «°±»½¾× +# useful in commentary. +UNUSUAL_OK_CHARSET= $(UNUSUAL_OK_LATIN_1)$(UNUSUAL_OK_IPA) # OK_CHAR matches any character allowed in the distributed files. # This is the same as SAFE_CHAR, except that UNUSUAL_OK_CHARSET and @@ -735,7 +739,7 @@ check_character_set: $(ENCHILADA) $(MISC) $(SOURCES) $(WEB_PAGES) \ CONTRIBUTING LICENSE README \ version tzdata.zi && \ - ! grep -Env $(SAFE_LINE)'|^UNUSUAL_OK_CHARSET='$(OK_CHAR)'*$$' \ + ! grep -Env $(SAFE_LINE)'|^UNUSUAL_OK_'$(OK_CHAR)'*$$' \ Makefile && \ ! grep -Env $(SAFE_SHARP_LINE) $(TDATA_TO_CHECK) backzone \ leapseconds yearistype.sh zone.tab && \ -- 2.17.1

1 0

[PATCH] Fix Asia/Shanghai 1940/9 DST transitions
by Paul Eggert Oct. 3, 2018

Oct. 3, 2018

* NEWS: Mention this. * asia (Shang): Switch to data from 2014 Li Yu paper. --- NEWS | 3 +++ asia | 34 +++++++++++++++++++++++++++------- 2 files changed, 30 insertions(+), 7 deletions(-) diff --git a/NEWS b/NEWS index a24d4b3..e217a50 100644 --- a/NEWS +++ b/NEWS @@ -42,6 +42,9 @@ Unreleased, experimental changes zic turns this into 01:00 on the day after September's second Saturday, which is the best that POSIX or C platforms can do. + Incorporate 1940-1949 Asia/Shanghai DST transitions from a 2014 + paper by Li Yu, replacing more-questionable data from Shanks. + Changes to time zone abbreviations Use "PST" and "PDT" for Philippine time. (Thanks to Paul Goyette.) diff --git a/asia b/asia index 365593a..a7b5c75 100644 --- a/asia +++ b/asia @@ -286,6 +286,29 @@ Zone Asia/Yangon 6:24:47 - LMT 1880 # or Rangoon # China +# From Paul Eggert (2018-10-02): +# The following comes from Table 1 of: +# Li Yu. Research on the daylight saving movement in 1940s Shanghai. +# Nanjing Journal of Social Sciences. 2014;(2):144-50. +# http://oversea.cnki.net/kns55/detail.aspx?dbname=CJFD2014&filename=NJSH2014… +# The table lists dates only; I am guessing 00:00 and 24:00 transition times. +# Also, the table lists the planned end of DST in 1949, but the corresponding +# zone line cuts this off on May 27, when the Communists took power. +# +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Shang 1940 only - Jun 1 0:00 1:00 D +Rule Shang 1940 only - Oct 12 24:00 0 S +Rule Shang 1941 only - Mar 15 0:00 1:00 D +Rule Shang 1941 only - Nov 1 24:00 0 S +Rule Shang 1942 only - Jan 31 0:00 1:00 D +Rule Shang 1945 only - Sep 1 24:00 0 S +Rule Shang 1946 only - May 15 0:00 1:00 D +Rule Shang 1946 only - Sep 30 24:00 0 S +Rule Shang 1947 only - Apr 15 0:00 1:00 D +Rule Shang 1947 only - Oct 31 24:00 0 S +Rule Shang 1948 1949 - May 1 0:00 1:00 D +Rule Shang 1948 1949 - Sep 30 24:00 0 S + # From Guy Harris: # People's Republic of China. Yes, they really have only one time zone. @@ -336,12 +359,9 @@ Zone Asia/Yangon 6:24:47 - LMT 1880 # or Rangoon # http://data.people.com.cn/pic/101p/1988/04/1988041201.jpg # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Shang 1940 only - Jun 3 0:00 1:00 D -Rule Shang 1940 1941 - Oct 1 0:00 0 S -Rule Shang 1941 only - Mar 16 0:00 1:00 D -Rule PRC 1986 only - May 4 2:00 1:00 D -Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S -Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D +Rule PRC 1986 only - May 4 2:00 1:00 D +Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S +Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # From Anthony Fok (2001-12-20): # BTW, I did some research on-line and found some info regarding these five @@ -543,7 +563,7 @@ Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] # Beijing time, used throughout China; represented by Shanghai. Zone Asia/Shanghai 8:05:43 - LMT 1901 - 8:00 Shang C%sT 1949 + 8:00 Shang C%sT 1949 May 27 8:00 PRC C%sT # Xinjiang time, used by many in western China; represented by Ürümqi / Ürümchi # / Wulumuqi. (Please use Asia/Shanghai if you prefer Beijing time.) -- 2.17.1

2 3

Re： Inquiry to NICT about Japanese Summer time in 1948-1952.
by aya sekido Oct. 2, 2018

Oct. 2, 2018

Dear Nick, Thank you for your interest. We will respond to your inquiry. It is said that corresponding summer time was performed by instruction of the GHQ: General Headquarters (office of the Supreme Commander of the Allied Powers). We do not have detailed data about summer time then. According to the law of those days, the last day of summer time was made into 25 hours. What came after 12:59 p.m. of the last day was 00:00 a.m. of the next day. If you have any further questions, please let us know. Sincerely, Japan Standard Time Group Space-Time standards Laboratory Applied Electromagnetic Research Institute National Institute of Information and Communications Technology From: Phake Nick <c933103(a)gmail.com> Sent: Sunday, September 09, 2018 12:53 AM To: horonet(a)ml.nict.go.jp Cc: tz(a)iana.org Subject: [horonet 13333] Inquiry to NICT about Japanese Summer time in 1948-1952. To receivers of this email: Recently, I have read an article, which mentioned the history of Japanese Summer Time Implementation in the past at www.bengo4.com/internet/n_8461/ <http://www.bengo4.com/internet/n_8461/> . In the article, it was mentioned that the summer time (DST) end at 25 hours at the last day of the implementation period. Does that mean the clock would go up to the 25th hours back then and reach 24:59 before it continues toward 00:00 on the next day in standard time? If not then how did the clock switched from Summer Time back to Standard Time back then? Please use the "reply to all" function when replying to the message so that other receivers of the message can also hear answer on the matter. Sincerely, P.N.

6 13

Turkey decided to stay in +3
by Kıvanç Yazan Oct. 2, 2018

Oct. 2, 2018

Hi, Recently there was some confusion on whether Turkey was going back to +2. A decision is published today. It says all-year-long summer time (ie. UTC+3) is here to stay. No end date is specified. http://www.resmigazete.gov.tr/eskiler/2018/10/20181002-7.pdf Thanks, Kivanc Yazan

1 0

stale leap seconds file at IETF
by Hal Murray Sept. 29, 2018

Sept. 29, 2018

From: https://www.ietf.org/timezones/data/leap-seconds.list # Updated through IERS Bulletin C55 # File expires on: 28 December 2018 >From ftp://ftp.nist.gov/pub/time/leap-seconds.list # Updated through IERS Bulletin C56 # File expires on: 28 June 2019 What's the procedure for getting the IETF copy updated? Is the TZ community maintaining that file or is somebody at the IETF responsible for tracking NIST? -- These are my opinions. I hate spam.

2 1

When will physics make 32-bit signed leap-second counts obsolete?
by Paul Eggert Sept. 27, 2018

Sept. 27, 2018

A while ago I vaguely remember a prediction on this list of when the TZif file format will become obsolete because we have accumulated 2**31 total leap seconds if we continue to just add leap seconds as needed to keep UTC roughly in sync with TAI. To some extent this is just a playful prediction, as the format will undoubtedly become obsolete for other reasons long before then, but it's still fun to predict. Unfortunately I don't remember the details, and a quick Google search didn't find it. Does anyone else remember this? If not, I'll have to recalculate. The topic has just come up again on the tzdist-bis mailing list, which is why I'm thinking about it again. See <https://mailarchive.ietf.org/arch/msg/tzdist-bis/Q7OVmd60wydqcJahS3QRNHwtXHM>.

3 2

another solar-based time proposal (not)
by scs＠eskimo.com Sept. 27, 2018

Sept. 27, 2018

Many have probably seen this, but I'm surprised no one has mentioned Monday's xkcd: https://xkcd.com/2050/

3 2

Samoa DST
by Vishal Vineet Kumar Sept. 25, 2018

Sept. 25, 2018

Hi Paul/Team, Kindly advice if there is a java patch available for upcoming DST in Samoa on 30th September. https://www.mcil.gov.ws/wp-content/uploads/2018/09/public-notice-_Daylight-… Thanks, Vishal. ________________________________ Notice of Confidentiality: The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system.

3 2

Timezone change for Turkey as of October 28, 2018
by Omer Sever Sept. 22, 2018

Sept. 22, 2018

Hello Paul, Turkey will set the clocks one hour back effective from October 28, 2018 at 04:00 AM I have not seen this change in the latest version of the timezone database and I wanted to inform about this change. Please find the government decision about the change: http://www.resmigazete.gov.tr/eskiler/2017/10/20171028-5.pdf Regards, Omer Sever

5 8

Europe/Volgograd change from UTC+3 to UTC+4 from 28oct2018
by Alexander Fetisov Sept. 20, 2018

Sept. 20, 2018

Hi! Volgograd region in southern Russia (Europe/Volgograd) change timezone from UTC+3 to UTC+4 from 28oct2018. http://sozd.parliament.gov.ru/bill/452878-7 -- WBR, Aleksander

1 0

[DRAFT] EU-related changes likely – here’s a heads-up
by Paul Eggert Sept. 19, 2018

Sept. 19, 2018

This set of changes is so experimental that I have not installed it into the development repository. I am circulating it to give people a heads-up for the sort of tzdb changes that are likely to occur if the recent European Commission proposal becomes official. Comments are welcome; please send them to tz(a)iana.org. * NEWS: Mention this. * africa (Africa/Cairo, Africa/Tripoli, Africa/El_Aaiun) (Africa/Tunis): * asia (Asia/Amman, Asia/Beirut, Asia/Gaza, Asia/Hebron) (Asia/Damascus): * europe (Europe/Kaliningrad): Switch from "WET"/"CET"/"EET" to numeric offsets around 2019-03-31. This sort of thing is also done in the other entries noted below, which have other stuff going on too. * africa (Africa/Casablanca): * asia (Asia/Nicosia, Asia/Famagusta): * backzone (Europe/Ljubljana, Europe/Sarajevo, Europe/Skopje) (Europe/Vaduz, Europe/Zagreb): * europe (Europe/Tirane, Europe/Andorra, Europe/Vienna) (Europe/Brussels, Europe/Sofia, Europe/Prague, Europe/Copenhagen) (Atlantic/Faroe, America/Scoresbysund, America/Godthab) (Europe/Tallinn, Europe/Helsinki, Europe/Paris, Europe/Berlin) (Europe/Athens, Europe/Budapest, Europe/Rome, Europe/Riga) (Europe/Vilnius, Europe/Luxembourg, Europe/Malta, Europe/Monaco) (Europe/Amsterdam, Europe/Oslo, Europe/Lisbon, Atlantic/Azores) (Atlantic/Madeira, Europe/Bucharest, Europe/Belgrade, Europe/Madrid) (Africa/Ceuta, Atlantic/Canary, Europe/Stockholm, Europe/Zurich) (Europe/Kiev, Europe/Uzhgorod, Europe/Zaporozhye): Assume these locations will not exercise the draft directive’s option, and so will move their time zone one hour east. * asia (EUAsia, E-EurAsia): Stay in sync with EU and E-Eur rules in ‘europe’. * backzone (Europe/Belfast, Europe/Guernsey, Europe/Isle_of_Man): * europe (Europe/London, Europe/Gibraltar): Assume the UK, Crown dependencies and Gibraltar will roll along as before. * europe (UK): New rule. (Eire, EU, W-Eur, C-Eur): Stop DST in 2019. (Europe/Dublin): Switch to plain IST (a standard time) in 2019. (America/Danmarkshavn): Use numeric abbreviation for consistency with other locations in Greenland. * zic.8: Adjust example to match new data. * ziguard.awk (Zone_Dublin_post_1968): No longer a need for special treatment for last line of Dublin zone. --- NEWS | 55 +++++++++++++++++++ africa | 36 ++++++------ asia | 31 +++++++---- backzone | 27 ++++++--- europe | 154 ++++++++++++++++++++++++++++++++++------------------ zic.8 | 19 +++++-- ziguard.awk | 2 +- 7 files changed, 223 insertions(+), 101 deletions(-) diff --git a/NEWS b/NEWS index 99040dc..ba0772b 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,61 @@ Unreleased, experimental changes Changes to future timestamps + The European Commission has proposed to end DST in March 2019. See: + https://ec.europa.eu/commission/priorities/state-union-speeches/state-union… + Under this proposal, EU member states will advance their clocks by + an hour at 2019-03-31 01:00 UTC as usual, and will have the option + to move their clocks back an hour at 2019-10-27 01:00 UTC; member + states must announce by 2019-03-31 whether they are taking the + option. After 2019-10-27 no seasonal changes will be permitted; + member states can make one-off changes but must give six months' + notice. (Thanks to Even Scharning for the URL and for Clive + D.W. Feather for summarizing the proposal.) For now, make the + following guesses about how this proposal will play out (and + please remember that these are just guesses, some of which will + surely be wrong): + + * The European Parliament and the Council will approve the proposal. + + * No member state will exercise the option of moving clocks back + on 2019-10-27. + + * Every member state but Ireland will therefore make its last + transition by advancing standard time by an hour (i.e., moving + east by one time zone) on 2019-03-31. + + * Ireland's usual transition from winter to standard time on + 2019-03-31 will be its last transition. + + * The following nearby countries that use EU or near-EU rules + will also stop using DST and move east one time zone: + Albania, Andorra, Bosnia & Herzegovina, Bulgaria, Croatia, the + Czech Republic, the Faroes, most of Greenland, Liechtenstein, + (Northern) Macedonia, Moldova, Monaco, Montenegro, Morocco, + Norway, Romania, San Marino, Serbia, Switzerland, Ukraine, + Vatican City, and Western Sahara. + + * Brexit will occur at 2019-03-29 23:00 UTC, and DST will continue + to be observed in the UK, the Crown dependencies and Gibraltar. + + * Akrotiri and Dhekelia (which do not have separate tzdb entries) + will continue to track Nicosia. + + * Use numeric offsets for abbreviations in the new zones, as it is + too early to know what English-language abbreviations (if any) + will be used. For example, if Spain stays at +02 all year, it's + not clear whether people will call its time "Eastern European + Time" (a geographic misnomer) or some other name. Although + eventually we should be consistent about time zone abbreviations + used for past and modern timestamps, for now let's leave the + abbreviations alone for timestamps before 2019-03-31. + + * However, the backward-compatibility zones WET, CET, MET, and EET + will keep their UTC offsets and traditional abbreviations, and + will observe DST as before in 2019 and will stay on standard + time thereafter, so that they can remain fallbacks for + traditionalists. + Fiji ends DST 2019-01-13 instead of the 2019-01-20 previously predicted. (Thanks to Raymond Kumar.) Adjust future predictions accordingly. diff --git a/africa b/africa index 555052b..9013b30 100644 --- a/africa +++ b/africa @@ -99,7 +99,8 @@ Zone Africa/Algiers 0:12:12 - LMT 1891 Mar 15 0:01 0:00 Algeria WE%sT 1977 Oct 21 1:00 Algeria CE%sT 1979 Oct 26 0:00 Algeria WE%sT 1981 May - 1:00 - CET + 1:00 - CET 2019 Mar 31 1:00u + 1:00 - +01 # Angola # Benin @@ -358,7 +359,8 @@ Rule Egypt 2014 only - Sep lastThu 24:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Cairo 2:05:09 - LMT 1900 Oct - 2:00 Egypt EE%sT + 2:00 Egypt EE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Equatorial Guinea # See Africa/Lagos. @@ -525,7 +527,8 @@ Zone Africa/Tripoli 0:52:44 - LMT 1920 1:00 Libya CE%sT 1997 Oct 4 2:00 - EET 2012 Nov 10 2:00 1:00 Libya CE%sT 2013 Oct 25 2:00 - 2:00 - EET + 2:00 - EET 2019 Mar 31 1:00u + 2:00 - +02 # Madagascar # See Africa/Nairobi. @@ -869,6 +872,9 @@ Zone Indian/Mauritius 3:50:00 - LMT 1907 # Port Louis # (car (cdr (cdr a))) (calendar-month-name (car a) t) (car (cdr a)) # (car (cdr (cdr b))) (calendar-month-name (car b) t) (car (cdr b))))) # (setq islamic-year (+ 1 islamic-year)))) +# From Paul Eggert (2019-09-15): +# Guess Morocco will stop observing DST in 2019, along with the EU, +# so omit the above program's output after 2018. # RULE NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -901,7 +907,7 @@ Rule Morocco 2012 only - Aug 20 2:00 1:00 S Rule Morocco 2012 only - Sep 30 3:00 0 - Rule Morocco 2013 only - Jul 7 3:00 0 - Rule Morocco 2013 only - Aug 10 2:00 1:00 S -Rule Morocco 2013 max - Oct lastSun 3:00 0 - +Rule Morocco 2013 2018 - Oct lastSun 3:00 0 - Rule Morocco 2014 2021 - Mar lastSun 2:00 1:00 S Rule Morocco 2014 only - Jun 28 3:00 0 - Rule Morocco 2014 only - Aug 2 2:00 1:00 S @@ -913,25 +919,13 @@ Rule Morocco 2017 only - May 21 3:00 0 - Rule Morocco 2017 only - Jul 2 2:00 1:00 S Rule Morocco 2018 only - May 13 3:00 0 - Rule Morocco 2018 only - Jun 17 2:00 1:00 S -Rule Morocco 2019 only - May 5 3:00 0 - -Rule Morocco 2019 only - Jun 9 2:00 1:00 S -Rule Morocco 2020 only - Apr 19 3:00 0 - -Rule Morocco 2020 only - May 24 2:00 1:00 S -Rule Morocco 2021 only - Apr 11 3:00 0 - -Rule Morocco 2021 only - May 16 2:00 1:00 S -Rule Morocco 2022 only - May 8 2:00 1:00 S -Rule Morocco 2023 only - Apr 23 2:00 1:00 S -Rule Morocco 2024 only - Apr 14 2:00 1:00 S -Rule Morocco 2025 only - Apr 6 2:00 1:00 S -Rule Morocco 2026 max - Mar lastSun 2:00 1:00 S -Rule Morocco 2036 only - Oct 19 3:00 0 - -Rule Morocco 2037 only - Oct 4 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 0:00 Morocco WE%sT 1984 Mar 16 1:00 - CET 1986 - 0:00 Morocco WE%sT + 0:00 Morocco WE%sT 2019 Mar 31 1:00u + 1:00 - +01 # Western Sahara # @@ -946,7 +940,8 @@ Zone Africa/Casablanca -0:30:20 - LMT 1913 Oct 26 Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún -1:00 - -01 1976 Apr 14 - 0:00 Morocco WE%sT + 0:00 Morocco WE%sT 2019 Mar 31 1:00u + 0:00 Morocco +00/+01 # Mozambique # @@ -1286,7 +1281,8 @@ Rule Tunisia 2006 2008 - Oct lastSun 2:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Africa/Tunis 0:40:44 - LMT 1881 May 12 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time - 1:00 Tunisia CE%sT + 1:00 Tunisia CE%sT 2019 Mar 31 1:00u + 1:00 - +01 # Uganda # See Africa/Nairobi. diff --git a/asia b/asia index 5e27d85..5a97b9e 100644 --- a/asia +++ b/asia @@ -71,12 +71,12 @@ # These rules are stolen from the 'europe' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule EUAsia 1981 max - Mar lastSun 1:00u 1:00 S +Rule EUAsia 1981 2019 - Mar lastSun 1:00u 1:00 S Rule EUAsia 1979 1995 - Sep lastSun 1:00u 0 - -Rule EUAsia 1996 max - Oct lastSun 1:00u 0 - -Rule E-EurAsia 1981 max - Mar lastSun 0:00 1:00 - +Rule EUAsia 1996 2019 - Oct lastSun 1:00u 0 - +Rule E-EurAsia 1981 2019 - Mar lastSun 0:00 1:00 - Rule E-EurAsia 1979 1995 - Sep lastSun 0:00 0 - -Rule E-EurAsia 1996 max - Oct lastSun 0:00 0 - +Rule E-EurAsia 1996 2019 - Oct lastSun 0:00 0 - Rule RussiaAsia 1981 1984 - Apr 1 0:00 1:00 - Rule RussiaAsia 1981 1983 - Oct 1 0:00 0 - Rule RussiaAsia 1984 1995 - Sep lastSun 2:00s 0 - @@ -944,12 +944,14 @@ Rule Cyprus 1981 1998 - Mar lastSun 0:00 1:00 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Nicosia 2:13:28 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep - 2:00 EUAsia EE%sT + 2:00 EUAsia EE%sT 2019 Mar 31 1:00u + 3:00 - +03 Zone Asia/Famagusta 2:15:48 - LMT 1921 Nov 14 2:00 Cyprus EE%sT 1998 Sep 2:00 EUAsia EE%sT 2016 Sep 8 - 3:00 - +03 2017 Oct 29 1:00u - 2:00 EUAsia EE%sT + 3:00 - +03 2017 Oct 29 1:00u + 2:00 EUAsia EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Classically, Cyprus belongs to Asia; e.g. see Herodotus, Histories, I.72. # However, for various reasons many users expect to find it under Europe. @@ -1750,7 +1752,8 @@ Rule Jordan 2014 max - Mar lastThu 24:00 1:00 S Rule Jordan 2014 max - Oct lastFri 0:00s 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Amman 2:23:44 - LMT 1931 - 2:00 Jordan EE%sT + 2:00 Jordan EE%sT 2019 Mar 28 24:00 + 2:00 Jordan +02/+03 # Kazakhstan @@ -2190,7 +2193,8 @@ Rule Lebanon 1993 1998 - Sep lastSun 0:00 0 - Rule Lebanon 1999 max - Oct lastSun 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Beirut 2:22:00 - LMT 1880 - 2:00 Lebanon EE%sT + 2:00 Lebanon EE%sT 2019 Mar 31 0:00 + 2:00 Lebanon +02/+03 # Malaysia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -2866,14 +2870,16 @@ Zone Asia/Gaza 2:17:52 - LMT 1900 Oct 2:00 - EET 2010 Mar 27 0:01 2:00 Palestine EE%sT 2011 Aug 1 2:00 - EET 2012 - 2:00 Palestine EE%sT + 2:00 Palestine EE%sT 2019 Mar 23 1:00 + 2:00 Palestine +02/+03 Zone Asia/Hebron 2:20:23 - LMT 1900 Oct 2:00 Zion EET/EEST 1948 May 15 2:00 EgyptAsia EE%sT 1967 Jun 5 2:00 Zion I%sT 1996 2:00 Jordan EE%sT 1999 - 2:00 Palestine EE%sT + 2:00 Palestine EE%sT 2019 Mar 23 1:00 + 2:00 Palestine +02/+03 # Paracel Is # no information @@ -3224,7 +3230,8 @@ Rule Syria 2009 max - Oct lastFri 0:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Damascus 2:25:12 - LMT 1920 # Dimashq - 2:00 Syria EE%sT + 2:00 Syria EE%sT 2019 Mar 29 0:00 + 2:00 Syria +02/+03 # Tajikistan # From Shanks & Pottenger. diff --git a/backzone b/backzone index 97792b1..349aaae 100644 --- a/backzone +++ b/backzone @@ -560,7 +560,8 @@ Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 - 0:00 EU GMT/BST + 0:00 EU GMT/BST 2019 Mar 29 23:00u # Brexit + 0:00 UK GMT/BST # Guernsey # Data from Joseph S. Myers @@ -573,7 +574,8 @@ Zone Europe/Guernsey -0:10:09 - LMT 1913 Jun 18 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 - 0:00 EU GMT/BST + 0:00 EU GMT/BST 2019 Mar 29 23:00u # Brexit + 0:00 UK GMT/BST # Isle of Man # @@ -594,7 +596,8 @@ Zone Europe/Isle_of_Man -0:17:55 - LMT 1883 Mar 30 0:00s 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 - 0:00 EU GMT/BST + 0:00 EU GMT/BST 2019 Mar 29 23:00u # Brexit + 0:00 UK GMT/BST # Jersey # Data from Joseph S. Myers @@ -607,7 +610,8 @@ Zone Europe/Jersey -0:08:26 - LMT 1898 Jun 11 16:00u 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 - 0:00 EU GMT/BST + 0:00 EU GMT/BST 2019 Mar 29 23:00u # Brexit + 0:00 UK GMT/BST # Slovenia Zone Europe/Ljubljana 0:58:04 - LMT 1884 @@ -615,7 +619,8 @@ Zone Europe/Ljubljana 0:58:04 - LMT 1884 1:00 C-Eur CE%sT 1945 May 8 2:00s 1:00 1:00 CEST 1945 Sep 16 2:00s 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Bosnia and Herzegovina Zone Europe/Sarajevo 1:13:40 - LMT 1884 @@ -623,7 +628,8 @@ Zone Europe/Sarajevo 1:13:40 - LMT 1884 1:00 C-Eur CE%sT 1945 May 8 2:00s 1:00 1:00 CEST 1945 Sep 16 2:00s 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Macedonia Zone Europe/Skopje 1:25:44 - LMT 1884 @@ -631,7 +637,8 @@ Zone Europe/Skopje 1:25:44 - LMT 1884 1:00 C-Eur CE%sT 1945 May 8 2:00s 1:00 1:00 CEST 1945 Sep 16 2:00s 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Moldova / Transnistria Zone Europe/Tiraspol 1:58:32 - LMT 1880 @@ -647,7 +654,8 @@ Zone Europe/Tiraspol 1:58:32 - LMT 1880 # Liechtenstein Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun 1:00 - CET 1981 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Croatia Zone Europe/Zagreb 1:03:52 - LMT 1884 @@ -655,7 +663,8 @@ Zone Europe/Zagreb 1:03:52 - LMT 1884 1:00 C-Eur CE%sT 1945 May 8 2:00s 1:00 1:00 CEST 1945 Sep 16 2:00s 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Madagascar Zone Indian/Antananarivo 3:10:04 - LMT 1911 Jul diff --git a/europe b/europe index e5017c2..1d8f201 100644 --- a/europe +++ b/europe @@ -500,12 +500,16 @@ Rule GB-Eire 1990 1995 - Oct Sun>=22 1:00u 0 GMT # # Use Europe/London for Jersey, Guernsey, and the Isle of Man. +Rule UK 2019 max - Mar lastSun 1:00u 1:00 - +Rule UK 2019 max - Oct lastSun 1:00u 0 - + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s 0:00 GB-Eire %s 1968 Oct 27 1:00 - BST 1971 Oct 31 2:00u 0:00 GB-Eire %s 1996 - 0:00 EU GMT/BST + 0:00 EU GMT/BST 2019 Mar 29 23:00u # Brexit + 0:00 UK GMT/BST Link Europe/London Europe/Jersey Link Europe/London Europe/Guernsey Link Europe/London Europe/Isle_of_Man @@ -533,10 +537,10 @@ Link Europe/London Europe/Isle_of_Man Rule Eire 1971 only - Oct 31 2:00u -1:00 - Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 - Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 - -Rule Eire 1981 max - Mar lastSun 1:00u 0 - +Rule Eire 1981 2019 - Mar lastSun 1:00u 0 - Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 - Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 - -Rule Eire 1996 max - Oct lastSun 1:00u -1:00 - +Rule Eire 1996 2019 - Oct lastSun 1:00u -1:00 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 @@ -550,11 +554,12 @@ Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 0:00 - GMT 1948 Apr 18 2:00s 0:00 GB-Eire GMT/IST 1968 Oct 27 # The next line is for when negative SAVE values are used. - 1:00 Eire IST/GMT + 1:00 Eire IST/GMT 2019 Mar 31 1:00u # 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 +# 0:00 EU GMT/IST 2019 Mar 31 1:00u + 1:00 - IST ############################################################################### @@ -570,20 +575,23 @@ Rule EU 1977 1980 - Apr Sun>=1 1:00u 1:00 S Rule EU 1977 only - Sep lastSun 1:00u 0 - Rule EU 1978 only - Oct 1 1:00u 0 - Rule EU 1979 1995 - Sep lastSun 1:00u 0 - -Rule EU 1981 max - Mar lastSun 1:00u 1:00 S -Rule EU 1996 max - Oct lastSun 1:00u 0 - -# The most recent directive covers the years starting in 2002. See: +Rule EU 1981 2019 - Mar lastSun 1:00u 1:00 S +Rule EU 1996 2019 - Oct lastSun 1:00u 0 - +# The last summer time directive covers 2002-2019. See: # Directive 2000/84/EC of the European Parliament and of the Council # of 19 January 2001 on summer-time arrangements. # http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32000L0084:EN:N… +# The above ruleset assumes that the 2018-09-12 European Commission proposal to +# abolish DST will take effect unmodified; see +# https://ec.europa.eu/commission/sites/beta-political/files/soteu2018-discon… # W-Eur differs from EU only in that W-Eur uses standard time. Rule W-Eur 1977 1980 - Apr Sun>=1 1:00s 1:00 S Rule W-Eur 1977 only - Sep lastSun 1:00s 0 - Rule W-Eur 1978 only - Oct 1 1:00s 0 - Rule W-Eur 1979 1995 - Sep lastSun 1:00s 0 - -Rule W-Eur 1981 max - Mar lastSun 1:00s 1:00 S -Rule W-Eur 1996 max - Oct lastSun 1:00s 0 - +Rule W-Eur 1981 2019 - Mar lastSun 1:00s 1:00 S +Rule W-Eur 1996 2019 - Oct lastSun 1:00s 0 - # Older C-Eur rules are for convenience in the tables. # From 1977 on, C-Eur differs from EU only in that C-Eur uses standard time. @@ -641,8 +649,8 @@ Rule C-Eur 1977 1980 - Apr Sun>=1 2:00s 1:00 S Rule C-Eur 1977 only - Sep lastSun 2:00s 0 - Rule C-Eur 1978 only - Oct 1 2:00s 0 - Rule C-Eur 1979 1995 - Sep lastSun 2:00s 0 - -Rule C-Eur 1981 max - Mar lastSun 2:00s 1:00 S -Rule C-Eur 1996 max - Oct lastSun 2:00s 0 - +Rule C-Eur 1981 2019 - Mar lastSun 2:00s 1:00 S +Rule C-Eur 1996 2019 - Oct lastSun 2:00s 0 - # E-Eur differs from EU only in that E-Eur switches at midnight local time. Rule E-Eur 1977 1980 - Apr Sun>=1 0:00 1:00 S @@ -801,14 +809,16 @@ Rule Albania 1984 only - Apr 1 0:00 1:00 S Zone Europe/Tirane 1:19:20 - LMT 1914 1:00 - CET 1940 Jun 16 1:00 Albania CE%sT 1984 Jul - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Andorra # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Andorra 0:06:04 - LMT 1901 0:00 - WET 1946 Sep 30 1:00 - CET 1985 Mar 31 2:00 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Austria @@ -838,7 +848,8 @@ Zone Europe/Vienna 1:05:21 - LMT 1893 Apr 1:00 1:00 CEST 1945 Apr 12 2:00s 1:00 - CET 1946 1:00 Austria CE%sT 1981 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Belarus # @@ -935,7 +946,8 @@ Zone Europe/Brussels 0:17:30 - LMT 1880 0:00 Belgium WE%sT 1940 May 20 2:00s 1:00 C-Eur CE%sT 1944 Sep 3 1:00 Belgium CE%sT 1977 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Bosnia and Herzegovina # See Europe/Belgrade. @@ -963,7 +975,8 @@ Zone Europe/Sofia 1:33:16 - LMT 1880 2:00 Bulg EE%sT 1982 Sep 26 3:00 2:00 C-Eur EE%sT 1991 2:00 E-Eur EE%sT 1997 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Croatia # See Europe/Belgrade. @@ -997,7 +1010,8 @@ Zone Europe/Prague 0:57:44 - LMT 1850 # 0:00 - GMT 1947 Feb 23 2:00 # End of rearguard section. 1:00 Czech CE%sT 1979 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Use Europe/Prague also for Slovakia. # Denmark, Faroe Islands, and Greenland @@ -1054,10 +1068,12 @@ Zone Europe/Copenhagen 0:50:20 - LMT 1890 1:00 Denmark CE%sT 1942 Nov 2 2:00s 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Denmark CE%sT 1980 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn 0:00 - WET 1981 - 0:00 EU WE%sT + 0:00 EU WE%sT 2019 Mar 31 1:00u + 1:00 - +01 # # From Paul Eggert (2004-10-31): # During World War II, Germany maintained secret manned weather stations in @@ -1149,14 +1165,16 @@ Rule Thule 2007 max - Nov Sun>=1 2:00 0 S Zone America/Danmarkshavn -1:14:40 - LMT 1916 Jul 28 -3:00 - -03 1980 Apr 6 2:00 -3:00 EU -03/-02 1996 - 0:00 - GMT + 0:00 - +00 Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -2:00 - -02 1980 Apr 6 2:00 -2:00 C-Eur -02/-01 1981 Mar 29 - -1:00 EU -01/+00 + -1:00 EU -01/+00 2019 Mar 31 1:00u + 0:00 - +00 Zone America/Godthab -3:26:56 - LMT 1916 Jul 28 # Nuuk -3:00 - -03 1980 Apr 6 2:00 - -3:00 EU -03/-02 + -3:00 EU -03/-02 2019 Mar 31 1:00u + -2:00 - -02 Zone America/Thule -4:35:08 - LMT 1916 Jul 28 # Pituffik air base -4:00 Thule A%sT @@ -1224,7 +1242,8 @@ Zone Europe/Tallinn 1:39:00 - LMT 1880 2:00 C-Eur EE%sT 1998 Sep 22 2:00 EU EE%sT 1999 Oct 31 4:00 2:00 - EET 2002 Feb 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Finland @@ -1278,7 +1297,8 @@ Rule Finland 1981 1982 - Sep lastSun 3:00 0 - Zone Europe/Helsinki 1:39:49 - LMT 1878 May 31 1:39:49 - HMT 1921 May # Helsinki Mean Time 2:00 Finland EE%sT 1983 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Åland Is Link Europe/Helsinki Europe/Mariehamn @@ -1374,7 +1394,8 @@ Zone Europe/Paris 0:09:21 - LMT 1891 Mar 15 0:01 1:00 C-Eur CE%sT 1944 Aug 25 0:00 France WE%sT 1945 Sep 16 3:00 1:00 France CE%sT 1977 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Germany @@ -1417,7 +1438,8 @@ Zone Europe/Berlin 0:53:28 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 May 24 2:00 1:00 SovietZone CE%sT 1946 1:00 Germany CE%sT 1980 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # From Tobias Conradi (2011-09-12): # Büsingen <http://www.buesingen.de>, surrounded by the Swiss canton @@ -1444,7 +1466,8 @@ Link Europe/Zurich Europe/Busingen Zone Europe/Gibraltar -0:21:24 - LMT 1880 Aug 2 0:00s 0:00 GB-Eire %s 1957 Apr 14 2:00 1:00 - CET 1982 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 1:00 UK +01/+02 # Greece # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -1479,7 +1502,8 @@ Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 2:00 Greece EE%sT 1981 # Shanks & Pottenger say it switched to C-Eur in 1981; # go with EU rules instead, since Greece joined Jan 1. - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Hungary # From Paul Eggert (2014-07-15): @@ -1514,7 +1538,8 @@ Zone Europe/Budapest 1:16:20 - LMT 1890 Oct 1:00 Hungary CE%sT 1941 Apr 8 1:00 C-Eur CE%sT 1945 1:00 Hungary CE%sT 1980 Sep 28 2:00s - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Iceland # @@ -1662,7 +1687,8 @@ Zone Europe/Rome 0:49:56 - LMT 1866 Sep 22 1:00 Italy CE%sT 1943 Sep 10 1:00 C-Eur CE%sT 1944 Jun 4 1:00 Italy CE%sT 1980 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 Link Europe/Rome Europe/Vatican Link Europe/Rome Europe/San_Marino @@ -1747,7 +1773,8 @@ Zone Europe/Riga 1:36:34 - LMT 1880 2:00 Latvia EE%sT 1997 Jan 21 2:00 EU EE%sT 2000 Feb 29 2:00 - EET 2001 Jan 2 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Liechtenstein @@ -1817,7 +1844,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u 2:00 - EET 2003 Jan 1 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Luxembourg # Whitman disagrees with most of these dates in minor ways; @@ -1853,7 +1881,8 @@ Zone Europe/Luxembourg 0:24:36 - LMT 1904 Jun 0:00 Belgium WE%sT 1940 May 14 3:00 1:00 C-Eur WE%sT 1944 Sep 18 3:00 1:00 Belgium CE%sT 1977 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Macedonia # See Europe/Belgrade. @@ -1875,7 +1904,8 @@ Rule Malta 1980 only - Mar 31 2:00 1:00 S Zone Europe/Malta 0:58:04 - LMT 1893 Nov 2 0:00s # Valletta 1:00 Italy CE%sT 1973 Mar 31 1:00 Malta CE%sT 1981 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Moldova @@ -1961,7 +1991,8 @@ Zone Europe/Monaco 0:29:32 - LMT 1891 Mar 15 0:09:21 - PMT 1911 Mar 11 # Paris Mean Time 0:00 France WE%sT 1945 Sep 16 3:00 1:00 France CE%sT 1977 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Montenegro # See Europe/Belgrade. @@ -2038,7 +2069,8 @@ Zone Europe/Amsterdam 0:19:32 - LMT 1835 0:20 Neth +0020/+0120 1940 May 16 0:00 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Neth CE%sT 1977 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Norway # http://met.no/met/met_lex/q_u/sommertid.html (2004-01) agrees with Shanks & @@ -2056,7 +2088,8 @@ Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 1:00 Norway CE%sT 1940 Aug 10 23:00 1:00 C-Eur CE%sT 1945 Apr 2 2:00 1:00 Norway CE%sT 1980 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Svalbard & Jan Mayen @@ -2151,7 +2184,8 @@ Zone Europe/Warsaw 1:24:00 - LMT 1880 1:00 C-Eur CE%sT 1944 Oct 1:00 Poland CE%sT 1977 1:00 W-Eur CE%sT 1988 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Portugal @@ -2255,7 +2289,8 @@ Zone Europe/Lisbon -0:36:45 - LMT 1884 0:00 Port WE%sT 1983 Sep 25 1:00s 0:00 W-Eur WE%sT 1992 Sep 27 1:00s 1:00 EU CE%sT 1996 Mar 31 1:00u - 0:00 EU WE%sT + 0:00 EU WE%sT 2019 Mar 31 1:00u + 1:00 - +01 # This Zone can be simplified once we assume zic %z. Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT @@ -2271,7 +2306,8 @@ Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada -1:00 Port -01/+00 1983 Sep 25 1:00s -1:00 W-Eur -01/+00 1992 Sep 27 1:00s 0:00 EU WE%sT 1993 Mar 28 1:00u - -1:00 EU -01/+00 + -1:00 EU -01/+00 2019 Mar 31 1:00u + 0:00 - +00 # This Zone can be simplified once we assume zic %z. Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal -1:07:36 - FMT 1912 Jan 1 1:00u # Funchal MT @@ -2285,7 +2321,8 @@ Zone Atlantic/Madeira -1:07:36 - LMT 1884 # Funchal -1:00 Port +01 1945 Aug 25 22:00s -1:00 Port -01/+00 1966 Apr 3 2:00 0:00 Port WE%sT 1983 Sep 25 1:00s - 0:00 EU WE%sT + 0:00 EU WE%sT 2019 Mar 31 1:00u + 1:00 - +01 # Romania # @@ -2313,7 +2350,8 @@ Zone Europe/Bucharest 1:44:24 - LMT 1891 Oct 2:00 C-Eur EE%sT 1991 2:00 Romania EE%sT 1994 2:00 E-Eur EE%sT 1997 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Russia @@ -2491,7 +2529,8 @@ Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s - 2:00 - EET + 2:00 - EET 2019 Mar 31 1:00u + 2:00 - +02 # From Paul Eggert (2016-02-21), per Tim Parenti (2014-07-03) and @@ -3345,7 +3384,8 @@ Zone Europe/Belgrade 1:22:00 - LMT 1884 # transition to EU rules was 1982-11-27, for all of Yugoslavia at the time. # Shanks & Pottenger don't give as much detail, so go with Koželj. 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 Link Europe/Belgrade Europe/Ljubljana # Slovenia Link Europe/Belgrade Europe/Podgorica # Montenegro Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina @@ -3444,7 +3484,8 @@ Rule SpainAfrica 1978 only - Aug 4 0:00 0 - Zone Europe/Madrid -0:14:44 - LMT 1900 Dec 31 23:45:16 0:00 Spain WE%sT 1940 Mar 16 23:00 1:00 Spain CE%sT 1979 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 Zone Africa/Ceuta -0:21:16 - LMT 1900 Dec 31 23:38:44 0:00 - WET 1918 May 6 23:00 0:00 1:00 WEST 1918 Oct 7 23:00 @@ -3453,12 +3494,14 @@ Zone Africa/Ceuta -0:21:16 - LMT 1900 Dec 31 23:38:44 0:00 - WET 1967 # Help zishrink.awk. 0:00 SpainAfrica WE%sT 1984 Mar 16 1:00 - CET 1986 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. -1:00 - -01 1946 Sep 30 1:00 0:00 - WET 1980 Apr 6 0:00s 0:00 1:00 WEST 1980 Sep 28 1:00u - 0:00 EU WE%sT + 0:00 EU WE%sT 2019 Mar 31 1:00u + 1:00 - +01 # IATA SSIM (1996-09) says the Canaries switch at 2:00u, not 1:00u. # Ignore this for now, as the Canaries are part of the EU. @@ -3514,7 +3557,8 @@ Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 1:00 - CET 1916 May 14 23:00 1:00 1:00 CEST 1916 Oct 1 1:00 1:00 - CET 1980 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Switzerland # From Howse: @@ -3615,7 +3659,8 @@ Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 # See above comment. 0:29:46 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 # Turkey @@ -3858,7 +3903,8 @@ Zone Europe/Kiev 2:02:04 - LMT 1880 3:00 Russia MSK/MSD 1990 Jul 1 2:00 2:00 1:00 EEST 1991 Sep 29 3:00 2:00 E-Eur EE%sT 1995 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Ruthenia used CET 1990/1991. # "Uzhhorod" is the transliteration of the Rusyn/Ukrainian pronunciation, but # "Uzhgorod" is more common in English. @@ -3872,7 +3918,8 @@ Zone Europe/Uzhgorod 1:29:12 - LMT 1890 Oct 1:00 - CET 1991 Mar 31 3:00 2:00 - EET 1992 2:00 E-Eur EE%sT 1995 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Zaporozh'ye and eastern Lugansk oblasts observed DST 1990/1991. # "Zaporizhia" is the transliteration of the Ukrainian name, but # "Zaporozh'ye" is more common in English. Use the common English @@ -3885,7 +3932,8 @@ Zone Europe/Zaporozhye 2:20:40 - LMT 1880 1:00 C-Eur CE%sT 1943 Oct 25 3:00 Russia MSK/MSD 1991 Mar 31 2:00 2:00 E-Eur EE%sT 1995 - 2:00 EU EE%sT + 2:00 EU EE%sT 2019 Mar 31 1:00u + 3:00 - +03 # Vatican City # See Europe/Rome. diff --git a/zic.8 b/zic.8 index 4ef7675..17336dc 100644 --- a/zic.8 +++ b/zic.8 @@ -554,7 +554,8 @@ Rule EU 1996 max \*- Oct lastSun 1:00u 0 \*- Zone Europe/Zurich 0:34:08 \*- LMT 1853 Jul 16 0:29:46 \*- BMT 1894 Jun 1:00 Swiss CE%sT 1981 - 1:00 EU CE%sT + 1:00 EU CE%sT 2019 Mar 31 1:00u + 2:00 - +02 .sp Link Europe/Zurich Europe/Vaduz .sp @@ -568,8 +569,9 @@ was changed to 7\(de\|26\(fm\|22.50\(sd; although this works out to is rounded here. After 1894-06-01 at 00:00 the UT offset became one hour and Swiss daylight saving rules (defined with lines beginning with .q "Rule Swiss") -apply. From 1981 to the present, EU daylight saving rules have -applied, and the UTC offset has remained at one hour. +apply. From 1981 to 2019-03-31 01:00 UTC, EU daylight saving rules were +applied, and the UTC offset remained at one hour; +after that, the UTC offset has been (and is planned to be) two hours. .PP In 1941 and 1942, daylight saving time applied from the first Monday in May at 01:00 to the first Monday in October at 02:00. @@ -583,10 +585,15 @@ For purposes of display, .q "LMT" and .q "BMT" -were initially used, respectively. Since +were initially used, respectively. When Swiss rules and later EU rules were applied, the time zone abbreviation -has been CET for standard time and CEST for daylight saving -time. +was +.q "CET" +for standard time and +.q "CEST" +for daylight saving time. +Now that EU DST rules no longer apply, the time zone abbreviation is simply +.q "+02". .SH FILES .TP .I /etc/localtime diff --git a/ziguard.awk b/ziguard.awk index 42e2910..f53a749 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -43,7 +43,7 @@ DATAFORM != "main" { Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/ Zone_Dublin_post_1968 \ = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \ - && (!$(in_comment + 4) || 1968 < $(in_comment + 4))) + && 1968 < $(in_comment + 4)) if (Rule_Eire || Zone_Dublin_post_1968) { if ((Rule_Eire \ || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT")) \ -- 2.17.1

7 15

DST in Samoa causes some teachers to have "thick brains", says P.M.
by Paul Eggert Sept. 18, 2018

Sept. 18, 2018

When DST hits Samoa on September 31, some schools will continue with their nominal schedules, effectively observing DST. However, Prime Minister Tuilaepa Sa’ilele Malielegaoi wants all schools to adjust their nominal schedules by an hour during DST, so that schools effectively continue to run on standard time. The Prime Minister criticized schools not on board with his plan, saying "Some teachers just have thick brains, they are not thinking properly." He also said, "The problem is that no matter the explanation I give to change the starting time for classes, some people just don't want to understand." My source is an article currently on the front page of the Samoa Observer, which is registering the largest number of hits of any article there: Feagaimaali’i-Luamanu J. P.M. slams teachers with "thick brains," wants schools to start at 9am. Samoa Observer. 2018-09-17. http://www.sobserver.ws/en/17_09_2018/local/36843/PM-slams-teachers-with-%E…

1 0

Update -Egypt DST
by mohamed abdallah Sept. 17, 2018

Sept. 17, 2018

Please be aware that Egypt has ceased using the daylight saving time since 2016 and although this fact our android smartphones keeps changing the time (GMT+2) to the daylight saving time (GMT+3). If possible please address this issue and reply. Sent from my HTC

2 1

Re: [tz] European Commission proposes ending DST in March 2019
by Even Scharning Sept. 14, 2018

Sept. 14, 2018

Here is a press release from the European Commission: http://europa.eu/rapid/press-release_IP-18-5709_en.htm And the State of the Union 2018 subpage on Seasonal Clock Changes: https://ec.europa.eu/commission/priorities/state-union-speeches/state-union… Our summary: https://time.is/time_zone_news/end_of_seasonal_clock_changes_in_the_eu Even Scharning Time.is - exact time for any time zone https://time.is/

3 2

Ethiopian time in past mainstream media
by Arthur David Olson Sept. 14, 2018

Sept. 14, 2018

>From January, 2015: "If you have a meeting in Ethiopia, you'd better double check the time." https://www.pri.org/stories/2015-01-30/if-you-have-meeting-ethiopia-you-bet… Noted today by Tony Finch on @Twitter: https://twitter.com/fanf/status/1040568915871649792 @dashdashado

2 1

European Commission proposes ending DST in March 2019
by Paul Eggert Sept. 13, 2018

Sept. 13, 2018

In a major speech today covering several topics, European Commission President Jean-Claude Juncker said the commission is proposing ending daylight saving time in the European Union next year. Under the proposal, member states will move their clocks forward in March 2019 as usual, and then chaos will ensue. Well, not exactly chaos, but each member state will be on its own as to whether to move clocks back in October 2019. It should make for interesting times in Ireland and elsewhere. Healy C. Irish people could never have to change clocks from 2019 as EU propose end to laws. Irish Sun. 2018-09-12 10:50 +01. https://www.thesun.ie/news/3108149/irish-clocks-daylight-savings-abolished-…

2 1

Traditional Chinese Time
by Phake Nick Sept. 13, 2018

Sept. 13, 2018

After reading the discussion about time around Ethiopian area, I am reminded that there is actually another clock that is in use for Chinese-speaking area [and maybe also some other neighboring region]. The system, nowadays mostly used in traditional customary/religious activity only, would divide a day into 12 "double hours" (it seems to be a common English translation for the original Chinese term), and then assign each double hour a name from "Earthly Branch". The tricky thing here is, the first hour "zi" actually start at 11 o'clock (pm) standard time. And so everyday start and end at 23:00 according to this system [However, note that some have suggested changing the system, so that despite the 'zi' hour still represent the time period between 11pm and 1am, in some's mind it would be broken into a 'early zi' hour that belong to the previous day while the second half of the hour would be treated as a 'late zi' hour that belongs to the second day]. Also, according to old calendar books, DST are not observed for the traditional timing system, so the "zi" hour would start at DST 24:00 if there's a DST. And then, nowadays there are people who directly use time that are keep officially according to timezone rules to convert time into this traditional system, however there are also people who use the local solar time instead.

1 0

Inquiry to NICT about Japanese Summer time in 1948-1952.
by Phake Nick Sept. 8, 2018

Sept. 8, 2018

To receivers of this email: Recently, I have read an article, which mentioned the history of Japanese Summer Time Implementation in the past at www.bengo4.com/internet/n_8461/ . In the article, it was mentioned that the summer time (DST) end at 25 hours at the last day of the implementation period. Does that mean the clock would go up to the 25th hours back then and reach 24:59 before it continues toward 00:00 on the next day in standard time? If not then how did the clock switched from Summer Time back to Standard Time back then? Please use the "reply to all" function when replying to the message so that other receivers of the message can also hear answer on the matter. Sincerely, P.N.

1 0

1948-1951 Asia/Tokyo DST information
by Phake Nick Sept. 8, 2018

Sept. 8, 2018

It seems like the current info about past DST for Asia/Tokyo in tz database is incorrect. The law cited in the latest commit do say the DST en at 00:00 on the day after the second Saturday in September, however the second line of the law write that "the Second Saturday in September would have 25 hours in a day". I was made aware of it by reading an interview on NICT (The National Institute of Information and Communications Technology) of Japan and the history of DST in Japan given in the interview by NICT representative do said DST used to end at 25:00 there. See https://www.bengo4.com/internet/n_8461/

5 9

Possible closure of WWV et al.
by Arthur David Olson Sept. 3, 2018

Sept. 3, 2018

"If this budget passes as written, WWV, WWVH, and WWVB will all be closed." https://swling.com/blog/2018/08/information-from-the-nist-regarding-possibl… @dashdashado

5 4

EU plans to abolish summer time
by Clive D.W. Feather Aug. 31, 2018

Aug. 31, 2018

https://www.bbc.co.uk/news/world-europe-45366390 A recent EU public consultation was massively in favour of abolishing the twice-yearly clock changes. It's not clear from the article whether the final proposal will be to abolish it completely, allowing each member state to pick either its current summer offset or its current winter offset, or whether states will be allowed to continue to change on the coordinated dates. Assuming the UK leaves the EU on schedule, it's even more unclear what the UK will do. -- 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

2 2

BBC: Clock changes: EU backs ending daylight saving
by Marshall Eubanks Aug. 31, 2018

Aug. 31, 2018

Clearly, not going to happen that soon. Regards https://www.bbc.co.uk/news/world-europe-45366390 The EU Commission is proposing to end the practice of adjusting clocks by an hour in spring and autumn after a survey found most Europeans opposed it. Commission President Jean-Claude Juncker said millions "believe that in future, summer time should be year-round, and that's what will happen". The Commission's proposal requires support from the 28 national governments and MEPs to become law. In the EU clocks switch between winter and summer under daylight saving time. A European Parliament resolution says it is "crucial to maintain a unified EU time regime". However, the Commission has not yet drafted details of the proposed change. In a consultation paper it said one option would be to let each member state decide whether to go for permanent summer or winter time. That would be "a sovereign decision of each member state", Commission spokesman Alexander Winterstein explained on Friday.

6 6

Mozambique officially uses LMT?
by Steve Allen Aug. 30, 2018

Aug. 30, 2018

A month ago was the longest lunar eclipse this century, and it was well visible from Mozambique. I know folks there who forwarded a couple of low resolution versions of information pages that the national meteorological agency issued. Upon looking at them I realized that they were saying that someone at the national meteorological agency believed that each town in Mozambique, including the capitol city Maputo, is running on Local Mean Time. I have attached the images. They are the official announcement from INAM. In a lunar eclipse all points on earth see the same fuzzy shadow events within milliseconds, but all times in the table are offset according to the longitude of the city. I know that cell phones in Mozambique use what tzdb says. I cannot say what outlying villages and people without cell phones use, other than that there is no such thing as precise timing of civil events and transportation departures/arrivals as in most modern cultures. So I cannot say for sure whether this is a mistake, an official doing these calculations the way things used to work, or whether outlying towns still set their clocks using a stick in the ground. I have no contacts to dive deeper into Mozambican government, so I wonder if anyone else can find out more. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

3 5

[PROPOSED] * asia: Add story about Higgins time.
by Paul Eggert Aug. 30, 2018

Aug. 30, 2018

--- asia | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/asia b/asia index 7166380..5e27d85 100644 --- a/asia +++ b/asia @@ -2939,15 +2939,34 @@ Link Asia/Qatar Asia/Bahrain # Saudi Arabia # -# From Paul Eggert (2014-07-15): +# From Paul Eggert (2018-08-29): # Time in Saudi Arabia and other countries in the Arabian peninsula was not -# standardized until relatively recently; we don't know when, and possibly it +# standardized until 1968 or so; we don't know exactly when, and possibly it # has never been made official. Richard P Hunt, in "Islam city yielding to # modern times", New York Times (1961-04-09), p 20, wrote that only airlines # observed standard time, and that people in Jeddah mostly observed quasi-solar # time, doing so by setting their watches at sunrise to 6 o'clock (or to 12 # o'clock for "Arab" time). # +# Timekeeping differed depending on who you were and which part of Saudi +# Arabia you were in. In 1969, Elias Antar wrote that although a common +# practice had been to set one's watch to 12:00 (i.e., midnight) at sunset - +# which meant that the time on one side of a mountain could differ greatly from +# the time on the other side - many foreigners set their watches to 6pm +# instead, while airlines instead used UTC +03 (except in Dhahran, where they +# used UTC +04), Aramco used UTC +03 with DST, and the Trans-Arabian Pipe Line +# Company used Aramco time in eastern Saudi Arabia and airline time in western. +# (The American Military Aid Advisory Group used plain UTC.) Antar writes, +# "A man named Higgins, so the story goes, used to run a local power +# station. One day, the whole thing became too much for Higgins and he +# assembled his staff and laid down the law. 'I've had enough of this,' he +# shrieked. 'It is now 12 o'clock Higgins Time, and from now on this station is +# going to run on Higgins Time.' And so, until last year, it did." See: +# Antar E. Dinner at When? Saudi Aramco World, 1969 March/April. 2-3. +# http://archive.aramcoworld.com/issue/196902/dinner.at.when.htm +# newspapers.com says a similar story about Higgins was published in the Port +# Angeles (WA) Evening News, 1965-03-10, page 5, but I lack access to the text. +# # The TZ database cannot represent quasi-solar time; airline time is the best # we can do. The 1946 foreign air news digest of the U.S. Civil Aeronautics # Board (OCLC 42299995) reported that the "... Arabian Government, inaugurated @@ -2957,7 +2976,8 @@ Link Asia/Qatar Asia/Bahrain # # Shanks & Pottenger also state that until 1968-05-01 Saudi Arabia had two # time zones; the other zone, at UT +04, was in the far eastern part of -# the country. Ignore this, as it's before our 1970 cutoff. +# the country. Presumably this is documenting airline time. Ignore this, +# as it's before our 1970 cutoff. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Riyadh 3:06:52 - LMT 1947 Mar 14 -- 2.17.1

1 0

EU Public Consultation on summertime arrangements
by John Wilcock Aug. 29, 2018

Aug. 29, 2018

https://ec.europa.eu/info/consultations/2018-summertime-arrangements_en > > Objective of the consultation > > Following a number of requests from citizens, from the European > Parliament, and from certain EU Member States, the Commission has > decided to investigate the functioning of the current EU summertime > arrangements and to assess whether or not they should be changed. > > In this context, the Commission is interested in gathering the views > of European citizens, stakeholders and Member States on the current EU > summertime arrangements and on any potential change to those arrangements. >

9 39

Fwd: TZDB Questions
by Paul Eggert Aug. 29, 2018

Aug. 29, 2018

[Forwarded with permission.] -------- Forwarded Message -------- Subject: TZDB Questions Date: Mon, 27 Aug 2018 17:52:53 -0700 From: Mikey Schott <maschott(a)gmail.com> To: eggert(a)cs.ucla.edu Hello, Dr. Eggert. First let me express my thanks to you for all of the time and energy you have put into the upkeep of the time zone database. I appreciate all of the thought and detail that goes into the decisions regarding each zone. I've been working extensively with the time zone database over the past month to identify a list of currently unique time zones for use in a front-end web application. I'd be happy to share the details of my work if you are curious, but since its purpose is tangential to that of the time zone database, I'll leave them out of this email. The reason I'm writing is because after working so closely with the data, I had a few questions I was hoping you could answer for me. I have more or less completed the work I was doing, so these questions come more from curiosity than necessity. 1. Has there been any consideration to move the source data into a more structured format like csv, xml, or json? I realize I'm probably in the minority here in terms of people who would find this useful. 2. The latest zone entry for some zones that no longer use dst still point to dst rules, e.g. Asia/Tokyo and the Japan rule set even though dst is no longer used in Japan . Is there a reason why some non-dst zones use this method where they point to an outdated rule set whereas most non-dst zones use no rule set (i.e. rule = '-')? 3. I've noticed that some zones just use a shortened version of their offset for their format, whereas timeanddate.com gives them a more descriptive format (e.g. Europe/Volgograd uses MSK vs. +03). Is there a reason for the discrepancy? Does the time zone database error on the side of caution here? 4. I believe that one of the primary purposes of the Link zones is to ensure that there is a zone that covers every country. Is there a specific list or source that the time zone database uses to decide the list of countries that are covered? I noticed that Bouvet Island (BV) and Heard and McDonald Islands (HM) are not included despite having ISO-3166-2 country codes. (Although both have a population of 0, so it hardly qualifies as an oversight.) 5. Do you have a favorite time zone? I've become quite fond of Antarctica/Troll both for its name and its unique offset. Thanks again for all of your work on the database. I've signed up for the mailing list so I can keep up to date. -Mikey

3 3

Re: [tz] TZDB Questions
by Mikey Schott Aug. 29, 2018

Aug. 29, 2018

Great. Thanks for all the answers.

1 0

The rules of DST@Shanghai need some modifications
by Hong Xie Aug. 21, 2018

Aug. 21, 2018

The existing rules of DST@Shanghai is # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Shang 1940 only - Jun 3 0:00 1:00 D > Rule Shang 1940 1941 - Oct 1 0:00 0 S > Rule Shang 1941 only - Mar 16 0:00 1:00 D > Rule PRC 1986 only - May 4 0:00 1:00 D > Rule PRC 1986 1991 - Sep Sun>=11 0:00 0 S > Rule PRC 1987 1991 - Apr Sun>=10 0:00 1:00 D There are a news record about the DST in China: http://bjrb.bjd.com.cn/html/2017-08/25/content_169986.htm The accurate hour of DST@China is 02:00. For Example, In 1986, the start time of DST@China is 02:00 May 4 1986. The end time of DST@China is 02:00 Sep 14 1986. So the rule should be modified to: # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S > Rule Shang 1940 only - Jun 3 0:00 1:00 D > Rule Shang 1940 1941 - Oct 1 0:00 0 S > Rule Shang 1941 only - Mar 16 0:00 1:00 D > Rule PRC 1986 only - May 4 2:00 1:00 D > Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S > Rule PRC 1987 1991 - Apr Sun>=10 2:00 1:00 D

2 1

time and cost to reprogram computers for DST in Japan
by Paul Eggert Aug. 20, 2018

Aug. 20, 2018

Earlier this week Mainichi Japan published an article describing some criticism of reintroducing DST to Japan. My favorite quote was this one, abut the time and cost to reprogram computers: "The biggest hurdle in Japan to putting daylight saving time in place is the cost and workload required to adjust computer systems. Professor Tetsutaro Uehara of Ritsumeikan University, a specialist in information systems, estimates that it would take about four years and hundreds of billions of yen to do just that. "'Japan is a country with advanced information technology systems, and computers with timing functions are used everywhere. Many are programmed with Japan time based on the international standard time,' pointed out Uehara. 'Software would have to be rewritten to introduce summer time. Such work would take about four years and cost hundreds of billions of yen. It is crazy to attempt to put it in place by the 2020 Games,' said the bewildered professor." My source: Nakagawa S, Hatta K. Daylight saving time causes more trouble than benefits, say critics. The Mainichi. 2018-08-12. https://mainichi.jp/english/articles/20180812/p2a/00m/0na/010000c

6 8

Time zones in the news
by Arthur David Olson Aug. 13, 2018

Aug. 13, 2018

"Trump’s diplomatic learning curve: Time zones, ‘Nambia’ and ‘Nipple’" https://www.politico.com/story/2018/08/13/trump-world-knowledge-diplomatic-… @dashdashado

1 0

2-hour DST during 2020 Tokyo Olympics?
by Paul Eggert Aug. 8, 2018

Aug. 8, 2018

Prompted by the recent deadly heat wave in Japan, Prime Minister Shinzo Abe met yesterday with the president of the 2020 Tokyo Olympic organizing committee, and discussed whether to introduce one or two hours of daylight saving time during the 2020 Olympics to help beat that summer's heat. Although Japan's 2020 Olympics bid said that Tokyo's July/August climate has "many days of mild and sunny weather" and is "an ideal climate for athletes to perform at their best", in reality a Tokyo summer's heat and humidity can be brutal: summer temperatures regularly get to 35°C (95°F) and last week peaked at 41°C (106°F). The International Olympic Committee has agreed to allow staging the marathon at 07:00 to beat the heat. "Why not 05:00? the sun will already be up then," Tokyo residents may be thinking. Apparently the recent heat wave has caused organizers to think the same thing, as a 2-hour DST would advance the event's effective starting time to 05:00 by the sun while still keeping it nominally at 07:00. Although the 1964 Tokyo Games were held in October to avoid heat, this was before the Olympics schedule was subject to the scheduling demands of broadcasters and sponsors. The 2016 Rio de Janeiro Summer Olympics ratings were down 9% from 2012 (including digital streaming) and event dates will be an important factor in the 2020 ratings. Although a 2-hour DST would presumably affect attendance and ratings only in Japan, that alone is a significant concern for the event's organizers. My sources: Tokyo weighs daylight saving time for Olympics as heat wave incinerates weather descriptions used for 2020 Games bid. Japan Times. 2018-07-28. https://www.japantimes.co.jp/news/2018/07/28/national/tokyo-weighs-daylight… OLYMPICS/2020 Tokyo organizers consider daylight saving to beat heat. Asahi Shimbun. 2018-07-28. http://www.asahi.com/ajw/articles/AJ201807280009.html

6 7

California may vote on permanent daylight time
by Steve Allen Aug. 5, 2018

Aug. 5, 2018

The legislators have approved a bill to allow California voters to decide whether the state should move to permanent daylight time. The governor now has less than 12 days to veto. Even if voters say yes, federal approval will be required. http://www.santacruzsentinel.com/technology/20180622/year-round-daylight-sa… -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

7 7

Proposed Volgograd time zone change
by Stepan Golosunov Aug. 5, 2018

Aug. 5, 2018

There is currently a bill to change time in Volgograd oblast from Moscow time to Moscow+1. The bill is the result of a local referendum, so it will likely be passed into law. That would require changing Europe/Volgograd from UTC+3 to UTC+4. Proposed change date (2018-10-28) though looks too optimistic (publication of the law before that date while still possible is unlikely) and will likely be amended. http://sozd.parliament.gov.ru/bill/452878-7 Other news: The bill to reintroduce Julian calendar awaits its rejection for some time already: http://sozd.parliament.gov.ru/bill/194304-7 The bill to move clocks 1 hour forward ("permanent summer time") throughout Russia was recently recommended to be rejected: http://sozd.parliament.gov.ru/bill/383137-7 Russian Railways announced that they are changing time displayed on station clocks, timetables and tickets from Moscow time to local time: http://eng.rzd.ru/newse/public/en?STRUCTURE_ID=15&layer_id=4839&id=107332

1 0

Incorrect Time Zone Data for American/Grand_Turk
by Robert MacGrogan Aug. 4, 2018

Aug. 4, 2018

Hi there. It looks to me like the time zone data for America/Grand_Turk is incorrect in 2018e version of the database. Turks and Caicos switched to supporting daylight savings time in March of 2018. So in summer the correct time for America/Ground_Turk should be GMT -4 and then back to GMT -5 again in the fall. The current database returns times for summer of 2018 as GMT -5, which is incorrect. Thank you. -- Rob MacGrogan | Director of Software Development rmacgrogan(a)flightbridge.com <rmacgrogan(a)flightbridge.com> 850-509-6158 [image: FlightBridge] <http://www.flightbridge.com/> FlightBridge, Inc. 530 Means Street, Suite 405 Atlanta, GA 30318 www.flightbridge.com

7 19

[PROPOSED] One line per metadatum in tzdata.zi
by Paul Eggert July 31, 2018

July 31, 2018

With the new metadata, version lines could be long. E.g., 'make DATAFORM=rearguard REDO=posix_only PACKRATDATA=backzone BACKWARD=' could generate a tzdata.zi line like this: # version 2018e-57-gba7f088,dataform=rearguard,redo=posix_only,ddeps=(backzone,!backward) which is quite a mouthful and is stretching the definition of "version". To avoid the problem, output a separate comment line for each metadata component instead, like this: # version 2018e-57-gba7f088 # dataform rearguard # redo posix_only # ddeps backzone !backward This is easier to read and to parse and should scale better if we add more metadata later. * NEWS: Mention this. * zishrink.awk: Output a separate line for each metadatum. 2018-07-21 Paul Eggert <eggert(a)cs.ucla.edu> Use space, not comma, in tzdata.zi "# version" * zishrink.awk: Use space instead of comma to separate original version string from auxiliary configuration information. This saves two bytes and (more important) is easier for humans to read. --- NEWS | 16 ++++++++-------- zishrink.awk | 20 ++++++++++---------- 2 files changed, 18 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 413d649..a3fc622 100644 --- a/NEWS +++ b/NEWS @@ -92,14 +92,14 @@ Unreleased, experimental changes tzdata.zi is now more stable from release to release. (Problem noted by Tom Lane.) It is also a bit shorter. - tzdata.zi's version comment now contains information about which - data format was selected, which input files were used, and how - leap seconds are treated. (Problems noted by Lester Caine and - Brian Inglis.) If the Makefile defaults are used, no text is - appended to the version comment, for backward compatibility. - A redistributor intending to alter its copy of the files should - also append "-SOMETHING" to the 'version' file's first line, where - "SOMETHING" identifies what was changed. + tzdata.zi now can contain comment lines documenting configuration + information, such as which data format was selected, which input + files were used, and how leap seconds are treated. (Problems + noted by Lester Caine and Brian Inglis.) If the Makefile defaults + are used these comment lines are absent, for backward + compatibility. A redistributor intending to alter its copy of the + files should also append "-LABEL" to the 'version' file's first + line, where "LABEL" identifies the redistributor's change. Release 2018e - 2018-05-01 23:42:51 -0700 diff --git a/zishrink.awk b/zishrink.awk index 162e515..74e0de9 100644 --- a/zishrink.awk +++ b/zishrink.awk @@ -287,30 +287,30 @@ BEGIN { # that affect the output of this script, you should append '-SOMETHING' # to the contents of 'version', where SOMETHING identifies what was changed. - if (dataform != "main") { - version = version ",dataform=" dataform - } - if (redo != "posix_right") { - version = version ",redo=" redo - } ndeps = split(deps, dep) ddeps = "" for (i = 1; i <= ndeps; i++) { if (default_dep[dep[i]]) { default_dep[dep[i]]++ } else { - ddeps = ddeps "," dep[i] + ddeps = ddeps " " dep[i] } } for (d in default_dep) { if (default_dep[d] == 1) { - ddeps = ddeps ",!" d + ddeps = ddeps " !" d } } + print "# version", version + if (dataform != "main") { + print "# dataform", dataform + } + if (redo != "posix_right") { + print "# redo " redo + } if (ddeps) { - version = version ",ddeps=(" substr(ddeps, 2) ")" + print "# ddeps" ddeps } - print "# version", version print "# This zic input file is in the public domain." prehash_rule_names() -- 2.7.4

1 0

Getting current tzdb version in use
by Aldrin Martoq Ahumada July 26, 2018

July 26, 2018

Hi, I was looking for a reliable way to get the current tzdb version (something like 2018e), but it seems it doesn’t exists yet. A couple of examples: - In Mac OS 10.13.6, there is a /usr/share/zoneinfo/+VERSION that says 2018c. - In one of my updated Ubuntu 16.04 servers, the only reliable way is to do a dpkg -s tzdata | grep ^Version, and guess the real version from the string “Version: 2017c-0ubuntu0.16.04" - The “tzinfo” ruby library can get the version only if it uses its own version of tzdata, if it uses the OS files, there is no string version. Knowing the current tzdb version is essential for automating timezone updates. I think an appropriate place to put that string is in the binary TZif file itself, so tools like tzinfo can get the current version *of the current timezone in use*, instead of looking some random file like +VERSION in a random directory/folder. Is there any chances for this to happen? Or any other suggestion? Aldrin.

18 51

Re: [tz] Celinograd (Astana)
by Paul Eggert July 20, 2018

July 20, 2018

Marat Nigametzianov wrote: > https://ru.m.wikipedia.org/wiki/Время_в_Казахстане Generally we prefer primary sources, as Wikipedia is less reliable (anybody can edit it). > And this is link to order from 1956 about timezone in USSR > http://astro.uni-altai.ru/~orion/blog/2011/11/novyie-granitsyi-chasovyih-po… Thanks, that source should be quite helpful. Proposed patch attached. This is to commentary only. > Where is a two part of kazahstan and celinograd (astana) is in eastern part > of it, so it always have to be +6 Currently Astana is covered by Asia/Almaty, which already says that the region was at UT +06 from 1930-06-21 until 1981-04-01. So I'm afraid that I don't see why a change to tzdata is needed (other than to commentary).

2 2

Getting current tzdb version in use
by Paul Eggert July 20, 2018

July 20, 2018

On 07/19/2018 08:50 AM, lester(a)lsces.co.uk wrote: > The bottom line is that currently we have no way of knowing just what data is > being supplied. Even if the data matches the raw tz version, it may or may not > include the pre-1970 <tel:1970> data archived to backzone. Yes, and this is partly why I have resisted putting version information into the installed files. Version info is typically not available unless you've merely cloned the development Git repository and have made no change to the data or to the 'make' parameters that select or alter the data, a situation that is reasonably rare in practice. It would take quite a bit of effort to get reliable version information in real installations, and nobody knows exactly what would be entailed in that effort. Since many people have requested version info I had compromised by putting a version string into tzdata.zi as a sort of experiment. The experiment has clearly failed so far. That being said, we can improve things a bit by putting into tzdata.zi information about whether the file 'backward' was used, as well as whether the (dicey) file 'backzone' and the (obsolete) file 'pacificnew' were used. We can also record whether the rearguard (or vanguard) data format was selected. Proposed patch attached. Harold, if you're changing your C++ library to look for "unknown", this patch might append some stuff to that "unknown" string.

2 2

rearguard
by Lord Buddha July 18, 2018

July 18, 2018

This would be so much easier (for me;) ) if all data forms were published by IANA. $ awk -v DATAFORM=vanguard -f ziguard.awk africa antarctica asia australasia europe northamerica southamerica etcetera systemv factory backward *malloc(): memory corruptionAborted (core dumped)* On Ubuntu 18.04 trying to get files in rearguard format so I can patch Java & JodaTime.... Need to patch as we need the Fiji change now.

3 4

[PATCH] Give title lines to many files lacking them
by Paul Eggert July 16, 2018

July 16, 2018

--- Makefile | 2 ++ africa | 2 ++ antarctica | 2 ++ asia | 2 ++ australasia | 2 ++ backward | 2 ++ difftime.c | 2 ++ etcetera | 2 ++ europe | 2 ++ factory | 2 ++ localtime.c | 2 ++ newstrftime.3 | 2 ++ northamerica | 2 ++ pacificnew | 2 ++ private.h | 2 ++ southamerica | 2 ++ systemv | 2 ++ tzfile.h | 2 ++ tzselect.ksh | 5 ++--- workman.sh | 1 + yearistype.sh | 1 + zdump.c | 2 ++ zic.c | 2 ++ zoneinfo2tdf.pl | 1 + 24 files changed, 45 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 9e3b8f9..d01bb9a 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,5 @@ +# Make and install tzdb code and data. + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/africa b/africa index eb7f8ae..131330e 100644 --- a/africa +++ b/africa @@ -1,3 +1,5 @@ +# tzdb data for Africa and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/antarctica b/antarctica index 866cf4f..1dd9b00 100644 --- a/antarctica +++ b/antarctica @@ -1,3 +1,5 @@ +# tzdb data for Antarctica and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/asia b/asia index 810ef47..7166380 100644 --- a/asia +++ b/asia @@ -1,3 +1,5 @@ +# tzdb data for Asia and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/australasia b/australasia index 938c591..87ba620 100644 --- a/australasia +++ b/australasia @@ -1,3 +1,5 @@ +# tzdb data for Australasia and environs, and for much of the Pacific + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/backward b/backward index a455044..51e10f4 100644 --- a/backward +++ b/backward @@ -1,3 +1,5 @@ +# tzdb links for backward compatibility + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/difftime.c b/difftime.c index 856234a..7b96927 100644 --- a/difftime.c +++ b/difftime.c @@ -1,3 +1,5 @@ +/* Return the difference between two timestamps. */ + /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson. diff --git a/etcetera b/etcetera index 1a59630..91ded93 100644 --- a/etcetera +++ b/etcetera @@ -1,3 +1,5 @@ +# tzdb data for ships at sea and other miscellany + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/europe b/europe index 8a8f8f9..a5feb59 100644 --- a/europe +++ b/europe @@ -1,3 +1,5 @@ +# tzdb data for Europe and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/factory b/factory index 5f0573d..d4e7659 100644 --- a/factory +++ b/factory @@ -1,3 +1,5 @@ +# tzdb data for noncommittal factory settings + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/localtime.c b/localtime.c index b217865..6b45254 100644 --- a/localtime.c +++ b/localtime.c @@ -1,3 +1,5 @@ +/* Convert timestamp from time_t to struct tm. */ + /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson. diff --git a/newstrftime.3 b/newstrftime.3 index 1fd80df..eee503e 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -1,3 +1,5 @@ +.\" strftime man page +.\" .\" Based on the UCB file whose corrected copyright information appears below. .\" Copyright 1989, 1991 The Regents of the University of California. .\" All rights reserved. diff --git a/northamerica b/northamerica index 06db1a8..ffbda74 100644 --- a/northamerica +++ b/northamerica @@ -1,3 +1,5 @@ +# tzdb data for North and Central America and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/pacificnew b/pacificnew index 7349434..0e6cf07 100644 --- a/pacificnew +++ b/pacificnew @@ -1,3 +1,5 @@ +# tzdb data for proposed US election time (this file is obsolete) + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/private.h b/private.h index 641f905..1ead147 100644 --- a/private.h +++ b/private.h @@ -1,3 +1,5 @@ +/* Private header for tzdb code. */ + #ifndef PRIVATE_H #define PRIVATE_H diff --git a/southamerica b/southamerica index aab355c..67562f2 100644 --- a/southamerica +++ b/southamerica @@ -1,3 +1,5 @@ +# tzdb data for South America and environs + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/systemv b/systemv index d9e2995..24c8f64 100644 --- a/systemv +++ b/systemv @@ -1,3 +1,5 @@ +# tzdb data for System V rules (this file is obsolete) + # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/tzfile.h b/tzfile.h index f7f5caf..27a38cc 100644 --- a/tzfile.h +++ b/tzfile.h @@ -1,3 +1,5 @@ +/* Layout and location of TZif files. */ + #ifndef TZFILE_H #define TZFILE_H diff --git a/tzselect.ksh b/tzselect.ksh index f7d8154..18fce27 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -1,12 +1,11 @@ #!/bin/bash +# Ask the user about the time zone, and output the resulting TZ value to stdout. +# Interact with the user via stderr and stdin. PKGVERSION='(tzcode) ' TZVERSION=see_Makefile REPORT_BUGS_TO=tz(a)iana.org -# Ask the user about the time zone, and output the resulting TZ value to stdout. -# Interact with the user via stderr and stdin. - # Contributed by Paul Eggert. This file is in the public domain. # Porting notes: diff --git a/workman.sh b/workman.sh index 4b3b64a..8fb18a4 100644 --- a/workman.sh +++ b/workman.sh @@ -1,4 +1,5 @@ #! /bin/sh +# Convert manual page troff stdin to formatted .txt stdout. # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. diff --git a/yearistype.sh b/yearistype.sh index dfdcdf0..d674175 100644 --- a/yearistype.sh +++ b/yearistype.sh @@ -1,4 +1,5 @@ #! /bin/sh +: 'Determine whether year is of appropriate type (this file is obsolete).' : 'This file is in the public domain, so clarified as of' : '2006-07-17 by Arthur David Olson.' diff --git a/zdump.c b/zdump.c index 4c61f58..608f288 100644 --- a/zdump.c +++ b/zdump.c @@ -1,3 +1,5 @@ +/* Dump time zone data in a textual format. */ + /* ** This file is in the public domain, so clarified as of ** 2009-05-17 by Arthur David Olson. diff --git a/zic.c b/zic.c index 88153db..9d455b5 100644 --- a/zic.c +++ b/zic.c @@ -1,3 +1,5 @@ +/* Compile .zi time zone data into TZif binary files. */ + /* ** This file is in the public domain, so clarified as of ** 2006-07-17 by Arthur David Olson. diff --git a/zoneinfo2tdf.pl b/zoneinfo2tdf.pl index e05ec01..c8c5591 100755 --- a/zoneinfo2tdf.pl +++ b/zoneinfo2tdf.pl @@ -1,4 +1,5 @@ #! /usr/bin/perl -w +# Summarize .zi input in a .zi-like format. # Courtesy Ken Pizzini. -- 2.7.4

1 0

Celinograd (Astana)
by Marat Nigametzianov July 16, 2018

July 16, 2018

Celinograd (Astana) in 1969 must be +6 UTC not +5 https://www.worldtimezone.com/dst_news/dst_news_ussr-map-1970.html -- Nigametzianov Marat ____________________________________________________________________________ 8 926 568-93-08, ppmarat(a)gmail.com

2 1

Fiji DST 2018/19
by Raymond Kumar July 15, 2018

July 15, 2018

Hi Paul, There is a DST time change in Fiji island from November 4th. http://www.fijitimes.com/government-approves-2018-daylight-saving/ The attached order states: Members of the public are advised to move their clocks one hour ahead at 2am on Sunday November 4. The daylight saving period will end at 3am on Sunday January 13, 2019. Fiji rules in tzdata2018e.tar.gz: There is a need to change the NON DST time from 14th Jan to 13th Jan. Can a new tzdata be generated for Fiji Islands. Rule Fiji 2014 max - Nov Sun>=1 2:00 1:00 - Rule Fiji 2015 max - Jan Sun>=14 3:00 0 - Thanks, Raymond Kumar Head of Billing & Products +679-7015315 ________________________________ 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 9

Re: [tz] EU Public Consultation on summertime arrangements
by Pierpaolo Bernardi July 11, 2018

July 11, 2018

Not time related. Only for pedantry sake: at the border between San Marino and Italy there *are* controls, by the Italian police. This is due to different tax laws in the two countries, which would make shopping in San Marino very convenient for Italy residents, if they weren't controlled when exiting from RSM for any good bought in RSM, and forced to pay due taxes. FWIW Il giorno 11 luglio 2018, alle ore 09:08, John Wilcock <john(a)tradoc.fr> ha scritto: Le 11/07/2018 à 00:05, Brian Inglis a écrit : > Most people are probably not that aware of European geography [...] Taking the world as a whole, you are no doubt correct, but most of the people at the EU who will be reading Paul's submission will be perfectly aware of European geography! >> I don't see the relevance of "Schengen area" - all current and potential >> Schengen area countries are either EU or EEA/EFTA members. > The Schengen Area also includes non-EU/EEA/EFTA countries Monaco, San Marino, > and the Vatican, which have not signed the Schengen agreement, but have no > borders, so are de facto included. While these three countries are indeed de facto within the Schengen area due to the lack of border *controls* — they do still have borders ;-) — it still seems (at least to me as a European) very odd to mention Schengen purely in order to include its *non*-signatories, especially as the next item in the list is in any case the all-inclusive "other countries not in the EU". -- John

1 0

(no subject)
by Ashish Ahmed July 10, 2018

July 10, 2018

Confirm

1 0

tz-art suggestion
by Steve Jones July 6, 2018

July 6, 2018

Not sure how this was missed, having passed its third birthday, but probably deserves a mention in tz-art: "Daylight Saving Time: How is this still a thing?" https://www.youtube.com/watch?v=br0NW9ufUUw Regards, Steve Jones [image: Emacs!]

3 2

strftime and nonnormalized dates/times
by scs＠eskimo.com July 5, 2018

July 5, 2018

I have a question about the strftime function. This is not related to time zones per se, but there are a lot of date/time programming experts here, and of course there's a reference implementation of strftime in tzcode. [Full disclosure: I am posting the same question to StackOverflow: https://stackoverflow.com/questions/51145727/ .] Most definitions of the %H, %M, and %S specifiers (including those in the ANSI/ISO C Standards) contain language like %H is replaced by the hour (24-hour clock) as a decimal number (00-23). Now, that little notation "(00-23)" at the end tells you the range of numbers you're going to see *if the struct tm you're printing was just created by localtime or gmtime*. My question concerns the presence or absence of a requirement that the struct tm being referenced by strftime *must* have been one just generated by localtime or gmtime. I don't think there's such a requirement, but if there isn't, those notations "(00-23)" and "(00-59)" don't really have any normative implications for strftime -- they're more of a misplaced requirement on the values generated by localtime and gmtime. But if strftime doesn't restrict the ranges of the various struct tm fields to their "normal" values, it makes me wonder how much latitude a push-the-boundaries programmer actually has when calling strftime. Are the values as unlimited as they are when calling, say, mktime? To make the question more concrete, it came to me when I found myself writing this code: time_t dt = t2 - t1; struct tm *tmp = gmtime(&dt); if(dt > 86400) tmp->tm_hour += dt / 86400 * 24; strftime(etbuf, sizeof(etbuf), "elapsed: %H:%M:%S", tmp); That is, I'm subtracting two times, and letting gmtime and strftime convert the difference to HH:MM:SS format for me. But if the time delta was more than a day, I'm not printing it as days; I'm just lumping it in with the hours (which, it's true, might end up being a very large number if there were months or years between t1 and t2). So, language lawyer question: Is this legal and portable? When calling strftime, are tm_hour, tm_min, and the rest limited to their normal ranges, or not? (Yes, I've tried it, and nonnormalized values work -- not at all surprisingly -- as expected under the popular implementations, but that's not the question.)

4 6

African Timezones
by Robin Roos July 4, 2018

July 4, 2018

Hi Folks, I am using a Java platform (hosted on Linux and on Windows) in which I find some expected timezones to be missing. I write to enquire whether they are defined at IANA and, if not, whether they can be added. The timezones in question are as follows: Africa/Praia (capital city of Cabo Verde, also known also as Cape Verde) = UTC-1 CVT (Cabo Verde Time) = UTC-1 (one hour West of Greenwich) WAT (West Africa Time) = UTC+1 (one hour East of Greenwich) CAT (Central Africa Time) = UTC+2 (two hours East of Greenwich) EAT (East Africa Time) = UTC+3 (three hours East of Greenwich) My source for this information is: https://www.worldtimezone.com/time-africa24.php Many thanks, Robin.

2 2

"time zone" vs "timezone" in documentation
by Paul Eggert July 4, 2018

July 4, 2018

[I am cc'ing this to the tz mailing list (and changing the subject line) to give tz readers a heads-up about the terminology issue. The question here is: should tzdb man pages say "time zone" or "timezone"? For context please see Michael Kerrisk's email <https://marc.info/?m=152964652828320>, which says: > When I inherited the project, the pages used a mixture of "time zone" > and "timezone", with the former predominant. I nevertheless > standardized on the latter, and although I don't recall for sure, I > suspect it was because that is the spelling used in POSIX. (As an > aside, there's an argument that--because POSIX--tzdb might want to > consider switching spellings.) I'm not religious about the particular > choice (although I have naturally now got used to the particular > choice I made some years ago), but I did make that choice because I > want consistency within the project, and I'm reluctant to introduce > inconsistency. and my response <https://marc.info/?m=152964676331902>, which says: > I deferred to POSIX for "timestamp" versus "time stamp", but > "timezone" is a bridge too far for me. ] On second thought, perhaps I was too hasty. We could distinguish "time zone" in the usual English-language sense (a set of geographic locations that currently share the same standard time offset from UTC) from "timezone" in the POSIX sense (a history and predicted future of UTC offsets, abbreviations and isdst flags). If so, the tzdb documentation could be more careful about using "time zone" for the former and "timezone" for the latter, and this would make for fewer changes to the GNU/Linux man-pages for tzdb. I can look into this and propose an updated set of tzdb-related patches accordingly. If I were designing the terminology from scratch, I wouldn't specify two nearly-identical phrases "time zone" and "timezone" to mean such different things. However, the phrases do have the advantage of existing practice (common English usage and POSIX, respectively).

9 11

[PROPOSED] * tz-link.html (Precision timekeeping): Mention Huygens.
by Paul Eggert June 29, 2018

June 29, 2018

--- tz-link.html | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tz-link.html b/tz-link.html index 548fbba..7ed1efd 100644 --- a/tz-link.html +++ b/tz-link.html @@ -813,11 +813,15 @@ title="Network Time Protocol">NTP</abbr>: The Network Time Protocol</a> (Internet <abbr>RFC</abbr> 5905) discusses how to synchronize clocks of Internet hosts.</li> +<li>The <a href="https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf"><font style="font-variant: small-caps">Huygens</font></a> +family of software algorithms can achieve accuracy to a few tens of +nanoseconds in scalable server farms without special hardware.</li> <li>The <a href="https://www.nist.gov/intelligent-systems-division/ieee-1588">Precision Time Protocol</a> (<abbr title="Institute of Electrical and Electronics Engineers">IEEE</abbr> 1588) -can achieve submicrosecond clock accuracy on a local area network.</li> +can achieve submicrosecond clock accuracy on a local area network +with special-purpose hardware.</li> <li><a href="https://tools.ietf.org/html/rfc4833">Timezone Options for <abbr title="Dynamic Host Configuration Protocol">DHCP</abbr></a> -- 2.17.1

1 0

California will vote on permanent daylight
by Steve Allen June 29, 2018

June 29, 2018

The governor approved AB 807 https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201720… Daylight time in California was established by the voters, and must be repealed by the voters, so nothing happens until after an election decides whether to ask the state legislature to consider how permanent daylight time could be achieved. -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

1 0

[PROPOSED] Make Makefile safer for parallelism
by Paul Eggert June 27, 2018

June 27, 2018

Although this still does not fully work with GNU Make, it’s better than what we had. * Makefile (TIME_T_ALTERNATIVES_HEAD) (TIME_T_ALTERNATIVES_TAIL): New macros. (TIME_T_ALTERNATIVES): Use them. (TZS_CUTOFF_FLAG): New macro. ($(ZDS)): Use it, so that submakes can use -t instead of -c cutoffs. (EIGHT_YARDS): New macro. (ENCHILADA): Use it. (INSTALL_DATA_DEPS, TZS_NEW_DEPS): New macros. (install_data, posix_only, right_only, posix_packrat, $(TZS_NEW)): Use them to avoid duplicate work with GNU make -j. ($(TZS_NEW), check_zishrink_posix, check_zishrink_right, check_public) (check_time_t_alternatives): Use rule-specific temporary directories so that other rules can run in parallel. ($(TZS_NEW)): Check for sort failure. ($(TZS)): Simply touch it if it doesn’t exist, so that it’s empty. (check_tzs): Treat empty $(TZS) as nonexistent. (check_character_set, check_white_space, check_name_lengths) (check_sorted, check_links, check_tables, check_tzs, check_web) (check_zishrink, check_public): No longer phony. (check_zishrink_posix, check_zishrink_right) (typecheck_long_long, typecheck_unsigned): New rules, so that they can be done in parallel. (clean_misc): Clean the timestamp files that are now made due to rules no longer being phony. (set-timestamps.out): Do not set timestamp of $(TZS). (set-tzs-timestamp.out): New rule. (check_time_t_alternatives): Break into subrules, one for each alternative, so that they can be done in parallel. (tarballs, rearguard_tarballs, traditional_tarballs) (signatures, rearguard_signatures, traditional_signatures): Depend on set-timestamps.out and rearguard.zi. (tzdb-$(VERSION).tar.lz): Depend on set-tzs-timestamp.out. (TYPECHECK_CFLAGS): New macro. --- Makefile | 240 +++++++++++++++++++++++++++++++++++++-------------------------- 1 file changed, 142 insertions(+), 98 deletions(-) diff --git a/Makefile b/Makefile index 2289dff..29058e5 100644 --- a/Makefile +++ b/Makefile @@ -106,8 +106,10 @@ MANDIR = $(TOPDIR)/$(USRSHAREDIR)/man LIBDIR = $(TOPDIR)/$(USRDIR)/lib -# Types to try, as an alternative to time_t. int64_t should be first. -TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t +# Types to try, as an alternative to time_t. +TIME_T_ALTERNATIVES = $(TIME_T_ALTERNATIVES_HEAD) $(TIME_T_ALTERNATIVES_TAIL) +TIME_T_ALTERNATIVES_HEAD = int64_t +TIME_T_ALTERNATIVES_TAIL = int32_t uint32_t uint64_t # What kind of TZif data files to generate. # (TZif is the binary time zone data format that zic generates.) @@ -493,11 +495,14 @@ AWK_SCRIPTS= checklinks.awk checktab.awk leapseconds.awk \ ziguard.awk zishrink.awk MISC= $(AWK_SCRIPTS) zoneinfo2tdf.pl TZS_YEAR= 2050 +TZS_CUTOFF_FLAG= -c $(TZS_YEAR) TZS= to$(TZS_YEAR).tzs TZS_NEW= to$(TZS_YEAR)new.tzs TZS_DEPS= $(PRIMARY_YDATA) asctime.c localtime.c \ private.h tzfile.h zdump.c zic.c -ENCHILADA= $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) $(TZS) tzdata.zi +# EIGHT_YARDS is just a yard short of the whole ENCHILADA. +EIGHT_YARDS = $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) tzdata.zi +ENCHILADA = $(EIGHT_YARDS) $(TZS) # Consult these files when deciding whether to rebuild the 'version' file. # This list is not the same as the output of 'git ls-files', since @@ -606,14 +611,16 @@ INSTALLARGS = \ YEARISTYPE='$(YEARISTYPE)' \ ZIC='$(ZIC)' +INSTALL_DATA_DEPS = zic leapseconds yearistype tzdata.zi + # 'make install_data' installs one set of TZif files. -install_data: zic leapseconds yearistype tzdata.zi +install_data: $(INSTALL_DATA_DEPS) $(ZIC_INSTALL) tzdata.zi -posix_only: +posix_only: $(INSTALL_DATA_DEPS) $(MAKE) $(INSTALLARGS) LEAPSECONDS= install_data -right_only: +right_only: $(INSTALL_DATA_DEPS) $(MAKE) $(INSTALLARGS) LEAPSECONDS='-L leapseconds' \ install_data @@ -640,7 +647,7 @@ posix_right: posix_only # This obsolescent rule is present for backwards compatibility with # tz releases 2014g through 2015g. It should go away eventually. -posix_packrat: +posix_packrat: $(INSTALL_DATA_DEPS) $(MAKE) $(INSTALLARGS) PACKRATDATA=backzone posix_only zones: $(REDO) @@ -651,29 +658,33 @@ ZDS = dummy.zd # Rule used only by submakes invoked by the $(TZS_NEW) rule. # It is separate so that GNU 'make -j' can run instances in parallel. $(ZDS): zdump - ./zdump -i -c $(TZS_YEAR) '$(wd)/'$$(expr $@ : '$.*$.zd') >$@ - -$(TZS_NEW): tzdata.zi zdump zic - rm -fr tzs.dir - mkdir tzs.dir - $(zic) -d tzs.dir tzdata.zi + ./zdump -i $(TZS_CUTOFF_FLAG) '$(wd)/'$$(expr $@ : '$.*$.zd') \ + >$@ + +TZS_NEW_DEPS = tzdata.zi zdump zic +$(TZS_NEW): $(TZS_NEW_DEPS) + rm -fr tzs$(TZS_YEAR).dir + mkdir tzs$(TZS_YEAR).dir + $(zic) -d tzs$(TZS_YEAR).dir tzdata.zi $(AWK) '/^L/{print "Link\t" $$2 "\t" $$3}' \ tzdata.zi | LC_ALL=C sort >$@.out wd=`pwd` && \ - set x `$(AWK) '/^Z/{print "tzs.dir/" $$2 ".zd"}' tzdata.zi \ + x=`$(AWK) '/^Z/{print "tzs$(TZS_YEAR).dir/" $$2 ".zd"}' \ + tzdata.zi \ | LC_ALL=C sort -t . -k 2,2` && \ + set x $$x && \ shift && \ ZDS=$$* && \ - $(MAKE) wd="$$wd" TZS_YEAR=$(TZS_YEAR) ZDS="$$ZDS" $$ZDS && \ - sed 's,^TZ=".*tzs\.dir/,TZ=",' $$ZDS >>$@.out - rm -fr tzs.dir + $(MAKE) wd="$$wd" TZS_CUTOFF_FLAG="$(TZS_CUTOFF_FLAG)" \ + ZDS="$$ZDS" $$ZDS && \ + sed 's,^TZ=".*\.dir/,TZ=",' $$ZDS >>$@.out + rm -fr tzs$(TZS_YEAR).dir mv $@.out $@ -# If $(TZS) does not already exist (e.g., old-format tarballs), create it. -# If it exists but 'make check_tzs' fails, a maintainer should inspect the +# If $(TZS) exists but 'make check_tzs' fails, a maintainer should inspect the # failed output and fix the inconsistency, perhaps by running 'make force_tzs'. $(TZS): - $(MAKE) force_tzs + touch $@ force_tzs: $(TZS_NEW) cp $(TZS_NEW) $(TZS) @@ -718,12 +729,14 @@ check_character_set: $(ENCHILADA) leapseconds yearistype.sh zone.tab && \ ! grep -Env $(OK_LINE) $(ENCHILADA); \ } + touch $@ check_white_space: $(ENCHILADA) patfmt=' \t|[\f\r\v]' && pat=`printf "$$patfmt\\n"` && \ ! grep -En "$$pat" $(ENCHILADA) ! grep -n '[[:space:]]$$' \ $$(ls $(ENCHILADA) | grep -Fvx leap-seconds.list) + touch $@ PRECEDES_FILE_NAME = ^(Zone|Link[[:space:]]+[^[:space:]]+)[[:space:]]+ FILE_NAME_COMPONENT_TOO_LONG = \ @@ -732,6 +745,7 @@ FILE_NAME_COMPONENT_TOO_LONG = \ check_name_lengths: $(TDATA_TO_CHECK) backzone ! grep -En '$(FILE_NAME_COMPONENT_TOO_LONG)' \ $(TDATA_TO_CHECK) backzone + touch $@ CHECK_CC_LIST = { n = split($$1,a,/,/); for (i=2; i<=n; i++) print a[1], a[i]; } @@ -744,52 +758,61 @@ check_sorted: backward backzone iso3166.tab zone.tab 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 $(AWK) -f checklinks.awk $(TDATA_TO_CHECK) $(AWK) -f checklinks.awk tzdata.zi + touch $@ check_tables: checktab.awk $(PRIMARY_YDATA) $(ZONETABLES) for tab in $(ZONETABLES); do \ $(AWK) -f checktab.awk -v zone_table=$$tab $(PRIMARY_YDATA) \ || exit; \ done + touch $@ check_tzs: $(TZS) $(TZS_NEW) - diff -u $(TZS) $(TZS_NEW) + if test -s $(TZS); then \ + diff -u $(TZS) $(TZS_NEW); \ + else \ + cp $(TZS_NEW) $(TZS); \ + fi + touch $@ # This checks only the HTML 4.01 strict page. # To check the the other pages, use <https://validator.w3.org/>. check_web: tz-how-to.html $(VALIDATE_ENV) $(VALIDATE) $(VALIDATE_FLAGS) tz-how-to.html + touch $@ # Check that zishrink.awk does not alter the data, and that ziguard.awk # preserves main-format data. -check_zishrink: zic leapseconds $(PACKRATDATA) $(TDATA) \ - $(DATAFORM).zi tzdata.zi - for type in posix right; do \ - mkdir -p time_t.dir/$$type time_t.dir/$$type-t \ - time_t.dir/$$type-shrunk && \ - case $$type in \ - right) leap='-L leapseconds';; \ - *) leap=;; \ - esac && \ - $(ZIC) $$leap -d time_t.dir/$$type $(DATAFORM).zi && \ +check_zishrink: check_zishrink_posix check_zishrink_right +check_zishrink_posix check_zishrink_right: \ + zic leapseconds $(PACKRATDATA) $(TDATA) $(DATAFORM).zi tzdata.zi + rm -fr $@.dir $(a)-t.dir $(a)-shrunk.dir + mkdir $@.dir $(a)-t.dir $(a)-shrunk.dir + case $@ in \ + *_right) leap='-L leapseconds';; \ + *) leap=;; \ + esac && \ + $(ZIC) $$leap -d $@.dir $(DATAFORM).zi && \ + $(ZIC) $$leap -d $(a)-shrunk.dir tzdata.zi && \ case $(DATAFORM) in \ main) \ - $(ZIC) $$leap -d time_t.dir/$$type-t $(TDATA) && \ + $(ZIC) $$leap -d $(a)-t.dir $(TDATA) && \ $(AWK) '/^Rule/' $(TDATA) | \ - $(ZIC) $$leap -d time_t.dir/$$type-t - \ - $(PACKRATDATA) && \ - diff -r time_t.dir/$$type time_t.dir/$$type-t;; \ - esac && \ - $(ZIC) $$leap -d time_t.dir/$$type-shrunk tzdata.zi && \ - diff -r time_t.dir/$$type time_t.dir/$$type-shrunk || exit; \ - done - rm -fr time_t.dir + $(ZIC) $$leap -d $(a)-t.dir - $(PACKRATDATA) && \ + diff -r $@.dir $(a)-t.dir;; \ + esac + diff -r $@.dir $(a)-shrunk.dir + rm -fr $@.dir $(a)-t.dir $(a)-shrunk.dir + touch $@ clean_misc: - rm -f core *.o *.out \ + rm -f *.o *.out $(TIME_T_ALTERNATIVES) \ + check_* core typecheck_* \ date tzselect version.h zdump zic yearistype libtz.a clean: clean_misc rm -fr *.dir *.zi tzdb-*/ $(TZS_NEW) @@ -826,10 +849,10 @@ $(MANTXTS): workman.sh # If git or GNU 'touch' 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: $(ENCHILADA) +set-timestamps.out: $(EIGHT_YARDS) rm -f $@ if (type git) >/dev/null 2>&1 && \ - files=`git ls-files $(ENCHILADA)` && \ + files=`git ls-files $(EIGHT_YARDS)` && \ touch -md @1 test.out; then \ rm -f test.out && \ for file in $$files; do \ @@ -847,62 +870,74 @@ set-timestamps.out: $(ENCHILADA) exit; \ done touch -cmr `ls -t $(TZDATA_ZI_DEPS) | sed 1q` tzdata.zi - touch -cmr `ls -t $(TZS_DEPS) | sed 1q` $(TZS) touch -cmr `ls -t $(VERSION_DEPS) | sed 1q` version touch $@ +set-tzs-timestamp.out: $(TZS) + touch -cmr `ls -t $(TZS_DEPS) | sed 1q` $(TZS) + touch $@ # The zics below ensure that each data file can stand on its own. # We also do an all-files run to catch links to links. -check_public: - $(MAKE) maintainer-clean - $(MAKE) CFLAGS='$(GCC_DEBUG_FLAGS)' ALL - mkdir -p public.dir - for i in $(TDATA_TO_CHECK) tzdata.zi; do \ - $(zic) -v -d public.dir $$i 2>&1 || exit; \ +check_public: $(VERSION_DEPS) + rm -fr public.dir + mkdir public.dir + ln $(VERSION_DEPS) public.dir + cd public.dir && $(MAKE) CFLAGS='$(GCC_DEBUG_FLAGS)' ALL + for i in $(TDATA_TO_CHECK) public.dir/tzdata.zi; do \ + public.dir/zic -v -d public.dir/zoneinfo $$i 2>&1 || exit; \ done - $(zic) -v -d public.dir $(TDATA_TO_CHECK) + public.dir/zic -v -d public.dir/zoneinfo-all $(TDATA_TO_CHECK) rm -fr public.dir + touch $@ # Check that the code works under various alternative # implementations of time_t. -check_time_t_alternatives: - if diff -q Makefile Makefile 2>/dev/null; then \ - quiet_option='-q'; \ - else \ - quiet_option=''; \ - fi && \ +check_time_t_alternatives: $(TIME_T_ALTERNATIVES) +$(TIME_T_ALTERNATIVES_TAIL): $(TIME_T_ALTERNATIVES_HEAD) +$(TIME_T_ALTERNATIVES): $(VERSION_DEPS) + rm -fr $@.dir + mkdir $@.dir + ln $(VERSION_DEPS) $@.dir + case $@ in \ + int32_t) range=-2147483648,2147483648;; \ + u*) range=0,4294967296;; \ + *) range=-4294967296,4294967296;; \ + esac && \ wd=`pwd` && \ zones=`$(AWK) '/^[^#]/ { print $$3 }' <zone1970.tab` && \ - for type in $(TIME_T_ALTERNATIVES); do \ - mkdir -p time_t.dir/$$type && \ - $(MAKE) clean_misc && \ - $(MAKE) TOPDIR="$$wd/time_t.dir/$$type" \ - CFLAGS='$(CFLAGS) -Dtime_tz='"'$$type'" \ + if test $@ = $(TIME_T_ALTERNATIVES_HEAD); then \ + range_target=; \ + else \ + range_target=to$$range.tzs; \ + fi && \ + (cd $@.dir && \ + $(MAKE) TOPDIR="$$wd/$@.dir" \ + CFLAGS='$(CFLAGS) -Dtime_tz='"'$@'" \ REDO='$(REDO)' \ - install && \ - diff $$quiet_option -r \ - time_t.dir/int64_t/etc \ - time_t.dir/$$type/etc && \ - diff $$quiet_option -r \ - time_t.dir/int64_t/usr/share \ - time_t.dir/$$type/usr/share && \ - case $$type in \ - int32_t) range=-2147483648,2147483647;; \ - uint32_t) range=0,4294967296;; \ - int64_t) continue;; \ - *u*) range=0,10000000000;; \ - *) range=-10000000000,10000000000;; \ - esac && \ - echo checking $$type zones ... && \ - time_t.dir/int64_t/usr/bin/zdump -V -t $$range $$zones \ - >time_t.dir/int64_t.out && \ - time_t.dir/$$type/usr/bin/zdump -V -t $$range $$zones \ - >time_t.dir/$$type.out && \ - diff -u time_t.dir/int64_t.out time_t.dir/$$type.out \ - || exit; \ - done - rm -fr time_t.dir + D=$$wd/$@.dir \ + TZS_YEAR="$$range" TZS_CUTOFF_FLAG="-t $$range" \ + install $$range_target) && \ + test $@ = $(TIME_T_ALTERNATIVES_HEAD) || { \ + (cd $(TIME_T_ALTERNATIVES_HEAD).dir && \ + $(MAKE) TOPDIR="$$wd/$@.dir" \ + TZS_YEAR="$$range" TZS_CUTOFF_FLAG="-t $$range" \ + D=$$wd/$@.dir \ + to$$range.tzs) && \ + diff -u $(TIME_T_ALTERNATIVES_HEAD).dir/to$$range.tzs \ + $@.dir/to$$range.tzs && \ + if diff -q Makefile Makefile 2>/dev/null; then \ + quiet_option='-q'; \ + else \ + quiet_option=''; \ + fi && \ + diff $$quiet_option -r $(TIME_T_ALTERNATIVES_HEAD).dir/etc \ + $@.dir/etc && \ + diff $$quiet_option -r \ + $(TIME_T_ALTERNATIVES_HEAD).dir/usr/share \ + $@.dir/usr/share; \ + } + touch $@ TRADITIONAL_ASC = \ tzcode$(VERSION).tar.gz.asc \ @@ -913,7 +948,8 @@ ALL_ASC = $(TRADITIONAL_ASC) $(REARGUARD_ASC) \ tzdb-$(VERSION).tar.lz.asc tarballs rearguard_tarballs traditional_tarballs \ -signatures rearguard_signatures traditional_signatures: version +signatures rearguard_signatures traditional_signatures: \ + version set-timestamps.out rearguard.zi VERSION=`cat version` && \ $(MAKE) VERSION="$$VERSION" $@_version @@ -963,7 +999,7 @@ tzdata$(VERSION)-rearguard.tar.gz: rearguard.zi set-timestamps.out gzip $(GZIPFLAGS)) >$@.out mv $@.out $@ -tzdb-$(VERSION).tar.lz: set-timestamps.out +tzdb-$(VERSION).tar.lz: set-timestamps.out set-tzs-timestamp.out rm -fr tzdb-$(VERSION) mkdir tzdb-$(VERSION) ln $(ENCHILADA) tzdb-$(VERSION) @@ -979,14 +1015,24 @@ tzdb-$(VERSION).tar.lz.asc: tzdb-$(VERSION).tar.lz $(ALL_ASC): gpg2 --armor --detach-sign $? -typecheck: - $(MAKE) clean - for i in "long long" unsigned; \ - do \ - $(MAKE) CFLAGS="-DTYPECHECK -D__time_t_defined -D_TIME_T \"-Dtime_t=$$i\"" ; \ - ./zdump -v Europe/Rome ; \ - $(MAKE) clean ; \ - done +TYPECHECK_CFLAGS = $(CFLAGS) -DTYPECHECK -D__time_t_defined -D_TIME_T +typecheck: typecheck_long_long typecheck_unsigned +typecheck_long_long typecheck_unsigned: $(VERSION_DEPS) + rm -fr $@.dir + mkdir $@.dir + ln $(VERSION_DEPS) $@.dir + cd $@.dir && \ + case $@ in \ + *_long_long) i="long long";; \ + *_unsigned ) i="unsigned" ;; \ + esac && \ + typecheck_cflags='' && \ + $(MAKE) \ + CFLAGS="$(TYPECHECK_CFLAGS) \"-Dtime_t=$$i\"" \ + TOPDIR="`pwd`" \ + install + $@.dir/zdump -i -c 1970,1971 Europe/Rome + touch $@ zonenames: tzdata.zi @$(AWK) '/^Z/ { print $$2 } /^L/ { print $$3 }' tzdata.zi @@ -1002,9 +1048,7 @@ zic.o: private.h tzfile.h version.h .KEEP_STATE: .PHONY: ALL INSTALL all -.PHONY: check check_character_set check_links check_name_lengths -.PHONY: check_public check_sorted check_tables -.PHONY: check_time_t_alternatives check_tzs check_web check_white_space +.PHONY: check check_time_t_alternatives .PHONY: check_zishrink .PHONY: clean clean_misc dummy.zd force_tzs .PHONY: install install_data maintainer-clean names -- 2.7.4

1 0

Europe/Zaporozhye
by Paul G June 26, 2018

June 26, 2018

Recently during a conversation about the tzdb and a colleague of mine mentioned that it seems to be a strange outlier that Europe/Zaporozhye has its own zone, since Zaporozh'ye is not a particularly large city (it's quite close to Donetsk, which he deemed more likely to be the major city in the area). I looked at the source code and saw that it mentions: # Zaporozh'ye and eastern Lugansk oblasts observed DST 1990/1991. (https://github.com/eggert/tz/blob/master/europe#L3850) He seemed to think that this was an absurd notion and that more or less any city in Ukraine would either follow Moscow time or Crimea time, but none of them would have yet a third history. It does seem a bit strange (though perfectly consistent with the weird nonsense everyone else gets up to) that only Zaporozh'ye and eastern Lugansk would follow a different time zone than their immediate neighbors - these are not even contiguous regions. In the timezone-boundary-builder project (https://github.com/evansiroky/timezone-boundary-builder) it seems that only Zaporozhia Oblast is included in the shapefile. We did a cursory search for references (including in the archives of this mailing list and the git history) in English and Russian and couldn't find any reference to Zaporozhia and Lugansk having a different time zone that wasn't derived from this project. So, questions about this: 1. Can anyone point to a reference to the fact that these regions used a different time zone than their neighbors? 2. If no reference is handy, does anyone know on what basis this zone was included in the database in the first place? 3. Is there any clarification as to the geographic extent of the zone? Does it cover Donetsk as well? What part of Lugansk counts as "eastern Lugansk"? Best, Paul

2 1

redundant Rule in proposal for Macao
by Michael H Deckers June 26, 2018

June 26, 2018

In Paul Eggert's proposal for Macao from 2018-05-10, we find +Rule Macau 1949 1951 - Apr Sat>=1 23:00s 1:00 D +Rule Macau 1951 only - Mar 31 23:00s 1:00 D with two successive switches to summer time at 1951-03-31 and 1951-04-07. The later switch has no effect, and can easily be omitted: +Rule Macau 1949 1950 - Apr Sat>=1 23:00s 1:00 D There are several similar cases in tzdb where the specification contains redundant data. For instance, Rule HK 1965 1976 - Apr Sun>=16 3:30 1:00 S Rule HK 1973 only - Dec 30 3:30 1:00 S with two successive switches to summer time at 1973-12-30 and 1974-04-21, the latter having no effect. In this case, removal of the redundancy would require an addtional Rule line, so concise notation could be construed as a reason for retaining the redundancy. Do we have a guideline for such cases? Michael Deckers.

2 1

Re: [tz] [PROPOSED] Use "PST/PDT" for Philippine time
by Paul Eggert June 25, 2018

June 25, 2018

Michael H Deckers wrote: > Fine if this were a generally applied guideline -- but it is not, > see eg America/Adak, Indonesia, and many others. When is this guideline > applied, and when not? The guideline is supposed to be applied reasonably consistently for clear-cut cases such as the Philippines. Alaska and Indonesia are more complicated, since they are not merely a question of what's the name of a time zone; they are also a question of time zone boundaries moving, and where it's not so clear what is being named. For example, a historian today would be unlikely to write "Sitka observed Alaska Standard Time in 1984" because in 1984 the Alaska time zone boundaries were quite different and Sitka was then in the geographically small part of Alaska that was in the same time zone as the Yukon. Unfortunately I don't see a good solution for these more-complicated cases, and am reluctant to change the data if it's likely this would introduce as much or more confusion than it would alleviate. > And all that does not justify the resurrection of an invented abbreviation. First, for the Phillippines it's no longer an abbreviation that exists only because we invented it. It's taken on a life of its own in reliable sources and in national law. And second, I doubt whether these sources got "PST" from tzdb, since tzdb has been using "PHST" for over two decades and used "PST" only briefly before that. Most likely it was independent reinvention.

3 2

Re: [tz] [IANA #985615] Sudan Time Zone change
by ahmed.atyya＠ntc.gov.sd June 25, 2018

June 25, 2018

Dear Sir/ Madam we would like to inform you that the Republic of Sudan is going to change the time zone from (GMT + 3:00) to (GMT+ 2:00) starting from Wednesday 1 November 2017. this is for your information and action if required. Best Regards Dear Mr. Paul We would like to inform you as TZ coordinator that the Republic of Sudan is planning to change its time zone from GMT+ 3:00 to GMT +2:00 ( The original time zone ) starting from 1 November 2017 Please if you can update time zone data base Or you you can tell us what action is needed from Sudan government Best Regards Ahmed Atyya Head of Numbering Section National Telecomm. Corporation – Sudan Phone: +249123499988 Email: ahmed.atyya@ ----- Original Message ----- From: Sabrina Tanamal via RT <iana-questions(a)iana.org> To: ahmed atyya <ahmed.atyya(a)ntc.gov.sd> Sent: Tue, 17 Oct 2017 01:33:06 +0300 (EAT) Subject: [IANA #985615] Sudan Time Zone change Dear Ahmed, Thank you for contacting us. We host the Time Zone Database, but updates are made by the Time Zone Coordinator in consultation with the Time Zone mailing list, in accordance with RFC 6557. Questions about the contents of the database should be sent to the mailing list. For mailing list archives and subscription information, please see http://www.iana.org/time-zones Best regards, Sabrina Tanamal IANA Services Specialist On Mon Oct 16 09:55:06 2017, ahmed.atyya(a)ntc.gov.sd wrote: > Dear Sir/ Madam > > > > > > we would like to inform you that the Republic of Sudan is going to > change the time zone from (GMT + 3:00) to (GMT+ 2:00) starting from > Wednesday 1 November 2017. > > > this is for your information and action if required. > > > > > > Best Regards > > > > > > Ahmed Atyya > > > Head of Numbering Section > > National Telecomm. Corporation – Sudan > > Phone: +249123499988 > > Email: ahmed.atyya(a)ntc.gov.sd

6 19

Re: [tz] [PROPOSED] Use "PST/PDT" for Philippine time
by Paul Eggert June 24, 2018

June 24, 2018

Michael H Deckers wrote: > My second point was about the abbreviation "PDT", as proposed > for Manila summer time (which you have called "invented"), > not the abbreviation "PST" (which you have not called > "invented" in your proposal). Ah, sorry, I misunderstood. With "PDT" I was attempting to follow this guideline in theory.html: > Use a consistent style in a tz region's history. > For example, if history tends to use numeric > abbreviations and a particular entry could go either way, use a > numeric abbreviation. Since most Philippine history used an alphabetic abbreviation, I thought it better to do so with daylight-saving time too. This is consistent with Hong Kong, Taiwan and Korea, all of which have "JST" for time during Japanese occupation because they use alphabetic abbreviations now, and it is in contrast to other locations that use "+09" for timestamps under Japanese occupation. We have competing guidelines here: "be consistent" and "don't invent abbreviations", and it's a judgment call as to which is more important. PS. Many of those "+09"s are sheer guesswork by Shanks, but that's a different story....

1 0

Philippine Standard Time
by Paul Goyette June 23, 2018

June 23, 2018

In the Philippines, there is a national law, Republic Act No. 10535 which declares the official time here as "Philippine Standard Time". The act [1] even specifies use of PST as the abbreviation, although the FAQ provided by PAGASA [2] uses the "acronym PhST to distinguish it from the Pacific Standard Time (PST)." (Interestingly, the act does nothing to define the actual value of Philippine Standard Time; there is no UTC offset or other reference. It simply declares what the time is called, and instructs government agencies to coordinate with PAGASA for synchronization. :) There are references to "Section 6 of Batas Pambansa Bilang 8" [3] (which directs the adoption of the Metric System), but Section 6 merely delegates the task of establishing the definition of "second" to PAGASA. I've been unable so far to find any specific implementing regulation that establishes an official 8-hour offset from GMT.) Not long ago, the TZ database clean-up of "invented" abbreviations removed the PST abbreviation for Asia/Manila, leaving us with no abbreviation. Based on the existence of national law declaring Philippine Standard Time, and formally establishing the abbreviation/acronym, could we please get "PST" (or, if you prefer, "PhST") re-included into the next update of the TZDB? Thanks! References: [1] http://www.officialgazette.gov.ph/2013/05/15/republic-act-no-10535/ [2] https://www1.pagasa.dost.gov.ph/index.php/astronomy/philippine-standard-tim… [3] http://www.chanrobles.com/bataspambansabilang8.htm +------------------+--------------------------+----------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +------------------+--------------------------+----------------------------+

6 8

US daylight saving proposals in Texas, California, and Louisiana
by Paul Eggert June 19, 2018

June 19, 2018

This week the Republican Party of Texas is writing its official platform, which contains new planks that call for "abolishing daylight saving time and Texas Child Protective Services". (This quote is from McGaughy's report cited below.) The California State Senate approved a proposal Thursday to move California toward Mountain Standard Time all year (or permanent PDT, if you prefer). The measure would require voter approval in November, plus a second bill and federal approval. The basic idea is similar to the proposal in Florida that Arthur noted in March. Last month the Louisiana legislature overwhelmingly approved a resolution to study a proposal that presumably would also be similar to Florida's, in that Louisiana would move to Eastern Standard Time all year (or permanent CDT, if you prefer). Sources: Bacon-Blood L. Should Louisiana use Daylight Saving Time? State task force will evaluate the options. Times-Picayune. 2018-05-24. https://www.nola.com/politics/index.ssf/2018/05/la_task_force_will_study_me… Luna T. End of daylight saving time inches closer in California. Sacramento Bee. 2018-06-14. https://www.sacbee.com/news/politics-government/capitol-alert/article213187… McGaughy L. New Texas GOP platform calls for abolishing daylight saving, protecting Confederate monuments. Dallas Morning News. 2018-06-18. https://www.dallasnews.com/news/texas-politics/2018/06/16/vote-count-underw…

1 0

[PROPOSED] Merge some changes from man-pages project
by Paul Eggert June 19, 2018

June 19, 2018

Make some minor formatting changes to be more like man-pages. * tzfile.5: Break a line the same place that man-pages does. * zdump.8, zic.8: Use bold, not italics, for command and function names. Do not capitalize command names. Add a section header OPTIONS. Document --help. Fix some problems with fonts. Don’t quote "SEE ALSO", and don’t mention newctime(3). Put FILES before NOTES, and format a la man-pages. * zic.8: Also, do some fixes of our own, noticed while merging the above. Use real life US Rule, not an invented one. Write “UTOFF”, not “GMTOFF” (man-pages used “UTCOFF” but it’s not necessarily UTC either). Quote more carefully. --- tzfile.5 | 3 +- zdump.8 | 22 ++++++++------ zic.8 | 88 ++++++++++++++++++++++++++++++++------------------------ 3 files changed, 66 insertions(+), 47 deletions(-) diff --git a/tzfile.5 b/tzfile.5 index 13213d2..2e6c3aa 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -181,7 +181,8 @@ use two minor extensions to the POSIX TZ format, as described in .BR newtzset (3). First, the hours part of its transition times may be signed and range from \*-167 through 167 instead of the POSIX-required unsigned values -from 0 through 24. Second, DST is in effect all year if it starts +from 0 through 24. +Second, DST is in effect all year if it starts January 1 at 00:00 and ends December 31 at 24:00 plus the difference between daylight saving and standard time. .PP diff --git a/zdump.8 b/zdump.8 index 833dd54..92e9e62 100644 --- a/zdump.8 +++ b/zdump.8 @@ -18,16 +18,19 @@ zdump \- time zone dumper .. .ie \n(.g .ds - \f(CW-\fP .el ds - \- -.I Zdump -prints the current time in each +The +.B zdump +program prints the current time in each .I zonename named on the command line. -.PP -These options are available: +.SH OPTIONS .TP -.BI "\*-\*-version" +.B \*-\*-version Output version information and exit. .TP +.B \*-\*-help +Output short usage message and exit. +.TP .B \*-i .I "(This option is experimental: its behavior may change in future versions.)" Output a description of time intervals. For each @@ -68,7 +71,7 @@ except omit the times relative to the extreme time values. This generates output that is easier to compare to that of implementations with different time representations. .TP -.BI "\*-c " [loyear,]hiyear +.BI "\*-c " \fR[\fIloyear , \fR]\fIhiyear Cut off interval output at the given year(s). Cutoff times are computed using the proleptic Gregorian calendar with year 0 and with Universal Time (UT) ignoring leap seconds. @@ -80,7 +83,7 @@ of 1970 includes the transition. The default cutoff is .BR \*-500,2500 . .TP -.BI "\*-t " [lotime,]hitime +.BI "\*-t " \fR[\fIlotime , \fR]\fIhitime Cut off interval output at the given time(s), given in decimal seconds since 1970-01-01 00:00:00 Coordinated Universal Time (UTC). @@ -220,7 +223,8 @@ for newer and .q "UT" for older timestamps, partly because the exact date of the introduction of UTC is problematic. -.SH "SEE ALSO" -newctime(3), tzfile(5), zic(8) +.SH SEE ALSO +.BR tzfile (5), +.BR zic (8) .\" This file is in the public domain, so clarified as of .\" 2009-05-17 by Arthur David Olson. diff --git a/zic.8 b/zic.8 index 00d4267..3e33618 100644 --- a/zic.8 +++ b/zic.8 @@ -28,27 +28,30 @@ zic \- time zone compiler . ds : . ds - \- .\} -.I Zic -reads text from the file(s) named on the command line +The +.B zic +program reads text from the file(s) named on the command line and creates the time conversion information files specified in this input. If a .I filename is .q "\*-" , -the standard input is read. -.PP -These options are available: +standard input is read. +.SH OPTIONS .TP -.BI "\*-\*-version" +.B "\*-\*-version" Output version information and exit. .TP +.B \*-\*-help +Output short usage message and exit. +.TP .BI "\*-d " directory Create time conversion information files in the named directory rather than in the standard directory named below. .TP .BI "\*-l " timezone Use the given time zone as local time. -.I Zic +.B zic will act as if the input contained a link line of the form .sp .ti +.5i @@ -57,7 +60,7 @@ Link \fItimezone\fP localtime .BI "\*-p " timezone Use the given time zone's rules when handling POSIX-format time zone environment variables. -.I Zic +.B zic will act as if the input contained a link line of the form .sp .ti +.5i @@ -80,17 +83,17 @@ The input specifies a link to a link. .PP A year that appears in a data file is outside the range of years representable by -.IR time (2) +.BR time (2) values. .PP A time of 24:00 or more appears in the input. Pre-1998 versions of -.I zic +.B zic prohibit 24:00, and pre-2007 versions prohibit times greater than 24:00. .PP A rule goes past the start or end of the month. Pre-2004 versions of -.I zic +.B zic prohibit this. .PP The output file does not contain all the information about the @@ -102,7 +105,7 @@ represented. .PP The output contains data that may not be handled properly by client code designed for older -.I zic +.B zic output formats. These compatibility issues affect only timestamps before 1970 or after the start of 2038. .PP @@ -148,7 +151,7 @@ to the end of the line the sharp character appears on. White space characters and sharp characters may be enclosed in double quotes (") if they're to be used as part of a field. Any line that is blank (after comment stripping) is ignored. -Non-blank lines are expected to be of one of three types: +Nonblank lines are expected to be of one of three types: rule lines, zone lines, and link lines. .PP Names must be in English and are case insensitive. @@ -165,14 +168,14 @@ abbreviation must be unambiguous in context. A rule line has the form .nf .ti +.5i -.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00s\0\0'u +\w'1:00d\0\0'u +.ta \w'Rule\0\0'u +\w'NAME\0\0'u +\w'FROM\0\0'u +\w'1973\0\0'u +\w'TYPE\0\0'u +\w'Apr\0\0'u +\w'lastSun\0\0'u +\w'2:00w\0\0'u +\w'1:00d\0\0'u .sp Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S .sp For example: .ti +.5i .sp -Rule US 1967 1973 \*- Apr lastSun 2:00s 1:00d D +Rule US 1967 1973 \*- Apr lastSun 2:00w 1:00d D .sp .fi The fields that make up a rule line are: @@ -220,7 +223,7 @@ field. should be .q \*- and is present for compatibility with older versions of -.I zic +.B zic in which it could contain year types. .TP .B IN @@ -274,7 +277,7 @@ Recognized forms include: where hour 0 is midnight at the start of the day, and hour 24 is midnight at the end of the day. Although -.I zic +.B zic rounds times to the nearest integer second (breaking ties to the even integer), the fractions may be useful to other applications requiring greater precision. @@ -321,7 +324,7 @@ Negative offsets are allowed; in Ireland, for example, daylight saving time is observed in winter and has a negative offset relative to Irish Standard Time. The offset is merely added to standard time; for example, -.I zic +.B zic does not distinguish a 10:30 standard time plus an 0:30 .B SAVE from a 10:00 standard time plus a 1:00 @@ -347,8 +350,8 @@ A zone line has the form .sp .nf .ti +.5i -.ta \w'Zone\0\0'u +\w'Asia/Amman\0\0'u +\w'GMTOFF\0\0'u +\w'Jordan\0\0'u +\w'FORMAT\0\0'u -Zone NAME GMTOFF RULES FORMAT [UNTIL] +.ta \w'Zone\0\0'u +\w'Asia/Amman\0\0'u +\w'UTOFF\0\0'u +\w'Jordan\0\0'u +\w'FORMAT\0\0'u +Zone NAME UTOFF RULES FORMAT [UNTIL] .sp For example: .sp @@ -357,7 +360,7 @@ Zone Asia/Amman 2:00 Jordan EE%sT 2017 Oct 27 01:00 .sp .fi The fields that make up a zone line are: -.TP "\w'GMTOFF'u" +.TP "\w'UTOFF'u" .B NAME The name of the time zone. This is the name used in creating the time conversion information file for the @@ -369,7 +372,7 @@ or a file name component is a maximal substring that does not contain .q "/" . .TP -.B GMTOFF +.B UTOFF The amount of time to add to UT to get standard time in this zone. This field has the same format as the .B AT @@ -413,7 +416,10 @@ Alternatively, a slash (/) separates standard and daylight abbreviations. To conform to POSIX, a time zone abbreviation should contain only -alphanumeric ASCII characters, "+" and "\*-". +alphanumeric ASCII characters, +.q "+" +and +.q "\*-". .TP .B UNTIL The time at which the UT offset or the rule(s) change for a location. @@ -518,7 +524,7 @@ if the leap second time given by the other fields should be interpreted as local wall clock time. .SH "EXTENDED EXAMPLE" Here is an extended example of -.I zic +.B zic input, intended to illustrate many of its features. In this example, the EU rules are for the European Union and for its predecessor organization, the European Communities. @@ -539,8 +545,8 @@ Rule EU 1979 1995 \*- Sep lastSun 1:00u 0 \*- Rule EU 1981 max \*- Mar lastSun 1:00u 1:00 S Rule EU 1996 max \*- Oct lastSun 1:00u 0 \*- .sp -.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'GMTOFF\0\0'u +\w'0:34:08\0\0'u +\w'FORMAT\0\0'u -# Zone NAME GMTOFF RULES FORMAT [UNTIL] +.ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'0:34:08\0\0'u +\w'RULES\0\0'u +\w'FORMAT\0\0'u +# Zone NAME UTOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 \*- LMT 1853 Jul 16 0:29:46 \*- BMT 1894 Jun 1:00 Swiss CE%sT 1981 @@ -556,8 +562,9 @@ seconds east of UT until 1853-07-16 at 00:00, when the legal offset was changed to 7\(de\|26\(fm\|22.50\(sd; although this works out to 0:29:45.50, the input format cannot represent fractional seconds so it is rounded here. After 1894-06-01 at 00:00 the UT offset became one hour -and Swiss daylight saving rules (defined with lines beginning with "Rule -Swiss") apply. From 1981 to the present, EU daylight saving rules have +and Swiss daylight saving rules (defined with lines beginning with +.q "Rule Swiss") +apply. From 1981 to the present, EU daylight saving rules have applied, and the UTC offset has remained at one hour. .PP In 1941 and 1942, daylight saving time applied from the first Monday @@ -568,11 +575,21 @@ saving has begun on the last Sunday in March at 01:00 UTC. Until 1995 it ended the last Sunday in September at 01:00 UTC, but this changed to the last Sunday in October starting in 1996. .PP -For purposes of -display, "LMT" and "BMT" were initially used, respectively. Since +For purposes of display, +.q "LMT" +and +.q "BMT" +were initially used, respectively. Since Swiss rules and later EU rules were applied, the display name for the time zone has been CET for standard time and CEST for daylight saving time. +.SH FILES +.TP +.I /etc/localtime +Default local time zone file. +.TP +.I /usr/share/zoneinfo +Default time zone information directory. .SH NOTES For areas with more than two types of local time, you may need to use local standard time in the @@ -585,17 +602,14 @@ for a particular zone, a clock advance caused by the start of daylight saving coincides with and is equal to a clock retreat caused by a change in UT offset, -.IR zic +.B zic produces a single transition to daylight saving at the new UT offset (without any change in wall clock time). To get separate transitions use multiple zone continuation lines specifying transition instants using universal time. -.SH FILES -.ta \w'/usr/share/zoneinfo\0\0'u -/etc/localtime default local time zone file -/usr/share/zoneinfo default time zone information directory -.SH "SEE ALSO" -newctime(3), tzfile(5), zdump(8) +.SH SEE ALSO +.BR tzfile (5), +.BR zdump (8) .\" This file is in the public domain, so clarified as of .\" 2009-05-17 by Arthur David Olson. -- 2.17.1

1 0

[PROPOSED] Remove Big Bang hack
by Paul Eggert June 13, 2018

June 13, 2018

The Big Bang hack introduced in 2013d should no longer be needed, now that type 0 is the default type and types are reordered to make this happen. I.e., since we now have a better fix for the Macquarie Island problem reported by Alan Gutierrez in <https://mm.icann.org/pipermail/tz/2013-May/019368.html>, we can revert much of the 2013-05-23 12:19:13 -0700 change “Rework to avoid problem with Australia/Macquarie on 32-bit hosts” and the 2014-05-01 16:32:16 -0700 followup change “zic: improve handling of low-valued time stamps” which caused zic to insert a dummy transition. As a result, zic now generates TZif files that are typically a few bytes shorter, as they were in 2013c and earlier. * Makefile, zic.8: Remove mention of Big Bang. * NEWS: Mention. * zic.c (BIG_BANG, WORK_AROUND_CLIENT_OVERFLOW_BUGS, early_time): Remove. All uses removed. (writezone): New arg DEFAULTTYPE. All callers changed. Simplify by not inserting a dummy transition before the Big Bang. (outzone): Compute default type for use by writezone. (addtt): Don’t second-guess type 0. --- Makefile | 1 - NEWS | 6 +++ zic.8 | 6 --- zic.c | 151 ++++++++++++++++----------------------------------------------- 4 files changed, 44 insertions(+), 120 deletions(-) diff --git a/Makefile b/Makefile index 3705fc0..2289dff 100644 --- a/Makefile +++ b/Makefile @@ -173,7 +173,6 @@ LDLIBS= # Add the following to the end of the "CFLAGS=" line as needed to override # defaults specified in the source code. "-DFOO" is equivalent to "-DFOO=1". -# -DBIG_BANG=-9999999LL if the Big Bang occurred at time -9999999 (see zic.c) # -DDEPRECATE_TWO_DIGIT_YEARS for optional runtime warnings about strftime # formats that generate only the last two digits of year numbers # -DEPOCH_LOCAL if the 'time' function returns local time not UT diff --git a/NEWS b/NEWS index b90e68c..87f675e 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,12 @@ Unreleased, experimental changes legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. + Because of the type 0 change, zic no longer outputs a dummy + transition at time -2**59 (before the Big Bang), as clients should + no longer need this to handle historical timestamps correctly. + This reverts a change introduced in 2013d and shrinks most TZif + files by a few bytes. + localtime.c no longer requires at least one time type in TZif files that lack transitions or have a POSIX-style TZ string. This future-proofs the code against possible future extensions to the diff --git a/zic.8 b/zic.8 index ba4796e..00d4267 100644 --- a/zic.8 +++ b/zic.8 @@ -591,12 +591,6 @@ produces a single transition to daylight saving at the new UT offset To get separate transitions use multiple zone continuation lines specifying transition instants using universal time. -.PP -timestamps well before the Big Bang are silently omitted from the output. -This works around bugs in software that mishandles large negative time -stamps. Call it sour grapes, but pre-Big-Bang timestamps are -physically suspect anyway. The pre-Big-Bang cutoff time is -approximate and may change in future versions. .SH FILES .ta \w'/usr/share/zoneinfo\0\0'u /etc/localtime default local time zone file diff --git a/zic.c b/zic.c index fd73f66..88153db 100644 --- a/zic.c +++ b/zic.c @@ -948,48 +948,6 @@ dolink(char const *fromfield, char const *tofield, bool staysymlink) static zic_t const min_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); -/* Estimated time of the Big Bang, in seconds since the POSIX epoch. - rounded downward to the negation of a power of two that is - comfortably outside the error bounds. - - For the time of the Big Bang, see: - - Ade PAR, Aghanim N, Armitage-Caplan C et al. Planck 2013 results. - I. Overview of products and scientific results. - arXiv:1303.5062 2013-03-20 20:10:01 UTC - <https://arxiv.org/pdf/1303.5062v1> [PDF] - - Page 36, Table 9, row Age/Gyr, column Planck+WP+highL+BAO 68% limits - gives the value 13.798 plus-or-minus 0.037 billion years. - Multiplying this by 1000000000 and then by 31557600 (the number of - seconds in an astronomical year) gives a value that is comfortably - less than 2**59, so BIG_BANG is - 2**59. - - BIG_BANG is approximate, and may change in future versions. - Please do not rely on its exact value. */ - -#ifndef BIG_BANG -#define BIG_BANG (- (1LL << 59)) -#endif - -/* If true, work around GNOME glib bug 878 - <https://gitlab.gnome.org/GNOME/glib/issues/878> - by refusing to output timestamps before BIG_BANG. - Such timestamps are physically suspect anyway. - The glib bug is scheduled to be fixed in glib 2.58. - There is a similar bug in 32-bit glibc 2.27 and earlier - <https://sourceware.org/bugzilla/show_bug.cgi?id=19738> - that is scheduled to be fixed in glibc 2.28; - unfortunately a similar bug might persist in 64-bit glibc - though this has not been verified. With all this in mind, - let's hope that the workaround will no longer be needed - in the year 2025. */ -enum { WORK_AROUND_CLIENT_OVERFLOW_BUGS = true }; - -static const zic_t early_time = (WORK_AROUND_CLIENT_OVERFLOW_BUGS - ? BIG_BANG - : MINVAL(zic_t, TIME_T_BITS_IN_FILE)); - /* Return true if NAME is a directory. */ static bool itsdir(char const *name) @@ -1775,7 +1733,8 @@ swaptypes(int i, int j) } static void -writezone(const char *const name, const char *const string, char version) +writezone(const char *const name, const char *const string, char version, + int defaulttype) { register FILE * fp; register ptrdiff_t i, j; @@ -1805,13 +1764,11 @@ writezone(const char *const name, const char *const string, char version) toi = 0; fromi = 0; - while (fromi < timecnt && attypes[fromi].at < early_time) - ++fromi; for ( ; fromi < timecnt; ++fromi) { - if (toi > 1 && ((attypes[fromi].at + + if (toi != 0 && ((attypes[fromi].at + gmtoffs[attypes[toi - 1].type]) <= - (attypes[toi - 1].at + - gmtoffs[attypes[toi - 2].type]))) { + (attypes[toi - 1].at + gmtoffs[toi == 1 ? 0 + : attypes[toi - 2].type]))) { attypes[toi - 1].type = attypes[fromi].type; continue; @@ -1919,8 +1876,8 @@ writezone(const char *const name, const char *const string, char version) for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; - int old0, new0; - char omittype[TZ_MAX_TYPES + 1]; + int old0; + char omittype[TZ_MAX_TYPES]; int typemap[TZ_MAX_TYPES]; register int thistypecnt; char thischars[TZ_MAX_CHARS]; @@ -1945,45 +1902,17 @@ writezone(const char *const name, const char *const string, char version) error(_("too many transition times")); thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; - memset(omittype, thistimecnt != timecnt, typecnt); - if (thistimecnt == 0) { - /* - ** No transition times fall in the current - ** (32- or 64-bit) window. - */ - if (typecnt != 0) - omittype[typecnt - 1] = false; - } else { - for (i = thistimei - 1; i < thistimelim; ++i) - if (i >= 0) - omittype[types[i]] = false; - /* - ** For America/Godthab and Antarctica/Palmer - */ - if (thistimei == 0) - omittype[0] = false; - } - - /* Reorder types to make type 0 the first-used standard type - if one is used, otherwise the first-used DST type if one - is used, otherwise no reordering. Use TYPEMAP to swap - OLD0 and NEW0 so that NEW0 appears as type 0 in the output - instead of OLD0. TYPEMAP also omits unused types. */ - omittype[typecnt] = false; /* strlen sentinel */ + memset(omittype, true, typecnt); + omittype[defaulttype] = false; + for (i = thistimei; i < thistimelim; i++) + omittype[types[i]] = false; + + /* Reorder types to make DEFAULTTYPE type 0. + Use TYPEMAP to swap OLD0 and DEFAULTTYPE so that + DEFAULTTYPE appears as type 0 in the output instead + of OLD0. TYPEMAP also omits unused types. */ old0 = strlen(omittype); - new0 = -1; - for (i = 0; i < timecnt; i++) - if (!omittype[types[i]]) { - if (! isdsts[types[i]]) { - new0 = types[i]; - break; - } - if (new0 < 0) - new0 = types[i]; - } - if (new0 < 0) - new0 = old0; - swaptypes(old0, new0); + swaptypes(old0, defaulttype); #ifndef LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH /* @@ -2035,7 +1964,8 @@ writezone(const char *const name, const char *const string, char version) thistypecnt = 0; for (i = old0; i < typecnt; i++) if (!omittype[i]) - typemap[i == old0 ? new0 : i == new0 ? old0 : i] + typemap[i == old0 ? defaulttype + : i == defaulttype ? old0 : i] = thistypecnt++; for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i) @@ -2133,7 +2063,7 @@ writezone(const char *const name, const char *const string, char version) for (i = old0; i < typecnt; i++) if (!omittype[i]) putc(ttisgmts[i], fp); - swaptypes(old0, new0); + swaptypes(old0, defaulttype); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); @@ -2487,6 +2417,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) zic_t one = 1; zic_t y2038_boundary = one << 31; zic_t max_year0; + int defaulttype = -1; max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; @@ -2595,9 +2526,9 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) */ stdoff = 0; zp = &zpfirst[i]; - usestart = i > 0 && (zp - 1)->z_untiltime > early_time; + usestart = i > 0 && (zp - 1)->z_untiltime > min_time; useuntil = i < (zonecount - 1); - if (useuntil && zp->z_untiltime <= early_time) + if (useuntil && zp->z_untiltime <= min_time) continue; gmtoff = zp->z_gmtoff; eat(zp->z_filename, zp->z_linenum); @@ -2612,7 +2543,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) if (usestart) { addtt(starttime, type); usestart = false; - } else addtt(early_time, type); + } else + defaulttype = type; } else for (year = min_year; year <= max_year; ++year) { if (useuntil && year > zp->z_untilrule.r_hiyear) break; @@ -2726,6 +2658,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) offset = oadd(zp->z_gmtoff, rp->r_stdoff); type = addtype(offset, ab, rp->r_isdst, rp->r_todisstd, rp->r_todisgmt); + if (defaulttype < 0 && !rp->r_isdst) + defaulttype = type; if (rp->r_hiyear == ZIC_MAX && ! (0 <= lastatmax && ktime < attypes[lastatmax].at)) @@ -2742,11 +2676,14 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) eat(zp->z_filename, zp->z_linenum); if (*startbuf == '\0') error(_("can't determine time zone abbreviation to use just after until time")); - else addtt(starttime, - addtype(startoff, startbuf, - startoff != zp->z_gmtoff, - startttisstd, - startttisgmt)); + else { + bool isdst = startoff != zp->z_gmtoff; + type = addtype(startoff, startbuf, isdst, + startttisstd, startttisgmt); + if (defaulttype < 0 && !isdst) + defaulttype = type; + addtt(starttime, type); + } } /* ** Now we may get to set starttime for the next zone line. @@ -2761,6 +2698,8 @@ error(_("can't determine time zone abbreviation to use just after until time")); starttime = tadd(starttime, -gmtoff); } } + if (defaulttype < 0) + defaulttype = 0; if (0 <= lastatmax) attypes[lastatmax].dontmerge = true; if (do_extend) { @@ -2788,7 +2727,7 @@ error(_("can't determine time zone abbreviation to use just after until time")); attypes[timecnt - 1].dontmerge = true; } } - writezone(zpfirst->z_name, envvar, version); + writezone(zpfirst->z_name, envvar, version, defaulttype); free(startbuf); free(ab); free(envvar); @@ -2797,20 +2736,6 @@ error(_("can't determine time zone abbreviation to use just after until time")); static void addtt(zic_t starttime, int type) { - if (starttime <= early_time - || (timecnt == 1 && attypes[0].at < early_time)) { - gmtoffs[0] = gmtoffs[type]; - isdsts[0] = isdsts[type]; - ttisstds[0] = ttisstds[type]; - ttisgmts[0] = ttisgmts[type]; - if (abbrinds[type] != 0) - strcpy(chars, &chars[abbrinds[type]]); - abbrinds[0] = 0; - charcnt = strlen(chars) + 1; - typecnt = 1; - timecnt = 0; - type = 0; - } attypes = growalloc(attypes, sizeof *attypes, timecnt, &timecnt_alloc); attypes[timecnt].at = starttime; attypes[timecnt].dontmerge = false; -- 2.7.4

1 0

[PROPOSED] GNOME glib bug fix installed
by Paul Eggert June 13, 2018

June 13, 2018

The bug fix was merged into glib master today. Since it’s four years after the fix was proposed (!), push back an estimate of when we can remove the workaround. Also, adjust to GNOME bug renumbering. * NEWS: Adjust bug number in history. * zic.c (WORK_AROUND_GLIB_BUG_878): Rename from WORK_AROUND_GNOME_BUG_730332. All uses changed. --- NEWS | 4 ++-- zic.c | 14 +++++++------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 34f7810..b90e68c 100644 --- a/NEWS +++ b/NEWS @@ -2106,8 +2106,8 @@ Release 2014d - 2014-05-27 21:34:40 -0700 Changes affecting code zic no longer generates files containing timestamps before the Big Bang. - This works around GNOME bug 730332 - <https://bugzilla.gnome.org/show_bug.cgi?id=730332>. + This works around GNOME glib bug 878 + <https://gitlab.gnome.org/GNOME/glib/issues/878> (Thanks to Leonardo Chiquitto for reporting the bug, and to Arthur David Olson and James Cloos for suggesting improvements to the fix.) diff --git a/zic.c b/zic.c index ce9ccaf..9e25b02 100644 --- a/zic.c +++ b/zic.c @@ -972,17 +972,17 @@ static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); #define BIG_BANG (- (1LL << 59)) #endif -/* If true, work around GNOME bug 730332 - <https://bugzilla.gnome.org/show_bug.cgi?id=730332> +/* If true, work around GNOME glib bug 878 + <https://gitlab.gnome.org/GNOME/glib/issues/878> by refusing to output timestamps before BIG_BANG. Such timestamps are physically suspect anyway. - The GNOME bug is scheduled to be fixed in GNOME 3.22, and if so - this workaround will no longer be needed when GNOME 3.21 and - earlier are obsolete, say in the year 2021. */ -enum { WORK_AROUND_GNOME_BUG_730332 = true }; + The glib bug is scheduled to be fixed in glib 2.58, and if so + this workaround will no longer be needed when glib 2.57 and + earlier are obsolete, say in the year 2025. */ +enum { WORK_AROUND_GLIB_BUG_878 = true }; -static const zic_t early_time = (WORK_AROUND_GNOME_BUG_730332 +static const zic_t early_time = (WORK_AROUND_GLIB_BUG_878 ? BIG_BANG : MINVAL(zic_t, TIME_T_BITS_IN_FILE)); -- 2.17.1

2 2

Clarification on LMT entries
by Matt Johnson June 8, 2018

June 8, 2018

Quick question. The entry for Europe/Kiev has two solar mean time entries: Zone Europe/Kiev 2:02:04 - LMT 1880 2:02:04 - KMT 1924 May 2 # Kiev Mean Time While I know how to read this, I'm not sure why the abbreviation KMT exists. Is this another invented abbreviation, or is there a source? Also, why 1880 on the LMT line? What is special about 1880? Thanks, Matt

4 3

Secure FTP support for IANA downloads
by pbassey＠ups.com June 6, 2018

June 6, 2018

Hello, I am writing to inquire about your site's use of FTP and the possibility of migrating over to Secure FTP in order to comply with our company's security compliance requirements. Does your site offer Secure FTP for your IANA downloads and if not, what would it take to enable this protocol so our company could securely download your files? Currently, we use this URL to download the IANA time zone files which is not secure: ftp://ftp.iana.org/tz/ Thank you in advance for your help. Regards, Peter Bassey Peter A. Bassey Enterprise Business Intelligence UPS 340 MacArthur Blvd Mahwah, NJ 07430 Phone: 201-828-7847 Mobile: 845-662-3743 pbassey(a)ups.com<mailto:pbassey@ups.com>

6 6

On solving the tzdata changes problem
by Aldrin Martoq Ahumada June 5, 2018

June 5, 2018

Hello, I think we can semi-automate when a tzdata change occurs in software, given the following: 1. Your software stores all dates as unix timestamps (seconds since the epoch, “ignoring” leap seconds). 2. Your system (or users) choose a local representation using an oficial timezone, like ‘America/Santiago’. 3. Your system stores somewhere what version of tzdata is currently being used, like ‘2018e’. So, when a new version of tzdata is released (say ‘2018f’), the sysadmin updates their tzdata packages, and then runs a tool that checks for every timezone used (‘America/Santiago’ for ex) if there are changes that could affect users between 2018e and 2018f. The typical example: my dentist appointment is not correct anymore. So, your system may ask the user: “There have been changes in the timezone where you live, would you like to review this 3 appointments and check if they are still correct?" The problem is that there is no historical data of tzdata: when a sysadmin updates the system, it gets a new version 2018f, but there is no automatic way of knowing the differences. I didn’t find one, so I wrote it. A web app that demo this concept is here: https://a0.github.io/a0-tzmigration/demo/ <https://a0.github.io/a0-tzmigration/demo/> You can even share the url, for example here is the diff between America/Santiago 2016j and America/Punta_Arenas 2017a: https://a0.github.io/a0-tzmigration/demo/?ta=America%2FSantiago&va=2016j&tb… <https://a0.github.io/a0-tzmigration/demo/?ta=America/Santiago&va=2016j&tb=A…> This can automate many issues we all have when updating tzdata. For the link above, a whole region of my country switched so the new America/Punta_Arenas timezone was created. You can easily spot errors, too: the America/Punta_Arenas should be equal to America/Santiago up to 2017, but there are differences in the years 1890, 1946. And you can do this, in your own systems, using the same data, which is here: https://a0.github.io/a0-tzmigration-ruby/data/ <https://a0.github.io/a0-tzmigration-ruby/data/>. It’s not perfect. It probably has errors. I generated it from the ruby tzinfo-data gem, which has info only from 2013c onwards, and transitions up to ≈ 2068 (50 years from now). Use with caution, happy to accept corrections. I’m writing a ruby gem and an npm package, would love to see other language implementations: https://github.com/a0/a0-tzmigration-ruby <https://github.com/a0/a0-tzmigration-ruby> https://github.com/a0/a0-tzmigration-js <https://github.com/a0/a0-tzmigration-js> API is not really stable, will check and release documentation next week, but the core idea is there: grab the JSON files from our github page and get the changes that MAY have to be applied. I’m writing a medium blog post to cover all of this. Hope that this help all of you, and happy to listen any suggestions or corrections. Cheers, — Aldrin.

5 6

[PROPOSED 1/3] Don’t reject TZif TZ strings that lack DST
by Paul Eggert June 5, 2018

June 5, 2018

* NEWS: Mention this. * localtime.c (tzloadbody): Don’t require a TZif file’s POSIX TZ string to specify DST. That way, the TZ string consistently overrides the type of the TZif file’s last transition, instead of overriding only when specifying DST. Although this currently matters only for invalid TZif files where the TZ string disagrees with the last transition’s time type, it will become more important if we stop requiring at least one time type in the binary data, as the TZ string will then be the only source for time types. --- NEWS | 6 ++++++ localtime.c | 11 +++++------ 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index ce009e7..2e9bf99 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,12 @@ Unreleased, experimental changes legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET, which previously used nonzero types for these timestamps. + localtime.c no longer ignores TZif POSIX-style TZ strings that + specify only standard time. Instead, these TZ strings now + override the default time type for timestamps after the last + transition (or for all time stamps if there are no transitions), + just as DST strings specifying DST have always done. + Changes to documentation New restrictions: A Rule name must start with a character that diff --git a/localtime.c b/localtime.c index 21160c0..5a3fe91 100644 --- a/localtime.c +++ b/localtime.c @@ -587,8 +587,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, struct state *ts = &lsp->u.st; up->buf[nread - 1] = '\0'; - if (tzparse(&up->buf[1], ts, false) - && ts->typecnt == 2) { + if (tzparse(&up->buf[1], ts, false)) { /* Attempt to reuse existing abbreviations. Without this, America/Anchorage would be right on @@ -599,7 +598,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, stay 40 in this example. */ int gotabbr = 0; int charcnt = sp->charcnt; - for (i = 0; i < 2; i++) { + for (i = 0; i < ts->typecnt; i++) { char *tsabbr = ts->chars + ts->ttis[i].tt_abbrind; int j; for (j = 0; j < charcnt; j++) @@ -618,7 +617,7 @@ tzloadbody(char const *name, struct state *sp, bool doextend, } } } - if (gotabbr == 2) { + if (gotabbr == ts->typecnt) { sp->charcnt = charcnt; /* Ignore any trailing, no-op transitions generated @@ -640,8 +639,8 @@ tzloadbody(char const *name, struct state *sp, bool doextend, sp->timecnt++; i++; } - sp->ttis[sp->typecnt++] = ts->ttis[0]; - sp->ttis[sp->typecnt++] = ts->ttis[1]; + for (i = 0; i < ts->typecnt; i++) + sp->ttis[sp->typecnt++] = ts->ttis[i]; } } } -- 2.17.1

1 2

UTC is enough for everyone, right?
by Philip Paeps June 4, 2018

June 4, 2018

I've just read this amusing introduction to the vagaries of dealing with time. A fun read. https://zachholman.com/talk/utc-is-enough-for-everyone-right I've not watched the accompanying presentations but the article is quite insightful. May merit inclusion in tz-link.html? Philip -- Philip Paeps Senior Reality Engineer Ministry of Information

1 0

[PROPOSED] Use type 0 for timestamps before first transition
by Paul Eggert June 3, 2018

June 3, 2018

I ran into this problem when helping to draft: https://tools.ietf.org/html/draft-murchison-tzdist-tzif-04 Its section 3.2 gives a complex four-step procedure for determining the type of timestamps before the first transition, derived from 2018e localtime.c. However, I just now checked, and glibc does only the last two steps. Furthermore, in practice nowadays only the last step is needed in almost all zones, because type 0 is almost always the right type to use; the only exceptions are the legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and EET. As the tzif-04 section 3.2 procedure is only for backward compatibility with older TZif files, now is a good time to clean up by specifying a simple way to deal with time stamps before the first transition, namely, to use time type 0. So, this patch changes zic so that the first-used standard time type (if there is one) is always time type 0. This is compatible with glibc and with any other program that uses the heuristic of using the lowest-numbered standard-time time type for timestamps before the first transition, since it merely changes zic to output a standard-time type 0. * NEWS, tzfile.5: Document this. * localtime.c (tzparse): Make standard time type 0, if standard time is in use. This should help future-proof this program if we ever get rid of the defaulttype member and just use 0. * zic.c (swaptypes): New function. (writezone): Reorder types to make type 0 the default type. Negate the local variable writetypes into omittypes, so that strlen can be used on it, and enlarge it by 1 to make room for a sentinel. Use memset where appropriate. --- NEWS | 13 +++++++++ localtime.c | 43 ++++++++++++++++++++++-------- tzfile.5 | 17 ++++++++---- zic.c | 77 +++++++++++++++++++++++++++++++++++++++-------------- 4 files changed, 114 insertions(+), 36 deletions(-) diff --git a/NEWS b/NEWS index 0ef70a1..ce009e7 100644 --- a/NEWS +++ b/NEWS @@ -17,6 +17,16 @@ Unreleased, experimental changes observed DST in 1942/79, not 1961/80, and there were several errors for transition times and dates. (Thanks to P Chan.) + Changes to code + + zic now always generates TZif files where time type 0 is used for + timestamps before the first transition. This simplifies the + reading of TZif files and should not affect behavior of existing + TZif readers because the same set of time types is used; only + their internal indexes may have changed. This affects only the + legacy zones EST5EDT, CST6CDT, MST7MDT, PST8PDT, CET, MET, and + EET, which previously used nonzero types for these timestamps. + Changes to documentation New restrictions: A Rule name must start with a character that @@ -25,6 +35,9 @@ Unreleased, experimental changes The latter restriction makes room for future extensions (a possibility noted by Tom Lane). + tzfile.5 now documents what time types apply before the first and + after the last transition, if any. + The name "TZif" is now used for the tz binary data format. tz-link.htm now mentions the A0 TimeZone Migration utilities. diff --git a/localtime.c b/localtime.c index 5b5a5b1..21160c0 100644 --- a/localtime.c +++ b/localtime.c @@ -131,7 +131,11 @@ struct state { char chars[BIGGEST(BIGGEST(TZ_MAX_CHARS + 1, sizeof gmt), (2 * (MY_TZNAME_MAX + 1)))]; struct lsinfo lsis[TZ_MAX_LEAPS]; - int defaulttype; /* for early times or if no transitions */ + + /* The time type to use for early times or if no transitions. + It is always zero for recent tzdb releases. + It might be nonzero for data from tzdb 2018e or earlier. */ + int defaulttype; }; enum r_type { @@ -657,6 +661,17 @@ tzloadbody(char const *name, struct state *sp, bool doextend, break; } } + + /* Infer sp->defaulttype from the data. Although this default + type is always zero for data from recent tzdb releases, + things are trickier for data from tzdb 2018e or earlier. + + The first set of heuristics work around bugs in 32-bit data + generated by tzdb 2013c or earlier. The workaround is for + zones like Australia/Macquarie where timestamps before the + first transition have a time type that is not the earliest + standard-time type. See: + https://mm.icann.org/pipermail/tz/2013-May/019368.html */ /* ** If type 0 is unused in transitions, ** it's the type to use for early times. @@ -678,6 +693,9 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (!sp->ttis[i].tt_isdst) break; } + /* The next heuristics are for data generated by tzdb 2018e or + earlier, for zones like EST5EDT where the first transition + is to DST. */ /* ** If no result yet, find the first standard type. ** If there is none, punt to type zero. @@ -690,7 +708,12 @@ tzloadbody(char const *name, struct state *sp, bool doextend, break; } } + /* A simple 'sp->defaulttype = 0;' would suffice here if we + didn't have to worry about 2018e-or-earlier data. Even + simpler would be to remove the defaulttype member and just + use 0 in its place. */ sp->defaulttype = i; + return 0; } @@ -1115,8 +1138,8 @@ tzparse(const char *name, struct state *sp, bool lastditch) /* ** Two transitions per year, from EPOCH_YEAR forward. */ - init_ttinfo(&sp->ttis[0], -dstoffset, true, stdlen + 1); - init_ttinfo(&sp->ttis[1], -stdoffset, false, 0); + init_ttinfo(&sp->ttis[0], -stdoffset, false, 0); + init_ttinfo(&sp->ttis[1], -dstoffset, true, stdlen + 1); sp->defaulttype = 0; timecnt = 0; janfirst = 0; @@ -1157,17 +1180,14 @@ tzparse(const char *name, struct state *sp, bool lastditch) if (! increment_overflow_time (&sp->ats[timecnt], janoffset + starttime)) - sp->types[timecnt++] = reversed; - else if (janoffset) - sp->defaulttype = reversed; + sp->types[timecnt++] = !reversed; sp->ats[timecnt] = janfirst; if (! increment_overflow_time (&sp->ats[timecnt], janoffset + endtime)) { - sp->types[timecnt++] = !reversed; + sp->types[timecnt++] = reversed; yearlim = year + YEARSPERREPEAT + 1; - } else if (janoffset) - sp->defaulttype = !reversed; + } } if (increment_overflow_time (&janfirst, janoffset + yearsecs)) @@ -1175,9 +1195,10 @@ tzparse(const char *name, struct state *sp, bool lastditch) janoffset = 0; } sp->timecnt = timecnt; - if (! timecnt) + if (! timecnt) { + sp->ttis[0] = sp->ttis[1]; sp->typecnt = 1; /* Perpetual DST. */ - else if (YEARSPERREPEAT < year - yearbeg) + } else if (YEARSPERREPEAT < year - yearbeg) sp->goback = sp->goahead = true; } else { register int_fast32_t theirstdoffset; diff --git a/tzfile.5 b/tzfile.5 index 530397f..13213d2 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -70,7 +70,9 @@ at which the rules for computing local time change. one-byte unsigned integer values; each one tells which of the different types of local time types described in the file is associated with the time period -starting with the same-indexed transition time. +starting with the same-indexed transition time +and continuing up to but not including the next transition time +(or continuing for one second, if this is the last transition). These values serve as indices into the next field. .IP * .I tzh_typecnt @@ -159,15 +161,20 @@ eight bytes are used for each transition time or leap second time. After the second header and data comes a newline-enclosed, POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file -(with nothing between the newlines if there is no POSIX representation for -such instants). -The POSIX-style string must agree with the local time type after -both data's last transition times; for example, given the string +or for all instants if the file has no transitions. +The POSIX-style TZ string is empty (i.e., nothing between the newlines) +if there is no POSIX representation for such instants. +If nonempty, the POSIX-style TZ string must agree with the local time +type after both data's last transition times if present; +for example, given the string .q "WET0WEST,M3.5.0,M10.5.0/3" then if a last transition time is in July, the transition's local time type must specify a daylight-saving time abbreviated .q "WEST" that is one hour east of UT. +Also, if there is at least one transition, time type 0 is associated +with the time period from the indefinite past up to but not including +the earliest transition time. .SS Version 3 format For version-3-format time zone files, the POSIX-TZ-style string may use two minor extensions to the POSIX TZ format, as described in diff --git a/zic.c b/zic.c index 679b3e2..ce9ccaf 100644 --- a/zic.c +++ b/zic.c @@ -1759,6 +1759,17 @@ is32(const zic_t x) return INT32_MIN <= x && x <= INT32_MAX; } +static void +swaptypes(int i, int j) +{ + { zic_t t = gmtoffs[i]; gmtoffs[i] = gmtoffs[j]; gmtoffs[j] = t; } + { char t = isdsts[i]; isdsts[i] = isdsts[j]; isdsts[j] = t; } + { unsigned char t = abbrinds[i]; abbrinds[i] = abbrinds[j]; + abbrinds[j] = t; } + { bool t = ttisstds[i]; ttisstds[i] = ttisstds[j]; ttisstds[j] = t; } + { bool t = ttisgmts[i]; ttisgmts[i] = ttisgmts[j]; ttisgmts[j] = t; } +} + static void writezone(const char *const name, const char *const string, char version) { @@ -1904,7 +1915,8 @@ writezone(const char *const name, const char *const string, char version) for (pass = 1; pass <= 2; ++pass) { register ptrdiff_t thistimei, thistimecnt, thistimelim; register int thisleapi, thisleapcnt, thisleaplim; - int writetype[TZ_MAX_TYPES]; + int old0, new0; + char omittype[TZ_MAX_TYPES + 1]; int typemap[TZ_MAX_TYPES]; register int thistypecnt; char thischars[TZ_MAX_CHARS]; @@ -1929,25 +1941,46 @@ writezone(const char *const name, const char *const string, char version) error(_("too many transition times")); thistimelim = thistimei + thistimecnt; thisleaplim = thisleapi + thisleapcnt; - for (i = 0; i < typecnt; ++i) - writetype[i] = thistimecnt == timecnt; + memset(omittype, thistimecnt != timecnt, typecnt); if (thistimecnt == 0) { /* ** No transition times fall in the current ** (32- or 64-bit) window. */ if (typecnt != 0) - writetype[typecnt - 1] = true; + omittype[typecnt - 1] = false; } else { for (i = thistimei - 1; i < thistimelim; ++i) if (i >= 0) - writetype[types[i]] = true; + omittype[types[i]] = false; /* ** For America/Godthab and Antarctica/Palmer */ if (thistimei == 0) - writetype[0] = true; + omittype[0] = false; } + + /* Reorder types to make type 0 the first-used standard type + if one is used, otherwise the first-used DST type if one + is used, otherwise no reordering. Use TYPEMAP to swap + OLD0 and NEW0 so that NEW0 appears as type 0 in the output + instead of OLD0. TYPEMAP also omits unused types. */ + omittype[typecnt] = false; /* strlen sentinel */ + old0 = strlen(omittype); + new0 = -1; + for (i = 0; i < timecnt; i++) + if (!omittype[types[i]]) { + if (! isdsts[types[i]]) { + new0 = types[i]; + break; + } + if (new0 < 0) + new0 = types[i]; + } + if (new0 < 0) + new0 = old0; + swaptypes(old0, new0); + #ifndef LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH /* ** For some pre-2011 systems: if the last-to-be-written @@ -1965,8 +1998,8 @@ writezone(const char *const name, const char *const string, char version) if (isdsts[types[i]]) mrudst = types[i]; else mrustd = types[i]; - for (i = 0; i < typecnt; ++i) - if (writetype[i]) { + for (i = old0; i < typecnt; i++) + if (!omittype[i]) { if (isdsts[i]) hidst = i; else histd = i; @@ -1980,7 +2013,7 @@ writezone(const char *const name, const char *const string, char version) ttisstds[mrudst], ttisgmts[mrudst]); isdsts[mrudst] = 1; - writetype[type] = true; + omittype[type] = false; } if (histd >= 0 && mrustd >= 0 && histd != mrustd && gmtoffs[histd] != gmtoffs[mrustd]) { @@ -1991,20 +2024,23 @@ writezone(const char *const name, const char *const string, char version) ttisstds[mrustd], ttisgmts[mrustd]); isdsts[mrustd] = 0; - writetype[type] = true; + omittype[type] = false; } } #endif /* !defined LEAVE_SOME_PRE_2011_SYSTEMS_IN_THE_LURCH */ thistypecnt = 0; - for (i = 0; i < typecnt; ++i) - typemap[i] = writetype[i] ? thistypecnt++ : -1; + for (i = old0; i < typecnt; i++) + if (!omittype[i]) + typemap[i == old0 ? new0 : i == new0 ? old0 : i] + = thistypecnt++; + for (i = 0; i < sizeof indmap / sizeof indmap[0]; ++i) indmap[i] = -1; thischarcnt = 0; - for (i = 0; i < typecnt; ++i) { + for (i = old0; i < typecnt; i++) { register char * thisabbr; - if (!writetype[i]) + if (omittype[i]) continue; if (indmap[abbrinds[i]] >= 0) continue; @@ -2053,8 +2089,8 @@ writezone(const char *const name, const char *const string, char version) uc = typemap[types[i]]; fwrite(&uc, sizeof uc, 1, fp); } - for (i = 0; i < typecnt; ++i) - if (writetype[i]) { + for (i = old0; i < typecnt; i++) + if (!omittype[i]) { puttzcode(gmtoffs[i], fp); putc(isdsts[i], fp); putc((unsigned char) indmap[abbrinds[i]], fp); @@ -2087,12 +2123,13 @@ writezone(const char *const name, const char *const string, char version) else puttzcode64(todo, fp); puttzcode(corr[i], fp); } - for (i = 0; i < typecnt; ++i) - if (writetype[i]) + for (i = old0; i < typecnt; i++) + if (!omittype[i]) putc(ttisstds[i], fp); - for (i = 0; i < typecnt; ++i) - if (writetype[i]) + for (i = old0; i < typecnt; i++) + if (!omittype[i]) putc(ttisgmts[i], fp); + swaptypes(old0, new0); } fprintf(fp, "\n%s\n", string); close_file(fp, directory, name); -- 2.17.1

1 0

[PROPOSED] zic performance tweak for wide-ranging years
by Paul Eggert June 1, 2018

June 1, 2018

* zic.c (rpytime): Improve performance when the year is outlandishly small or large. --- zic.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/zic.c b/zic.c index 7c04435..679b3e2 100644 --- a/zic.c +++ b/zic.c @@ -3141,6 +3141,15 @@ rpytime(const struct rule *rp, zic_t wantedy) dayoff = 0; m = TM_JANUARY; y = EPOCH_YEAR; + if (y < wantedy) { + wantedy -= y; + dayoff = (wantedy / YEARSPERREPEAT) * (SECSPERREPEAT / SECSPERDAY); + wantedy %= YEARSPERREPEAT; + wantedy += y; + } else if (wantedy < 0) { + dayoff = (wantedy / YEARSPERREPEAT) * (SECSPERREPEAT / SECSPERDAY); + wantedy %= YEARSPERREPEAT; + } while (wantedy != y) { if (wantedy > y) { i = len_years[isleap(y)]; -- 2.17.0

1 0

[PROPOSED] * Makefile ($(ALL_ASC)): Switch to gpg2.
by Paul Eggert June 1, 2018

June 1, 2018

--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 389a6db..3705fc0 100644 --- a/Makefile +++ b/Makefile @@ -978,7 +978,7 @@ tzdata$(VERSION).tar.gz.asc: tzdata$(VERSION).tar.gz tzdata$(VERSION)-rearguard.tar.gz.asc: tzdata$(VERSION)-rearguard.tar.gz tzdb-$(VERSION).tar.lz.asc: tzdb-$(VERSION).tar.lz $(ALL_ASC): - gpg --armor --detach-sign $? + gpg2 --armor --detach-sign $? typecheck: $(MAKE) clean -- 2.17.0

1 0

wrong Europe/Dublin dst offset rule
by Vicky May 30, 2018

May 30, 2018

Hi, while parsing the data i found the issue in rule Europe/Dublin Negative DST.. Previous version or not in any other file there is no negative dst. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav

5 6

[PROPOSED 1/3] * tz-link.html: Macao → Macau
by Paul Eggert May 28, 2018

May 28, 2018

--- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 508a1f1..d307bf7 100644 --- a/tz-link.html +++ b/tz-link.html @@ -754,8 +754,8 @@ hreflang="he">announcements (in Hebrew)</a>.</dd> <dd>The National Institute of Metrological Research maintains a <a href="http://www.nanospin.eu/res/tf/ora_legale_i.shtml">table of civil time (in Italian)</a>.</dd> -<dt>Macao</dt> -<dd>The Macao Meteorological and Geophysical Bureau maintains a +<dt>Macau</dt> +<dd>The Meteorological and Geophysical Bureau maintains a <a href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm">history of summer time</a>. Unfortunately it is incomplete and has errors.</dd> <dt>Malaysia</dt> -- 2.17.0

1 2

Asia\Nicosia
by GsaTitanium May 26, 2018

May 26, 2018

Hello, i am writing to you about an issue with Nicosia the capital of Cyprus. Cyprus is an EU member since May 1st 2004 which makes it a European country but you have it as an Asia Continent Country. Before May 1st 2004 Cyprus had Asia Timezone but since then we have Eastern European Time and we have also adopted the Eastern European Summer Time. Basically you representation of Nicosia as UTC+2 and UTC+3 (in summer) time is correct but in the wrong Continent. Cyprus as a European Union Member: https://europa.eu/european-union/about-eu/countries/member-countries/cyprus… Map of Europe Union including Cyprus: https://europa.eu/european-union/about-eu/countries_en?country=CY#map Waiting for you reply Thank you GsaTitanium

9 11

[PROPOSED 1/2] * tz-link.html: Update tzdist URLs.
by Paul Eggert May 25, 2018

May 25, 2018

--- tz-link.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tz-link.html b/tz-link.html index 3017a5e..508a1f1 100644 --- a/tz-link.html +++ b/tz-link.html @@ -281,11 +281,11 @@ transferring time zone data by reference. The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis mailing list</a> discusses two Internet drafts: <a id="TZDIST-Geolocate" -href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01">TZDIST +href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-02">TZDIST Geolocate Extension</a> lets a client determine its time zone region from its geographic location using a <a href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and -<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-00">The +<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-02">The Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of <abbr>TZif</abbr> data.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> -- 2.17.0

2 3

Thanks for the book recommendation
by Scott Kilpatrick May 25, 2018

May 25, 2018

Hi everyone, Recently I stumbled upon the tz database and mailing list when debugging some daylight saving issues at work. I'd just wanted to understand how political decisions about DST affect a Java program. Reading through the documentation about the database online, I noticed the link to the Dissent interview with Vanessa Ogle about her book, "The Global Transformation of Time, 1870-1950". (It was a bit jarring to see a link to Dissent in technical material like this, ha!) First I read that interview and then I picked up the book - and loved it! Many thanks to Paul E. or to whomever actually suggested the citation to the book in the "theory" page. It has helped me further go down this rabbit hole that I'd never expected to be so interested in. Best, Scott

1 0

[PATCH] Clarify that EST5EDT is problematic in POSIX
by Paul Eggert May 21, 2018

May 21, 2018

* theory.html: Don’t imply that EST5EDT is an OK POSIX TZ string, as POSIX does not specify the DST transitions in this case. Use past tense to describe the typical pre-POSIX behavior. Minor copyediting. --- theory.html | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/theory.html b/theory.html index 53f7cee..298972e 100644 --- a/theory.html +++ b/theory.html @@ -874,15 +874,15 @@ an older <code>zic</code>. <pre><code>TZ='Pacific/Auckland'</code></pre> </li> <li> - POSIX does not define the exact meaning of <code>TZ</code> values like + POSIX does not define the <abbr>DST</abbr> transitions + for <code>TZ</code> values like "<code>EST5EDT</code>". - Typically the current <abbr>US</abbr> <abbr>DST</abbr> rules - are used to interpret such values, but this means that the - <abbr>US</abbr> <abbr>DST</abbr> rules are compiled into each - program that does time conversion. - This means that when - <abbr>US</abbr> time conversion rules change (as in the United - States in 1987), all programs that do time conversion must be + Traditionally the current <abbr>US</abbr> <abbr>DST</abbr> rules + were used to interpret such values, but this meant that the + <abbr>US</abbr> <abbr>DST</abbr> rules were compiled into each + program that did time conversion. This meant that when + <abbr>US</abbr> time conversion rules changed (as in the United + States in 1987), all programs that did time conversion had to be recompiled to ensure proper results. </li> <li> @@ -893,14 +893,14 @@ an older <code>zic</code>. <li> In POSIX, there is no tamper-proof way for a process to learn the system's best idea of local wall clock. - (This is important for applications that an administrator wants + This is important for applications that an administrator wants used only at certain times – without regard to whether the user has fiddled the <code>TZ</code> environment variable. While an administrator can "do everything in <abbr>UT</abbr>" to get around the problem, doing so is inconvenient and precludes - handling daylight saving time shifts - as might be required to - limit phone calls to off-peak hours.) + handling daylight saving time shifts – as might be required to + limit phone calls to off-peak hours. </li> <li> POSIX provides no convenient and efficient way to determine @@ -923,7 +923,7 @@ an older <code>zic</code>. Unsigned 32-bit integers are used on one or two platforms, and 36-bit and 40-bit integers are also used occasionally. Although earlier POSIX versions allowed <code>time_t</code> to be a - floating-point type, this was not supported by any practical systems, + floating-point type, this was not supported by any practical system, and POSIX.1-2013 and the <code><abbr>tz</abbr></code> code both require <code>time_t</code> to be an integer type. </li> @@ -960,9 +960,9 @@ an older <code>zic</code>. separately maintaining both <code>TZ</code> and <code>TIMEZONE</code> seemed a nuisance; and systems where "new" forms of <code>TZ</code> might cause problems can simply - use <code>TZ</code> values such as "<code>EST5EDT</code>" which - can be used both by "new" programs (à la POSIX) and "old" - programs (as zone names and offsets). + use legacy <code>TZ</code> values such as "<code>EST5EDT</code>" which + can be used by "new" programs as well as by "old" programs that + assume pre-POSIX <code>TZ</code> values. </p> </li> <li> -- 2.17.0

1 0

[PROPOSED] Use “TZif” for binary files.
by Paul Eggert May 21, 2018

May 21, 2018

Also, mention tzdist-bis and draft-murchison-tzdist-tzif-00. --- Makefile | 8 +++++--- NEWS | 2 ++ theory.html | 15 ++++++++------- tz-link.html | 37 ++++++++++++++++++++++--------------- zic.c | 2 +- 5 files changed, 38 insertions(+), 26 deletions(-) diff --git a/Makefile b/Makefile index 91c30f7..06f7fd6 100644 --- a/Makefile +++ b/Makefile @@ -109,6 +109,8 @@ LIBDIR = $(TOPDIR)/$(USRDIR)/lib # Types to try, as an alternative to time_t. int64_t should be first. TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t +# What kind of TZif data files to generate. +# (TZif is the binary time zone data format that zic generates.) # If you want only POSIX time, with time values interpreted as # seconds since the epoch (not counting leap seconds), use # REDO= posix_only @@ -129,7 +131,7 @@ TIME_T_ALTERNATIVES = int64_t int32_t uint32_t uint64_t REDO= posix_right -# To install data in text form that has all the information of the binary data, +# To install data in text form that has all the information of the TZif data, # (optionally incorporating leap second information), use # TZDATA_TEXT= tzdata.zi leapseconds # To install text data without leap second information (e.g., because @@ -357,7 +359,7 @@ ZIC= $(zic) $(ZFLAGS) ZFLAGS= -# How to use zic to install tz binary files. +# How to use zic to install TZif files. ZIC_INSTALL= $(ZIC) -d '$(DESTDIR)$(TZDIR)' $(LEAPSECONDS) @@ -605,7 +607,7 @@ INSTALLARGS = \ YEARISTYPE='$(YEARISTYPE)' \ ZIC='$(ZIC)' -# 'make install_data' installs one set of tz binary files. +# 'make install_data' installs one set of TZif files. install_data: zic leapseconds yearistype tzdata.zi $(ZIC_INSTALL) tzdata.zi diff --git a/NEWS b/NEWS index a91f00a..6bd89c2 100644 --- a/NEWS +++ b/NEWS @@ -25,6 +25,8 @@ Unreleased, experimental changes The latter restriction makes room for future extensions (a possibility noted by Tom Lane). + The name "TZif" is now used for the tz binary data format. + Changes to build procedure New 'make' target 'rearguard_tarballs' to build the rearguard diff --git a/theory.html b/theory.html index d5055b2..f2409f4 100644 --- a/theory.html +++ b/theory.html @@ -932,15 +932,16 @@ an older <code>zic</code>. <li> <p> The <code>TZ</code> environment variable is used in generating - the name of a binary file from which time-related information is read + the name of a file from which time-related information is read (or is interpreted à la POSIX); <code>TZ</code> is no longer - constrained to be a three-letter time zone - abbreviation followed by a number of hours and an optional three-letter - daylight time zone abbreviation. + constrained to be a string containing abbreviations + and numeric data as described <a href="#POSIX">above</a>. + The file's format is <dfn><abbr>TZif</abbr></dfn>, + a time zone information format that contains binary data. The daylight saving time rules to be used for a particular <code><abbr>tz</abbr></code> region are encoded in the - binary file; the format of the file - allows U.S., Australian, and other rules to be encoded, and + <abbr>TZif</abbr> file; the format of the file allows <abbr>US</abbr>, + Australian, and other rules to be encoded, and allows for situations where more than two time zone abbreviations are used. </p> @@ -950,7 +951,7 @@ an older <code>zic</code>. might cause "old" programs (that expect <code>TZ</code> to have a certain form) to operate incorrectly; consideration was given to using some other environment variable (for example, <code>TIMEZONE</code>) - to hold the string used to generate the binary file's name. + to hold the string used to generate the <abbr>TZif</abbr> file's name. In the end, however, it was decided to continue using <code>TZ</code>: it is widely used for time zone purposes; separately maintaining both <code>TZ</code> diff --git a/tz-link.html b/tz-link.html index b8b7944..77e06d2 100644 --- a/tz-link.html +++ b/tz-link.html @@ -143,8 +143,10 @@ more errors.</p> After obtaining the code and data files, see the <code>README</code> file for what to do next. The code lets you compile the <code><abbr>tz</abbr></code> source files into -machine-readable binary files, one for each location. It also lets -you read a <code><abbr>tz</abbr></code> binary file and interpret time stamps for that +machine-readable binary files, one for each location. The binary files +are in a special time zone information format (<dfn><abbr>TZif</abbr></dfn>). +The code also lets +you read a <abbr>TZif</abbr> file and interpret time stamps for that location.</p> <h2 id="changes">Changes to the <code><abbr>tz</abbr></code> database</h2> <p> @@ -272,12 +274,17 @@ href="https://tools.ietf.org/html/rfc7808">TZDIST</a> (Internet <abbr>RFC</abbr> 7808), a time zone data distribution service, along with <a href="https://tools.ietf.org/html/rfc7809">CalDAV</a> (Internet <abbr>RFC</abbr> 7809), a calendar access protocol for -transferring time zone data by reference. The draft <a +transferring time zone data by reference. +The <a href="https://www.ietf.org/mailman/listinfo/tzdist-bis">tzdist-bis +mailing list</a> discusses two Internet drafts: <a id="TZDIST-Geolocate" href="https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-01">TZDIST Geolocate Extension</a> lets a client determine its time zone region from its geographic location using a <a -href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>.</li> +href="https://tools.ietf.org/html/rfc5870">'geo' URI</a>, and +<a href="https://tools.ietf.org/html/draft-murchison-tzdist-tzif-00">The +Time Zone Information Format (<abbr>TZif</abbr>)</a> specifies the format of +<abbr>TZif</abbr> data.</li> <li>The <a href="https://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification (iCalendar)</a> (Internet <abbr>RFC</abbr> 5445) @@ -426,35 +433,35 @@ source into text files, along with a runtime that can read those files. Tcl is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> -<h2 id="binary">Other <code><abbr>tz</abbr></code> binary file readers</h2> +<h2 id="TZif">Other <abbr>TZif</abbr> readers</h2> <ul> <li>The <a href="https://www.gnu.org/software/libc/"><abbr>GNU</abbr> C Library</a> has an independent, thread-safe implementation of -a <code><abbr>tz</abbr></code> binary file reader. +a <abbr>TZif</abbr> file reader. This library is freely available under the LGPL and is widely used in <abbr>GNU</abbr>/Linux systems.</li> <li><a href="https://www.gnome.org">GNOME</a>'s <a href="https://developer.gnome.org/glib/">GLib</a> has -a <code><abbr>tz</abbr></code> binary file reader written in C that +a <abbr>TZif</abbr> file reader written in C that creates a <code>GTimeZone</code> object representing sets of <abbr>UT</abbr> offsets. It is freely available under the <abbr>LGPL</abbr>.</li> <li>The <a href="https://github.com/bloomberg/bde/wiki">BDE Standard Library</a>'s <code>baltzo::TimeZoneUtil</code> component contains a C++ -implementation of a binary file reader. It is freely available under +implementation of a <abbr>TZif</abbr> file reader. It is freely available under the Apache License.</li> <li><a href="https://github.com/google/cctz">CCTZ</a> is a simple C++ library that translates between <abbr>UT</abbr> and civil time and -can read binary files. It is freely available under the Apache +can read <abbr>TZif</abbr> files. It is freely available under the Apache License.</li> <li><a href="http://bmsi.com/java/#TZ">ZoneInfo.java</a> -is a <code><abbr>tz</abbr></code> binary file reader written in Java. +is a <abbr>TZif</abbr> file reader written in Java. It is freely available under the <abbr>LGPL</abbr>.</li> <li><a href="https://github.com/derickr/timelib">Timelib</a> is a C -library that reads tz binary files and converts +library that reads <abbr>TZif</abbr> files and converts time stamps from one time zone or format to another. It is used by <a href="https://secure.php.net"><abbr title="PHP: Hypertext Preprocessor">PHP</abbr></a>, @@ -465,23 +472,23 @@ It is freely available under the <abbr>MIT</abbr> license.</li> JavaScript library that supports date arithmetic that is time zone aware. It is freely available under the <abbr>MIT</abbr> license.</li> <li>Tcl, mentioned <a href="#Tcl">above</a>, also contains a -<code><abbr>tz</abbr></code> binary file reader.</li> +<abbr>TZif</abbr> file reader.</li> <li><a href="http://search.cpan.org/perldoc?DateTime::TimeZone::Tzfile"> DateTime::TimeZone::Tzfile</a> -is a <code><abbr>tz</abbr></code> binary file reader written in Perl. +is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>The public-domain <a href="https://github.com/dbaron/tz.js">tz.js</a> library contains a Python tool that -converts <code><abbr>tz</abbr></code> binary data into +converts <abbr>TZif</abbr> data into <abbr>JSON</abbr>-format data suitable for use in its JavaScript library for time zone conversion. Dates before 1970 are not supported.</li> <li>The <a href="https://hackage.haskell.org/package/timezone-olson">timezone-olson</a> package contains <a href="https://www.haskell.org">Haskell</a> code that -parses and uses <code><abbr>tz</abbr></code> binary data. It is freely +parses and uses <abbr>TZif</abbr> data. It is freely available under a <abbr>BSD</abbr>-style license.</li> </ul> <h2 id="software">Other <code><abbr>tz</abbr></code>-based time zone software</h2> diff --git a/zic.c b/zic.c index 0c4c384..f1d0bf3 100644 --- a/zic.c +++ b/zic.c @@ -184,7 +184,7 @@ static bool yearistype(zic_t year, const char * type); enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; /* If true, work around a bug in Qt 5.6.1 and earlier, which mishandles - tz binary files whose POSIX-TZ-style strings contain '<'; see + TZif files whose POSIX-TZ-style strings contain '<'; see QTBUG-53071 <https://bugreports.qt.io/browse/QTBUG-53071>. This workaround will no longer be needed when Qt 5.6.1 and earlier are obsolete, say in the year 2021. */ -- 2.7.4

1 0

[PROPOSED] ‘white-space: pre-wrap’ to avoid tiny fonts
by Paul Eggert May 16, 2018

May 16, 2018

* theory.html, tz-how-to.html, tz-link.html: Use ‘white-space: pre-wrap’ to avoid tiny font on Android mobile browsers. Migrate this style setting to a <style> element, and be consistent about it in the tz web pages. --- theory.html | 3 +++ tz-how-to.html | 3 +++ tz-link.html | 9 ++++++--- 3 files changed, 12 insertions(+), 3 deletions(-) diff --git a/theory.html b/theory.html index 0ada9e3..2d6e505 100644 --- a/theory.html +++ b/theory.html @@ -3,6 +3,9 @@ <head> <title>Theory and pragmatics of the tz code and data</title> <meta charset="UTF-8"> + <style> + pre {margin-left: 2em; white-space: pre-wrap;} + </style> </head> <body> diff --git a/tz-how-to.html b/tz-how-to.html index a54f54a..367c6ed 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -5,6 +5,9 @@ <head> <title>How to Read the tz Database</title> <meta http-equiv="Content-type" content='text/html; charset="UTF-8"'> +<style> +pre {margin-left: 2em; white-space: pre-wrap;} +</style> </head> <body> <h2>How to Read the <a href="https://en.wikipedia.org/wiki/Tz_database">tz diff --git a/tz-link.html b/tz-link.html index b8b7944..87241da 100644 --- a/tz-link.html +++ b/tz-link.html @@ -3,6 +3,9 @@ <head> <title>Sources for time zone and daylight saving time data</title> <meta charset="UTF-8"> +<style> +pre {margin-left: 2em; white-space: pre-wrap;} +</style> </head> <body> <h1>Sources for time zone and daylight saving time data</h1> @@ -97,7 +100,7 @@ href="https://en.wikipedia.org/wiki/Unix_shell">shell</a> commands download the latest release's two <a href="https://en.wikipedia.org/wiki/Tar_(computing)">tarballs</a> to a <abbr>GNU</abbr>/Linux or similar host.</p> -<pre style="margin-left: 2em"><code>mkdir tzdb +<pre><code>mkdir tzdb cd tzdb <a href="https://www.gnu.org/software/wget/">wget</a> https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz wget https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz @@ -107,7 +110,7 @@ gzip -dc tzdata-latest.tar.gz | tar -xf - <p>Alternatively, the following shell commands download the same release in a single-tarball format containing extra data useful for regression testing:</p> -<pre style="margin-left: 2em"><code>wget <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a> +<pre><code>wget <a href="https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz">https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz</a> <a href="https://www.nongnu.org/lzip/">lzip</a> -dc tzdb-latest.tar.lz | tar -xf - </code></pre> <p>These commands use convenience links to the latest release @@ -133,7 +136,7 @@ less-secure protocol.</p> <p>Alternatively, a development repository of code and data can be retrieved from <a href="https://github.com">GitHub</a> via the shell command:</p> -<pre style="margin-left: 2em"><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> +<pre><code><a href="https://git-scm.com">git</a> clone <a href="https://github.com/eggert/tz">https://github.com/eggert/tz</a> </code></pre> <p> Since version 2012e, each release has been tagged in development repositories. -- 2.17.0

1 0

Brazilian Timezone
by Christian Brackmann May 16, 2018

May 16, 2018

Hello! I wonder about the brazilian timezone you call as "America/Sao_Paulo". In Brazil, São Paulo is just a city (with a very large population indeed), but as oficial time in Brazil we use the capital of Brazil, called "Brasília". Why do you use the city of São Paulo as reference? Our legal local time is Brasilia and not São Paulo. Can you please explain it better? Thank you in advance. Best regards. *--* Prof. Dr. Christian Puhlmann Brackmann Coordenador Geral de Pós-Graduação Pró-Reitoria de Pesquisa, Pós-graduação e Inovação Instituto Federal de Educação, Ciência e Tecnologia Farroupilha (IFFAR) brackmann(a)iffarroupilha.edu.br +55 55 3226 6636 / 98100-1819 ** *“Education is the most powerful weapon which you can use to change the world”*Nelson Mandela

2 1

Gripe about compressed rule set names in tzdata.zi
by Tom Lane May 14, 2018

May 14, 2018

Reviewing the changes between 2018d and 2018e crystallized something that had not been clear to me before: the "compressed" ruleset names used in tzdata.zi are chosen as sequential ASCII characters, or pairs of ASCII letters after the single-character names run out. This means that addition or deletion of a ruleset near the beginning of the file creates semantically-insignificant changes throughout the rest of the file, making it hard to review the diffs to get a sense of what changed, or to eyeball-validate the .zi file. It probably also bloats one's repository if storing tzdata.zi in a source code control system. So I'm wondering if it'd be acceptable to change the compression rule to something that gives more stable results. I've not really experimented to see what would work well, but one simple idea is to take the shortest unique prefix of each original ruleset name. There are other options if shortness is prized well above readability. I wouldn't expect the results to be 100% stable in the face of ruleset additions/deletions, since conflicts could appear or disappear, but 99% would be fine. Regardless of the specifics, this would surely have the effect of making tzdata.zi a bit bigger (although compression would likely buy back much of the delta). So, if nobody but me is annoyed by the current behavior, I'd expect such a proposal to get rejected. I'm willing to do the legwork to develop a concrete patch if it'd be likely to get accepted. regards, tom lane

2 4

new mailing list: tzdist-bis@ietf.org
by Eliot Lear May 11, 2018

May 11, 2018

Hello everyone, I would like to bring to your attention two drafts that we have formed a mailing list around two drafts: draft-murchison-tzdist-geolocate-01 The Time Zone Data Distribution Service (TZDIST) Geolocate Extension The basic idea behind this draft is, given a geo: URI, please provide provide an appropriate TZID. And draft-murchison-tzdist-tzif-00 The Time Zone Information Format (TZif) This document is the one I've been waiting for a long time: it describes the format that those tz files have been using, and it features as co-authors Paul Eggert and Arthur David Olson. The intent is to do a sort of micro-wg to get both of these docs turned into RFCs. To do that, we need good reviewers, particularly ones who have previously cracked and parsed the tz files (bonus points if you were crazy enough to write out one!!). There is a mailing list for this purpose: tzdist-bis(a)ietf.org. You can join it by going to https://www.ietf.org/mailman/listinfo/tzdist-bis. I look forward to seeing a few of you over there (you know who you are). Eliot

1 0

Time in Macau
by P Chan May 10, 2018

May 10, 2018

Hi, I would like to share some information about the history of time in Macau. All the sources I used can be accessed online. LegisMac http://legismac.safp.gov.mo/legismac/descqry/Descqry.jsf?lang=pt A database for searching titles of legal documents of Macau in Chinese and Portuguese. The term "HORÁRIO DE VERÃO" can be used for searching decrees about summer time. Archives of Macao http://www.archives.gov.mo/en/bo/ It contains images of old official gazettes. The Macao Meteorological and Geophysical Bureau have a page listing the summer time history. But it is not complete and has some mistakes. <http://www.smg.gov.mo/smg/geophysics/c_t_Summer%20Time.htm>http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm Macau adopted GMT+8 on 30 Oct 1904 to follow Hong Kong. Clocks were advanced by 25 minutes and 50 seconds. Which means the LMT used was +7:34:10. As stated in the "Portaria N.º 204" dated 21 October 1904 and published in the Official Gazette on 29 October 1904. http://igallery.icm.gov.mo/Images/Archives/BO/MO_AH_PUB_BO_1904_10/MO_AH_PU… Therefore the 1911 decree of Portugal did not change time in Macau. >From LegisMac, here is a list of decrees that changed the time. Decree Gazette no. Gazette date Title DIL 732 BOCM 51 1941.12.20 adoptando medidas excepcionais que garantam o funcionamento de todos os serviços públicos e particulares e restringindo ao mínimo o consumo de alguns géneros e artigos essenciais à vida da colónia. DIL 764 BOCM 9S 1942.04.30 Determinando que sejam adiantadas de uma hora os relógios da colónia e regulando os horários das repartições públicas. DIL 781 BOCM 21 1942.10.10 Substituindo o corpo do artigo 3° do diploma legislativo n° 732 e suas alíneas a) e b), respeitantes às alterações da hora e horário das Repartições Públicas, e revogando o diploma legislativo n° 764. PT 3434 BOCM 8S 1943.04.17 determinando que às 23 horas do dia 30 do corrente mês sejam adiantadas de uma hora os relógios da colónia e regulando o horário das Repartições Públicas. PT 3504 BOCM 20 1943.09.25 regulando o horário das Repartições Públicas e determinando que no dia 30 do corrente, às 23 horas, os relógios sejam atrasados de uma hora. PT 3843 BOCM 39 1945.09.29 regulando o horário das Repartições Públicas e determinando que no dia 30 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 3961 BOCM 17 1946.04.27 Determinando que, a partir das 23 horas do dia 30 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4026 BOCM 39 1946.09.28 estabelecendo o horário da Repartições Públicas e determinando que no dia 30 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 4153 BOCM 16 1947.04.10 Determinando que, a partir das 23 horas do dia 19 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4271 BOCM 48 1947.11.29 Determinando que, a aprtir do dia 30 do corrente às 24 horas, os relógios sejam atrasados de uma hora. PT 4374 BOCM 18 1948.05.01 Determina que, a partir das 23 horas do dia 2 do corrente mês, sejam adiantados de uma hora os relógios de Colónia. PT 4465 BOCM 44 1948.10.30 Determina que no dia 31 do corrente mês, às 24 horas, os relógios sejam atrasados de uma hora. PT 4590 BOCM 14 1949.04.02 Determina que, a partir das 23 horas do dia 2 do corrente mês, sejam adiantados de uma hora os relógios da Colónia. PT 4666 BOCM 44 1949.10.29 Determina que no dia 30 do corrente, a 0 hora, os relógios sejam atrasados de uma hora. PT 4771 BOCM 12 1950.03.25 Determina que, a partir das 23 horas do dia 1 do próximo mês de Abril, serão adiantados de uma horas os relógios da Colónia. PT 4838 BOCM 43 1950.10.28 Determina que no dia 28 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 4946 BOCM 12 1951.03.24 Determina que, a partir das 23 horas do dia 31 de Março do corrente ano, serão adiantados de uma hora os relógios desta colónia. PT 5025 BO 43 1951.10.27 Manda que no dia 29 do corrente, às zero horas, os relógios sejam atrasados de uma hora. PT 5149 BO 14 1952.04.05 Determina que a partir das 23 horas do dia 5 de Abril corrente serão adiantados de uma hora os relógios desta província. PT 5251 BO 43 1952.10.25 Determina que no dia 2 do próximo mês de Novembro, às zero horas, os relógios serão atrasados de uma hora. PT 5366 BO 13 1953.03.28 Determina que a partir das 23 horas do dia 4 do próximo mês de Abril serão adiantados de uma hora os relógios desta província. PT 5444 BO 44 1953.10.31 Determina que no dia 31 do corrente, às 24 horas, os relógios sejam atrasados de uma hora. PT 5540 BO 12 1954.03.20 Determina que, a partir das 23 horas de hoje, serão adiantados de uma hora os relógios da Província. PT 5589 BO 44 1954.10.30 Determina que, a partir das 24,00 horas de hoje, 30 do corrente, os relógios sejam atrasados de uma hora. PT 5676 BO 12 1955.03.19 Manda adiantar de uma hora os relógios da Província, a partir das 23 horas de hoje, 19 do corrente. PT 5739 BO 45 1955.11.05 Determina que às 24,00 horas de hoje, 5 de corrente, os relógios sejam atrasados de uma hora. PT 5823 BO 11 1956.03.17 Determina que a partir das 23 horas de hoje, 17 do corrente, serão adiantados de uma hora os relógios da Província. PT 5891 BO 44 1956.11.03 Determina que no dia 4 do corrente mês, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 5981 BO 12 1957.03.23 Determina que, a partir das 3,30 horas do dia 24 do corrente mês, sejam adiantados de uma hora os relógios da Província. PT 6064 BO 43 1957.10.26 Determina que no dia 3 do próximo mês do Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6172 BO 12 1958.03.22 Determina que, a partir das 3,30 horas do dia 23 do corrente mês, sejam adiantados de uma hora os relógios da Província. PT 6243 BO 43 1958.10.25 Determina que no dia 2 do próximo mês do Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6341 BO 12 1959.03.21 Determina que, a partir das 3,30 horas do dia 22 do corrente, sejam adiantados de uma hora os relógios da Província. PT 6411 BO 43 1959.10.24 Determina que no dia 1 do próximo mês de Novembro, às 3 horas e 30 minutos, os relógios sejam atrasados de uma hora. PT 6514 BO 11 1960.03.12 Determina que, a partir das 3,30 horas do dia 20 do corrente, sejam adiantados de uma hora os relógios da Província. PT 6584 BO 44 1960.10.29 Determina que no dia 6 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 6721 BO 10 1961.03.11 Determina que, a partir das 3,30 horas do dia 19 do corrente, sejam adiantados os relógios da Província. PT 6815 BO 43 1961.10.28 Determina que no dia 5 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 6947 BO 10 1962.03.10 Determina que a partir das 3,30 horas do dia 18 do corrente, sejam adiantados de uma hora os relógios da província. PT 7080 BO 43 1962.10.27 Determina que no dia 4 do próximo mês de Novembro, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 7218 BO 12 1963.03.23 Determina que a partir das 3,30 horas do dia 24 do corrente, sejam adiantados de uma hora os relógios de província. PT 7340 BO 43 1963.10.26 Detremina que a partir da 3,30 horas do dia 3 do próximo mês de Novembro, sejam atrasados de uma hora os relógios da província. PT 7491 BO 11 1964.03.14 Determina que a partir das 3,30 horas do dia 22 do corrente, os relógios sejam adiantados uma hora. PT 7664 BO 43 1964.10.24 Determina que a partir das 3,30 horas do dia 1 do próximo mês de Novembro, sejam atrasados de uma hora os relógios da província. PT 7846 BO 15 1965.04.10 Determina que a partir das 3,30 horas do dia 18 do corrente, os relógios sejam adiantados de uma hora. PT 7979 BO 42 1965.10.16 Determina que, a partir das 2,30 horas do próximo dia 17 do corrente, sejam atrasados de uma hora os relógios da província. PT 8146 BO 15 1966.04.09 Determina que os relógios da província sejam adiantados de uma hora, a partir das 3,30 horas do dia 17 do corrente. PT 8252 BO 41 1966.10.08 Determina que, às 2,30 horas do dia 16 do corrente, os relógios sejam atrasados de uma hora. PT 8429 BO 15 1967.04.15 Manda que no dia 16 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 8540 BO 41 1967.10.14 Manda que, no próximo dis 22 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 8735 BO 15 1968.04.13 Manda que no dia 21 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 8860 BO 41 1968.10.12 Manda que, no próximo dia 20 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 9035 BO 16 1969.04.19 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9156 BO 42 1969.10.18 Manda que no dia 19 do corrente, às relógios sejam atrasados de uma hora. PT 9328 BO 15 1970.04.11 Manda que no dia 19 do corrente às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9418 BO 41 1970.10.10 Manda que no dia 18 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 9587 BO 14 1971.04.03 Manda que no dia 18 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 9702 BO 41 1971.10.09 Manda que no dia 17 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 38-A/72 BO 14 1972.04.01 Manda que no dia 16 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 126-A/72 BO 41 1972.10.07 Manda que no dia 22 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 61/73 BO 14 1973.04.07 Manda que no dia 22 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 182/73 BO 40 1973.10.06 Manda que no dia 21 do corrente, às 3.30 horas, os relógios sejam atrasados de uma hora. PT 282/73 BO 51 1973.12.22 Manda que no dia 30 do corrente mês de Dezembro, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 177/74 BO 41 1974.10.12 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 51/75 BO 15 1975.04.12 Manda que no dia 20 do corrente, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 173/75 BO 41 1975.10.11 Manda que no dia 19 do corrente mês, às 3,30 horas, os relógios sejam atrasados de uma hora. PT 67/76/M BO 14 1976.04.03 Manda que no dia 18 de Abril do corrente ano, às 3,30 horas, os relógios sejam adiantados de uma hora. PT 169/76/M BO 41 1976.10.09 Manda que, no dia 17 de Outubro corrente, às 3,30 horas, os relógios, sejam atrasados de uma hora. PT 78/79/M BO 19 1979.05.12 Manda que, no dia 13 de Maio de 1979, os relógios sejam adiantados de uma hora. PT 166/79/M BO 42 1979.10.20 Manda que, no dia 21 de Outubro de 1979, os relógios sejam atrasados de uma hora. Note that DIL 732 does not belong to "HORÁRIO DE VERÃO" according to LegisMac. Here is a list of time change according to the decrees, each change corresponds to each decree. Date Time Change 1941-12-21 Sun 2300 +1 1942-04-30 Thu 2300 +1 1942-11-17 Tue 2300 -1 1943-04-30 Fri 2300 +1 1943-09-30 Thu 2300 -1 1945-09-30 Sun 2400 -1 1946-04-30 Tue 2300 +1 1946-09-30 Mon 2400 -1 1947-04-19 Sat 2300 +1 1947-11-30 Sun 2400 -1 1948-05-02 Sun 2300 +1 1948-10-31 Sun 2400 -1 1949-04-02 Sat 2300 +1 1949-10-30 Sun 0000 -1 1950-04-01 Sat 2300 +1 1950-10-28 Sat 2400 -1 1951-03-31 Sat 2300 +1 1951-10-29 Mon 0000 -1 1952-04-05 Sat 2300 +1 1952-11-02 Sun 0000 -1 1953-04-04 Sat 2300 +1 1953-10-31 Sat 2400 -1 1954-03-20 Sat 2300 +1 1954-10-30 Sat 2400 -1 1955-03-19 Sat 2300 +1 1955-11-05 Sat 2400 -1 1956-03-17 Sat 2300 +1 1956-11-04 Sun 0330 -1 1957-03-24 Sun 0330 +1 1957-11-03 Sun 0330 -1 1958-03-23 Sun 0330 +1 1958-11-02 Sun 0330 -1 1959-03-22 Sun 0330 +1 1959-11-01 Sun 0330 -1 1960-03-20 Sun 0330 +1 1960-11-06 Sun 0330 -1 1961-03-19 Sun 0330 +1 1961-11-05 Sun 0330 -1 1962-03-18 Sun 0330 +1 1962-11-04 Sun 0330 -1 1963-03-24 Sun 0330 +1 1963-11-03 Sun 0330 -1 1964-03-22 Sun 0330 +1 1964-11-01 Sun 0330 -1 1965-04-18 Sun 0330 +1 1965-10-17 Sun 0230 -1 1966-04-17 Sun 0330 +1 1966-10-16 Sun 0230 -1 1967-04-16 Sun 0330 +1 1967-10-22 Sun 0330 -1 1968-04-21 Sun 0330 +1 1968-10-20 Sun 0330 -1 1969-04-20 Sun 0330 +1 1969-10-19 Sun 0330 -1 1970-04-19 Sun 0330 +1 1970-10-18 Sun 0330 -1 1971-04-18 Sun 0330 +1 1971-10-17 Sun 0330 -1 1972-04-16 Sun 0330 +1 1972-10-22 Sun 0330 -1 1973-04-22 Sun 0330 +1 1973-10-21 Sun 0330 -1 1973-12-30 Sun 0330 +1 1974-10-20 Sun 0330 -1 1975-04-20 Sun 0330 +1 1975-10-19 Sun 0330 -1 1976-04-18 Sun 0330 +1 1976-10-17 Sun 0330 -1 1979-05-13 Sun 0330 +1 1979-10-21 Sun 0330 -1 Note that between 1942 and 1945, the time switched between GMT+9 and GMT+10. Also in 1965 and 1965 the DST ended at 2:30am. I actually don't speak Portuguese, please correct me if I'm wrong. Regards, P Chan

2 1

'Pyongyang Time' scrapped as North Korea synchronises clocks with the South
by Kim Sungwoo May 9, 2018

May 9, 2018

Hello, I am Sungwoo Kim, leave in Seoul, Republic of Korea. (South Korea) Since 5. 5. 2018, Pyongyang Time - North Korea time - had synchronized with South. We should discussion how we can synchronize PYT to KST with less side-effect. Here is articles include more information and backgrounds. https://www.telegraph.co.uk/news/2018/05/05/pyongyang-time-scrapped-north-k… http://www.xinhuanet.com/english/2018-05/05/c_137158132.htm http://calgarysun.com/news/world/no-more-pyongyang-time-north-korea-changes… https://qz.com/1265352/north-korea-will-reunifying-its-time-zone-with-south…

4 3

China DST
by chan jason May 7, 2018

May 7, 2018

Hi, There are some mistakes in the rules of PRC. The start and end time of DST in China should be 2:00 (i.e. 2:00 to 3:00 at the start and 2:00 to 1:00 at the end). Also in 1988, the start date should be 17 May instead of 10 May. Government notices about summer time: 1986-04-12 http://www.zj.gov.cn/attach/zfgb/198608.pdf p.21-22 (To establish summer time from 1986. On 4 May, set the clocks ahead one hour at 2 am. On 14 September, set the clocks backward one hour at 2 am.) 1987-02-15 http://www.gov.cn/gongbao/shuju/1987/gwyb198703.pdf p.114 (Summer time in 1987 to start from 12 April until 13 September) 1987-09-09 http://www.gov.cn/gongbao/shuju/1987/gwyb198721.pdf p.709 (From 1988, summer time to start from 2 am of the first Sunday of mid-April until 2 am of the first Sunday of mid-September) 1992-03-03 http://www.gov.cn/gongbao/shuju/1992/gwyb199205.pdf p.152 (To suspend summer time from 1992) The first page of People's Daily on 12 April 1988 stating that summer time to begin on 17 April. http://data.people.com.cn/pic/101p/1988/04/1988041201.jpg Proposed rules: Rule PRC 1986 only - May 4 2:00 1:00 D Rule PRC 1986 1991 - Sep Sun>=11 2:00 0 S Rule PRC 1987 1991 - Apr Sun>=11 2:00 1:00 D Regards, P Chan

4 4

Update for tz-how-to.html?
by Kerry Shetline May 6, 2018

May 6, 2018

Could we get an update to the tz-how-to.html document which: 1) Explains how to parse tzdata files for vanguard, rearguard, and standard versions? It looks like the way vanguard sections are not commented out, and rearguard sections are, that any third-party parser for tzdata is going to pick up vanguard zones and rules by default, rather than main. What I’d like to know how to parse the tzdata files, directly as they are found in a standard distribution, with rearguard, main, or vanguard results in mind, and without to run "make tarballs” to get a specific version. 2) Demonstrates the usage of the new ’s' and ‘d' suffixes in SAVE columns? Any help with these issues would be much appreciated. -Kerry

2 1

[PROPOSED] Today's North Korea change was at 23:30, not 24:00
by Paul Eggert May 5, 2018

May 5, 2018

* NEWS, asia (Asia/Pyongyang): Implement this. --- NEWS | 5 +++++ asia | 6 +++++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 90452b7..79d9d80 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ News for the tz database Unreleased, experimental changes + Changes to past time stamps + + The 2018-05-05 North Korea 30-minute time zone change took place + at 23:30 the previous day, not at 00:00 that day. + Changes to build procedure New 'make' target 'rearguard_tarballs' to build the rearguard diff --git a/asia b/asia index 3d30864..2e829b8 100644 --- a/asia +++ b/asia @@ -1995,6 +1995,10 @@ Rule ROK 1987 1988 - Oct Sun>=8 3:00 0 S # Assembly, as published in Rodong Sinmun. # From Tim Parenti (2018-04-29): # It appears to be the front page story at the top in the right-most column. +# +# From Paul Eggert (2018-05-04): +# The BBC reported that the transition was from 23:30 to 24:00 today. +# https://www.bbc.com/news/world-asia-44010705 # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Asia/Seoul 8:27:52 - LMT 1908 Apr 1 @@ -2007,7 +2011,7 @@ Zone Asia/Pyongyang 8:23:00 - LMT 1908 Apr 1 8:30 - KST 1912 Jan 1 9:00 - JST 1945 Aug 24 9:00 - KST 2015 Aug 15 00:00 - 8:30 - KST 2018 May 5 + 8:30 - KST 2018 May 4 23:30 9:00 - KST ############################################################################### -- 2.7.4

1 0

Morocco TZ
by Sebastien WILLEMIJNS May 4, 2018

May 4, 2018

Morocco TZ changes in 8 days... i think the list knew... https://www.africatopsuccess.com/2018/05/03/maroc-changement-dhoraire-dhive… -- --- Sébastien WILLEMIJNS

2 1

Re: [tz] [tz-announce] 2018e release of tz code and data available
by Paul Eggert May 4, 2018

May 4, 2018

On 05/04/2018 07:52 AM, J William Piggott wrote: > On 05/03/2018 08:22 PM, Paul Eggert wrote: > > 8< ... > >> ; effectively the main format now uses vanguard instead of rearguard format. > 8< ... > >> The full effect of this change is only in vanguard format; in rearguard and >> main format, the tm_isdst flag is still zero in winter and nonzero in summer. > ... > > Aren't these to statements contradictory? Yes they are, and that typo wasn't fixed until after the 2018e release was cut. You can see a copy of the fix here: https://mm.icann.org/pipermail/tz/2018-May/026447.html

1 0

[tz-announce] 2018e release of tz code and data available
by Paul Eggert May 4, 2018

May 4, 2018

The 2018e 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: North Korea switches back to +09 on 2018-05-05. The main format uses negative DST again, for Ireland etc. 'make tarballs' now also builds a rearguard tarball. New 's' and 'd' suffixes in SAVE columns of Rule and Zone lines. Changes to past and future time stamps North Korea switches back from +0830 to +09 on 2018-05-05. (Thanks to Kang Seonghoon, Arthur David Olson, Seo Sanghyeon, and Tim Parenti.) Bring back the negative-DST changes of 2018a, except be more compatible with data parsers that do not support negative DST. Also, this now affects historical time stamps in Namibia and the former Czechoslovakia, not just Ireland. The main format now uses negative DST to model time stamps in Europe/Dublin (from 1971 on), Europe/Prague (1946/7), and Africa/Windhoek (1994/2017). This does not affect UT offsets, only time zone abbreviations and the tm_isdst flag. Also, this does not affect rearguard or vanguard formats; effectively the main format now uses vanguard instead of rearguard format. Data parsers that do not support negative DST can still use data from the rearguard tarball described below. Changes to build procedure The command 'make tarballs' now also builds the tarball tzdataVERSION-rearguard.tar.gz, which is like tzdataVERSION.tar.gz except that it uses rearguard format intended for trailing-edge data parsers. Changes to data format and to code The SAVE column of Rule and Zone lines can now have an 's' or 'd' suffix, which specifies whether the adjusted time is standard time or daylight saving time. If no suffix is given, daylight saving time is used if and only if the SAVE column is nonzero; this is the longstanding behavior. Although this new feature is not used in tzdata, it could be used to specify the legal time in Namibia 1994-2017, as opposed to the popular time (see below). Changes to past time stamps From 1994 through 2017 Namibia observed DST in winter, not summer. That is, it used negative DST, as Ireland still does. This change does not affect UTC offsets; it affects only the tm_isdst flag and the abbreviation used during summer, which is now CAT, not WAST. Although (as noted by Michael Deckers) summer and winter time were both simply called "standard time" in Namibian law, in common practice winter time was considered to be DST (as noted by Stephen Colebourne). The full effect of this change is only in vanguard format; in rearguard and main format, the tm_isdst flag is still zero in winter and nonzero in summer. In 1946/7 Czechoslovakia also observed negative DST in winter. The full effect of this change is only in vanguard format; in rearguard and main formats, it is modeled as plain GMT without daylight saving. Also, the dates of some 1944/5 DST transitions in Czechoslovakia have been changed. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2018e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2018e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2018e.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 4758e88f99c71af65d73ce730e87438466032a5f dated 2018-05-01 23:42:51 -0700 and tagged '2018e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 4a245cae2d0922b24539a94cf4a8ccc2bba1ee696e0aaefecb41c7c8d78724a7fcea6039909336177b8b26fec8fc47719e3e56ca9839dbaf52f9a4fec84d4717 tzcode2018e.tar.gz d059fcd381b2f6ecdafcd68fdd2a00451d1bf9b1affeb164ae7cabca2e022d499e77f0706ec3f3091b8e84c2211aa66da6c90937108771f1bf070cfebc105cae tzdata2018e.tar.gz afb7569cc9faef6e3d2be16ceef65f8531ac123dac14e3b40a4f54dab916e930b09eb665458e55f98398c4b8c5d108f34985a42bf711b2170de90d819bf0e630 tzdb-2018e.tar.lz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJa6V9nAAoJEO2X6Q5iqn40r+EQAJSt3ap8G8swYPzBg6TstckZ tOxrDcGlRu4km6jzIhHelOwj2Sxw8X/0JyRc09xbGbXGE/mv35DrzKC8ijfazu9pg Mr4eOclfFGq8l48aRag86hR33k62K84Xdl0WrwVFVefhlsRel9i6lXnBFcmgHl/C vSwJXyrZ2DgvZH88B6j8qnYkw/BMbsTKLM1L/3EHxKZqq/TCHS19Z1XbbkF6mm/u 73aHHmXEnpSVol+3aekEKuS+PSdc+loYaAMvibBJ34ci2bc1X1HkOPF30dRSTETW pVtKXp1qFtmHRR07I28l7/jEzmI+XPheCswhOKowWqKe59tA2CTiFnkhuBQUmoZS XDjKpcgvrad9RSES1aVAfVn2iCx78Inu0W8UIWZ/eiMOh0taQH3n7K1KBnLwCEKd rAB9ummGRK787XJEe2/xnH/h0lilU7Ye6EddNwuGf5Q3PlS9brDov66dnIUWi76L uPRTufummczt6XcA9YL0zEhwvAzjSSqQzoga7mXBKSIwakRoKXCIoux+EdQOWNOy /VUMH5NIkND+kRcRdqTXs93Whu7SCV14DKi5j1LL39YC8nqGi0q3u8wndm22AhCr ZR9uMv1Qq1iCXb09sIBfdi7bf0S8348jz1deb/d7jgJ4ISBR7v8UiR3Z/JO8hiPR QSP93j37rjAsFyBSWMxq =knlj -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJa6V9nAAoJEO2X6Q5iqn40qYUQAI21DF4x+Qr9uhMf5UL3u/UI BnLTeDqc4t1oLbuuJsbtgausc/m6EIgo2j9+uadXefnguP4fwKHJ2doReuRZ3njI hGnqP2+yCfTRNrZYBU3p6U+/OJq8r/UBsn9aGxNStcZHe6FswnxXWlzpRNbPdNBC nGeYMs2HOQjcdG08BF1sjGm4FC/NS6bugNhs0EcrMLaVa+c0keRWNg9o7Y/SvrZB awFAMz4LhOog2qxhGWtFgSVRAAj5aEDqugOXZL27VszgGPexiAaMCFyQARIHigIw 959D7RYmpeNuEeP6XbzGFgDO6aMbxahoUpP9cCOUI6qKShtDKnY2XkjPmVQiAfjZ zvpsE1dYbWyVTWqWhWL3z0lPCFN6B4eneY6UXY/KtENRl1jEafKN5/7JqKOMBSRo umE1Jy6qSSz5jLuz5pX59iOXWZETIlwtAW6lKe2s6l9xWPL9R8xXoPvbQRadqDxB uANcGZSrKD1jKuybPJa/6BZRF+FlldCkZVVKSSdXuPLF1HhohlvFZqi1WPmWvGd+ s/1+3OhWzB4BHyrp3Wbtj+ZwCtg9UVbJLBM2bgL9nGEyv/1XSxgLJEp3rneIMpJv AMK8rr3XehXLDkXAfx68Mzs3F4lYEdXk6y9f9ZsVj+IdBotwzzjJWeCfnlmJM52y 8cCrPGUjdneFidV9OZ+J =4LFO -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJa6V9pAAoJEO2X6Q5iqn40EBwP/1fxMc1IozcXCWSm+h/XZ3M+ bImmIdf8Ws/FZC5yXHWkU4n3DZN6A2Xf/dDTDaZPeyhL3rjd6ju0zxTsQpxdqRms FrEiqlq2CpIVe+pY4EeowfsFdKVYIxtiTw9BNytaDOIgYxRmokNUQusaHw2qrZg6 t6giUhH6bh1/YgZakFP65WItjESR8Dg4aJ7X1f8BJkSEyy9I2lnyWOG7LwB8xNvS YRPRjkVqdVXzdS9MtqO+U5b9pe1MvU6q0lRAOwUvZsGfB7fULkdQcS1XaYDVRdPA WdMKqn21S+oRHYzX5/BZHE68uGFlufPohikYfSCO6pk8eqDe0xbkOl6fpgjjqTZf wCAcZBBoCP11lH8Omdu8bW6LJ0q1jkwuCZxmLBPwonInoByPO/TeDstYSp39KCv2 +w0pl87uYe6/IEwSC1bH0HBF8kzcEq5q5JVHLyqwOKrAm6Nfm5sC5vWFhk3GmMGU FGpFLnwUJlTefy9X3ds8zEvmCAiFMisu5cciMRwfCLvTHSObRGEXtp5pxpr0VhBf A6Qc+83JPTwhEWdVQMVbEWRkkJNG50xAwOhjJaClXjjlvJqQtpUPHLR7fRaQWvm8 sCXhh+PeWpgIbbzaE7TzkVu9sLUGiIvbLiP2yNMOuoZp+UUnrsSaswbeCl0bkGe3 LSswAxioa5rs8zd8WtZe =/AeX -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets,this particular release's data entries are also available in arearguard-format tarball and signature that does not contain suchoffsets. This is intended to be a temporary transition aid for theseparsers. The URLs are: https://web.cs.ucla.edu/~eggert/tz/release/2018e/tzdata2018e-rearguard.tar.… https://web.cs.ucla.edu/~eggert/tz/release/2018e/tzdata2018e-rearguard.tar.… with the following SHA-512 and GPG checksums: dd92cf2d01388d52731db7569360e3c7e673c3189c8cba807d031fb6b6ce8c115d3f4de3be1c7a6b1e038fa919efdd254cdd4f7731c3130b447dee2c7c5814a4 tzdata2018e-rearguard.tar.gz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJa6V9oAAoJEO2X6Q5iqn40jJMP+gKGNy3VBhJ9B2/plNXta2nH M5fAwJphPXutCv2ums0LPVNbi0FWjPo9T2/6Lmy71vyyusW/9ltS+/bECSnmrZRO VEql2UWghxGMaV3Y2wpFI2XGqepQYsT9Xa1tgXUvXHakQPYe5Osx0J3P50F9ROMy kiWR4VSsSE3IZDiZC32HQjcHsREcUtpgYfn943Zr1Go2FRnp2esnbN0eQtTV5vJW uSYWdfSNWNsSqXR9O2cq9kzCeVKxZjjs2hi1adIrQLzQKy26RXUC9f4tepzRrPfT euHiHUrZXE5p2161Q702P1Nw3zPFrA/SHiFZTpP84mri60RVZTWPP21ityktFukt B+Ebkpd7EwyyFFZB1grbnb1uLc2qkM76gKtIPJAtkWEe7BwwwREh9d/92K/L9XTe opehULRUjX65UyOWNUD9dl3aiy1FHQyWAuX3fRF1u2vrh3WSuIHbO0Uq9RCMQtHP VSY45Ldwv3+PGfyaKlQvftqFAFJ2kjmIC7zQZe5HmBIYG8TIyUCS/P17XZzIrEpw aBNrPe4hV63DSVEvBYLHaCPMMIASASBvSZ2S5Rb2HopAzVd6xOYSvGCqwjdtFpr6 1bD4EeIb2wBxPWH8KFZiSDYK/FpfhuZR7teY6bzG+fsZMtzChP4pcQrebMD3RIPZ RBDXrhtfn+5b78wn6VMM =VPo7 -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Pyongyang Time transition plan announced
by Seo Sanghyeon May 3, 2018

May 3, 2018

Rodong Sinmun 2018-04-30 announced Pyongyang Time transition plan. https://www.nknews.org/kcna/wp-content/uploads/sites/5/2018/04/rodong-2018-… I won't translate, but even if you don't know Korean it should be easy to confirm that the transition date is 2018-05-05. 2018 is Juche 107. Citation should be Decree No. 2232 of April 30, 2018, of the Presidum of the Supreme People's Assembly, as published in Rodong Sinmun. -- Seo Sanghyeon

7 12

[PROPOSED] Fix typos in 2018e historical NEWS
by Paul Eggert May 3, 2018

May 3, 2018

* NEWS: Fix typos in description of 2018e’s changes to historical timestamps in Namibia and Czechoslovakia. --- NEWS | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index e985ce6..90452b7 100644 --- a/NEWS +++ b/NEWS @@ -64,12 +64,12 @@ Release 2018e - 2018-05-01 23:42:51 -0700 both simply called "standard time" in Namibian law, in common practice winter time was considered to be DST (as noted by Stephen Colebourne). The full effect of this change is only in vanguard - format; in rearguard and main format, the tm_isdst flag is still + and main format; in rearguard format, the tm_isdst flag is still zero in winter and nonzero in summer. In 1946/7 Czechoslovakia also observed negative DST in winter. - The full effect of this change is only in vanguard format; in - rearguard and main formats, it is modeled as plain GMT without + The full effect of this change is only in vanguard and main + formats; in rearguard format, it is modeled as plain GMT without daylight saving. Also, the dates of some 1944/5 DST transitions in Czechoslovakia have been changed. -- 2.17.0

1 0

[PROPOSED] Port better to GCC 8
by Paul Eggert May 1, 2018

May 1, 2018

* private.h (ATTRIBUTE_MALLOC): New macro. Use this and related macros starting with GCC 3.0, not GCC 2.96 which was not an official release. * zdump.c (xmalloc): * zic.c (emalloc, ecpyalloc): Use it to pacify -Wsuggest-attribute=malloc with GCC 8. --- private.h | 4 +++- zdump.c | 2 +- zic.c | 4 ++-- 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/private.h b/private.h index 705544e..641f905 100644 --- a/private.h +++ b/private.h @@ -342,12 +342,14 @@ typedef unsigned long uintmax_t; #define SIZE_MAX ((size_t) -1) #endif -#if 2 < __GNUC__ + (96 <= __GNUC_MINOR__) +#if 3 <= __GNUC__ # define ATTRIBUTE_CONST __attribute__ ((const)) +# define ATTRIBUTE_MALLOC __attribute__ ((__malloc__)) # define ATTRIBUTE_PURE __attribute__ ((__pure__)) # define ATTRIBUTE_FORMAT(spec) __attribute__ ((__format__ spec)) #else # define ATTRIBUTE_CONST /* empty */ +# define ATTRIBUTE_MALLOC /* empty */ # define ATTRIBUTE_PURE /* empty */ # define ATTRIBUTE_FORMAT(spec) /* empty */ #endif diff --git a/zdump.c b/zdump.c index 1081648..a4d9108 100644 --- a/zdump.c +++ b/zdump.c @@ -136,7 +136,7 @@ sumsize(size_t a, size_t b) /* Return a pointer to a newly allocated buffer of size SIZE, exiting on failure. SIZE should be nonzero. */ -static void * +static void * ATTRIBUTE_MALLOC xmalloc(size_t size) { void *p = malloc(size); diff --git a/zic.c b/zic.c index 90ae1f4..31f1092 100644 --- a/zic.c +++ b/zic.c @@ -447,7 +447,7 @@ memcheck(void *ptr) return ptr; } -static void * +static void * ATTRIBUTE_MALLOC emalloc(size_t size) { return memcheck(malloc(size)); @@ -459,7 +459,7 @@ erealloc(void *ptr, size_t size) return memcheck(realloc(ptr, size)); } -static char * +static char * ATTRIBUTE_MALLOC ecpyalloc (char const *str) { return memcheck(strdup(str)); -- 2.17.0

1 0

[PROPOSED] Use GCC 8 for debugging
by Paul Eggert April 30, 2018

April 30, 2018

* Makefile (GCC_DEBUG_FLAGS): Use flags appropriate for GCC 8. --- Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3ac1a67..21fa488 100644 --- a/Makefile +++ b/Makefile @@ -236,14 +236,16 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ $(GCC_INSTRUMENT) \ -Wall -Wextra \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ - -Wbad-function-cast -Wcast-align -Wdate-time \ + -Wbad-function-cast -Wcast-align=strict -Wdate-time \ -Wdeclaration-after-statement -Wdouble-promotion \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ -Winit-self -Wjump-misses-init -Wlogical-op \ -Wmissing-declarations -Wmissing-prototypes -Wnested-externs \ -Wold-style-definition -Woverlength-strings -Wpointer-arith \ - -Wshadow -Wshift-overflow=2 -Wstrict-prototypes -Wstringop-overflow=5 \ + -Wshadow -Wshift-overflow=2 -Wstrict-prototypes -Wstringop-overflow=4 \ + -Wstringop-truncation -Wsuggest-attribute=cold \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ + -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ -Wtrampolines -Wundef -Wuninitialized -Wunused \ -Wvariadic-macros -Wvla -Wwrite-strings \ -- 2.17.0

1 0

DPRK to revert to UTC+9 from UTC+8:30
by Kang Seonghoon April 30, 2018

April 30, 2018

On 2018-04-29 (+09:00), according to Yoon Young-chan, senior presidental secretary for public relations of South Korea, has announced that North Korea will revert its time zone from UTC+8:30 (PYT; Pyongyang Time) back to UTC+9 (KST; Korea Standard Time), in lieu of the recent Panmunjom Declaration. Yet another time to change tzdata? Source: South and North agreed to unify PYT to KST, Yonhap News http://m.yna.co.kr/kr/contents/?cid=AKR20180429018500001 (no English translation exists right now) -- -- Kang Seonghoon | https://mearie.org/ -- Opinions expressed in this email do not necessarily represent the views of my employer. --

4 4

North Korea timezone to become GMT+9 from May 5 2018
by Phake Nick April 30, 2018

April 30, 2018

The URL to the announcement cannot be directly copied, but you can access www.kcna.kp then select "English" on top right hand corner, and then there will be an article titled "SPA Presidium of DPRK Decides to Reset Pyongyang Time" which talk about the upcoming change in time in North Korea. Media outside North Korea have reported about it too. However, there are no info with respect to exactly which moment in May 5 are they switching their timezone

3 3

North Korea to match South Korea's time zone
by Arthur David Olson April 29, 2018

April 29, 2018

A tweet from Jef Poskanzer... https://twitter.com/jef_poskanzer/status/990430801903865856 ...alerted me to North Korea's plan to match South Korea's time zone. An AP item on the matter... https://apnews.com/301adfec088647c1b1cbc69eb4b0949a ...cites South Korean President Moon Jae-in's spokesperson Yoon Young-chan; referring to North Korean leader Kim Jong Un, " Yoon said Kim...revealed plans to re-adjust its current time zone to match the South’s." No word in the AP item on specifics of the plan. @dashdashado

2 1

[PROPOSED] Support zi parsers that mishandle negative DST offsets
by Paul Eggert April 23, 2018

April 23, 2018

This is intended to provide a way to support both clients that require data to have only positive DST offsets, and clients that do not have this restriction. * Makefile (XDST, SDST): New macros. (TZDATA_ZI_DEPS): Add zidst.awk. (DSTDATA_ZI_DEPS): New macro. (all): Depend on fulldata.zi and pdstdata.zi. (fulldata.zi pdstdata.zi): New rule. (tzdata.zi): Use $(XDST)data.zi instead of reading original source. (check_zishrink): Check zidst.awk, too. (clean): Remove all *.zi files, not just tzdata.zi. * NEWS, europe: Mention this. * zidst.awk: New file. --- Makefile | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++----------- NEWS | 30 ++++++++++++++++++++++++++++++ europe | 39 ++++++++++++++++++++++----------------- zidst.awk | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 154 insertions(+), 28 deletions(-) create mode 100644 zidst.awk diff --git a/Makefile b/Makefile index 8c84cd9..92ddb80 100644 --- a/Makefile +++ b/Makefile @@ -10,6 +10,26 @@ VERSION= unknown # Email address for bug reports. BUGEMAIL= tz(a)iana.org +# To install the full data, which can contain daylight saving time +# offsets that are negative (relative to standard time), use +# XDST= full +# To install data containing only positive daylight saving time +# offsets, but otherwise as close to the full data as practical, use +# XDST= pdst +XDST= pdst +# Parsers requiring DST offsets to be positive should use the file +# pdstdata.zi, which contains almost all the data of 'africa' etc., +# except with positive DST offsets. This works around a problem that +# was discovered in January 2018 with negative DST in tests for ICU +# and OpenJDK. See: +# https://mm.icann.org/pipermail/tz/2018-January/025825.html +# https://mm.icann.org/pipermail/tz/2018-January/025822.html +# Currently the 'africa' etc. files use pdst form if comments are +# ignored, to ease transition for parsers that do not support +# negative DST offsets. This is intended to change to full form at +# some point, so that full-featured zi parsers that use the 'africa' +# files will get the full data without changing anything. + # Change the line below for your time zone (after finding the zone you want in # the time zone files, or adding it to a time zone file). # Alternately, if you discover you've got the wrong time zone, you can just @@ -463,7 +483,8 @@ TDATA= $(YDATA) $(NDATA) $(BACKWARD) ZONETABLES= zone1970.tab zone.tab TABDATA= iso3166.tab $(TZDATA_TEXT) $(ZONETABLES) LEAP_DEPS= leapseconds.awk leap-seconds.list -TZDATA_ZI_DEPS= zishrink.awk version $(TDATA) $(PACKRATDATA) +TZDATA_ZI_DEPS= zidst.awk zishrink.awk version $(TDATA) $(PACKRATDATA) +DSTDATA_ZI_DEPS= zidst.awk $(TDATA) $(PACKRATDATA) DATA= $(TDATA_TO_CHECK) backzone iso3166.tab leap-seconds.list \ leapseconds yearistype.sh $(ZONETABLES) AWK_SCRIPTS= checklinks.awk checktab.awk leapseconds.awk zishrink.awk @@ -500,7 +521,8 @@ VERSION_DEPS= \ SHELL= /bin/sh -all: tzselect yearistype zic zdump libtz.a $(TABDATA) +all: tzselect yearistype zic zdump libtz.a $(TABDATA) \ + fulldata.zi pdstdata.zi ALL: all date $(ENCHILADA) @@ -535,11 +557,15 @@ version: $(VERSION_DEPS) printf '%s\n' "$$V" >$@.out mv $@.out $@ -# This file can be tailored by setting BACKWARD, PACKRATDATA, etc. -tzdata.zi: $(TZDATA_ZI_DEPS) +# These files can be tailored by setting BACKWARD, PACKRATDATA, etc. +fulldata.zi pdstdata.zi: $(DSTDATA_ZI_DEPS) + $(AWK) -v outfile='$@' -f zidst.awk $(TDATA) $(PACKRATDATA) \ + >$@.out + mv $@.out $@ +tzdata.zi: $(XDST)data.zi version version=`sed 1q version` && \ LC_ALL=C $(AWK) -v version="$$version" -f zishrink.awk \ - $(TDATA) $(PACKRATDATA) >$@.out + $(XDST)data.zi >$@.out mv $@.out $@ version.h: version @@ -721,17 +747,32 @@ check_tzs: $(TZS) $(TZS_NEW) check_web: tz-how-to.html $(VALIDATE_ENV) $(VALIDATE) $(VALIDATE_FLAGS) tz-how-to.html -# Check that tzdata.zi generates the same binary data that its sources do. -check_zishrink: tzdata.zi zic leapseconds $(PACKRATDATA) $(TDATA) +# The format of the source files, either full or pdst. +# Currently they are in pdst format, but this is expected to change. +SDST = pdst + +# Check that zishrink.awk does not alter the data, and that zidst.awk +# preserves $(SDST) data. +check_zishrink: zic leapseconds $(PACKRATDATA) $(TDATA) \ + $(XDST)data.zi tzdata.zi for type in posix right; do \ - mkdir -p time_t.dir/$$type time_t.dir/$$type-shrunk && \ + mkdir -p time_t.dir/$$type time_t.dir/$$type-$(SDST) \ + time_t.dir/$$type-shrunk && \ case $$type in \ right) leap='-L leapseconds';; \ *) leap=;; \ esac && \ - $(ZIC) $$leap -d time_t.dir/$$type $(TDATA) && \ - $(AWK) '/^Rule/' $(TDATA) | \ + $(ZIC) $$leap -d time_t.dir/$$type $(XDST)data.zi && \ + $(AWK) '/^Rule/' $(XDST)data.zi | \ $(ZIC) $$leap -d time_t.dir/$$type - $(PACKRATDATA) && \ + case $(XDST) in \ + $(SDST)) \ + $(ZIC) $$leap -d time_t.dir/$$type-$(SDST) $(TDATA) && \ + $(AWK) '/^Rule/' $(TDATA) | \ + $(ZIC) $$leap -d time_t.dir/$$type-$(SDST) \ + $(XDST)data.zi && \ + diff -r time_t.dir/$$type time_t.dir/$$type-$(SDST);; \ + esac && \ $(ZIC) $$leap -d time_t.dir/$$type-shrunk tzdata.zi && \ diff -r time_t.dir/$$type time_t.dir/$$type-shrunk || exit; \ done @@ -741,7 +782,7 @@ clean_misc: rm -f core *.o *.out \ date tzselect version.h zdump zic yearistype libtz.a clean: clean_misc - rm -fr *.dir tzdata.zi tzdb-*/ $(TZS_NEW) + rm -fr *.dir *.zi tzdb-*/ $(TZS_NEW) maintainer-clean: clean @echo 'This command is intended for maintainers to use; it' diff --git a/NEWS b/NEWS index 4f763c0..c455f3c 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,36 @@ News for the tz database Unreleased, experimental changes + Briefly: + Support zi parsers that mishandle negative DST offsets + + Changes to build procedure + + The new XDST macro in the Makefile lets the installer choose + XDST=full, which allows arbitrary DST offsets in the data, or + XDST=pdst, which allows only positive DST offsets. Choosing + XDST=full is arguably more correct for Ireland, which observes + Irish Standard Time (IST, UTC+01) in summer and GMT (UTC) in + winter. Choosing XDST=pdst is better for zoneinfo parsers that do + not work well with negative DST offsets, notably OpenJDK+CLDR. + On platforms using tzcode or similar APIs, XDST should not affect + any behavior other than that depending on the tm_isdst flag. + + For now this change does not affect client-visible behavior by + default, as the Makefile defaults to XDST=pdst and uncommented + parts of the data source files contain only pdst-format data. + After a bit of time for testing, XDST=full and full-format source + files are planned to become the default, so that parsers that + support negative DST offsets can get full data without changing + their build procedures. Parsers requiring positive DST offsets + should use the new file pdstdata.zi instead of tzdata.zi or the + source files 'africa' etc.: pdstdata.zi is pdst-compatible, it is + automatically built from the data source files, and it will + continue to be pdst-compatible regardless of XDST. To get + full-format data now, use the new file fulldata.zi, which will + continue to be full-format regardless of XDST. To get the format + selected by XDST, use tzdata.zi. + Changes to code The code is a bit more portable to MS-Windows. (Thanks to Manuela diff --git a/europe b/europe index 6c1ccbe..5aeda33 100644 --- a/europe +++ b/europe @@ -508,11 +508,27 @@ Link Europe/London Europe/Jersey Link Europe/London Europe/Guernsey Link Europe/London Europe/Isle_of_Man -# From Paul Eggert (2018-01-19): +# From Paul Eggert (2018-01-30): +# In January 2018 we discovered that the negative DST offsets in the +# Eire rules cause problems with tests for ICU: +# https://mm.icann.org/pipermail/tz/2018-January/025825.html +# and with tests for OpenJDK: +# https://mm.icann.org/pipermail/tz/2018-January/025822.html +# To work around this problem, zidst.awk translates the following data +# lines into two forms. First, fulldata.zi contains the full data, +# which includes negative DST offsets. Second, pdstdata.zi uses a +# traditional approximation for Irish time stamps after 1971-10-31 +# 02:00 UTC; although this approximation has tm_isdst flags that are +# the reverse of the full data, its UTC offsets are correct and this +# suffices for ICU and OpenJDK. Although this source file currently +# has pdstdata.zi lines active and fulldata.zi lines commented out, +# this is intended to change in the near future and downstream code +# should not rely on it. +# # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. -# Although currently commented out, this will need to become uncommented -# once the ICU/OpenJDK workaround is removed; see below. +# This rule set is active in fulldata.zi and is commented out in +# pdstdata.zi. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S #Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT #Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST @@ -533,24 +549,13 @@ Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 0:00 1:00 IST 1947 Nov 2 2:00s 0:00 - GMT 1948 Apr 18 2:00s 0:00 GB-Eire GMT/IST 1968 Oct 27 -# From Paul Eggert (2018-01-18): -# The next line should look like this: +# The next line is active in fulldata.zi and commented out in pdstdata.zi. # 1:00 Eire IST/GMT -# However, in January 2018 we discovered that the Eire rules cause -# problems with tests for ICU: -# https://mm.icann.org/pipermail/tz/2018-January/025825.html -# and with tests for OpenJDK: -# https://mm.icann.org/pipermail/tz/2018-January/025822.html -# To work around this problem, use a traditional approximation for -# time stamps after 1971-10-31 02:00 UTC, to give ICU and OpenJDK -# developers breathing room to fix bugs. This approximation has -# correct UTC offsets, but results in tm_isdst flags are the reverse -# of what they should be. This workaround is temporary and should be -# removed reasonably soon. +# These three lines are active in pdstdata.zi and commented out in +# fulldata.zi. 1:00 - IST 1971 Oct 31 2:00u 0:00 GB-Eire GMT/IST 1996 0:00 EU GMT/IST -# End of workaround for ICU and OpenJDK bugs. ############################################################################### diff --git a/zidst.awk b/zidst.awk new file mode 100644 index 0000000..7885e9a --- /dev/null +++ b/zidst.awk @@ -0,0 +1,50 @@ +# Convert tzdata source into full or positive-DST form + +# Contributed by Paul Eggert. This file is in the public domain. + +# This is not a general-purpose converter; it is designed for current tzdata. +# +# When converting to full form, the output can use negative DST offsets. +# +# When converting to positive-DST form, the output uses only positive +# DST offsets. The idea is for the output data to simulate the +# behavior of the input data as best it can within the constraints of +# positive DST offsets. +# +# In the input, lines requiring the full format are commented #[full] +# and the positive DST near-equivalents are commented #[pdst]. + +BEGIN { + dst_type["full"] = 1 + dst_type["pdst"] = 1 + + # The command line should set OUTFILE to the name of the output file, + # which should start with either "full" or "pdst". + todst = substr(outfile, 1, 4) + if (!dst_type[todst]) exit 1 +} + +/^Zone/ { zone = $2 } + +{ + in_comment = /^#/ + + # Test whether this line should differ between the full and the pdst versions. + Rule_Eire = /^#?Rule[\t ]+Eire[\t ]/ + Zone_Dublin_post_1968 \ + = (zone == "Europe/Dublin" && /^#?[\t ]+[01]:00[\t ]/ \ + && (!$(in_comment + 4) || 1968 < $(in_comment + 4))) + + # If so, uncomment the desired version and comment out the undesired one. + if (Rule_Eire || Zone_Dublin_post_1968) { + if ((Rule_Eire \ + || (Zone_Dublin_post_1968 && $(in_comment + 3) == "IST/GMT")) \ + == (todst == "full")) { + sub(/^#/, "") + } else if (/^[^#]/) { + sub(/^/, "#") + } + } +} + +{ print } -- 2.14.3

7 14

[PATCH] Fix ziguard.awk Namibia invalid assumption
by Paul Eggert April 22, 2018

April 22, 2018

* ziguard.awk: Don’t assume input is in rearguard format. --- ziguard.awk | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/ziguard.awk b/ziguard.awk index 7cdceab..dbe64d6 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -63,7 +63,11 @@ outfile != "main.zi" { || (1994 <= $(in_comment + 4) && $(in_comment + 4) <= 2017) \ || in_comment + 3 == NF)) if (Rule_Namibia || Zone_using_Namibia_rule) { - if (in_comment == vanguard) { + if ((Rule_Namibia \ + ? ($(in_comment + 9) ~ /^-/ \ + || ($(in_comment + 9) == 0 && $(in_comment + 10) == "CAT")) \ + : $(in_comment + 1) == "2:00" && $(in_comment + 2) == "Namibia") \ + == vanguard) { uncomment = in_comment } else { comment_out = !in_comment -- 2.14.3

1 0

[PROPOSED] Update and/or clean up POSIX version info
by Paul Eggert April 15, 2018

April 15, 2018

--- asctime.c | 12 +++--------- localtime.c | 7 +++---- theory.html | 2 +- 3 files changed, 7 insertions(+), 14 deletions(-) diff --git a/asctime.c b/asctime.c index a55f785..56c54b3 100644 --- a/asctime.c +++ b/asctime.c @@ -1,3 +1,5 @@ +/* asctime and asctime_r a la POSIX and ISO C, except pad years before 1000. */ + /* ** This file is in the public domain, so clarified as of ** 1996-06-05 by Arthur David Olson. @@ -29,7 +31,7 @@ ** leading zeroes to get the newline in the traditional place. ** The -4 ensures that we get four characters of output even if ** we call a strftime variant that produces fewer characters for some years. -** The ISO C 1999 and POSIX 1003.1-2004 standards prohibit padding the year, +** The ISO C and POSIX standards prohibit padding the year, ** but many implementations pad anyway; most likely the standards are buggy. */ #ifdef __GNUC__ @@ -64,10 +66,6 @@ static char buf_asctime[MAX_ASCTIME_BUF_SIZE]; -/* -** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. -*/ - char * asctime_r(register const struct tm *timeptr, char *buf) { @@ -117,10 +115,6 @@ asctime_r(register const struct tm *timeptr, char *buf) } } -/* -** A la ISO/IEC 9945-1, ANSI/IEEE Std 1003.1, 2004 Edition. -*/ - char * asctime(register const struct tm *timeptr) { diff --git a/localtime.c b/localtime.c index b6b82bb..5b5a5b1 100644 --- a/localtime.c +++ b/localtime.c @@ -88,9 +88,8 @@ static const char gmt[] = "GMT"; /* ** The DST rules to use if TZ has no rules and we can't load TZDEFRULES. ** Default to US rules as of 2017-05-07. -** POSIX 1003.1 section 8.1.1 says that the default DST rules are -** implementation dependent; for historical reasons, US rules are a -** common default. +** POSIX does not specify the default DST rules; +** for historical reasons, US rules are a common default. */ #ifndef TZDEFRULESTRING #define TZDEFRULESTRING ",M3.2.0,M11.1.0" @@ -2211,7 +2210,7 @@ timeoff(struct tm *tmp, long offset) #ifdef STD_INSPIRED /* -** IEEE Std 1003.1-1988 (POSIX) legislates that 536457599 +** 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 diff --git a/theory.html b/theory.html index b27b212..fc2102b 100644 --- a/theory.html +++ b/theory.html @@ -68,7 +68,7 @@ standard for <a href="https://en.wikipedia.org/wiki/Unix">UNIX</a>-like systems. As of this writing, the current edition of POSIX is: <a href="http://pubs.opengroup.org/onlinepubs/9699919799/"> The Open -Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2008, 2016 +Group Base Specifications Issue 7</a>, IEEE Std 1003.1-2017, 2018 Edition. Because the database's scope encompasses real-world changes to civil timekeeping, its model for describing time is more complex than the -- 2.7.4

1 0

[PROPOSED] * europe: Adjust to kalendar.beda.cz correction.
by Paul Eggert April 15, 2018

April 15, 2018

--- europe | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/europe b/europe index 160be9f..6b97fd0 100644 --- a/europe +++ b/europe @@ -971,14 +971,9 @@ Zone Europe/Sofia 1:33:16 - LMT 1880 # Czech Republic / Czechia # -# From Paul Eggert (2018-04-14): -# The source for Czech data is: Kdy začíná a končí letní čas. +# From Paul Eggert (2018-04-15): +# The source for Czech data is: Kdy začíná a končí letní čas. 2018-04-15. # https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas -# with one correction, taken from: -# Sbírka zákonů a nařízení republiky Československé, částka 92/1946. -# http://ftp.aspi.cz/opispdf/1946/092-1946.pdf -# which says that the winter time (negative DST) starting 1946-12-01 -# was a switch from 03:00 to 02:00 (not from 02:00 to 01:00). # We know of no English-language name for historical Czech winter time; # abbreviate it as "GMT", as it happened to be GMT. # -- 2.14.3

1 0

start of 1946 winter time in "Kdy začíná a končí letní čas"
by Paul Eggert April 14, 2018

April 14, 2018

I recently proposed some tz database changes for Prague; see <https://en.wikipedia.org/wiki/Tz_database> and <https://mm.icann.org/pipermail/tz/2018-April/026415.html>. I used your web page <https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas> as the main source for these fixes; thank you! I noticed what appears to be a typographical error in your web page. It says: 1946-7 zimní čas 1. prosinec (2:00) 23. únor (2:00) However, the primary source <http://ftp.aspi.cz/opispdf/1946/092-1946.pdf> says: "§1. Počátek zimního času v roce 1946 se určuje na den 1. prosince 1946 o třetí hodiné ranní středoevropského času a provede se posunutím hodinových ručiček na druhou hodinu." Google Translate suggests this means the transition was December 1 at 03:00, not December 1 at 02:00. That is, the clock was 03:00 before the transition, and 02:00 afterwards. The attached patch contains a proposed fix to kalendar.beda.cz. I am CC:ing this to the time zone mailing list to give them a heads-up as to why I made this change in the tz database.

1 0