- tz - lists.iana.org

CST timezone that does not account for DST
by Nilesh Parmar July 31, 2015

July 31, 2015

Hello Team, How can we have CST timezone that does not account for DST ? Using the POSIX string, we can create a timezone called CST that is GMT+6 as follows: [root@hp-dl120gen9-01 ~]# TZ=:CST6 date Thu Jul 9 06:50:29 CST 2015 But this is not consitent if tzdata package is update. Also this does take into account DST change? Thanks, Nilesh P.

6 7

Time zone identifiers in user interfaces
by Gilmore Davidson July 30, 2015

July 30, 2015

Hi, long time lurker here, finally throwing my voice into the ring. This is a follow-up to the “Time Zone City for China” thread a week ago (starting at http://mm.icann.org/pipermail/tz/2015-July/022480.html <http://mm.icann.org/pipermail/tz/2015-July/022480.html> ). What particularly caught my attention was the discussion about the use of time zone IDs in user interfaces. Paul Eggert: "The string 'Asia/Shanghai' is a tzdata-specific identifier, not intended to be visible to non-experts.” Guy Harris: "Several time zone selectors I've seen are lazily-written crap that either directly display the tzdb name or tweak it slightly by, for example, splitting it into continent and city and displaying them in a more "user-friendly" form.” Guy Harris: “> Looks like this logic is not well understood by the communities. Then we need to do a better job of explaining it to them.” Not to put too fine a point on it… Yes, there needs to be a better job done of explaining that the city names in time zone IDs should not be used in user interfaces. After reading that discussion I went looking through the tzdb files for guidance around the use of IDs in UIs. All I managed to find was this snippet in the Theory file, on line 385: This naming convention is not intended for use by inexperienced users to select TZ values by themselves (though they can of course examine and reuse existing settings). Distributors should provide documentation and/or a simple selection interface that explains the names; see the 'tzselect' program supplied with this distribution for one example. Given that the above snippet is around halfway through the file – and its wording still provides a fair bit of leeway – it’s not exactly enforcing the stronger opinions displayed on this list about how the IDs should be used. For some context, my domain knowledge is restricted to web sites/applications, so I can’t speak to the OS-level discussions in the previous thread. What I do know is how web developers deal with time zones, if they deal with them at all. For the most part, they use a library specific to their language of choice which slightly abstracts the tzdb data. There are two things these libraries have in common: 1. They use tzdb zone identifiers as the primary part of their API. 2. They don’t have any mentions in their documentation that these identifiers are not for public display. This is not me picking on time zone library authors, as I know that some of them are on this mailing list. My main point is that web developers are, for the most part, so abstracted from the tzdb source that the zone IDs are the only interface they know. Therefore the IDs are what they put in their selection UIs. There’s also the not-insignificant matter of localisation of display names (even Moment Timezone, referenced in tz-link.htm, notes in its API documentation: "Because these strings are generally localized, Moment Timezone does not provide any long names for zones.”). Personally, I didn’t know of the existence of CLDR until I started reading this mailing list. So, instead of dismissing zone-IDs-in-a-user-interface as “lazily written crap”, how about we: a) Acknowledge that most web-based UIs for picking time zones are written by developers who genuinely don’t know any better (I count my past self in this category) b) Make an effort to better educate them about recommended uses of the IDs. I am not intending for this to come across as antagonistic or facetious. I just genuinely want the quality of time zone selectors on the web to improve. Cheers, Gil

2 3

[PROPOSED PATCH 1/2] * southamerica: Give source for 1965 Venezuela transition.
by Paul Eggert July 30, 2015

July 30, 2015

--- southamerica | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/southamerica b/southamerica index dcc063f..dd9235f 100644 --- a/southamerica +++ b/southamerica @@ -1734,6 +1734,10 @@ Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 # Venezuela # +# From Paul Eggert (2015-07-28): +# For the 1965 transition see Gaceta Oficial № 27.619 (1964-12-15), p 205.533 +# http://www.pgr.gob.ve/dmdocuments/1964/27619.pdf +# # From John Stainforth (2007-11-28): # ... the change for Venezuela originally expected for 2007-12-31 has # been brought forward to 2007-12-09. The official announcement was @@ -1745,6 +1749,6 @@ Zone America/Montevideo -3:44:44 - LMT 1898 Jun 28 # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Caracas -4:27:44 - LMT 1890 -4:27:40 - CMT 1912 Feb 12 # Caracas Mean Time? - -4:30 - VET 1965 # Venezuela Time + -4:30 - VET 1965 Jan 1 0:00 # Venezuela T. -4:00 - VET 2007 Dec 9 3:00 -4:30 - VET -- 2.1.4

8 12

Uruguay out of DST
by J J July 24, 2015

July 24, 2015

>> >>* Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambi… <http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambi…> * >> That is a press release published by an organization lobbying for the change, >> and surely such a source is less reliable than the newspapers we're already citing. >> The whole thing is very mysterious, at least to this outsider. Here is the decree signed by the president of Uruguay, on presidency website, http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf

1 0

Uruguay out of DST
by Steffen Thorsen July 24, 2015

July 24, 2015

According to media in Uruguay, it looks like they will not be using DST the coming summer: http://www.elobservador.com.uy/gobierno-resolvio-que-no-habra-cambio-horari… http://www.republica.com.uy/este-ano-no-se-modificara-el-huso-horario-en-ur… It is a bit unclear if this is just this coming summer, or a permanent change. Our English summary (will be updated when we know more details): http://www.timeanddate.com/news/time/uruguay-stops-dst-2015.html Best regards, Steffen Thorsen - timeanddate.com

22 63

Time Zone City for China
by 寇含军 July 23, 2015

July 23, 2015

Dear Sir or Madam, I have a question that bothered me for many years since I started to use the Linux systems. When we, Chinese users, are selecting the desired timezone for our Linux boxes, we always feel weird that there has been no "Asia/Beijing". Instead we see "Asia/Shanghai" or "Asia/Chongqing". This might by how IANA "thinks" what the China timezone convention is, but SERIOUSLY this is not what we, Chinese users, are expecting. We would be very happy to see "Asia/Beijing" among the list. I googled that this question has been asked in many places to different maintainers or distributors, and finally I figured out that IANA is the ultimate upstream who can fix this issue. As a matter of fact, if you take a look at the Windows time zone settings dialog, Beijing is in the list, but no Shanghai. Please add ""Asia/Beijing" to the list. Please take it into consideration and thank you very much! Best Regards, Hanjun Kou, an ordinary Chinese Linux user

7 15

Lack of "initial" transitions for some zones
by Jon Skeet July 22, 2015

July 22, 2015

I suspect this is just a matter of how the data has been specified, but it's a little odd... I'm looking at the output of zic for each zone, and almost all zones start with a "transition" for some timestamp in the long distant past - including fixed zones such as UTC and Etc/*. However, the legacy "root" zones of CET, EET, PST8PDT etc don't have this initial "transition" in the file - unless I'm misinterpreting it, which is always a possibility. Would it make sense to adjust either the data or zic to make all zic output (in the 8-byte-timestamp format, at least) cover all of time? I realize that this "extra" data (presumably an insertion of "standard time until the first transition") may well not be historically accurate - but I doubt that it would be any less accurate than other zones in a similar situation. Jon

4 10

No DST for Uruguay since 2015
by Guillermo Pereyra July 20, 2015

July 20, 2015

http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf

3 2

About the core city of a tz region
by David Patte ₯ July 20, 2015

July 20, 2015

I am curious about the protocol that tz uses to specify the name of each tz region. Is the core city in a region always the most populous city in the tz region? And what is done if a smaller city's population overtakes the named city? Is the zone renamed? Also, since historical data (pre-1970) is now maintained only for the named city in a region, does it not make sense to use the population as of 1970, since the historical records actually affected more people at that time?

4 4

Zone America/Glace_Bay
by Hank W. July 20, 2015

July 20, 2015

I just read in Wikipedia that Glace Bay, Nova Scotia, Canada existed only from 1901 to 1995. The government of Glace Bay was dissolved on 1 Aug 1995 when eight municipalities, including Glace Bay, were consolidated to form Cape Breton (a.k.a. CBRM, short for Cape Breton Regional Municipality), which is currently the second-most populous municipality in Nova Scotia after Halifax. Wikipedia shows Cape Bretons coordinates as 46° 9 north latitude by 60° 10 west longitude. That longitude corresponds to a local mean time of UTC-4:00:40. https://en.wikipedia.org/wiki/Glace_Bay https://en.wikipedia.org/wiki/Cape_Breton_Regional_Municipality Hank Wisniewski of Austin, Texas, U.S.A.

4 6

Type values in rules
by Jon Skeet July 20, 2015

July 20, 2015

Hi folks, It wasn't until last night that I first saw a non "-" entry for a type line - Australia/Adelaide had rules of Rule AS 1990 1994 even Mar Sun>=18 2:00s 0 - Rule AS 1990 1994 odd Mar Sun>=1 2:00s 0 - until release 2000f. Now in Noda Time I could probably support non-infinite rules with a fixed set of types (hopefully just odd and even), but it would be a bit of work. If type values are effectively obsolete, I may not bother. So, is it just coincidence that there have been no uses of the Type field in the released data since 2000f, or is this effectively policy now? (I can understand keeping the functionality for private usage, where others may use zic with their own data sets, but for Noda Time I'm not worried about that. Jon

2 2

Full timezone names
by William Roberts July 20, 2015

July 20, 2015

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.

2 1

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

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