September 2013 - tz - lists.iana.org

[PATCH] Record that San Luis is at UTC-3, not UTC-4 with perpetual DST.
by Paul Eggert Sept. 5, 2013

Sept. 5, 2013

* southamerica (SanLuis): Move October 2009 transition from here ... (America/Argentina/San_Luis): ... to here. This causes San Luis to not appear to be on perpetual DST. --- southamerica | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/southamerica b/southamerica index f2e8f12..aab2e1a 100644 --- a/southamerica +++ b/southamerica @@ -451,6 +451,17 @@ Rule Arg 2008 only - Oct Sun>=15 0:00 1:00 S # rules...San Luis is still using "Western ARgentina Time" and it got # stuck on Summer daylight savings time even though the summer is over. +# From Paul Eggert (2013-09-05): +# Perhaps San Luis operates on the legal fiction that it is at UTC-4 +# with perpetual summer time, but ordinary usage typically seems to +# just say it's at UTC-3; see, for example, +# <http://es.wikipedia.org/wiki/Hora_oficial_argentina>. +# We've documented similar situations as being plain changes to +# standard time, so let's do that here too. This does not change UTC +# offsets, only tm_isdst and the time zone abbreviations. One minor +# plus is that this silences a zic complaint that there's no POSIX TZ +# setting for time stamps past 2038. + # From Paul Eggert (2013-02-21): # Milne says Cordoba time was -4:16:48.2. Round to the nearest second. @@ -588,7 +599,7 @@ Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31 # San Luis (SL) Rule SanLuis 2008 2009 - Mar Sun>=8 0:00 0 - -Rule SanLuis 2007 2009 - Oct Sun>=8 0:00 1:00 S +Rule SanLuis 2007 2008 - Oct Sun>=8 0:00 1:00 S Zone America/Argentina/San_Luis -4:25:24 - LMT 1894 Oct 31 -4:16:48 - CMT 1920 May @@ -604,7 +615,8 @@ Zone America/Argentina/San_Luis -4:25:24 - LMT 1894 Oct 31 -3:00 - ART 2004 May 31 -4:00 - WART 2004 Jul 25 -3:00 Arg AR%sT 2008 Jan 21 - -4:00 SanLuis WAR%sT + -4:00 SanLuis WAR%sT 2009 Oct 11 + -3:00 - ART # # Santa Cruz (SC) Zone America/Argentina/Rio_Gallegos -4:36:52 - LMT 1894 Oct 31 -- 1.8.1.2

1 0

[PATCH 1/4] northamerica: move America/Shiprock to 'backward'
by Paul Eggert Sept. 5, 2013

Sept. 5, 2013

This fixes the 2013-08-15 change so that 'make check' works again. * backward (America/Shiprock): Move this link here.... * northamerica (America/Shiprock): ... to here. --- backward | 1 + northamerica | 5 +++-- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/backward b/backward index c8c184e..561e2ff 100644 --- a/backward +++ b/backward @@ -25,6 +25,7 @@ Link America/Guadeloupe America/Marigot Link America/Argentina/Mendoza America/Mendoza Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario +Link America/Denver America/Shiprock Link America/Guadeloupe America/St_Barthelemy Link America/St_Thomas America/Virgin Link Pacific/Auckland Antarctica/McMurdo diff --git a/northamerica b/northamerica index 13278d2..7676c77 100644 --- a/northamerica +++ b/northamerica @@ -636,8 +636,9 @@ Zone America/Phoenix -7:28:18 - LMT 1883 Nov 18 11:31:42 # Navajo Nation participates in the Daylight Saving Time policy, due to its # large size and location in three states." (The "only" means that other # tribal nations don't use DST.) - -Link America/Denver America/Shiprock +# +# From Paul Eggert (2013-08-26): +# See America/Denver for a zone appropriate for the Navajo Nation. # Southern Idaho (Ada, Adams, Bannock, Bear Lake, Bingham, Blaine, # Boise, Bonneville, Butte, Camas, Canyon, Caribou, Cassia, Clark, -- 1.8.1.2

10 19

Adding verified historic details
by Lester Caine Sept. 5, 2013

Sept. 5, 2013

Paul I sat down and worked my way through the UK details to see what is documented and what not. I'm normally using the results rather than the raw data, but I think I understand how this works now. I'm still using my own code in parallel with the version of TZ that Derick has built into the PHP clock tools so the main thing here is now comparing results. I've even got the original emails still archived. I've been using the 1880 'legal' date for the adoption of GMT and calling 'the other time' Railway time, but I can accept combining them. However the documents are all legal ones so using 'legal' time so midnight for a change was legal midnight not GMT until 1880 - that's politics for you :) As far as I am concerned, the Isle of Man was using LMT until 1883 and we now have a date of 30th March to go with that. I've always worked with 18 minutes offset, although Tynwald which is always quoted as the reference is 4.4814degW - 17m55.5s and that goes back 1000 years, but I think we can skip earlier solar times. So looking at the Europe data file ... # 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 Link Europe/London Europe/Jersey Link Europe/London Europe/Guernsey Link Europe/London Europe/Isle_of_Man I think I need to add ... # AT4 of 1883 - The Statutory Time et cetera Act 1883 - Zone Europe/Isle_of_Man 0:17:55 - LMT 1883 March 30 0:00s Then the London Rules apply from then so in my simple way of thinking Link To Europe/London ( date is optional as on line above? ) Fills the picture. Europe/Isle_of_Man exists in it's own right up to 1883, and then it follows Europe/London. I'm fairly sure from the IOM documents that Jersey and Guernsey followed the same date, but their archives have not got that far back yet. So do we have to duplicate the whole zone record each timezone to add this one item of data? - - Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

10 30

[PATCH] * newctime.3: Fix typos reported by Paul Goyette.
by Paul Eggert Sept. 5, 2013

Sept. 5, 2013

--- newctime.3 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/newctime.3 b/newctime.3 index ece8507..61cd9e4 100644 --- a/newctime.3 +++ b/newctime.3 @@ -62,9 +62,9 @@ The time stamp represents the time in seconds since 1970-01-01 00:00:00 Coordinated Universal Time (UTC). The POSIX standard says that time stamps must be nonnegative -must ignore leap seconds. +and must ignore leap seconds. Many implementations extend POSIX by allowing negative time stamps, -and can therefore represent time stamps that that predate the +and can therefore represent time stamps that predate the introduction of UTC and are some other flavor of Universal Time (UT). Some implementations support leap seconds, in contradiction to POSIX. .PP -- 1.8.1.2

1 0

Proposed patch - Theory notes for backward file
by Stephen Colebourne Sept. 5, 2013

Sept. 5, 2013

Theory notes for backward file Note that the file exists for compatibility and canonicalization Explicitly note IDs in that file are deprecated Explicitly note that data set should make sense without backward ---------------- https://github.com/jodastephen/tz/commit/709e51dc7aeea8c2286b8a50c0d91d475b… The aim of this patch is simple - to document what the backward file is for in more detail. Stephen ---------------- @@ -362,12 +362,19 @@ constraints. Although a 'zone.tab' location's longitude corresponds to its LMT offset with one hour for every 15 degrees east longitude, this relationship is not exact and is not true for 'time.tab'. +The file 'backward' consists of Link entries mapping deprecated names +to their replacements. Usage of a deprecated name is discouraged. +As such, the file permits canonicalization, where the use of a +deprecated name can be automatically replaced with the replacement. +If the data set is used with the 'backward' file file excluded, then +it must remain logical and complete. For example, there must be no +references to any deprecated name from any other file. + Older versions of this package used a different naming scheme, -and these older names are still supported. -See the file 'backward' for most of these older names +and these older names are still supported using 'backward'. (e.g. 'US/Eastern' instead of 'America/New_York'). -The other old-fashioned names still supported are -'WET', 'CET', 'MET', and 'EET' (see the file 'europe'). +Some other old-fashioned names are not deprecated, such as +'WET', 'CET', 'MET', and 'EET', see the 'europe' file.

5 11

Proposed patch - Theory change to reinstate reference to ISO-3166
by Stephen Colebourne Sept. 5, 2013

Sept. 5, 2013

Theory change to reinstate reference to ISO-3166 Use ISO-3166 as a guide for when a name should exist Countries are not specified and nothing is mandated -------------------------- https://github.com/jodastephen/tz/commit/e6199cc2616e938efb9422b263bd09da70… This patch reinstates the link to ISO-3166 in a softer way. In my opinion, the original removal (of something present for 16 years) did not have consensus and should have been reverted. However, I offer this patch as a possible middle ground. Stephen -------------------------- @@ -316,6 +316,8 @@ in decreasing order of importance: 'America/New_York' precludes 'America/New_York/Bronx'. Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there. + Use ISO-3166 as a guide to ensuring time zone name coverage. + There should typically be at least one name per ISO-3166 code. If all the clocks in a region have agreed since 1970, don't bother to include more than one location even if subregions' clocks disagreed before 1970.

5 7

State of the tzdb
by Stephen Colebourne Sept. 4, 2013

Sept. 4, 2013

We're a lot further forward now to regaining stability, but there are a few points still outstanding. 1) Should there be one zone ID in the main files (not "backward") for each inhabited ISO-3166 code? I've argued for this as a reinstatement of a rule of 16 years standing which is no more than common sense. Paul has argued against. 2) Zone ID for America/Shiprock Reinstate Yes/No? 3) Zone ID for Antarctica/South_Pole Reinstate Yes/No? At a minimum, the "backward" link needs to point to McMurdo 4) Recognise correct usage of "backward" file As per ECMAscript: http://norbertlindenberg.com/ecmascript/intl.html#sec-6.4.2 the "backward" is, and will continue to be, used for canonicalization - ie. identifying which IDs can be normalized away. As such, the tzdb needs to be very careful about cross-ISO-3166 links placed in the "backward" file (IMO there should be none to avoid political offence via canonicalization). The use of "backward" should be further documented in Theory to indicate its usage as a canonicalization file, and to indicate that the entire tzdb data set must make sense if the "backward" file is not processed (thus no lines in zone.tab should point to an ID in "backward") 5) Pre-1970 data Some of this seems uncontroversial at this point (don't remove data, don't create new IDs just for pre-1970). Some of it is still under discussion. Only enhancement of existing IDs is necessary to the applications I work with. As noted in the other thread, removing IDs that only differ in LMT is harder than initially thought, as the start of fixed offsets and the name of fixed offsets are pieces of data covered under the no deletion rule. As such, it is unlikely that there are many possibilities for merging zones. 6) ... anything I've forgotten? Finally, I'm sorry I've had to spend so must list time discussing this. Unfortunately, this data is just too important to me and the applications/langauages downstream of me to allow me to not object loudly. thanks Stephen

6 13

[PATCH] Document some longstanding unwritten guidelines.
by Paul Eggert Sept. 3, 2013

Sept. 3, 2013

These come from POSIX or similar platforms, or from the standard 'zic' implementation, but never got written down anywhere. * Theory: Document other POSIX-inspired restrictions on names. * zic.8 (DESCRIPTION): Document that zic's behavior is unspecified if some names are duplicates. Sometimes it complains, sometimes not. --- Theory | 10 ++++++++-- zic.8 | 3 +++ 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/Theory b/Theory index bd62c5c..b11cbc8 100644 --- a/Theory +++ b/Theory @@ -299,15 +299,21 @@ Here are the general rules used for choosing location names, in decreasing order of importance: Use only valid POSIX file name components (i.e., the parts of - names other than '/'). Within a file name component, + names other than '/'). Do not use the file name + components '.' and '..'. Within a file name component, use only ASCII letters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer 'Brunei' to 'Bandar_Seri_Begawan'. + A name must not be empty, or contain '//', or start or end with '/'. Do not use names that differ only in case. Although the reference - implementation is case-sensitive, some other implementations + implementation is case-sensitive, some other implementations are not, and they would mishandle names differing only in case. + If one name A is an initial prefix of another name AB (ignoring case), + then B must not start with '/', as a regular file cannot have + the same name as a directory in POSIX. For example, + 'America/New_York' precludes 'America/New_York/Bronx'. Uninhabited regions like the North Pole and Bouvet Island do not need locations, since local time is not defined there. If all the clocks in a region have agreed since 1970, diff --git a/zic.8 b/zic.8 index d61555e..d0d34ce 100644 --- a/zic.8 +++ b/zic.8 @@ -362,6 +362,9 @@ field is used as an alternate name for that zone. .PP Except for continuation lines, lines may appear in any order in the input. +However, the behavior is unspecified if multiple zone or link lines +define the same name, or if the source of one link line is the target +of another. .PP Lines in the file that describes leap seconds have the following form: .nf -- 1.8.1.2

1 0

[PATCH 2/3] Replace some zones with links when that doesn't lose non-LMT info.
by Meno Hochschild Sept. 3, 2013

Sept. 3, 2013

*Paul Eggert* eggert at cs.ucla.edu <mailto:tz%40iana.org?Subject=Re:%20Re%3A%20%5Btz%5D%20%5BPATCH%202/3%5D%20Replace%20some%20zones%20with%20links%20when%20that%0A%20doesn%27t%20lose%20non-LMT%20info.&In-Reply-To=%3C522616ED.6060902%40cs.ucla.edu%3E> /Tue Sep 3 17:05:49 UTC 2013/ Lester Caine wrote: >/can we at least agree that the quality of the material is heading in the right direction? / Yes, that's the idea. While I personally have no problem with tidy-up of obviously wrong data and also agree that correction of mistakes is more important than stability (which has never been absolutely pretended), I think end-users of tzdb should get a better opportunity to estimate how reliable the data are and how much trust they can put in their time zone calculations. Offsets in LMT-lines can easily be qualified as UNKNOWN. For the proposed date of 1970 as general separation point between UNSAFE and (apparently) RELIABLE I am not so sure. Would it not be helpful for end-users if there is an additional year-type attribute per zone which tells the users since when the data can be confirmed with high probability of correctness? Would require about 400+ attributes (ok, 1970 as default). I am sure for example in UK or in Germany the data are correct even a pretty while before 1970. Flexibility would be a good thing, isn't it? External APIs could support the users with this extra quality information per offset and make them better aware that historical tz data are not set in stone. Just giving a thought...

3 2

Dealing with Pre-1970 Data
by David Patte ₯ Sept. 3, 2013

Sept. 3, 2013

Though it has been handy to have some pre-1970 data within the tz database, I don't see that it is the best solution for historical tz data in the long run. It is clear that that going back far enough in time there is a different LMT for every 15 seconds of latitude. My own preference would be that historical (and perhaps all tz data) be given a numberic identifier, not a 'America/Someplace' name, for the populated areas in question. A good source of geographic identifiers already available is the geonames database. The tz data for Montreal could be identified by the geonames number for Montreal, and the tz data for Toronto associated with the geoname number for Toronto. Then, to build regions, since all geonames records already have a field for the tz region, these could reflect the numeric identifier of the tz recommended region for each location. For example, Ottawa, in the geonames database would refer to the numeric identifier of Toronto instead of 'America/Toronto', until sometime decides to add historical data for Ottawa's own tz history, at which point it would adopt the identifier for Ottawa.

10 69