July 2015 - tz - lists.iana.org

Re: [tz] Full timezone names
by Matt Johnson July 20, 2015

July 20, 2015

CLDR is indeed the best resource available for full names, particularly due to localization concerns. AFAIK, there is no desire to replicate this in tzdb. Abbreviations are particularly tricky. Not only might they change per language, but there might not be any "real" abbreviation in use by people in the region. ________________________________ From: William Roberts<mailto:wmr501@outlook.com> Sent: ‎7/‎19/‎2015 8:57 PM To: tz(a)iana.org<mailto:tz@iana.org> Subject: [tz] Full timezone names Hi I'm currently using the tz data that comes with PHP. Is there a way of retrieving the full timezone name from the tz database, eg. Central European Time, Eastern Standard Time etc. So far I haven't been able to, so am using the CLDR repository which assigns a metazone to each timezone from the tz database, and from that I can get the full timezone name but it's not ideal as they don't always match exactly with the abbreviations from the tz data. Are there any plans to enable the full timezone names to be retrieved from the tz database the same way you would the abbreviations in PHP for example, or is getting them from the CLDR repository the best way to go about it? Thanks.

1 0

Behaviour in the face of multiple identical rules
by Jon Skeet July 19, 2015

July 19, 2015

This is more of an awareness-raising post than anything else... the data here is very far in the past. While trying to validate Noda Time against zic, I came up against issues with data releases between 1993 and 1996 in Egypt/Cairo. It turns out that this is because the Egypt rule is duplicated in the asia file, and this affects things. As a smallish example, if you create a file called testzone like this: Rule Egypt 1900 only - Oct 1 0:00 0 - > Rule Egypt 1943 1945 - Nov 1 0:00 0 - > Rule Egypt 1945 only - Apr 16 0:00 1:00 " > DST" > Rule Egypt 1957 only - May 10 0:00 1:00 " > DST" > Rule Egypt 1957 1958 - Oct 1 0:00 0 - > Rule Egypt 1958 only - May 1 0:00 1:00 " > DST" > # Rule Egypt 1957 only - May 10 0:00 1:00 " > DST" > > # Zone NAME GMTOFF RULES FORMAT [UNTIL] > Zone Africa/Cairo 2:05:00 - LMT 1900 Oct > 2:00 Egypt EET%s ... then execute: $ zic -d . testzone && zdump -v -c 1955,1958 $PWD/Africa/Cairo You'll see output like this for the May 1957 transition: .../Africa/Cairo Thu May 9 21:59:59 1957 UT = Thu May 9 23:59:59 1957 > EET isdst=0 gmtoff=7200 > ...Africa/Cairo Thu May 9 22:00:00 1957 UT = Fri May 10 01:00:00 1957 > EET DST isdst=1 gmtoff=10800 That looks okay - the transition is around midnight, as described. If, however, you uncomment that last "Rule" line above - which is an exact duplicate of the earlier one - you get: .../Africa/Cairo Thu May 9 20:59:59 1957 UT = Thu May 9 22:59:59 1957 > EET isdst=0 gmtoff=7200 > .../Africa/Cairo Thu May 9 21:00:00 1957 UT = Fri May 10 00:00:00 1957 > EET DST isdst=1 gmtoff=10800 Now the transition is one hour earlier. As it happens, this duplicate rule doesn't make any difference to Noda Time - it still emits the first output. I *strongly suspect* that I shouldn't care about this - that situations with duplicate rules should be deemed out of scope for any implementation. However, if anyone can think of any good justification why an implementation *should* behave like zic in this case, I'd be really interested to hear it. (I'm not asking for zic to change here. It already emits a warning because the rule is defined in multiple files, and I think that's good enough.) Jon

3 4

No leap second on 2015-12-31.
by Tim Parenti July 18, 2015

July 18, 2015

Per IERS Bulletin C50 (2015-07-07), no leap second will be observed on 2015-12-31. This patch updates leap-seconds.list from NIST. -- Tim Parenti

2 1

[Announce] C++11 / C++14 IANA Time Zone Database Parser
by Howard Hinnant July 18, 2015

July 18, 2015

http://howardhinnant.github.io/tz.html It is still very early in its development process. It has only been tested on OS X 10.10.4. It requires at least C++11, and prefers C++14. Contributions to making it more portable to reasonable C++11 and beyond platforms are welcomed. Howard

2 5

[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