- tz - lists.iana.org

[PROPOSED PATCH] Fix zdump problem with abbrevs like '-05'
by Paul Eggert July 17, 2015

July 17, 2015

* zdump.c (is_digit): New macro, copied from private.h. (abbrok): Use it. Allow abbreviations that (when quoted) conform to POSIX.1-2001 or later. * NEWS: Document this. --- NEWS | 3 ++- zdump.c | 28 +++++++++++----------------- 2 files changed, 13 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 498e77b..101a1e5 100644 --- a/NEWS +++ b/NEWS @@ -21,7 +21,8 @@ Unreleased, experimental changes Changes affecting code - zic no longer warns about valid time zone abbreviations like '-05'. + zdump and zic no longer warn about valid time zone abbreviations + like '-05'. Release 2015e - 2015-06-13 10:56:02 -0700 diff --git a/zdump.c b/zdump.c index adb806c..64ff6ce 100644 --- a/zdump.c +++ b/zdump.c @@ -269,6 +269,9 @@ static void show(timezone_t, char *, time_t, bool); static const char *tformat(void); static time_t yeartot(intmax_t) ATTRIBUTE_PURE; +/* Unlike <ctype.h>'s isdigit, this also works if c < 0 | c > UCHAR_MAX. */ +#define is_digit(c) ((unsigned)(c) - '0' <= 9) + /* Is A an alphabetic character in the C locale? */ static bool is_alpha(char a) @@ -485,25 +488,16 @@ abbrok(const char *const abbrp, const char *const zone) if (warned) return; cp = abbrp; - wp = NULL; - while (is_alpha(*cp)) + while (is_alpha(*cp) || is_digit(*cp) || *cp == '-' || *cp == '+') ++cp; - if (cp - abbrp == 0) - wp = _("lacks alphabetic at start"); - else if (cp - abbrp < 3) - wp = _("has fewer than 3 alphabetics"); + if (cp - abbrp < 3) + wp = _("has fewer than 3 characters"); else if (cp - abbrp > 6) - wp = _("has more than 6 alphabetics"); - if (wp == NULL && (*cp == '+' || *cp == '-')) { - ++cp; - if ('0' <= *cp && *cp <= '9') - if (*cp++ == '1' && '0' <= *cp && *cp <= '4') - cp++; - if (*cp != '\0') - wp = _("differs from POSIX standard"); - } - if (wp == NULL) - return; + wp = _("has more than 6 characters"); + else if (*cp) + wp = _("has characters other than ASCII alphanumerics, '-' or '+'"); + else + return; fflush(stdout); fprintf(stderr, _("%s: warning: zone \"%s\" abbreviation \"%s\" %s\n"), -- 2.1.0

1 0

[PROPOSED PATCH] Don't warn about abbreviations like '-05'
by Paul Eggert July 15, 2015

July 15, 2015

* NEWS, zic.8: Document this. * zic.c (newabbr): Allow abbreviations that (when quoted) conform to POSIX.1-2001 or later. --- NEWS | 4 ++++ zic.8 | 2 ++ zic.c | 20 ++++---------------- 3 files changed, 10 insertions(+), 16 deletions(-) diff --git a/NEWS b/NEWS index 041983c..498e77b 100644 --- a/NEWS +++ b/NEWS @@ -19,6 +19,10 @@ Unreleased, experimental changes installed data files for Europe/Simferopol and Europe/Tallinn. It does not affect timestamps. (Thanks to Howard Hinnant.) + Changes affecting code + + zic no longer warns about valid time zone abbreviations like '-05'. + Release 2015e - 2015-06-13 10:56:02 -0700 diff --git a/zic.8 b/zic.8 index cf78ae3..968cc6f 100644 --- a/zic.8 +++ b/zic.8 @@ -376,6 +376,8 @@ of the time zone abbreviation goes. Alternately, a slash (/) separates standard and daylight abbreviations. +To conform to POSIX, a time zone abbreviation should contain only +alphanumeric ASCII characters, "+" and "\*-". .TP .B UNTILYEAR [MONTH [DAY [TIME]]] The time at which the UT offset or the rule(s) change for a location. diff --git a/zic.c b/zic.c index f51fc48..6fac4e3 100644 --- a/zic.c +++ b/zic.c @@ -2893,27 +2893,15 @@ newabbr(const char *const string) register const char * cp; const char * mp; - /* - ** Want one to ZIC_MAX_ABBR_LEN_WO_WARN alphabetics - ** optionally followed by a + or - and a number from 1 to 14. - */ cp = string; mp = NULL; - while (is_alpha(*cp)) + while (is_alpha(*cp) || ('0' <= *cp && *cp <= '9') + || *cp == '-' || *cp == '+') ++cp; - if (cp - string == 0) -mp = _("time zone abbreviation lacks alphabetic at start"); if (noise && cp - string < 3) -mp = _("time zone abbreviation has fewer than 3 alphabetics"); + mp = _("time zone abbreviation has fewer than 3 characters"); if (cp - string > ZIC_MAX_ABBR_LEN_WO_WARN) -mp = _("time zone abbreviation has too many alphabetics"); - if (mp == NULL && (*cp == '+' || *cp == '-')) { - ++cp; - if (is_digit(*cp)) - if (*cp++ == '1' && - *cp >= '0' && *cp <= '4') - ++cp; - } + mp = _("time zone abbreviation has too many characters"); if (*cp != '\0') mp = _("time zone abbreviation differs from POSIX standard"); if (mp != NULL) -- 2.1.0

1 0

Re: [tz] Uruguay out of DST
by Pablo Camargo July 13, 2015

July 13, 2015

Hello! Just to confirm: "Uruguay out of DST" is official. Next source in Spanish (presidential decree). >>> http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf Context: >>> http://presidencia.gub.uy/normativa/decretos/decretos-06-2015 Media coverage of the news (text) had better coverage, but the official communication was there (pdf). So we are looking forward for a future update of tz. Thanks! P.Camargo.

3 2

Unnecessary faux transition in Atlantic/Canary 1980 Sep/28
by Howard Hinnant July 13, 2015

July 13, 2015

Hi, I wouldn’t call this a bug, but a potential database inefficiency. I’m working on a TZ parser and using it to explore the timezone transitions as specified by the timezone database. I’m looking at the Atlantic/Canary transition on 1980 Sep 28 0:00s. At this time the timezone transitions from a permanent saving of 1:00 and abbreviation of WEST to a rule based savings specified by EU: 1980-09-27 23:59:59u = 1980-09-28 00:59:59 WEST // as specified by 0:00 1:00 WEST 1980-09-28 00:00:00u = 1980-09-28 01:00:00 WEST // as specified by 0:00 EU WE%sT I.e. there is no change in offset, savings, or abbreviation. And then an hour later EU specifies a savings and abbreviation change: 1980-09-28 00:59:59u = 1980-09-28 01:59:59 WEST 1980-09-28 01:00:00u = 1980-09-28 01:00:00 WET My observation is that this is a lot of transitions for one night. Would it not be better to delay the transition from "0:00 1:00 WEST” to "0:00 EU WE%sT” by one hour, and thus have only one transition instead of two? Here is a change that does so: diff --git a/europe b/europe index c64c41b..630c234 100644 --- a/europe +++ b/europe @@ -2922,7 +2922,7 @@ Zone Africa/Ceuta -0:21:16 - LMT 1901 Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. -1:00 - CANT 1946 Sep 30 1:00 # Canaries T 0:00 - WET 1980 Apr 6 0:00s - 0:00 1:00 WEST 1980 Sep 28 0:00s + 0:00 1:00 WEST 1980 Sep 28 1:00s 0:00 EU WE%sT # 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. Howard

3 4

Europe/Chisinau Timezone
by Roman Tudos July 11, 2015

July 11, 2015

Please be informed that according Moldavian Law dst start on last last Sunday of March end on last sunday of October at 02:00 to 03:00 and at 03:00 to 02:00 respectively 2015Sun, 29 Mar, 02:00EET <http://www.timeanddate.com/time/zones/eet> → EEST <http://www.timeanddate.com/time/zones/eest>+1 hour (DST start)UTC+3h Sun, 25 Oct, 03:00EEST <http://www.timeanddate.com/time/zones/eest> → EET <http://www.timeanddate.com/time/zones/eet>-1 hour (DST end)UTC+2h2016Sun, 27 Mar, 02:00EET <http://www.timeanddate.com/time/zones/eet> → EEST <http://www.timeanddate.com/time/zones/eest>+1 hour (DST start)UTC+3h Sun, 30 Oct, 03:00EEST <http://www.timeanddate.com/time/zones/eest> → EET <http://www.timeanddate.com/time/zones/eet>-1 hour (DST end)UTC+2h2017Sun, 26 Mar, 02:00EET <http://www.timeanddate.com/time/zones/eet> → EEST <http://www.timeanddate.com/time/zones/eest>+1 hour (DST start)UTC+3h Sun, 29 Oct, 03:00EEST <http://www.timeanddate.com/time/zones/eest> → EET <http://www.timeanddate.com/time/zones/eet>-1 hour (DST end)UTC+2h2018Sun, 25 Mar, 02:00EET <http://www.timeanddate.com/time/zones/eet> → EEST <http://www.timeanddate.com/time/zones/eest>+1 hour (DST start)UTC+3h Sun, 28 Oct, 03:00EEST <http://www.timeanddate.com/time/zones/eest> → EET <http://www.timeanddate.com/time/zones/eet>-1 hour (DST end)UTC+2h Please take consideration for changes in tzdata PS. Sorry for my english -- Vita sine libertate, nihil

3 2

Discrepancies in time zone data interpretation at standard offset changes
by Jon Skeet July 11, 2015

July 11, 2015

Heads up for Stephen Colebourne: this post highlights a discrepancy between Joda Time and tzdump, so you may want to read carefully :) This is in relation to my earlier message about the text format. My confusion here is the reason I'm anxious to see canonical data :) Currently, both Joda Time and Noda Time have some interesting code when working out the transitions for a time zone which checks whether the later transition occurs at the same *local* time as the earlier transition, and if so extends the earlier transition to consume the later one. I've worked out that this is basically to handle an oddity that sometimes occurs when standard offsets change. One example of a zone in which this happens is America/Juneau. Here are the zone lines from 2015e, and I've highlighted the ones we're immediately concerned with: Zone America/Juneau 15:02:19 - LMT 1867 Oct 18 -8:57:41 - LMT 1900 Aug 20 12:00 -8:00 - PST 1942 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1980 Apr 27 2:00 -9:00 US Y%sT 1980 Oct 26 2:00 * -8:00 US P%sT 1983 Oct 30 2:00* * -9:00 US Y%sT 1983 Nov 30* -9:00 US AK%sT The US rules in force at the time are: Rule US 1967 2006 - Oct lastSun 2:00 0 S Rule US 1976 1986 - Apr lastSun 2:00 1:00 D So, the first bolded zone line comes to an end at the instant of the transition into standard time, while standard time is -8 (so a wall offset of -7). I assume this transition should *not* be included in the eventual set of transitions (i.e. the bound given is exclusive). This would occur at 1983-10-30T09:00Z. Now, in the second bolded zone line, the standard offset is -9 instead, so the transition into daylight saving time would occur at 1983-10-30T10:00Z. So looking at the rules in a naive way, residents of Juneau would have to change their watches twice on October 30th 1983. At 2am they'd put their watches back an hour to account for the change in standard time (but still be in daylight saving time)... and then when it next hit 2am they'd put their watches back *another* hour to account for the transition into standard time. Now, I'm pretty sure that's not what's intended, and indeed zdump shows just a single transition setting local time back two hours at 1983-10-30T09:00Z: America/Juneau Sun Oct 30 08:59:59 1983 UTC = Sun Oct 30 01:59:59 1983 PDT isdst=1 America/Juneau Sun Oct 30 09:00:00 1983 UTC = Sun Oct 30 00:00:00 1983 YST isdst=0 ... whereas Noda Time (and, I've just checked, Joda Time) have a single transition at 1983-10-30T10:00Z instead. Is it documented somewhere what should happen in this case? (As a side question, is there a single canonical place documenting the time zone data format? I've found various sources over the years, but it would be nice to have somewhere canonical - ideally either within each release or on the IANA home page. The Theory file gives a lot of interesting more abstract information, but a single place saying "Here is what each file in the release means, with details of its format" would be very welcome. Apologies if it already exists and I've just missed it...) Jon

2 1

UY Timezone DST changed since June 2015
by Nicolas Antoniello July 9, 2015

July 9, 2015

Hi folks, Just to request a Timezone DB update as Past June 2015, Uruguay (UY) eliminated the DST Timezone change (now it's UTC-3 all year). So for Montevideo (capital city) and all rest of Uruguayan cities now is all year UTC-3. Thanks in advance, Nicolas

1 0

Greetings from Mongolia
by amgalan tsogtgerel July 4, 2015

July 4, 2015

Dear Paul Eggert, Greetings from Mongolia. I am writing this letter on behalf of the Communications Regulatory Commission of Mongolia. The Mongolian Government has approved the Resolution ? 82, dated 09 March 2015, to use Daylight Saving Time (DST) every year from last week of March until last week of September from 2015. According to the Resolution, the clocks in Mongolia has set forward one hour at 2 : 00 (2 am) local time. Unfortunately, some of system, service and software which are widely using in Mongolia have not updated their time zone. Regarding this issue, the CRC has sent you official letter dated 15th June 2015 to you for your support on above mentioned issue and we have not received any response from you yet. Here I attached the copy of letter. Thank you for your understanding. I look forward hearing from you soon. BR, Amgalan Ts. (Ms) Foreign Relation Officer, Legal, Information and Administration Dept, CRC of Mongolia. mobile: 976 91112268 phone: 976 11 304258,304257 fax:976 11 327720 e-mail: amgalants(a)crc.gov.mn<mailto:amgalants@crc.gov.mn>

7 8

[PROPOSED_PATCH] Moldova DST transitions were off by an hour
by Paul Eggert July 2, 2015

July 2, 2015

* NEWS: Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC. (Thanks to Roman Tudos.) * europe (Moldova): New rule. (Europe/Chisinau): Use it. --- NEWS | 5 +++++ europe | 14 +++++++++++++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 156da23..f0fedbd 100644 --- a/NEWS +++ b/NEWS @@ -6,6 +6,11 @@ Unreleased, experimental changes Uruguay will stop observing DST. (Thanks to Steffen Thorsen.) + Changes affecting past and future time stamps + + Moldova starts and ends DST at 00:00 UTC, not at 01:00 UTC. + (Thanks to Roman Tudos.) + Changes affecting installed data files Data entries have been simplified for Atlantic/Canary, Europe/Simferopol, diff --git a/europe b/europe index a5e95bb..7cbf1f8 100644 --- a/europe +++ b/europe @@ -1763,6 +1763,18 @@ Zone Europe/Malta 0:58:04 - LMT 1893 Nov 2 0:00s # Valletta # News from Moldova (in russian): # http://ru.publika.md/link_317061.html +# From Roman Tudos (2015-07-02): +# http://lex.justice.md/index.php?action=view&view=doc&lang=1&id=355077 +# From Paul Eggert (2015-07-01): +# The abovementioned official link to IGO1445-868/2014 states that +# 2014-10-26's fallback transition occurred at 03:00 local time. Also, +# http://www.trm.md/en/social/la-30-martie-vom-trece-la-ora-de-vara +# says the 2014-03-30 spring-forward transition was at 02:00 local time. +# Guess that since 1997 Moldova has switched one hour before the EU. + +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Moldova 1997 max - Mar lastSun 2:00 1:00 S +Rule Moldova 1997 max - Oct lastSun 3:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Chisinau 1:55:20 - LMT 1880 @@ -1777,7 +1789,7 @@ Zone Europe/Chisinau 1:55:20 - LMT 1880 2:00 Russia EE%sT 1992 2:00 E-Eur EE%sT 1997 # See Romania commentary for the guessed 1997 transition to EU rules. - 2:00 EU EE%sT + 2:00 Moldova EE%sT # Monaco # Shanks & Pottenger give 0:09:20 for Paris Mean Time; go with Howse's -- 2.1.0

1 0

Trivia: Sunrise in Santiago
by Hank W. June 30, 2015

June 30, 2015

Today, 30 June 2015, is the latest sunrise of winter in Santiago, Chile. I was curious about what that latest time is, not only because this is Chile's first winter on "permanent" Summer Time, but also because UTC-3 is so far from Santiago's LMT of UTC-4.713. Sunrise in Santiago today will be at 08:48 CLST! Hank Wisniewski of Austin, Texas, U.S.A. "'Tis better to be silent and thought the fool than to speak and dispel all doubt." -unknown

1 0

Best practices for upcoming leap second event
by Paul Eggert June 28, 2015

June 28, 2015

If you're responsible for proper timekeeping you probably have already thought about the upcoming leap second at the end of Tuesday 2015-06-30 UTC. This is the first leap second in eighteen years that has fallen on a non-holiday weekday. It might not hurt to run through your checklist again, and (if you haven't already done so) compare it to the checklist recommended by GPS.GOV, NAVCEN, NCCIC, NIST, and USNO. You can find that checklist here: http://www.gps.gov/news/2015/05/leap-second/2015-best-practices-for-leap-se… The new leap second has been in the tz database since release 2015a dated 2015-01-29 22:35:20 -0800, so if you're newer than that you should be good as far as tz is concerned. In the typical case where you're not using tz's leap-second support, you don't need to worry about tz at all.

1 0

Three more tweaks
by Howard Hinnant June 21, 2015

June 21, 2015

Hi, I’ve surveyed the entire database for transitions 24h or less apart with one of them being a faux transition. I found only 6. You just eliminated the first. Two more are in Europe/Istanbul and I see no way to eliminate the faux transition. Here are the remaining 3 with explanations and fixes: ——————————— Europe/Simferopol 1996 Mar 31: 1996-03-30 20:59:59u = 1996-03-30 23:59:59 MSK // 03:00:00 E-Eur MSK/MSD 1996-03-30 21:00:00u = 1996-03-31 01:00:00 MSD // 03:00:00 E-Eur MSK/MSD And then 3h later: 1996-03-30 23:59:59u = 1996-03-31 03:59:59 MSD // 03:00:00 E-Eur MSK/MSD 1996-03-31 00:00:00u = 1996-03-31 04:00:00 MSD // 03:00:00 01:00 MSD The second faux transition can be combined with the first actual transition with: diff --git a/europe b/europe index 630c234..1242927 100644 --- a/europe +++ b/europe @@ -2364,7 +2364,7 @@ Zone Europe/Simferopol 2:16:24 - LMT 1880 # changed in May. 2:00 E-Eur EE%sT 1994 May # From IATA SSIM (1994/1997), which also says that Kerch is still like Kiev. - 3:00 E-Eur MSK/MSD 1996 Mar 31 3:00s + 3:00 E-Eur MSK/MSD 1996 Mar 31 0:00s 3:00 1:00 MSD 1996 Oct 27 3:00s # IATA SSIM (1997-09) says Crimea switched to EET/EEST. # Assume it happened in March by not changing the clocks. ——————————— Europe/Sofia 1982 Sep 26: 1982-09-25 22:59:59u = 1982-09-26 01:59:59 EEST // 02:00:00 Bulg EE%sT 1982-09-25 23:00:00u = 1982-09-26 02:00:00 EEST // 02:00:00 C-Eur EE%sT And then 1h later: 1982-09-25 23:59:59u = 1982-09-26 02:59:59 EEST // 02:00:00 C-Eur EE%sT 1982-09-26 00:00:00u = 1982-09-26 02:00:00 EET // 02:00:00 C-Eur EE%sT The first faux transition can be merged with the second actual transition with: diff --git a/europe b/europe index 630c234..f096de5 100644 --- a/europe +++ b/europe @@ -845,7 +845,7 @@ Zone Europe/Sofia 1:33:16 - LMT 1880 1:00 C-Eur CE%sT 1945 1:00 - CET 1945 Apr 2 3:00 2:00 - EET 1979 Mar 31 23:00 - 2:00 Bulg EE%sT 1982 Sep 26 2:00 + 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 ——————————— Europe/Tallinn 1999 Nov 1: 1999-10-31 00:59:59u = 1999-10-31 03:59:59 EEST // 02:00:00 EU EE%sT 1999-10-31 01:00:00u = 1999-10-31 03:00:00 EET // 02:00:00 EU EE%sT And then 21h later: 1999-10-31 21:59:59u = 1999-10-31 23:59:59 EET // 02:00:00 EU EE%sT 1999-10-31 22:00:00u = 1999-11-01 00:00:00 EET // 02:00:00 EET The second faux transition can be combined with the first actual transition with: diff --git a/europe b/europe index 630c234..c788416 100644 --- a/europe +++ b/europe @@ -1084,7 +1084,7 @@ Zone Europe/Tallinn 1:39:00 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 1:00 EEST 1989 Sep 24 2:00s 2:00 C-Eur EE%sT 1998 Sep 22 - 2:00 EU EE%sT 1999 Nov 1 + 2:00 EU EE%sT 1999 Oct 31 4:00 2:00 - EET 2002 Feb 21 2:00 EU EE%sT Thanks, Howard

2 2

[tz-announce] 2015e release of tz code and data available
by Paul Eggert June 13, 2015

June 13, 2015

The 2015e 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: Changes affecting future time stamps Morocco will suspend DST from 2015-06-14 03:00 through 2015-07-19 02:00, not 06-13 and 07-18 as we had guessed. (Thanks to Milamber.) Assume Cayman Islands will observe DST starting next year, using US rules. Although it isn't guaranteed, it is the most likely. Changes affecting data format The file 'iso3166.tab' now uses UTF-8, so that its entries can better spell the names of Åland Islands, Côte d'Ivoire, and Réunion. Changes affecting code When displaying data, tzselect converts it to the current locale's encoding if the iconv command works. (Problem reported by random832.) tzselect no longer mishandles Dominica, fixing a bug introduced in Release 2014f. (Problem reported by Owen Leibman.) zic -l no longer fails when compiled with -DTZDEFAULT=\"/etc/localtime\". This fixes a bug introduced in Release 2014f. (Problem reported by Leonardo Chiquitto.) Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2015e.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2015e.tar.gz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2015e.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2015e.tar.gz As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz 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 503ee68905da57fc52df74c889aedf4e67e59a79 dated Sat Jun 13 10:56:02 2015 -0700 and tagged '2015e' in the experimental github repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: fdc568a68f4876b967b39e21fa53f063dc5756e886e2a273cc046d5a014eb517e9c91eb6e03d18c94a89ce48578868aed710790415c500188fce4e4add0ce7ca tzcode2015e.tar.gz 86498190a20c5c67827aa75f7e9c6aa6c19d58a88a70425ce70d5ae7cea42dc7386eb2867fa455fcfcdedc6a105ad70fbbdc7c27c7a58a51bd21d76a135983ce tzdata2015e.tar.gz Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVfG8zAAoJEO2X6Q5iqn4014YP/jGiiK7VYqstDoQNm33/pOwx WlwTSkzByrhx0whaaAlTQ+j61q2MdZaDlpdDd4CEGN1vWaiI26MOEbZEKVpW5ogm xKGL9esGltoc3jelmWJTVf0e03l+k0+zDcnBq+58Pi5rkgM/WVFyZBDyCT5HGLq+ NPaHLHU4dlWtwpyd9Mr4eMb6DPEM4zbTK2NbHh/uf+ODG8F1VW8FP63N/hqq4Y/q 4H+ngf9jJxw73pBri/WBmidSxLWhhc+woezhKqbCThto4Jhoehlp3txIqBmAoN3G AwppaGiHV6PYheLqloCDmdxABMoS95tznuk8eL2FF69IP541kaOchHvKCnbEf6gu Sdr388Ayli/C98ZQknwzNWVlfKKW+d+nidS5iGyEHRpI/42RPemGh5kgYmZucZpH DRIbujsi9usxjrazWC8oGf7WH6D6ZmsUusl7pj071YnU0gpXyVSk9GUoMWIp3Wxc CSHJWxF6lkxOmHDqZFHhcVyyKlPHXFpWpDUPhu/QTi7oiSQeXRoP9BQAz07oN8WS 69JUSxCvkFANkFxnx6knsDBwduFUqiZ209WwV0R72DI/7Gi6OuubXUvgcQfJOHab wOyEInI32uHRKxEaQuDmu1PSzlur0iNGH3PtuQzgwLlMM0KXsRbLBhOO5zP2BgQ6 zVgFQ9FGlnExUxsBcnTf =BRRd -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVfG8/AAoJEO2X6Q5iqn40ed0P/jn6lgG6tH+C2Xv2DYz5buRK CMDoGidznyzDuPSNgSPRaDetoKQ/6iVzEIgHYwBxBtmKmPXUgSY8rJPCabSLNKWK T3o7f8aREnIcfexmct/4DEeUOXePUIbSHnX6Noy3AmSvIsKT8ZahEpnELKgWFQD8 0EEOlck1rTTpEi9G2RATUwr430ii1OguIt0sKYycTvT1VFdihKWoFhgV9ydgaMh2 88he3Ornt4xd4/b278IJl3GI0WWVbVl2A+ziRPAkl3AH7iW7mTcv+/8i3u7txVW+ zB47UHOfV9jpiecLUQDw42KZJTlS+AkbgCitrpL++bZz1WQHWP9JkpgvAR8bdkBf WPNvcPXiG0I6Vtl2ZZrc2WXi9L22m0xIJA2so4vpBwBIMkTnaFa6VthLGy9UgHpA wteG6OogfdNm7fv+GhuRUNuHtd5TP5HdywhWMrMtGqgOvkEm/lF6tRMd12Wm57IW u72Gv3RrJILBuOvBvWPZJMNsjc8Uj1U+dhKa8Z51VHA85ZyiRM3mQr8g+1WETH/E sjnj8NgKkh7TL/N5vWJH1M3g1XZ3uofPL1Cbyqg04BGrMytxGAjigzIDbbg5pky+ yFUqR3qm12d9QPlm1xh35qxqYYDXcbiQkXENwGukLRzcc0jdU4BrFpDc1tVgukUg TmCC2ALEcxWWPEc1vtUG =gO91 -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

Morocco DST Interruption during Ramadan 2015
by Milamber June 12, 2015

June 12, 2015

Hello, (Google Translation) The current time of Morocco (GMT + 1) will be suspended from next Sunday until July 19, announced Monday the Ministry of Civil Service and Modernisation of Administration. The hour will thus be delayed 60 minutes Sunday, June 14 at 3:00, the ministry said in a statement, adding that the time will be advanced again 60 minutes Sunday, July 19, 2015 at 2:00. The move comes under 2.12.126 Decree of 26 Jumada I 1433 (18 April 2012) and the decision of the Head of Government of 16 N. 3-29-15 Chaaban 1435 (4 June 2015). Source (french): http://lnt.ma/le-maroc-reculera-dune-heure-le-dimanche-14-juin/ (currently the official notice isn't publish on official government website http://www.mmsp.gov.ma) I thinks that the new rule for all new ramadan period is the time change the Sunday (like the DST) or not the Saturday. Milamber Note: Current prediction in tzdata: Africa/Casablanca Sat Jun 13 01:59:59 2015 UT = Sat Jun 13 02:59:59 2015 WEST isdst=1 gmtoff=3600 Africa/Casablanca Sat Jun 13 02:00:00 2015 UT = Sat Jun 13 02:00:00 2015 WET isdst=0 gmtoff=0 Africa/Casablanca Sat Jul 18 01:59:59 2015 UT = Sat Jul 18 01:59:59 2015 WET isdst=0 gmtoff=0 Africa/Casablanca Sat Jul 18 02:00:00 2015 UT = Sat Jul 18 03:00:00 2015 WEST isdst=1 gmtoff=3600

3 6

Possible bug in the tz database
by Howard Hinnant June 8, 2015

June 8, 2015

I’m new to this list, so please forgive me for my inexperience and lack of history. I am concerned about the timezone America/North_Dakota/Beula: Early of the local morning of 2010-11-07 the local timezone GMTOFF changed from -7:00 to -6:00, and the timezone abbreviation changed from MDT to CST. I am not questioning this historical fact. Rather I am concerned about exactly when it happened and does the tz database accurately reflect this event. Here are the relevant entries today: Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 -7:00 US M%sT 2010 Nov 7 2:00 -6:00 US C%sT Which says at 2:00am local time on 2010/Nov/07 the change from MDT to CST occurs. Local time is defined by GMTOFF == -7:00 + US timezone rules for 2010. Or in other words 2:00am + 7:00 + any daylight savings time adjustment. I’m sure I’m preaching to the choir with this audience. I think there is no dispute that: 2010-11-07 01:59:59 MDT == 2010-11-07 07:59:59 UTC At this point in time the GMTOFF == -7:00 and in the US rule SAVE == 1:00 for a total offset of -6:00. However according to US rules for this date, the local clock ticks from 01:59:59 MDT to 01:00:00 MST. To reach 2:00am local time we need to wait another hour: 2010-11-07 02:00:00 MST == 2010-11-07 09:00:00 UTC According to US time zone rules (speaking about the recognized practice in the US, not about tz database rules), there was no 2010-11-07 02:00:00 MDT. It simply did not exist. So 2010-11-07 02:00:00 local time in US rules is unambiguously a standard time, not a daylight savings time. Whereas the times [01:00:00, 01:59:59] *are* ambiguous (or more accurately described with a half-open range: [01:00:00, 02:00:00). Since 2010-11-07 02:00:00 is unambiguously a standard time, the database could read like this with no change in behavior: Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 -7:00 US M%sT 2010 Nov 7 2:00s -6:00 US C%sT But this data indicates that local time behaves as follows that morning: 2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 01:00:00 MST = 2010-11-07 08:00:00 UTC 2010-11-07 01:00:01 MST = 2010-11-07 08:00:01 UTC … 2010-11-07 01:59:59 MST = 2010-11-07 08:59:59 UTC 2010-11-07 03:00:00 CST = 2010-11-07 09:00:00 UTC 2010-11-07 03:00:01 CST = 2010-11-07 09:00:01 UTC However I believe the intended behavior is: 2010-11-07 01:59:59 MDT = 2010-11-07 07:59:59 UTC 2010-11-07 02:00:00 CST = 2010-11-07 08:00:00 UTC 2010-11-07 02:00:01 CST = 2010-11-07 08:00:01 UTC I believe the tz database can be changed to give the desired behavior with: diff --git a/northamerica b/northamerica index 88423e6..aeaf12c 100644 --- a/northamerica +++ b/northamerica @@ -371,7 +371,7 @@ Zone America/North_Dakota/New_Salem -6:45:39 - LMT 1883 Nov 18 12:14:21 # of 6h47'07". Zone America/North_Dakota/Beulah -6:47:07 - LMT 1883 Nov 18 12:12:53 - -7:00 US M%sT 2010 Nov 7 2:00 + -7:00 US M%sT 2010 Nov 7 1:00s -6:00 US C%sT # US mountain time, represented by Denver If I have misinterpreted the meanings of the fields to the tz database in some way, I would appreciate an education. I’ve reread all of the man pages and other documentation I can find, and haven’t been able to rectify this contradiction on my own. If this is indeed a bug that can be corrected, I am volunteering to detect and correct similar issues elsewhere in the database and generate a pull request for https://github.com/eggert/tz. Howard

5 5

NTSB investigation derailed by time zone labyrinth
by Paul Eggert June 6, 2015

June 6, 2015

When the chair of the U.S. National Transportation Safety Board appeared before the House Transportation and Infrastructure Committee this week, he was asked "Could you just tell us again in plain English why we don't know if this operator was on the phone three weeks after the accident?" He had trouble answering, because although the NTSB has detailed timestamped data for the engineer's cell phone records, and they have physical access to the phone and the phone's passwords, they can't figure out the data's time zones. The cell phone companies don't know either. My sources: Jaffe E. We still basically have no idea what happened with the Amtrak 188 derailment. CityLab 2015-06-04. http://www.citylab.com/commute/2015/06/we-still-basically-have-no-idea-what… Nixon R. Phone data labyrinth hinders investigation of Amtrak derailment. New York Times 2015-06-05. http://www.nytimes.com/2015/06/06/us/inquiry-into-amtrak-derailment-is-slow…

1 0

DST in the US 1945-1966
by Matt Johnson June 4, 2015

June 4, 2015

Wikipedia's page at:http://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States#H… states the following: >From 1945 to 1966 there was no federal law on daylight saving time, so localities could choose when it began and ended or drop it entirely. In 1954 only California and Nevada had statewide DST west of the Mississippi, and only a few cities between Nevada and St Louis. In the 1964 Official Railway Guide, 21 of the 48 states had no DST anywhere. I'm wondering if we have any additional details about the localities that adopted DST during this period and those that did not? Also, do we already incorporated data from the source mentioned? (the 1964 Official Railway Guide) Specifically, I was discussing this topic with another developer who was curious about Nashville, Tennessee. One could probably assume that it was on Central time - due to the Standard Time Act, but whether or not it used DST (specifically in 1949) or not is the question. The tz database entry for Chicago would say yes - but my guess is that it might not be certain that both Chicago and Nashville used DST that year. Thanks.

2 1

[PROPOSED PATCH] tzselect: port to POSIX sh and fix a typo
by Paul Eggert May 27, 2015

May 27, 2015

* tzselect.ksh: Use portable names for trap signals. Also, fix a typo: signal 2 (INT) was meant, not signal 12. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 2a622f5..2c3b2f4 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -191,7 +191,7 @@ done tmp=${TMPDIR-/tmp}/tzselect.$$ && (umask 77 && mkdir -- "$tmp") };} && - trap 'status=$?; rm -fr -- "$tmp"; exit $status' 0 1 12 13 15 && + trap 'status=$?; rm -fr -- "$tmp"; exit $status' 0 HUP INT PIPE TERM && (iconv -f UTF-8 -t //TRANSLIT <"$TZ_COUNTRY_TABLE" >$tmp/iso3166.tab) \ 2>/dev/null && TZ_COUNTRY_TABLE=$tmp/iso3166.tab && -- 2.1.4

1 0

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

"zic -l" complains about "empty component" in /etc/localtime
by Leonardo Chiquitto May 20, 2015

May 20, 2015

Hello, With 2015d I can no longer use "zic -l" to recreate /etc/localtime. I'm getting the following error: # ./zic -l America/Sao_Paulo ./zic: file name '/etc/localtime' contains empty component If I comment out the check introduced by commit 0ddac5ef7e in componentcheck(), then it works fine again: # ./zic -l America/Sao_Paulo # ls -lai /etc/localtime 1183669 -rw-r--r-- 5 root root 2015 May 17 20:20 /etc/localtime # ls -lai /usr/share/zoneinfo/America/Sao_Paulo 1183669 -rw-r--r-- 5 root root 2015 May 17 20:20 /usr/share/zoneinfo/America/Sao_Paulo A quick analysis: when "/etc/localtime" is passed to namecheck(), in the first loop iteration componentcheck() will be called with all three arguments set to "/etc/localtime". A possible fix is to skip this call to componentcheck() in the first iteration (patch attached). Leonardo

2 2

Leap seconds in the news
by Arthur David Olson May 20, 2015

May 20, 2015

>From the Wall Street Journal: "Markets Are Jumpy Over Coming Leap Second" http://www.wsj.com/articles/markets-are-jumpy-over-coming-leap-second-14319… @dashdashado

5 5

[PROPOSED PATCH] Guess Cayman Is will observe DST starting 2016
by Paul Eggert May 15, 2015

May 15, 2015

* NEWS: Document this. * backzone (America/Cayman): Move from here ... * northamerica: ... back to here, and assume US-style DST starting 2016. * zone1970.tab (KY): Now a separate row, since KY and PA disagree starting 2016. --- NEWS | 5 +++++ backzone | 5 ----- northamerica | 13 +++++++++++-- zone1970.tab | 3 ++- 4 files changed, 18 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index 392f09b..d69a98c 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,11 @@ News for the tz database Unreleased, experimental changes + Changes affecting future time stamps + + Assume Cayman Islands will observe DST starting next year, using US rules. + Although it isn't guaranteed, it is the most likely. + Changes affecting data format The file 'iso3166.tab' now uses UTF-8, so that its entries can better diff --git a/backzone b/backzone index 6b392bd..0316708 100644 --- a/backzone +++ b/backzone @@ -279,11 +279,6 @@ Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad -4:30 - ANT 1965 # Netherlands Antilles Time -4:00 - AST -# Cayman Is -Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown - -5:07:11 - KMT 1912 Feb # Kingston Mean Time - -5:00 - EST - # Canada Zone America/Coral_Harbour -5:32:40 - LMT 1884 -5:00 NT_YK E%sT 1946 diff --git a/northamerica b/northamerica index c3af9eb..88423e6 100644 --- a/northamerica +++ b/northamerica @@ -2661,7 +2661,17 @@ Zone Atlantic/Bermuda -4:19:18 - LMT 1930 Jan 1 2:00 # Hamilton -4:00 US A%sT # Cayman Is -# See America/Panama. + +# From Paul Eggert (2015-05-15): +# The Cayman government has decided to introduce DST in 2016, the idea being +# to keep in sync with New York. The legislation hasn't passed but the change +# seems quite likely. See: Meade B. Cayman 27. +# http://www.cayman27.com.ky/2015/05/15/clock-ticks-toward-daylight-saving-ti… + +Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown + -5:07:11 - KMT 1912 Feb # Kingston Mean Time + -5:00 - EST 2016 + -5:00 US E%sT # Costa Rica @@ -3184,7 +3194,6 @@ Zone America/Managua -5:45:08 - LMT 1890 Zone America/Panama -5:18:08 - LMT 1890 -5:19:36 - CMT 1908 Apr 22 # Colón Mean Time -5:00 - EST -Link America/Panama America/Cayman # Puerto Rico # There are too many San Juans elsewhere, so we'll use 'Puerto_Rico'. diff --git a/zone1970.tab b/zone1970.tab index 5da0200..2689c00 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -206,6 +206,7 @@ KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul +KY +1918-08123 America/Cayman KZ +4315+07657 Asia/Almaty most locations KZ +4448+06528 Asia/Qyzylorda Qyzylorda (Kyzylorda, Kzyl-Orda) KZ +5017+05710 Asia/Aqtobe Aqtobe (Aktobe) @@ -259,7 +260,7 @@ NR -0031+16655 Pacific/Nauru NU -1901-16955 Pacific/Niue NZ,AQ -3652+17446 Pacific/Auckland New Zealand time NZ -4357-17633 Pacific/Chatham Chatham Islands -PA,KY +0858-07932 America/Panama +PA +0858-07932 America/Panama PE -1203-07703 America/Lima PF -1732-14934 Pacific/Tahiti Society Islands PF -0900-13930 Pacific/Marquesas Marquesas Islands -- 2.1.0

1 0

Time Zone Database from Portugal
by Suzana Ferreira May 15, 2015

May 15, 2015

Hi, Where can I see information about Time Zone Database related to Portugal in your site?http://www.iana.org/time-zones http://tools.ietf.org/html/rfc6557 Thank you, -- Suzana Ferreira, Astrónoma ********************************************* Observatório Astronómico de Lisboa (OAL) -------------- desde 1861 -------------- Edifício Leste, Tapada da Ajuda, PT-1349-018 LISBOA, PORTUGAL tel: (351) 213616734 / fax: (351) 213616750 www.oal.ul.pt *********************************************

2 1

Time Zones - Canary Islands - Offshore Spain - Error
by moxhull May 15, 2015

May 15, 2015

Dear Paul Eggert, I use software which sources your data in github for time zones. The Canary Islands, located off the coast of Morocco, belong to Spain but have a different time zone. It's causing me problems because it seems your files do not take account of this. Would you kindly amend your files accordingly, please, so that my software programmer can use an updated file, so in turn I can use his software? Please see below for references. Many thanks indeed, so grateful. Yours sincerely, Sylvie ---------- Forwarded message ---------- From: Anatoly Zaytsev <astrozet(a)gmail.com> Date: Thu, May 14, 2015 at 5:41 PM Subject: Re: Zet 8 Geo, time zones To: moxhull <moxhull(a)gmail.com> Hello Sylvie, 1) This is not so important. 2) I use more (seems) relevant source: https://github.com/eggert/tz Paul Eggert tz-bounces(a)iana.org also https://github.com/eggert/tz/blob/master/europe line 2922 Please talk with him. ----------------- Anatoly Zaytsev www.astrozet.com ----- Original Message ----- From: "moxhull" <moxhull(a)gmail.com> To: <astrozet(a)gmail.com> Sent: Thursday, May 14, 2015 7:02 PM Subject: Zet 8 Geo, time zones Dear Anatoly, I hope you are well. I write for two items: - I have retired from my job in Geneva (Switzerland), sold my house in France, and I have moved to the Canary Islands, a part of Spain that is off the coast of Morocco. So my addresses, email and telephone number need to be changed in your records - see below. - The Canary Islands do not use the same time as mainland Spain, so I'm having trouble with the time changes. I tried to make a few modifications in my Zet but I do not know enough and did not succeed. Please would make the corrections in the time zone files and make them available? For reference see: http://en.wikipedia.org/wiki/Time_in_Spain#The_Canary_Islands_exception Thank you very much for correcting this. Kind regards, Sylvie Weber Calle Aceviño 49 Ed. Tarahal, Apto 201 38400 Puerto de la Cruz, Tenerife Spain Tel. +34 674 80 18 34 email: moxhull(a)gmail.com [image: Inline image 1]

2 1

Question about IANA time zone names
by Avila, Edgar May 15, 2015

May 15, 2015

Hi, I'm a software engineer working on the data modeling group. We are trying to figure out how the IANA time zone names can be described on our message model. At the modem it seems that the time zone names such as America/Costa_Rica or Japan are just a string without restrictions. We wonder whether there is a restriction such as maximum length of characters, pattern of characters to allow, etc. One more question, is it really America/Costa_Rica or Japan a name or an ID? The following is the description we have today in one of our schemas: <xs:simpleType name="IANATimeZoneId_Type"> <xs:annotation> <xs:documentation> Timezone Id represented by IANA. </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> Thanks in advance ________________________________ [https://www.aciworldwide.com/photolibrary/ACI_logotag_footer.gif]<http://www.aciworldwide.com> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally.

2 1