- tz - lists.iana.org

Shortz circuit? (Spoiler)
by Arthur David Olson Sept. 6, 2013

Sept. 6, 2013

(Spoiler ahead.) (Yes, really.) Today's "New York Times" crossword gives "Prime meridian std." as the clue for the three-letter entry at 44 down; the solution, according to... http://www.xwordinfo.com/Crossword?date=9/6/2013 ...is "GST." Rather than GMT or BST. @dashdashado

2 1

[PATCH] Support time stamps past 2038 in zones like America/Santiago.
by Paul Eggert Sept. 6, 2013

Sept. 6, 2013

This implements a suggestion by Arthur David Olson. Without this change, zic -v diagnoses problems with several zones where it cannot compute a POSIX-equivalent TZ setting for time stamps past 2038, which means these time stamps may be mishandled. This entails a minor change to the binary tz file format, to allow a minor extension to the POSIX TZ setting in the binary file, instead of requiring a pure POSIX TZ setting. The zones fixed by this change are America/Godthab, America/Santiago, Antarctica/Palmer, Asia/Gaza, Asia/Hebron, Asia/Jerusalem, Pacific/Easter, and Pacific/Fiji. The only zone that remains unfixed is Asia/Tehran, which schedules clock transitions via the Iranian calendar, something that even the extended TZ setting cannot represent. * localtime.c (getrule): Allow transition times to be signed. * newtzset.3: Describe the extensions to POSIX TZ strings. Some of these extensions (e.g., hours == 26) were already implemented but were not documented. Give examples. * tzfile.5: Document the relaxed restriction on the stored TZ string; its hours component can be in the range -167..167 rather than the POSIX-required 0..24. Refer to newtzset(5). * zic.c (stringoffset): Allow hours to go up to 167. (stringrule): Be willing to generate hours in the range -167 through 167. --- localtime.c | 2 +- newtzset.3 | 37 ++++++++++++++++++++++++++++++++++--- tzfile.5 | 6 +++++- zic.c | 27 ++++++++++++++------------- 4 files changed, 54 insertions(+), 18 deletions(-) diff --git a/localtime.c b/localtime.c index 619a656..91a3171 100644 --- a/localtime.c +++ b/localtime.c @@ -835,7 +835,7 @@ getrule(const char *strp, register struct rule *const rulep) ** Time specified. */ ++strp; - strp = getsecs(strp, &rulep->r_time); + strp = getoffset(strp, &rulep->r_time); } else rulep->r_time = 2 * SECSPERHOUR; /* default = 2:00:00 */ return strp; } diff --git a/newtzset.3 b/newtzset.3 index 3689e50..bb40c01 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -177,16 +177,47 @@ The .I time has the same format as .I offset -except that no leading sign +except that POSIX does not allow a leading sign .RB (`` \(mi '' or -.RB `` \(pl '') -is allowed. The default, if +.RB `` \(pl ''). +As an extension to POSIX, the hours part of +.I time +can range from \(mi167 to 167; this allows for unusual rules such +as "the Saturday before the first Sunday of March". The default, if .I time is not given, is .BR 02:00:00 . .RE .LP +Here are some examples of +.B TZ +values that directly specify the time zone rules; they use some of the +extensions to POSIX. +.TP +.B EST5 +stands for US eastern +time (EST), 5 hours behind UTC, without daylight saving. +.TP +.B FJT\(mi12FJST,M10.3.4/74,M1.3.4/75 +stands for Fiji Time (FJT) and Fiji Summer Time (FJST), 12 hours ahead +of UTC, where clocks spring forward at 74:00 on the third Thursday in +October (i.e., 02:00 on the first Sunday on or after October 18), and +fall back at 75:00 on the third Thursday in January (i.e., 03:00 on +the first Sunday on or after January 18). +.TP +.B IST\(mi2IDT,M3.4.4/26,M10.5.0 +stands for Israel standard time (IST) and Israel daylight time (IDT), +2 hours ahead of UTC, where clocks spring forward at 26:00 on the +fourth Thursday in March (i.e., 02:00 on the first Friday on or after +March 23), and fall back at 02:00 on the last Sunday in October. +.TP +.B WGT3WGST,M3.5.0/\(mi2,M10.5.0/\(mi1 +stands for Western Greenland Time (WGT) and Western Greenland Summer +Time (WGST), 3 hours behind UTC, where clocks follow the EU rules of +springing forward the last Sunday in March at \(mi02:00 (i.e., 01:00 UTC) +and falling back the last Sunday in October at \(mi01:00 (i.e., 01:00 UTC). +.PP If no .I rule is present in diff --git a/tzfile.5 b/tzfile.5 index e92eaed..c7bd40e 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -145,7 +145,11 @@ POSIX-TZ-environment-variable-style string for use in handling instants after the last transition time stored in the file (with nothing between the newlines if there is no POSIX representation for such instants). +This string may use a minor extension to the POSIX TZ format: the +hours part of its transition times may be signed and range from +\(mi167 through 167 instead of the POSIX-required unsigned values +from 0 through 24. .SH SEE ALSO -newctime(3) +newctime(3), newtzset(3) .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson. diff --git a/zic.c b/zic.c index 97786ae..260dc2e 100644 --- a/zic.c +++ b/zic.c @@ -1776,7 +1776,7 @@ stringoffset(char *result, zic_t offset) minutes = offset % MINSPERHOUR; offset /= MINSPERHOUR; hours = offset; - if (hours > HOURSPERDAY) { + if (hours >= HOURSPERDAY * DAYSPERWEEK) { result[0] = '\0'; return -1; } @@ -1793,7 +1793,7 @@ static int stringrule(char *result, const struct rule *const rp, const zic_t dstoff, const zic_t gmtoff) { - register zic_t tod; + register zic_t tod = rp->r_tod; result = end(result); if (rp->r_dycode == DC_DOM) { @@ -1807,32 +1807,33 @@ stringrule(char *result, const struct rule *const rp, const zic_t dstoff, (void) sprintf(result, "J%d", total + rp->r_dayofmonth); } else { register int week; + register int wday = rp->r_wday; + register int wdayoff; if (rp->r_dycode == DC_DOWGEQ) { - if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) - return -1; - week = 1 + rp->r_dayofmonth / DAYSPERWEEK; + wdayoff = (rp->r_dayofmonth - 1) % DAYSPERWEEK; + wday -= wdayoff; + tod += wdayoff * SECSPERDAY; + week = 1 + (rp->r_dayofmonth - 1) / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { - if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) - return -1; + wdayoff = rp->r_dayofmonth % DAYSPERWEEK; + wday -= wdayoff; + tod += wdayoff * SECSPERDAY; week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ + if (wday < 0) + wday += DAYSPERWEEK; (void) sprintf(result, "M%d.%d.%d", - rp->r_month + 1, week, rp->r_wday); + rp->r_month + 1, week, wday); } - tod = rp->r_tod; if (rp->r_todisgmt) tod += gmtoff; if (rp->r_todisstd && rp->r_stdoff == 0) tod += dstoff; - if (tod < 0) { - result[0] = '\0'; - return -1; - } if (tod != 2 * SECSPERMIN * MINSPERHOUR) { (void) strcat(result, "/"); if (stringoffset(end(result), tod) != 0) -- 1.8.1.2

2 1

Re: [tz] [tzdb] Re: Proposed patch - Theory change to reinstate reference to ISO-3166
by random832＠fastmail.us Sept. 6, 2013

Sept. 6, 2013

On Fri, Sep 6, 2013, at 4:29, Tobias Conradi wrote: > >> The ISO website also shows > >> ISO 3166:1981 > >> ISO 3166:1988 > >> ISO 3166:1993 > > > > Those are all the same standard. > Your sources? Mine are pages of the ISO website, among them the two I > provided a link for. You're being absurdly pedantic. They are three _versions of_ one standard - the later version supersedes the earlier ones. This is entirely obvious from the names, and needs no further source.

1 0

[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