- tz - lists.iana.org

Jordan permanently on UTC+3?
by Paul Eggert Sept. 20, 2013

Sept. 20, 2013

I looked for hints about what Jordan's going to do with its clocks next month, and found this article from February: Cancelling winter saved Jordan $7 million Petra News Agency 2013-02-20 11:34 UTC http://www.albawaba.com/business/jordan-winter-electricity--472005 Currently the tz database is guessing that Jordan will revert to UTC+2 next month, but if this article is any indication they'll stay at UTC+3 indefinitely, which means the obvious tz patch (already mentioned in the 2012-10-15 comments) would be appropriate.

1 0

Tocantins in Brazil probably not observing DST this season
by Steffen Thorsen Sept. 20, 2013

Sept. 20, 2013

According to this article, Tocantins in Brazil is very likely not to observe DST from October. The decree has not yet been issued, so the decision may still be revoked, but we assume it is very likely because it has been announced by the congressman and DST is so unpopular there. http://conexaoto.com.br/2013/09/18/ministerio-confirma-que-tocantins-esta-f… We will keep this article updated when this is confirmed: http://www.timeanddate.com/news/time/brazil-starts-dst-2013.html Best regards, Steffen Thorsen - timeanddate.com

2 1

Getting close to new release: testing, testing, ...
by Paul Eggert Sept. 20, 2013

Sept. 20, 2013

We need to release a new version soon, because of Fiji. I did further testing and it appears that the recent changes to add meta-information to the zic output won't fly, because they're incompatible with the GNU C library on Ubuntu 12.04. So we need to rethink that feature. There's no rush to introduce it, so let's omit it from the next release. Also, the -t option recently added to tzselect seems like it will be superseded by the tzwinnow approach, whenever we get that working and stable, so for now I think I'd rather omit this. There are a few other problems found by "make public", mostly links that were in the wrong files. I'll post proposed changes soon. If other people could do some testing that'd be nice. You can run "make public". The output should contain the following diagnostics: warning: "antarctica", line 318: Antarctica/Palmer: pre-2013 clients may mishandle distant timestamps warning: "asia", line 1412: 24:00 not handled by pre-1998 versions of zic warning: "asia", line 2332: 24:00 not handled by pre-1998 versions of zic warning: "asia", line 1026: Asia/Jerusalem: pre-2013 clients may mishandle distant timestamps (rule from "asia", line 1021) warning: "asia", line 1315: Asia/Amman: pre-1994 clients may mishandle distant timestamps warning: "asia", line 2016: Asia/Gaza: pre-2013 clients may mishandle distant timestamps warning: "asia", line 2347: Asia/Hebron: pre-2013 clients may mishandle distant timestamps warning: "australasia", line 269: Pacific/Fiji: pre-2013 clients may mishandle distant timestamps warning: "europe", line 998: America/Godthab: pre-2013 clients may mishandle distant timestamps warning: "southamerica", line 1141: America/Santiago: pre-2013 clients may mishandle distant timestamps warning: "southamerica", line 1313: Pacific/Easter: pre-2013 clients may mishandle distant timestamps along with a very long section that starts as follows, which shows that the tz code is still broken on platforms with unsigned 32-bit time_t (this is a longstanding problem). checking uint32_t zones ... --- tzpublic/int64_t.out 2013-09-11 02:43:50.871343089 -0700 +++ tzpublic/uint32_t.out 2013-09-11 02:43:55.907343185 -0700 @@ -210,278 +210,6 @@ Europe/Andorra Sun Mar 29 01:00:00 2037 UT = Sun Mar 29 03:00:00 2037 CEST isdst=1 Europe/Andorra Sun Oct 25 00:59:59 2037 UT = Sun Oct 25 02:59:59 2037 CEST isdst=1 Europe/Andorra Sun Oct 25 01:00:00 2037 UT = Sun Oct 25 02:00:00 2037 CET isdst=0 -Europe/Andorra Sun Mar 28 00:59:59 2038 UT = Sun Mar 28 01:59:59 2038 CET isdst=0 -Europe/Andorra Sun Mar 28 01:00:00 2038 UT = Sun Mar 28 03:00:00 2038 CEST isdst=1 -Europe/Andorra Sun Oct 31 00:59:59 2038 UT = Sun Oct 31 02:59:59 2038 CEST isdst=1

22 69

Historical data
by David Braverman Sept. 20, 2013

Sept. 20, 2013

I've followed the discussions about historical data with interest. I would like to keep historical data in the tzdb, and I understand why I'm in the minority. But I wonder if there couldn't be a compromise? We've implemented a .NET library that uses the tzdb by interpreting[1] the database rather than by compiling it. So for us, we only deploy the tzdb text files that the customer cares about. Some customers are strictly North American concerns, so we only put the northamerica file in their configuration; others need the whole database of 500-some zones. I think other posters have suggested separating pre-1970 data out into a separate file or file set. This would be perfect for our implementation. For the zic implementation, it seems like compilation is an all-or-nothing deal right now. But would it be difficult to create a build script that includes the historical data to the zic package if someone needs it, in addition to the post-1970 build script? Sorry if the question seems naïve. I just think there's room to compromise here. David Braverman Inner Drive Technology Chicago [1] The tzdb files actually get compiled down to an intermediate set of objects at application start, then live on in a singleton. The process takes about a second on an Azure Extra-Small instance. More info here: https://www.inner-drive.com/Demo/Timezones.aspx

2 1

Data changes for v2013e
by Stephen Colebourne Sept. 20, 2013

Sept. 20, 2013

To better help everyone understand the data changes in 2013e, I've run a tool to analyse them and produce nice coloured git diffs. Changes from 2013d to 2013e https://github.com/jodastephen/tzdiff/commit/57aac13605f184a46f74d22f7dddc9… Lines in green are new added data, lines in red are deletions. >From a purely data perspective, the majority of 2013e changes are LMT based. The largest change is to McMurdo/South_Pole. Previous changes for reference: Changes from 2013c to 2013d https://github.com/jodastephen/tzdiff/commit/db93687fe0d5a6bb4a8ee9dd2d81e9… Changes from 2013b to 2013c https://github.com/jodastephen/tzdiff/commit/d145f2ae94c0587aba378920b44227… Changes from 2013a to 2013b https://github.com/jodastephen/tzdiff/commit/639b044db3e3c24d98b0cf5a6fba85… Stephen

1 0

While searching for Vaduz info...
by Andrew Paprocki Sept. 19, 2013

Sept. 19, 2013

I was hunting around for information when the Vaduz change was proposed and while I didn't find anything related to Vaduz specifically, I came across these very nice historical German documents that may be of use to others. The first from a watch-makers journal in 1916 with many pages discussing the adoption of "summer time" that year and reservations about it. There are mentions of those who proposed the legislation, etc. for anyone who can read German and feels like digging through the various pages talking about it. This is the most relevant page (but there are many others -- search for Sommerzeit): (Page 131) http://babel.hathitrust.org/cgi/pt?id=nyp.33433090896915;view=1up;seq=145 The second discusses WET / CET in terms of railroads and contains an interesting snippet regarding CET being authorized since 1 Feb 1920 as well as Netherlands being 20 minutes offset from GMT. I can't find mention of 1 Feb 1920 in the database, so I'm not sure what it is referring to or if this is new/known information. Also, the database says that railroads did not observe the GMT+0:20 in Netherlands, yet this is a railroad journal specifically mentioning it. (Page 84) http://babel.hathitrust.org/cgi/pt?id=njp.32101066879451;view=1up;seq=98 Just leaving these here since some may be interested. Make sure the links leave you on the page # indicated -- sometimes Hathi jumps to an incorrect page. -Andrew

2 1

Re: [tz] tz Digest, Vol 24, Issue 75
by Sterling Udell Sept. 17, 2013

Sept. 17, 2013

> > Can I suggest that we split this into two updates, the first containing > only the Fiji change, and the second with everything else? +1

1 0

Re: [tz] Pulling the data apart ...
by random832＠fastmail.us Sept. 17, 2013

Sept. 17, 2013

On Mon, Sep 16, 2013, at 14:32, Tobias Conradi wrote: > On Mon, Sep 16, 2013 at 7:40 PM, <random832(a)fastmail.us> wrote: > > People don't use the term "separated" for that. > > Except those that do, Huh? Surely you're not claiming that the format _actually_ separates them with no space between them. Go ahead and delete every space from your files, see if zic accepts them. > e.g. tz documentation writers that use "any > number" instead of "one or more". I assert that by "number" they meant "natural number" rather than "integer" (or complex number, or rational number, or real number). The fact that it is a number of characters implies it is an integer. The fact that it is a number of characters that separates something implies it is nonzero and positive. "number" by itself is defined by context. No-one would imagine that this includes non-integers or negative numbers or complex numbers. Not even in your wildest fantasies did you claim there may be sqrt(2)+pi*i spaces, even though that is a number.

5 6

tz mailing list guidelines
by Paul Eggert Sept. 16, 2013

Sept. 16, 2013

Now's as good a time as any to say what guidelines are used when discarding or blocking contributions to the tz mailing list. The tz mailing list discusses proposals for updates that would improve the time zone code and data. When contributions to the mailing list, on balance, harm the project more than help it, it is often advisable to discard them. Examples of abuse include (but are not limited to) spamming, commercial advertising, personal attacks, repetitive or out-of-scope topics, disinformation, sock puppetry, block evasion, copyright violations, and legal threats. An abusive mailing list correspondent should be blocked, with contributions discarded. The length of the block should depend on the severity of the offenses and the estimated future likelihood that future contributions would help more than harm. Correspondents whose contributions consist entirely of spam, for example, should be blocked permanently right away. Correspondents who make significant useful contributions should be treated more leniently: their first block should be for a period of a day to a week; the second, a month to six months; and later blocks, one year to permanent.

1 0

[PATCH 1/3] * backward: Move some links back to primary files.
by Paul Eggert Sept. 16, 2013

Sept. 16, 2013

This should allay concerns that the links would go away any time soon. Suggested by Stephen Colebourne in <http://mm.icann.org/pipermail/tz/2013-September/019801.html>. Change "`" to "'"; these days, "`" and "'" are not symmetric. * antarctica (Antarctica/McMurdo): * europe (Europe/Jersey, Europe/Guernsey, Europe/Isle_of_Man) (Europe/Mariehamn, Europe/Busingen, Europe/Vatican, Europe/San_Marino) (Arctic/Longyearbyen, Europe/Ljubljana, Europe/Podgorica) (Europe/Sarajevo, Europe/Skopje, Europe/Zagreb, Europe/Bratislava): * northamerica (America/St_Barthelemy, America/Marigot): * southamerica (America/Lower_Princes, America/Kralendijk): Move here from 'backward'. This reverts a 2013-08-09 change. --- antarctica | 15 +++++++-------- backward | 19 ------------------- europe | 28 +++++++++++++++++++++------- northamerica | 44 +++++++++++++++++++++++--------------------- southamerica | 12 ++++++++---- 5 files changed, 59 insertions(+), 59 deletions(-) diff --git a/antarctica b/antarctica index 4cb7476..234e59c 100644 --- a/antarctica +++ b/antarctica @@ -16,9 +16,9 @@ # # Except for the French entries, # I made up all time zone abbreviations mentioned here; corrections welcome! -# FORMAT is `zzz' and GMTOFF is 0 for locations while uninhabited. +# FORMAT is 'zzz' and GMTOFF is 0 for locations while uninhabited. -# These rules are stolen from the `southamerica' file. +# These rules are stolen from the 'southamerica' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule ArgAQ 1964 1966 - Mar 1 0:00 0 - Rule ArgAQ 1964 1966 - Oct 15 0:00 1:00 S @@ -231,7 +231,7 @@ Zone Antarctica/Syowa 0 - zzz 1957 Jan 29 # Scott Base, Ross Island, since 1957-01. # See Pacific/Auckland. # -# These rules for New Zealand are stolen from the `australasia' file. +# These rules for New Zealand are stolen from the 'australasia' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule NZAQ 1974 only - Nov 3 2:00s 1:00 D Rule NZAQ 1975 1988 - Oct lastSun 2:00s 1:00 D @@ -269,11 +269,11 @@ Rule NZAQ 2008 max - Apr Sun>=1 2:00s 0 S # From Lee Hotz (2001-03-08): # I queried the folks at Columbia who spent the summer at Vostok and this is # what they had to say about time there: -# ``in the US Camp (East Camp) we have been on New Zealand (McMurdo) +# "in the US Camp (East Camp) we have been on New Zealand (McMurdo) # time, which is 12 hours ahead of GMT. The Russian Station Vostok was # 6 hours behind that (although only 2 miles away, i.e. 6 hours ahead # of GMT). This is a time zone I think two hours east of Moscow. The -# natural time zone is in between the two: 8 hours ahead of GMT.'' +# natural time zone is in between the two: 8 hours ahead of GMT." # # From Paul Eggert (2001-05-04): # This seems to be hopelessly confusing, so I asked Lee Hotz about it @@ -339,10 +339,7 @@ Zone Antarctica/Palmer 0 - zzz 1965 # # # McMurdo Station, Ross Island, since 1955-12 -# See Pacific/Auckland. -# # Amundsen-Scott South Pole Station, continuously occupied since 1956-11-20 -# See Pacific/Auckland. # # From Chris Carrier (1996-06-27): # Siple, the first commander of the South Pole station, @@ -363,3 +360,5 @@ Zone Antarctica/Palmer 0 - zzz 1965 # makes all of the clocks run fast. So every couple of days, # we have to go around and set them back 5 minutes or so. # Maybe if we let them run fast all of the time, we'd get to leave here sooner!! + +Link Pacific/Auckland Antarctica/McMurdo diff --git a/backward b/backward index 561e2ff..b8db6bb 100644 --- a/backward +++ b/backward @@ -18,19 +18,13 @@ Link America/Indiana/Indianapolis America/Fort_Wayne Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Indiana/Knox America/Knox_IN -Link America/Curacao America/Kralendijk Link America/Kentucky/Louisville America/Louisville -Link America/Curacao America/Lower_Princes -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 Link Pacific/Auckland Antarctica/South_Pole -Link Europe/Oslo Arctic/Longyearbyen Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta Link Asia/Chongqing Asia/Chungking @@ -74,20 +68,7 @@ Link America/Havana Cuba Link Africa/Cairo Egypt Link Europe/Dublin Eire Link Europe/London Europe/Belfast -Link Europe/Prague Europe/Bratislava -Link Europe/Zurich Europe/Busingen -Link Europe/London Europe/Guernsey -Link Europe/London Europe/Isle_of_Man -Link Europe/London Europe/Jersey -Link Europe/Belgrade Europe/Ljubljana -Link Europe/Helsinki Europe/Mariehamn -Link Europe/Belgrade Europe/Podgorica -Link Europe/Rome Europe/San_Marino -Link Europe/Belgrade Europe/Sarajevo -Link Europe/Belgrade Europe/Skopje Link Europe/Chisinau Europe/Tiraspol -Link Europe/Rome Europe/Vatican -Link Europe/Belgrade Europe/Zagreb Link Europe/London GB Link Europe/London GB-Eire Link Etc/GMT GMT+0 diff --git a/europe b/europe index 52f15e1..4f972a5 100644 --- a/europe +++ b/europe @@ -440,6 +440,9 @@ Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s 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 Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00 -0:25:21 1:00 IST 1916 Oct 1 2:00s @@ -1105,7 +1108,9 @@ Zone Europe/Helsinki 1:39:52 - LMT 1878 May 31 1:39:52 - HMT 1921 May # Helsinki Mean Time 2:00 Finland EE%sT 1983 2:00 EU EE%sT -# Use Europe/Helsinki for the Aaland Islands. + +# Aaland Is +Link Europe/Helsinki Europe/Mariehamn # France @@ -1255,7 +1260,10 @@ Zone Europe/Berlin 0:53:28 - LMT 1893 Apr # Source for the time in Busingen 1980: # http://www.srf.ch/player/video?id=c012c029-03b7-4c2b-9164-aa5902cd58d3 -# Use Europe/Zurich for Busingen. +# From Arthur David Olson (2012-03-03): +# Busingen and Zurich have shared clocks since 1970. + +Link Europe/Zurich Europe/Busingen # Georgia # Please see the "asia" file for Asia/Tbilisi. @@ -1474,7 +1482,9 @@ Zone Europe/Rome 0:49:56 - LMT 1866 Sep 22 1:00 C-Eur CE%sT 1944 Jul 1:00 Italy CE%sT 1980 1:00 EU CE%sT -# Use Europe/Rome also for San Marino and Vatican City. + +Link Europe/Rome Europe/Vatican +Link Europe/Rome Europe/San_Marino # Latvia @@ -1853,7 +1863,7 @@ Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 # before 1895, and therefore probably changed the local time somewhere # between 1895 and 1925 (inclusive). -# From Paul Eggert (2013-08-09): +# From Paul Eggert (2013-09-02): # # Actually, Jan Mayen was never occupied by Germany during World War II, # so it must have diverged from Oslo time during the war, as Oslo was @@ -1879,6 +1889,7 @@ Zone Europe/Oslo 0:43:00 - LMT 1895 Jan 1 # # All these events predate our cutoff date of 1970, so use Europe/Oslo # for these regions. +Link Europe/Oslo Arctic/Longyearbyen # Poland # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -2449,11 +2460,14 @@ Zone Europe/Belgrade 1:22:00 - LMT 1884 # Shanks & Pottenger don't give as much detail, so go with Kozelj. 1:00 - CET 1982 Nov 27 1:00 EU CE%sT -# Use Europe/Belgrade also for Bosnia and Herzegovina, Croatia, Macedonia, -# Montenegro, and Slovenia. +Link Europe/Belgrade Europe/Ljubljana # Slovenia +Link Europe/Belgrade Europe/Podgorica # Montenegro +Link Europe/Belgrade Europe/Sarajevo # Bosnia and Herzegovina +Link Europe/Belgrade Europe/Skopje # Macedonia +Link Europe/Belgrade Europe/Zagreb # Croatia # Slovakia -# See Europe/Prague. +Link Europe/Prague Europe/Bratislava # Slovenia # See Europe/Belgrade. diff --git a/northamerica b/northamerica index 418261f..d3b124e 100644 --- a/northamerica +++ b/northamerica @@ -20,7 +20,7 @@ # Howse writes (pp 121-125) that time zones were invented by # Professor Charles Ferdinand Dowd (1825-1904), # Principal of Temple Grove Ladies' Seminary (Saratoga Springs, NY). -# His pamphlet ``A System of National Time for Railroads'' (1870) +# His pamphlet "A System of National Time for Railroads" (1870) # was the result of his proposals at the Convention of Railroad Trunk Lines # in New York City (1869-10). His 1870 proposal was based on Washington, DC, # but in 1872-05 he moved the proposed origin to Greenwich. @@ -40,8 +40,8 @@ # From Paul Eggert (2001-03-06): # Daylight Saving Time was first suggested as a joke by Benjamin Franklin -# in his whimsical essay ``An Economical Project for Diminishing the Cost -# of Light'' published in the Journal de Paris (1784-04-26). +# in his whimsical essay "An Economical Project for Diminishing the Cost +# of Light" published in the Journal de Paris (1784-04-26). # Not everyone is happy with the results: # # I don't really care how time is reckoned so long as there is some @@ -167,8 +167,8 @@ Zone PST8PDT -8:00 US P%sT # of the Aleutian islands. No DST. # From Paul Eggert (1995-12-19): -# The tables below use `NST', not `NT', for Nome Standard Time. -# I invented `CAWT' for Central Alaska War Time. +# The tables below use 'NST', not 'NT', for Nome Standard Time. +# I invented 'CAWT' for Central Alaska War Time. # From U. S. Naval Observatory (1989-01-19): # USA EASTERN 5 H BEHIND UTC NEW YORK, WASHINGTON @@ -237,9 +237,9 @@ Zone PST8PDT -8:00 US P%sT # H.R. 6, Energy Policy Act of 2005, SEC. 110. DAYLIGHT SAVINGS. # (a) Amendment- Section 3(a) of the Uniform Time Act of 1966 (15 # U.S.C. 260a(a)) is amended-- -# (1) by striking `first Sunday of April' and inserting `second +# (1) by striking 'first Sunday of April' and inserting 'second # Sunday of March'; and -# (2) by striking `last Sunday of October' and inserting `first +# (2) by striking 'last Sunday of October' and inserting 'first # Sunday of November'. # (b) Effective Date- Subsection (a) shall take effect 1 year after the # date of enactment of this Act or March 1, 2007, whichever is later. @@ -678,13 +678,13 @@ Zone America/Boise -7:44:49 - LMT 1883 Nov 18 12:15:11 # and Switzerland counties have their own time zone histories as noted below. # # Shanks partitioned Indiana into 345 regions, each with its own time history, -# and wrote ``Even newspaper reports present contradictory information.'' +# and wrote "Even newspaper reports present contradictory information." # Those Hoosiers! Such a flighty and changeable people! # Fortunately, most of the complexity occurred before our cutoff date of 1970. # # Other than Indianapolis, the Indiana place names are so nondescript -# that they would be ambiguous if we left them at the `America' level. -# So we reluctantly put them all in a subdirectory `America/Indiana'. +# that they would be ambiguous if we left them at the 'America' level. +# So we reluctantly put them all in a subdirectory 'America/Indiana'. # From Paul Eggert (2005-08-16): # http://www.mccsc.edu/time.html says that Indiana will use DST starting 2006. @@ -948,8 +948,8 @@ Zone America/Kentucky/Monticello -5:39:24 - LMT 1883 Nov 18 12:20:36 # This story is too entertaining to be false, so go with Howse over Shanks. # # From Paul Eggert (2001-03-06): -# Garland (1927) writes ``Cleveland and Detroit advanced their clocks -# one hour in 1914.'' This change is not in Shanks. We have no more +# Garland (1927) writes "Cleveland and Detroit advanced their clocks +# one hour in 1914." This change is not in Shanks. We have no more # info, so omit this for now. # # Most of Michigan observed DST from 1973 on, but was a bit late in 1975. @@ -989,7 +989,7 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00 # occupied 1857/1900 by the Navassa Phosphate Co # US lighthouse 1917/1996-09 # currently uninhabited -# see Mark Fineman, ``An Isle Rich in Guano and Discord'', +# see Mark Fineman, "An Isle Rich in Guano and Discord", # _Los Angeles Times_ (1998-11-10), A1, A10; it cites # Jimmy Skaggs, _The Great Guano Rush_ (1994). @@ -1023,7 +1023,7 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00 # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94 # <http://www.jstor.org/stable/1774359>. # -# See the `europe' file for Greenland. +# See the 'europe' file for Greenland. # Canada @@ -1224,7 +1224,7 @@ Zone America/St_Johns -3:30:52 - LMT 1884 # most of east Labrador -# The name `Happy Valley-Goose Bay' is too long; use `Goose Bay'. +# The name 'Happy Valley-Goose Bay' is too long; use 'Goose Bay'. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Goose_Bay -4:01:40 - LMT 1884 # Happy Valley-Goose Bay -3:30:52 - NST 1918 @@ -1405,7 +1405,6 @@ Zone America/Montreal -4:54:16 - LMT 1884 -5:00 Mont E%sT 1974 -5:00 Canada E%sT - # Ontario # From Paul Eggert (2006-07-09): @@ -2211,7 +2210,7 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # From Paul Eggert (1996-06-12): # For an English translation of the decree, see # <a href="http://mexico-travel.com/extra/timezone_eng.html"> -# ``Diario Oficial: Time Zone Changeover'' (1996-01-04). +# "Diario Oficial: Time Zone Changeover" (1996-01-04). # </a> # From Rives McDow (1998-10-08): @@ -2640,7 +2639,7 @@ Rule CR 1991 1992 - Jan Sat>=15 0:00 1:00 D # go with Shanks & Pottenger. Rule CR 1991 only - Jul 1 0:00 0 S Rule CR 1992 only - Mar 15 0:00 0 S -# There are too many San Joses elsewhere, so we'll use `Costa Rica'. +# There are too many San Joses elsewhere, so we'll use 'Costa Rica'. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Costa_Rica -5:36:13 - LMT 1890 # San Jose -5:36:13 - SJMT 1921 Jan 15 # San Jose Mean Time @@ -2931,7 +2930,10 @@ Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe a Pitre -4:00 - AST -# Use America/Guadeloupe also for St Barthelemy and for St Martin (French part). +# St Barthelemy +Link America/Guadeloupe America/St_Barthelemy +# St Martin (French part) +Link America/Guadeloupe America/Marigot # Guatemala # @@ -3177,7 +3179,7 @@ Zone America/Panama -5:18:08 - LMT 1890 -5:00 - EST # Puerto Rico -# There are too many San Juans elsewhere, so we'll use `Puerto_Rico'. +# There are too many San Juans elsewhere, so we'll use 'Puerto_Rico'. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan -4:00 - AST 1942 May 3 @@ -3196,7 +3198,7 @@ Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries -4:00 - AST # St Pierre and Miquelon -# There are too many St Pierres elsewhere, so we'll use `Miquelon'. +# There are too many St Pierres elsewhere, so we'll use 'Miquelon'. # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -4:00 - AST 1980 May diff --git a/southamerica b/southamerica index ff47cef..ea264a1 100644 --- a/southamerica +++ b/southamerica @@ -1349,9 +1349,13 @@ Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad -4:30 - ANT 1965 # Netherlands Antilles Time -4:00 - AST -# Sint Maarten -# Caribbean Netherlands -# Use America/Curacao. +# From Arthur David Olson (2011-06-15): +# use links for places with new iso3166 codes. +# The name "Lower Prince's Quarter" is both longer than fourteen charaters +# and contains an apostrophe; use "Lower_Princes" below. + +Link America/Curacao America/Lower_Princes # Sint Maarten +Link America/Curacao America/Kralendijk # Caribbean Netherlands # Ecuador # @@ -1646,7 +1650,7 @@ Rule Uruguay 1937 1941 - Mar lastSun 0:00 0 - # Whitman gives 1937 Oct 3; go with Shanks & Pottenger. Rule Uruguay 1937 1940 - Oct lastSun 0:00 0:30 HS # Whitman gives 1941 Oct 24 - 1942 Mar 27, 1942 Dec 14 - 1943 Apr 13, -# and 1943 Apr 13 ``to present time''; go with Shanks & Pottenger. +# and 1943 Apr 13 "to present time"; go with Shanks & Pottenger. Rule Uruguay 1941 only - Aug 1 0:00 0:30 HS Rule Uruguay 1942 only - Jan 1 0:00 0 - Rule Uruguay 1942 only - Dec 14 0:00 1:00 S -- 1.8.1.2

13 70

Re: [tz] Pulling the data apart ...
by Lester Caine Sept. 16, 2013

Sept. 16, 2013

Tobias Conradi wrote: > On Mon, Sep 16, 2013 at 4:31 PM, <random832(a)fastmail.us> wrote: >> On Sun, Sep 15, 2013, at 12:23, Michael Deckers wrote: >>> >>> On 2013-09-13 18:32, Alan Barrett wrote: >>> >>>> The input format is documented in the zic(8) man page. Here's the >>>> relevant part: >>>> Input lines are made up of fields. Fields are separated from >>>> one another by any number of white space characters. >>> >>> Actually, "one or more" seems to be meant rather than "any number" >>> (which would include zero). >> >> .... The fact that they're _separated_ implies there is at least one >> character, because if not then there is no separation. > It does not. There could also be separation by less than one white > space character. > > Only, one could not find it by looking for white space characters. There is no reason that a format could not be fixed length fields simply padded with spaces as required. If an entry uses all the space then no separation. Pulling in data originally formated on 80 column punched often did that simply to get the most data on the card. That is where my 'header code' comes from, the first 2 characters identify the record type, and the next character is the first field of data so no white space :) -- 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

2 1

Re: [tz] Proposal to restrict field separator to tab
by Lester Caine Sept. 16, 2013

Sept. 16, 2013

Tobias Conradi wrote: > This is a proposal to restrict field separator to tab > > Current seems to be: > "any number of white space characters" > > Reason: > More than one person in 2013 alone reported problems parsing the data. > > http://mm.icann.org/pipermail/tz/2013-May/019160.html > http://mm.icann.org/pipermail/tz/2013-September/020189.html > > One person in 2013 assumes the current statement means something > different from its English language meaning > > / Actually, "one or more" seems to be meant rather than "any number" / > http://mm.icann.org/pipermail/tz/2013-May/019160.html As someone who would benefit from that change, I'm still a little look warm. Use of 'tab' in the ZONE line would make pulling apart easy, but then the follow on lines need different handling. It is nice that these documents 'reads' nicely looking down the page, but removing a tab from the follow on lines to keep the fields in order will then make things messy as a text document. That said, I am using the tab on these lines to indicate how that line is handled, so a space there would cause a problem anyway, and I drop the 'extra' field to line things up again ... -- 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

2 2

Pulling the data apart ...
by Lester Caine Sept. 16, 2013

Sept. 16, 2013

Paul ... I've started on phase two which is extracting the data, but I'm falling at the first hurdle. Should there be a tab character between 'Zone' and the name? I've found many entries in the africa file which don't and it is messing up my 'csv' splitter. Just need a special rule when 'Zone' is found, but looks a little inconsistent with respect to the following lines? -- 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

6 6

[PATCH 1/3] * tzfile.5 (SEE ALSO): Mention zdump(8), zic(8).
by Paul Eggert Sept. 15, 2013

Sept. 15, 2013

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index 4089910..69b9e8b 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -151,6 +151,6 @@ between daylight saving and standard time. .PP Future changes to the format may append more data. .SH SEE ALSO -newctime(3), newtzset(3) +newctime(3), newtzset(3), zdump(8), zic(8) .\" This file is in the public domain, so clarified as of .\" 1996-06-05 by Arthur David Olson. -- 1.8.3.1

1 2

Deputies of the Russian Duma introduced a bill to switch to "winter time" in Russia
by Alexander Krivenyshev Sept. 15, 2013

Sept. 15, 2013

Once again, Deputies of the Russian State Duma (Ivan Melnikov and Oleg Smolin) have attempted to introduce a bill concerning the switch to "winter time" in Russia. The bill proposes that Russia return to winter time on Oct. 27, 2013 and reinstate the original 11 time zones. original document (in Russian) (http://asozd2c.duma.gov.ru/addwork/scans.nsf/ID/53CA0EEFC86797C443257BDE004 C0BE9/$FILE/339386-6.PDF?OpenElement) http://www.worldtimezone.com/dst_news/dst_news_russia56.html Alexander Krivenyshev, http://www.WorldTimeZone.com

1 0

TAI as a time zone?
by DataPacRat Sept. 15, 2013

Sept. 15, 2013

Would it be feasible to include International Atomic Time (TAI) and/or GPS time (which differs from TAI by a fixed number of seconds) in the tz database as a time zone separate from UTC? I ask because I'm getting ready to submit at least one calendar to BCP 47 which is based on the leap-second-free TAI, and from the feedback I've gotten so far, it seems that the most widely-acceptable way to deal with the differences between TAI and UTC is to employ the tz database, if it's possible to do so. -- Thank you for your time, -- DataPacRat

4 7

Question about leap seconds
by random832＠fastmail.us Sept. 12, 2013

Sept. 12, 2013

Two things: Can a transition time ever reasonably fall _on_ a leap second, and can the zic input format represent this case? I am sketching out a design for a new time zone file format, and it occurs to me that it might be a good idea to specify transitions with POSIX timestamps so the data regarding one time zone is independent of whether leap seconds are enabled or not.

9 17

Re: [tz] Using MediaWiki / Wikidata
by Lester Caine Sept. 12, 2013

Sept. 12, 2013

Tobias Conradi wrote: > was: Re: [tz] [PATCH 3/3] * europe (Europe/Vaduz): Now a link to Europe/Zurich. > > On Tue, Sep 10, 2013 at 7:29 PM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: >> It may well make sense to organize what is currently tz commentary >> into something that is, well, a bit more organized. The format >> I'm most familiar with is MediaWiki, for what it's worth. > And here is some infrastructure using MediaWiki: > https://en.wikipedia.org/wiki/Category:Tz_database > > E.g. > https://en.wikipedia.org/wiki/Africa/Luanda > https://en.wikipedia.org/wiki/America/Indiana/Indianapolis > https://en.wikipedia.org/wiki/Asia/Novosibirsk > > But there are vandalizing admins around, e.g. Anthony Bradbury: > https://en.wikipedia.org/w/index.php?title=Special:Log&page=Time+in+Africa > > Another option could be to use wikidata, e.g. > Asia/Novosibirsk > https://www.wikidata.org/wiki/Q4806295 > and put evidences and for time offsets there. Personally I have no time for wikipedia since we had a lot of well written material removed in the past because some other editors decided they did not like it. So I have no confidence that any material posted would remain clean or even available. I think that a 'private' wiki is much more appropriate given that what we are going to archive is evidential material? With publicly accessible sandboxes for providing new material. Which is then managed based on it's suitability for inclusion? I could live with mediawiki format, but I much prefer clean html documents using ckeditor. And adding interactive packages is something I don't find particularly easy with those type of systems anyway. Is there somewhere appropriate to host a service Paul? I'm happy to run something on my servers, but I suspect the load may be quite high ;) -- 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

4 6

[PATCH 1/3] Fix off-by-one bug with Kingston Mean Time.
by Paul Eggert Sept. 12, 2013

Sept. 12, 2013

* northamerica (America/Cayman, America/Jamaica, America/Grand_Turk): Change KMT from -5:07:12 to -5:07:11 (should be -5:07:10.41). * zone.tab: Fine-tune geographical coordinates to match -5:07:10.41. I chose the latitude to match the General Post Office, Kingston, in the city center according to Google Maps. --- northamerica | 19 +++++++------------ zone.tab | 2 +- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/northamerica b/northamerica index 3a572ba..55755dd 100644 --- a/northamerica +++ b/northamerica @@ -2622,7 +2622,7 @@ Zone Atlantic/Bermuda -4:19:18 - LMT 1930 Jan 1 2:00 # Hamilton # Cayman Is # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown - -5:07:12 - KMT 1912 Feb # Kingston Mean Time + -5:07:11 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST # Costa Rica @@ -3067,17 +3067,12 @@ Zone America/Tegucigalpa -5:48:52 - LMT 1921 Apr # Great Swan I ceded by US to Honduras in 1972 # Jamaica - -# From Bob Devine (1988-01-28): -# Follows US rules. - -# From U. S. Naval Observatory (1989-01-19): -# JAMAICA 5 H BEHIND UTC - -# From Shanks & Pottenger: +# Shanks & Pottenger give -5:07:12, but Milne records -5:07:10.41 from an +# unspecified official document, and says "This time is used throughout the +# island". Go with Milne. Round to the nearest second as required by zic. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Jamaica -5:07:12 - LMT 1890 # Kingston - -5:07:12 - KMT 1912 Feb # Kingston Mean Time +Zone America/Jamaica -5:07:11 - LMT 1890 # Kingston + -5:07:11 - KMT 1912 Feb # Kingston Mean Time -5:00 - EST 1974 Apr 28 2:00 -5:00 US E%sT 1984 -5:00 - EST @@ -3217,7 +3212,7 @@ Rule TC 2007 max - Mar Sun>=8 2:00 1:00 D Rule TC 2007 max - Nov Sun>=1 2:00 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone America/Grand_Turk -4:44:32 - LMT 1890 - -5:07:12 - KMT 1912 Feb # Kingston Mean Time + -5:07:11 - KMT 1912 Feb # Kingston Mean Time -5:00 TC E%sT # British Virgin Is diff --git a/zone.tab b/zone.tab index 769432b..7d4c575 100644 --- a/zone.tab +++ b/zone.tab @@ -233,7 +233,7 @@ IR +3540+05126 Asia/Tehran IS +6409-02151 Atlantic/Reykjavik IT +4154+01229 Europe/Rome JE +4912-00207 Europe/Jersey -JM +1800-07648 America/Jamaica +JM +175805-0764736 America/Jamaica JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE -0117+03649 Africa/Nairobi -- 1.8.3.1

13 34

Re: [tz] uniform time in Switzerland in second half of 19th century
by Paul Eggert Sept. 11, 2013

Sept. 11, 2013

Pierre-Yves Berger found some documentary evidence of the 1894 transition in Switzerland, and I got my hands on a copy of Messerli's book, which gives more details about the circa-1855 transition. Here's a patch, which I'll push to the experimental repository. As far as data goes, this merely moves the 1855 transition to 1853-07-16. >From 9805c5c4a38750ff0c2345fdcc2a273357153259 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert(a)cs.ucla.edu> Date: Wed, 11 Sep 2013 18:28:36 -0700 Subject: [PATCH] * europe, zic.8 (Europe/Zurich): Change transition to 1853-07-16. Explain how I derived this guess from Messerli's book. Also, give better evidence about the 1894 transition, from Pierre-Yves Berger. --- europe | 39 ++++++++++++++++++++++++++++----------- zic.8 | 6 +++--- 2 files changed, 31 insertions(+), 14 deletions(-) diff --git a/europe b/europe index 8d26b4e..e70cfb4 100644 --- a/europe +++ b/europe @@ -2662,23 +2662,40 @@ Zone Europe/Stockholm 1:12:12 - LMT 1879 Jan 1 # ... the meridian for Bern mean time ... is 7 degrees 26'22.50". # Expressed in time, it is 0h29m45.5s. +# From Pierre-Yves Berger (2013-09-11): +# the "Circulaire du conseil federal" (December 11 1893) +# <http://www.amtsdruckschriften.bar.admin.ch/viewOrigDoc.do?id=10071353> ... +# clearly states that the [1894-06-01] change should be done at midnight +# but if no one is present after 11 at night, could be postponed until one +# hour before the beginning of service. + # From Paul Eggert (2013-09-11): -# Round to the nearest even second, 0:29:46. -# -# We can find no reliable source for Shanks's claim that all of Switzerland -# except Geneva switched to Bern Mean Time at 00:00 on 1848-09-12. On the -# contrary, a more-reliable source talks about "the gradual introduction of a -# national time (from the 1850s)" (Google translation) with a switch to CET in -# 1894; see Speich's review of Messerli's thesis, Traverse 1997/3, 131-3 -# <http://www.tg.ethz.ch/dokumente/pdf_files/rez_messerli.pdf>. For now, model -# this messy process as a transition in 1855. Shanks's 1894 transition is more -# plausible for Zurich but has not been checked. +# Round BMT to the nearest even second, 0:29:46. +# +# We can find no reliable source for Shanks's assertion that all of Switzerland +# except Geneva switched to Bern Mean Time at 00:00 on 1848-09-12. This book: +# +# Jakob Messerli. Gleichmassig, punktlich, schnell: Zeiteinteilung und +# Zeitgebrauch in der Schweiz im 19. Jahrhundert. Chronos, Zurich 1995, +# ISBN 3-905311-68-2, OCLC 717570797. +# +# suggests that the transition was more gradual, and that the Swiss did not +# agree about civil time during the transition. The timekeeping it gives the +# most detail for is postal and telegraph time: here, federal legislation (the +# "Bundesgesetz uber die Erstellung von elektrischen Telegraphen") passed on +# 1851-11-23, and an official implementation notice was published 1853-07-16 +# (Bundesblatt 1853, Bd. II, S. 859). On p 72 Messerli writes that in +# practice since July 1853 Bernese time was used in "all postal and telegraph +# offices in Switzerland from Geneva to St. Gallen and Basel to Chiasso" +# (Google translation). For now, model this transition as occuring on +# 1853-07-16, though it probably occurred at some other date in Zurich, and +# legal civil time probably changed at still some other transition date. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Zurich 0:34:08 - LMT 1855 # See above comment. +Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 # See above comment. 0:29:46 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT diff --git a/zic.8 b/zic.8 index a2374a1..7ea94c5 100644 --- a/zic.8 +++ b/zic.8 @@ -468,7 +468,7 @@ Rule EU 1996 max - Oct lastSun 1:00u 0 - .sp .ta \w'# Zone\0\0'u +\w'Europe/Zurich\0\0'u +\w'GMTOFF\0\0'u +\w'RULES/SAVE\0\0'u +\w'FORMAT\0\0'u # Zone NAME GMTOFF RULES/SAVE FORMAT UNTIL -Zone Europe/Zurich 0:34:08 - LMT 1855 +Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 0:29:46 - BMT 1894 Jun 1:00 Swiss CE%sT 1981 1:00 EU CE%sT @@ -480,9 +480,9 @@ Link Europe/Zurich Switzerland In this example, the zone is named Europe/Zurich but it has an alias as Switzerland. This example says that Zurich was 34 minutes and 8 -seconds west of UT until 1855-01-01 at 00:00, when the legal offset +seconds west of UT until 1853-07-16 at 00:00, when the legal offset was changed to 7\(de\|26\(fm\|22.50\(sd; although this works out to -0:29.45.50, the input format cannot represent fractional seconds so it +0:29:45.50, the input format cannot represent fractional seconds so it is rounded here. After 1894-06-01 at 00:00 Swiss daylight saving rules (defined with lines beginning with "Rule Swiss") apply, and the UT offset became one hour. From 1981 to the present, EU daylight saving rules have -- 1.8.1.2

1 0

Re: [tz] Getting close to new release: testing, testing, ... [SEC=UNOFFICIAL]
by Timothy Arceri Sept. 11, 2013

Sept. 11, 2013

Will you be including the updates to the Australian Daylight Saving's abbreviations in this release? http://mm.icann.org/pipermail/tz/2013-April/019099.html -----Original Message----- From: tz-bounces(a)iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Eggert Sent: Wednesday, 11 September 2013 7:55 PM To: Time zone mailing list Subject: [tz] Getting close to new release: testing, testing, ... We need to release a new version soon, because of Fiji. I did further testing and it appears that the recent changes to add meta-information to the zic output won't fly, because they're incompatible with the GNU C library on Ubuntu 12.04. So we need to rethink that feature. There's no rush to introduce it, so let's omit it from the next release. Also, the -t option recently added to tzselect seems like it will be superseded by the tzwinnow approach, whenever we get that working and stable, so for now I think I'd rather omit this. There are a few other problems found by "make public", mostly links that were in the wrong files. I'll post proposed changes soon. If other people could do some testing that'd be nice. You can run "make public". The output should contain the following diagnostics: warning: "antarctica", line 318: Antarctica/Palmer: pre-2013 clients may mishandle distant timestamps warning: "asia", line 1412: 24:00 not handled by pre-1998 versions of zic warning: "asia", line 2332: 24:00 not handled by pre-1998 versions of zic warning: "asia", line 1026: Asia/Jerusalem: pre-2013 clients may mishandle distant timestamps (rule from "asia", line 1021) warning: "asia", line 1315: Asia/Amman: pre-1994 clients may mishandle distant timestamps warning: "asia", line 2016: Asia/Gaza: pre-2013 clients may mishandle distant timestamps warning: "asia", line 2347: Asia/Hebron: pre-2013 clients may mishandle distant timestamps warning: "australasia", line 269: Pacific/Fiji: pre-2013 clients may mishandle distant timestamps warning: "europe", line 998: America/Godthab: pre-2013 clients may mishandle distant timestamps warning: "southamerica", line 1141: America/Santiago: pre-2013 clients may mishandle distant timestamps warning: "southamerica", line 1313: Pacific/Easter: pre-2013 clients may mishandle distant timestamps along with a very long section that starts as follows, which shows that the tz code is still broken on platforms with unsigned 32-bit time_t (this is a longstanding problem). checking uint32_t zones ... --- tzpublic/int64_t.out 2013-09-11 02:43:50.871343089 -0700 +++ tzpublic/uint32_t.out 2013-09-11 02:43:55.907343185 -0700 @@ -210,278 +210,6 @@ Europe/Andorra Sun Mar 29 01:00:00 2037 UT = Sun Mar 29 03:00:00 2037 CEST isdst=1 Europe/Andorra Sun Oct 25 00:59:59 2037 UT = Sun Oct 25 02:59:59 2037 CEST isdst=1 Europe/Andorra Sun Oct 25 01:00:00 2037 UT = Sun Oct 25 02:00:00 2037 CET isdst=0 -Europe/Andorra Sun Mar 28 00:59:59 2038 UT = Sun Mar 28 01:59:59 2038 CET isdst=0 -Europe/Andorra Sun Mar 28 01:00:00 2038 UT = Sun Mar 28 03:00:00 2038 CEST isdst=1 -Europe/Andorra Sun Oct 31 00:59:59 2038 UT = Sun Oct 31 02:59:59 2038 CEST isdst=1

3 3

POSIX extension check
by Arthur David Olson Sept. 10, 2013

Sept. 10, 2013

It's probably worthwhile to check whether extended POSIX in zic-produced binaries will cause grief when those binaries are used with old versions of localtime.c. If so, one or more of documentation, a zic warning, or a version number bump may be in order. --ado

8 19

a patch for zic.c to allow 'follow rules'
by Alois Treindl Sept. 10, 2013

Sept. 10, 2013

Dear Arthur, I have been preparing a small modification for zic.c which will allow it to understand a 'follow rule' in zone files, like this: # experimental table for Geneva, to test the 'follow' mechanism Zone Europe/Geneva 0:24:37 - LMT 1848 Sep 12 0:24:37 - GET 1894 Jun # Geneva MTime 0 follow Europe/Zurich For test purposes, one can simply insert this zone in the europe file. The feature is helpful in the extension of tzdata to cover complete timezone history. For this purpose, about 1000 additional zone files need to be written, and to be maintained. The process to do so has started in the astrological community, as it needs a complete pre-1970 timezone history. I will not bother you with details. I intend to help creating and maintaining a set of files like 'europe_hist', 'asia_hist' etc which contain the additional zones. The 'follow rule' will allow to keep these extra zone files very small, as usually the additional zones will all have a cross-over moment into a regular tzdata zone. I have for the moment called the modified zic source file zicx.c and prepared a patch file for zic.c to implement the 'follow rule' feature. I have tried to keep the modification very small. Please have a look at the patch, and check for the errors I have probably made. Description of the code: ------------------------ The follow rule must be the last line in a zone, and recursion is not allowed. It is parsed in inzsub() which reacts on GMTOFF = 0 and the word 'follow' in the RULE field. The zone line is stored in zones[] with a special value z_gmtoff = FOLLOW_MARK and the zone_name to follow in field z_rule (which is abused for this purpose). Before the call to outzone() the two sets of zone lines are patched together in a temporary array, so that outzone() and all functions deeper down() need not be modified. Patch ----- --- zic.c 2011-03-09 20:41:27.000000000 +0100 +++ zicx.c 2011-08-25 16:09:04.000000000 +0200 @@ -262,6 +262,17 @@ static int typecnt; #define YR_MAXIMUM 1 #define YR_ONLY 2 +/* +** follow rules, added by Alois Treindl August 2011 +** Zones may end with a line: 0 follow zone_name +** which the parser will represent with FOLLOW_MARK in z_gmtoff, +** and the zone name in z_rule. +** Before the call to outzone() the zone and its follow zone will be +** patched together, so that outzone() sees a regular zone array. +** To keep zone files readable, follow rules cannot be used recursively. +*/ +#define FOLLOW_MARK 999999 + static struct rule * rules; static int nrules; /* number of rules */ @@ -589,7 +600,48 @@ _("%s: More than one -L option specified */ for (j = i + 1; j < nzones && zones[j].z_name == NULL; ++j) continue; - outzone(&zones[i], j - i); + if (zones[j -1].z_gmtoff == FOLLOW_MARK) { + /* copy zone and follow zone into one new array */ + int k,n,m, nrows; + struct zone *xzones, *zp; + nrows = j - i - 1; + zp = &zones[j - 1]; /* line with the follow rule */ + xzones = (struct zone *) (void *) emalloc((int) (nrows * sizeof *xzones)); + for (k = 0; k < nrows; k++) + xzones[k] = zones[i + k]; + /* now find the follow zone in array zones[] */ + for (m = 0; m < nzones; m++) { + if (zones[m].z_name != NULL && strcmp(zp->z_rule, zones[m].z_name) == 0) break; + } + if (m == nzones) { /* error, follow zone not found */ + char *cp; + cp = emalloc(80 + strlen(zp->z_rule) + strlen(zones[i].z_name));; + sprintf(cp, "For zone %s follow zone %s not found, no zonefile created.", zones[i].z_name, zp->z_rule); + eat(zp->z_filename, zp->z_linenum); + error(cp); + ifree(cp); + ifree((void *)xzones); + } + /* now find the next date in the follow zone */ + for (n = m + 1; n < nzones; n++) { + if (zp->z_untiltime < zones[n].z_untiltime) break; + } + /* missing errorcode for case n == nzones, + * assume we are still in same follow zone. + * The follow zone part we need starts at zones[n]. + * Now find where follow zone ends, will be m. + */ + for (m = n; m < nzones && zones[m].z_name == NULL; ++m) + continue; + xzones = (struct zone *) (void *) erealloc((char *) xzones, (int) ((nrows + m - n) * sizeof *xzones)); + for (k = 0; k < m - n; k++) + xzones[nrows + k] = zones[n + k]; + nrows += m - n; + outzone(&xzones[0], nrows); + ifree((void *) xzones); + } else { + outzone(&zones[i], j - i); + } } /* ** Make links. @@ -784,7 +836,7 @@ associate(void) } for (i = 0; i < nzones; ++i) { zp = &zones[i]; - if (zp->z_nrules == 0) { + if (zp->z_nrules == 0 && zp->z_gmtoff != FOLLOW_MARK) { /* ** Maybe we have a local standard time offset. */ @@ -1079,11 +1131,23 @@ const int iscont; return FALSE; } } - z.z_rule = ecpyalloc(fields[i_rule]); - z.z_format = ecpyalloc(fields[i_format]); - if (max_format_len < strlen(z.z_format)) - max_format_len = strlen(z.z_format); - hasuntil = nfields > i_untilyear; + /* check for 0 follow zonename + ** zonename must contain at least one /, and follow must be + * 'follow' or an abbreviation thereof. + */ + if (z.z_gmtoff == 0 && strchr(fields[i_format], '/') != NULL + && itsabbr(fields[i_rule], "follow")) { + z.z_gmtoff = FOLLOW_MARK; + z.z_rule = ecpyalloc(fields[i_format]); + z.z_format = ""; + hasuntil = FALSE; /* no continue of zone now */ + } else { + z.z_rule = ecpyalloc(fields[i_rule]); + z.z_format = ecpyalloc(fields[i_format]); + if (max_format_len < strlen(z.z_format)) + max_format_len = strlen(z.z_format); + hasuntil = nfields > i_untilyear; + } if (hasuntil) { z.z_untilrule.r_filename = filename; z.z_untilrule.r_linenum = linenum;

1 1

DESTDIR patch
by Dr. Volker Zell Sept. 10, 2013

Sept. 10, 2013

Hi Attached a patch which adds DESTDIR support to the Makefile. Ciao Volker

2 1

Fiji daylight savings
by David Wheeler Sept. 9, 2013

Sept. 9, 2013

Hi all, we've just received notice that Fiji will start daylight savings shortly, but this doesn't seem to be represented in tzdata. See link below for details. http://www.fiji.gov.fj/Media-Center/Press-Releases/DAYLIGHT-SAVING-STARTS-O… Cheers, -- David _____________________________ David Wheeler - Lead Engineer david(a)inomial.com p +61 3 9663 3554 WINNER 2013 ACOMMS Awards for Services to Industry - Professional services Telecommunications and Utility Billing, Rating, Policy and Session Management

3 2

Rules for TZ+ database
by Lester Caine Sept. 9, 2013

Sept. 9, 2013

First I'd like to thank Kevin Lyda for taking the time to construct the original tz repository. It is a quite remarkable piece of work. I'm currently looking at a beautifully documented history of the Theory file from the moment Authur created it on 16/2/1987 ... 1987-02-16 in modern money ... The first rule is +* In SVR2, time display in a process is controlled by the environment + variable TZ, which "must be a three-letter time zone name, followed + by a munber representing the difference between local time and + Greenwich Mean Time in hours, followed by an optional three-letter + name for a daylight time zone;" when the optional daylight time zone is + present, "standard U.S.A. Daylight Savings Time conversion is applied." + This means that SVR2 can't deal with other (for example, Australian) + daylight savings time rules, or situations where more than two + time zone abbreviations are used in an area. So it was very much conceived as an 'American' system. Handling other daylight saving offsets or more complex rules was to difficult at that time so ignored. I'll fast forward over the changes which introduced long names to replace the three letter codes, and set up rules about size of population being used to select them. Politics is nothing new and the entire database is an archive of POLITICAL decisions. Until 2001 when a commit was added from a certain Paul Eggert ... +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. And the new rule of + * Uniquely identify every national region where clocks have all + agreed since 1970. This is essential for the intended use: static + clocks keeping local civil time. Does not SPECIFICALLY rule out the gathering of pre 1970 data? It just sets the ground rules for ONE view of the data to be limited. This is about making the data more accessible and was probably the wrong approach even back then. I'll skip the 'frivolity' of adding Mars time in 2004, but it does have relevance to the next step forward. All documented data is valid! http://lsces.org.uk/hg/tz/rev/8a52c38a5f56 is the change that pulls support for specifically 32 bit systems, that note had only JUST been added but is the first reference on scope that I've found? Then finally there is a formal definition of the SCOPE of the database in http://lsces.org.uk/hg/tz/rev/7c18a2e16943 so up until that time data HAS been gathered for the whole of time not just post 1970. I'm more than happy to accept this as the rules for 'TZ' but things have moved on considerably since 1987 and substantially more material is now available and easily accessed to provide insight into all of the documented changes to time standards. So if the 'TZ' distribution is going to ignore that material then we need to set up a 'TZ+' distribution that actively includes all available material. It's not a question it's a statement. Reviewing the Theory file of cause we fall at the first hurdle since the POSIX time format has difficulty coping with some of the intricacies of time management. While encoding a daylight saving change in the time is to be commended, it is only right for a specific period of time. The more accurate approach is purely to identify a 'set of rules' that can be used. This also then automatically covers the provision of leap seconds. What I am saying here is that POSIX is just an implementation detail and while mapping the data to it does require defining, it's not fundamental to the real data. So lets use a standard that is better at handling the modern systems. Obviously I fundamentally disagree with the current scope and that should probably have been disputed in 2011. If one accepts that POSIX is incapable of handling the material, then applying one of it's limitations is also wrong? Since the Calendrical issues section already includes the whole of history, we do have a good base to build on, and are already discussing what 'Universal Time' was prior to 1970. If we can agree that while the validity of some legacy data may be questionably, it is a fact of life that many of these events happened, me just have some uncertainty as to when they happened? I think we can also agree that there is substantial new material which is currently only recorded in notes and which can only enhance the historic record? I'm under no illusion that the problems of manipulating this data into a more usable format is substantial, but it is not impossible. NAMING 'timezones' is the fundamental problem here, and the "This naming convention is not intended for use by inexperienced users" is of fundamental importance here. Mapping rules to usable names is all that is required, so internally in the data we have something suitable for managing the complexity of the problem, while outside a naive user punches in an ISO3166 and gets a timezone suitable for the time frame he is working in. There is a substantial amount of additional history here that could potentially be exposed, such as, for example, ISO3166 codes which have been superseded, or even 'old' TZ names which are now recorded for posterity in archives! The 'backward' file is missing key information on when a particular 'match' was changed, and while dates are not particularly critical, there may be fundamental data provided if one of the legacy names is being reviewed and the CURRENT rule set no longer matches what was being supplied at that time. With hg (or git) I can call up an historic view of backward, and then select a view of the data at that time. Something that one time would have been a substantial amount of work happens in the click of a mouse. DVCS provides a view of the information in a format that relates to how it was entered. That data can be viewed in many other ways if we provide the right tools, that is the key here. 'winnowing' is just one way of manipulating the data, and another would be 'time slicing', providing a snapshot of all the rules active at a particular date. Currently there are a much smaller number of rules active than there were pre-1970, and pre standard time there were an infinite number due to all the different methods of tracking time. During the transition from then until now we have some complex information to map, such as French stations being 5 minutes drift, and UK trains using a different time to the legal system. But if we are looking at times when those rules apply then we need to know that there were differences. There was recorded desention to many summertime changes and this happened in a time where those facts were recorded so that material needs to be made available once it is established. This cuases no end of problems in identifying each area affected, but that's why I brought up the OHM historic mapping. Linking up with that, simple things like historic changes of country names can link us to the appropriate data. This may well require the provision of more than one rule, so that is something that needs handling - with notes if necessary. I've not got as far as I would like and I need to get on, but there is more than enough here already. OK 'TZ' only provides data from 1970 but 'TZ+' would provide all the historic data including the 'TZ' filtered set and additional data within the TZ timeframe. -- 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

13 56

US osm timezone
by Lester Caine Sept. 9, 2013

Sept. 9, 2013

http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set. OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves. -- 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

3 5

tz dependency lat & lng
by kokosani kokosani Sept. 8, 2013

Sept. 8, 2013

7 27

[PATCH] New file 'pre1970' for zones that differ only in pre-1970 time stamps.
by Paul Eggert Sept. 7, 2013

Sept. 7, 2013

This lets us preserve information about pre-1970 time stamps when we change a Zone to a Link to another zone whose time stamps agree after 1970. This should address concerns about some recent changes that removed this information. This implementation is a stripped-down version of a suggestion by Andrew Main (Zefram) in <http://mm.icann.org/pipermail/tz/2013-August/019615.html> and <http://mm.icann.org/pipermail/tz/2013-August/019639.html> to allow filtering tz data by date range. Unlike Zefram's suggestion, this implementation supports only two date ranges, namely 1970 on, using 'make BACKWARD=backward'; and all dates, using 'make BACKWARD="pre1970 back-pre1970"'. At some point I'd like to improve it to support arbitrary date ranges, but at least we've now restored the data whose loss was of some concern. * .gitignore: Add back-pre1970. * Makefile (BACKWARD): New macro. (YDATA): Use it instead of 'backward'. (AWK_SCRIPTS): New macro, with additional script back-pre1970.awk. (MISC): Use it. (back-pre1970): New rule. (clean_misc): Clean back-pre1970. Also clean time.tab, while we're at it. (check_public): Don't require pre1970 to stand alone. * pre1970, back-pre1970.awk: New files. --- .gitignore | 1 + Makefile | 32 +++++- back-pre1970.awk | 18 ++++ pre1970 | 291 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 337 insertions(+), 5 deletions(-) create mode 100644 back-pre1970.awk create mode 100644 pre1970 diff --git a/.gitignore b/.gitignore index 18dbbcc..28b1bc9 100644 --- a/.gitignore +++ b/.gitignore @@ -4,6 +4,7 @@ *.txt *~ ChangeLog +back-pre1970 date leapseconds time.tab diff --git a/Makefile b/Makefile index a74d1a7..ffddb08 100644 --- a/Makefile +++ b/Makefile @@ -49,6 +49,22 @@ POSIXRULES= America/New_York ZONETABTYPE= zone +# How to support obsolescent time zones in a backward-compatible way. +# This variable affects only pre-1970 time stamps, on hosts that support them. +# It has two possible values, 'backward' and 'pre1970 back-pre1970'. +# +# 'backward' is the traditional approach, and is simpler and more efficient; +# it is designed to generate one zone for each region where clocks have agreed +# since 1970. +# +# 'pre1970 back-pre1970' can generate more than one zone in that situation, +# which means it can preserve a bit of pre-1970 data that 'backward' does not; +# almost all pre-1970 data is missing, though, so don't get your hopes up. +# +# Sometimes 'backward' is more-compatible with earlier versions of this database, +# and sometimes 'pre1970 back-pre1970' is; it depends on the situation. +BACKWARD= backward + # Also see TZDEFRULESTRING below, which takes effect only # if the time zone files cannot be accessed. @@ -322,7 +338,7 @@ COMMON= Makefile DOCS= README Theory $(MANS) date.1 PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica -YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward +YDATA= $(PRIMARY_YDATA) pacificnew etcetera $(BACKWARD) NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) @@ -330,9 +346,10 @@ TABDATA= iso3166.tab time.tab zone.tab DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) \ leap-seconds.list yearistype.sh WEB_PAGES= tz-art.htm tz-link.htm +AWK_SCRIPTS= back-pre1970.awk checktab.awk leapseconds.awk zone-time.awk MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ - $(WEB_PAGES) checktab.awk leapseconds.awk workman.sh \ - zoneinfo2tdf.pl + $(WEB_PAGES) $(AWK_SCRIPTS) \ + workman.sh zoneinfo2tdf.pl ENCHILADA= $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) # And for the benefit of csh users on systems that assume the user @@ -423,6 +440,9 @@ zones: $(REDO) time.tab: $(YDATA) zone.tab zone-time.awk $(AWK) -f zone-time.awk $(YDATA) >$@ +back-pre1970: pre1970 backward + $(AWK) -v pre1970=pre1970 -f $@.awk backward >$@ + $(TZLIB): $(LIBOBJS) -mkdir $(TOPDIR) $(LIBDIR) ar ru $@ $(LIBOBJS) @@ -457,6 +477,7 @@ check_web: $(WEB_PAGES) clean_misc: rm -f core *.o *.out \ + back-pre1970 time.tab \ date leapseconds tzselect version.h zdump zic yearistype clean: clean_misc rm -f -r tzpublic @@ -488,7 +509,7 @@ set-timestamps: $$cmd || exit; \ done -# The zics below ensure that each data file can stand on its own. +# The zics below ensure that each non-pre1970 data file can stand on its own. # We also do an all-files run to catch links to links. check_public: $(ENCHILADA) @@ -496,7 +517,8 @@ check_public: $(ENCHILADA) make "CFLAGS=$(GCC_DEBUG_FLAGS)" mkdir tzpublic for i in $(TDATA) ; do \ - $(zic) -v -d tzpublic $$i 2>&1 || exit; \ + test $$i = pre1970 || $(zic) -v -d tzpublic $$i 2>&1 \ + || exit; \ done $(zic) -v -d tzpublic $(TDATA) rm -f -r tzpublic diff --git a/back-pre1970.awk b/back-pre1970.awk new file mode 100644 index 0000000..f7c54fc --- /dev/null +++ b/back-pre1970.awk @@ -0,0 +1,18 @@ +# Generate 'back-pre1970' from the two input files 'pre1970' and 'backward'. +# The output consists of all lines in 'backward' that are not links to +# files mentioned in 'pre1970'. Think of it as 'backward' minus 'pre1970'. + +# The 'backward' file is the input. +# The awk variable 'pre1970' contains the name of the pre1970 file. + +# This file is in the public domain. + +# Contributed by Paul Eggert. + +BEGIN { + while ((getline <pre1970) == 1) + if ($1 == "Zone") + pre1970_zone[$2] = 1 +} + +! (/^Link/ && pre1970_zone[$3]) { print } diff --git a/pre1970 b/pre1970 new file mode 100644 index 0000000..d8b8f34 --- /dev/null +++ b/pre1970 @@ -0,0 +1,291 @@ +# Pre-1970 data + +# This file is in the public domain. + +# This file contains zones that were formerly in other source files, +# but were later removed or replaced by backward-compatibility links +# as they differ from other zones only in pre-1970 time stamps. + +# Although the tz database focuses on post-1970 time stamps, these +# entries are retained here as they may be of some use to people +# interested in pre-1970 time stamps, even though they cover only a +# tiny sliver of pre-1970 data and are unreliable for that data. +# Also, these entries can help with backward compatibility with some +# old versions of the tz database. They are incompatible with other +# old versions of the database, though; it depends on which old +# version you're interested in. + +# Entries are sorted by Zone name. Each entry is preceded by the name +# of the country that the entry is in, along with any other commentary +# and rules associated with the entry. Some rules, e.g., 'Canada', +# are defined by other source files; this file is not intended to be +# used without those other files. + +# Zone NAME GMTOFF RULES FORMAT [UNTIL] + +# Mali +# no longer different from Bamako, but too famous to omit +Zone Africa/Timbuktu -0:12:04 - LMT 1912 + 0:00 - GMT + +# Anguilla +Zone America/Anguilla -4:12:16 - LMT 1912 Mar 2 + -4:00 - AST + +# Antigua and Barbuda +Zone America/Antigua -4:07:12 - LMT 1912 Mar 2 + -5:00 - EST 1951 + -4:00 - AST + +# Argentina +# Chubut (CH) +# The name "Comodoro Rivadavia" exceeds the 14-byte POSIX limit. +Zone America/Argentina/ComodRivadavia -4:30:00 - LMT 1894 Oct 31 + -4:16:48 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Mar 3 + -4:00 - WART 1991 Oct 20 + -3:00 Arg AR%sT 1999 Oct 3 + -4:00 Arg AR%sT 2000 Mar 3 + -3:00 - ART 2004 Jun 1 + -4:00 - WART 2004 Jun 20 + -3:00 - ART + +# Aruba +Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad + -4:30 - ANT 1965 # Netherlands Antilles Time + -4:00 - AST + +# Canada + +Zone America/Atikokan -6:06:28 - LMT 1895 + -6:00 Canada C%sT 1940 Sep 29 + -6:00 1:00 CDT 1942 Feb 9 2:00s + -6:00 Canada C%sT 1945 Sep 30 2:00 + -5:00 - EST + +Zone America/Blanc-Sablon -3:48:28 - LMT 1884 + -4:00 Canada A%sT 1970 + -4:00 - AST + +# Cayman Is +Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown + -5:07:12 - 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 + -5:00 - EST + +# Curacao +Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad + -4:30 - ANT 1965 # Netherlands Antilles Time + -4:00 - AST + +# Dominica +Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau + -4:00 - AST + +# Mexico +Zone America/Ensenada -7:46:28 - LMT 1922 Jan 1 0:13:32 + -8:00 - PST 1927 Jun 10 23:00 + -7:00 - MST 1930 Nov 16 + -8:00 - PST 1942 Apr + -7:00 - MST 1949 Jan 14 + -8:00 - PST 1996 + -8:00 Mexico P%sT + +# US +Zone America/Fort_Wayne -5:00 US E%sT 1946 + -5:00 - EST # Always EST as of 1986 + +# Grenada +Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's + -4:00 - AST + +# Guadeloupe +Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe a Pitre + -4:00 - AST + +# Canada +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Mont 1917 only - Mar 25 2:00 1:00 D +Rule Mont 1917 only - Apr 24 0:00 0 S +Rule Mont 1919 only - Mar 31 2:30 1:00 D +Rule Mont 1919 only - Oct 25 2:30 0 S +Rule Mont 1920 only - May 2 2:30 1:00 D +Rule Mont 1920 1922 - Oct Sun>=1 2:30 0 S +Rule Mont 1921 only - May 1 2:00 1:00 D +Rule Mont 1922 only - Apr 30 2:00 1:00 D +Rule Mont 1924 only - May 17 2:00 1:00 D +Rule Mont 1924 1926 - Sep lastSun 2:30 0 S +Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D +# The 1927-to-1937 rules can be expressed more simply as +# Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D +# Rule Mont 1927 1937 - Sep lastSat 24:00 0 S +# The rules below avoid use of 24:00 +# (which pre-1998 versions of zic cannot handle). +Rule Mont 1927 only - May 1 0:00 1:00 D +Rule Mont 1927 1932 - Sep lastSun 0:00 0 S +Rule Mont 1928 1931 - Apr lastSun 0:00 1:00 D +Rule Mont 1932 only - May 1 0:00 1:00 D +Rule Mont 1933 1940 - Apr lastSun 0:00 1:00 D +Rule Mont 1933 only - Oct 1 0:00 0 S +Rule Mont 1934 1939 - Sep lastSun 0:00 0 S +Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D +Rule Mont 1945 1948 - Sep lastSun 2:00 0 S +Rule Mont 1949 1950 - Oct lastSun 2:00 0 S +Rule Mont 1951 1956 - Sep lastSun 2:00 0 S +Rule Mont 1957 1973 - Oct lastSun 2:00 0 S +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Montreal -4:54:16 - LMT 1884 + -5:00 Mont E%sT 1918 + -5:00 Canada E%sT 1919 + -5:00 Mont E%sT 1942 Feb 9 2:00s + -5:00 Canada E%sT 1946 + -5:00 Mont E%sT 1974 + -5:00 Canada E%sT + +# Montserrat +Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill + -4:00 - AST + +# Bahamas +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S +Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 + -5:00 Bahamas E%sT 1976 + -5:00 US E%sT + +# Trinidad and Tobago +Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 + -4:00 - AST + +# Brazil +# Rio_Branco is too ambiguous, since there's a Rio Branco in Uruguay too. +Zone America/Porto_Acre -4:31:12 - LMT 1914 + -5:00 Brazil AC%sT 1988 Sep 12 + -5:00 - ACT + +# Argentina +# Santa Fe (SF), Entre Rios (ER), Corrientes (CN), Misiones (MN), Chaco (CC), +# Formosa (FM), La Pampa (LP), Chubut (CH) +Zone America/Rosario -4:02:40 - LMT 1894 Nov + -4:16:44 - CMT 1920 May + -4:00 - ART 1930 Dec + -4:00 Arg AR%sT 1969 Oct 5 + -3:00 Arg AR%sT 1991 Jul + -3:00 - ART 1999 Oct 3 0:00 + -4:00 Arg AR%sT 2000 Mar 3 0:00 + -3:00 - ART + +# St Kitts-Nevis +Zone America/St_Kitts -4:10:52 - LMT 1912 Mar 2 # Basseterre + -4:00 - AST + +# St Lucia +Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries + -4:04:00 - CMT 1912 # Castries Mean Time + -4:00 - AST + +# Virgin Is +Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie + -4:00 - AST + +# St Vincent and the Grenadines +Zone America/St_Vincent -4:04:56 - LMT 1890 # Kingstown + -4:04:56 - KMT 1912 # Kingstown Mean Time + -4:00 - AST + +# British Virgin Is +Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town + -4:00 - AST + +# McMurdo, Ross Island, since 1955-12 +Zone Antarctica/McMurdo 0 - zzz 1956 + 12:00 NZAQ NZ%sT + +# Japan +Zone Asia/Ishigaki 8:16:36 - LMT 1896 + 8:00 - CST + +# Israel +Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 + 2:21 - JMT 1918 + 2:00 Zion I%sT + +# Russia +Zone Asia/Tomsk 5:39:52 - LMT 1924 May 2 + 6:00 - TSK 1957 Mar + 7:00 Russia TS%s 1991 Mar 31 2:00s + 6:00 1:00 TSD 1991 Sep 29 2:00s + 6:00 - TSK 1992 Jan 19 2:00s + 7:00 Russia TS%s + +# Svalbard & Jan Mayen +Zone Atlantic/Jan_Mayen -1:00 - EGT + +# Australia +Zone Australia/Canberra 9:56:32 - LMT 1895 Feb + 10:00 - EST 1917 Jan 1 0:01 + 10:00 Aus EST 1971 Oct 31 2:00 + 10:00 AN EST 1981 Oct 25 2:00 + 10:00 1:00 EST 1982 Apr 4 3:00 + 10:00 AN EST + +# UK +Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 + -0:25:21 - DMT 1916 May 21 2:00 # Dublin/Dunsink MT + -0:25:21 1:00 IST 1916 Oct 1 2:00s # Irish Summer Time + 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 + +# Slovenia +Zone Europe/Ljubljana 0:58:04 - LMT 1884 + 1:00 - CET 1941 Apr 18 23:00 + 1:00 C-Eur CE%sT 1945 May 8 2:00s + 1:00 1:00 CEST 1945 Sep 16 2:00s + 1:00 - CET 1982 Nov 27 + 1:00 EU CE%sT + +# Bosnia and Herzegovina +Zone Europe/Sarajevo 1:13:40 - LMT 1884 + 1:00 - CET 1941 Apr 18 23:00 + 1:00 C-Eur CE%sT 1945 May 8 2:00s + 1:00 1:00 CEST 1945 Sep 16 2:00s + 1:00 - CET 1982 Nov 27 + 1:00 EU CE%sT + +# Macedonia +Zone Europe/Skopje 1:25:44 - LMT 1884 + 1:00 - CET 1941 Apr 18 23:00 + 1:00 C-Eur CE%sT 1945 May 8 2:00s + 1:00 1:00 CEST 1945 Sep 16 2:00s + 1:00 - CET 1982 Nov 27 + 1:00 EU CE%sT + +# Moldova +Zone Europe/Tiraspol 1:58:32 - LMT 1880 + 1:55 - CMT 1918 Feb 15 # Chisinau MT + 1:44:24 - BMT 1931 Jul 24 # Bucharest MT + 2:00 Romania EE%sT 1940 Aug 15 + 2:00 1:00 EEST 1941 Jul 17 + 1:00 C-Eur CE%sT 1944 Aug 24 + 3:00 Russia MSK/MSD 1991 Mar 31 2:00 + 2:00 Russia EE%sT 1992 Jan 19 2:00 + 3:00 Russia MSK/MSD + +# Croatia +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone Europe/Zagreb 1:03:52 - LMT 1884 + 1:00 - CET 1941 Apr 18 23:00 + 1:00 C-Eur CE%sT 1945 May 8 2:00s + 1:00 1:00 CEST 1945 Sep 16 2:00s + 1:00 - CET 1982 Nov 27 + 1:00 EU CE%sT -- 1.8.1.2

13 23

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 7:26, Tobias Conradi wrote: > > They are three _versions of_ one > > standard > Now we have > 1) edition (Wikipedia) > 2) revision (Clive) > 3) version (random832) http://dictionary.reference.com/browse/synonym If you are honestly claiming your grasp of the English language is really so weak as to fail to understand that these mean the same thing, then I'm sorry for calling you pedantic. > > - the later version supersedes the earlier ones. > The ISO website uses the verb "revise". See above. > I vote for disallowing such comments on the tz mailing list. This is not a democracy. You're free to ignore me. Or even remove me from your "tzdb(a)yahoogroups.com" list, though that will mainly have the effect of preventing _me_ from seeing _your_ emails if you find yourself banned from the tz list again. (For the record, I did not agree with your being banned, but it does say something about the relative thickness of the ice we are each standing on)

2 1

Re: [tz] [tzdb] Re: Proposed patch - Theory change to reinstate reference to ISO-3166
by Clive D.W. Feather Sept. 6, 2013

Sept. 6, 2013

Tobias Conradi said: >> They are three _versions of_ one >> standard > Now we have > 1) edition (Wikipedia) > 2) revision (Clive) > 3) version (random832) > >> - the later version supersedes the earlier ones. > The ISO website uses the verb "revise". When you revise the document, you get a new version. If the revision is printed as a single impression, that is a new edition. See sections 9.5 to 9.9 of ISO/IEC Guide 2. >> This is >> entirely obvious from the names, and needs no further source. > I vote for disallowing such comments on the tz mailing list. I could vote for your comments to be disallowed. Thankfully this isn't subject to a vote. -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

1 0

Re: [tz] Proposed patch - Theory change to reinstate reference to ISO-3166
by Clive D.W. Feather Sept. 6, 2013

Sept. 6, 2013

Tobias Conradi said: > >> There are two standards containing the string ISO 3166-1, the one > >> published the latest is > >> ISO 3166-1:2006 > >> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe… > >> > >> The other is > >> ISO 3166-1:1997 > >> http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumbe… > >> > >> 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. (1) Those pages - the latter says "revised by". (2) The ISO Directives http://isotc.iso.org/livelink/livelink?func=ll&objId=4230452&objAction=brow… which make it clear that you can only use the same number for revisions which don't significantly alter the scope of the standard. (3) Too many years taking part in ISO/IEC/JTC1/SC22/WG14, including being the UK's official representative. There is one standard (3166) divided into three parts (-1 to -3) and revised and republished on various dates (:2006). >> The standards don't include a normative table of codes. > Your sources? That was an error on my part, I accept. >> That is, the tables >> in those standards are *snapshots*. > Even "snapshots" can be normative. True. >> The standard itself defines rules for maintaining the official list of >> codes, what the codes should look like, and so on. The official list, >> however, is maintained by the "maintenance agency" (who, IIRC, is DIN). >> They can update the list whenever they want. > Hopefully they stick to the published rules. But the rules don't say *when* they can change it. Actually, they say: "Changes to this part of ISO 3166 are decided by the ISO 3166/MA and become effective immediately. They are announced in ISO 3166 Newsletters and are authoritative amendments to Clauses 1 to 13 and the annexes of this part of ISO 3166." In other words, each time 3166/MA decides to add, remove, or change a code, ISO 3166 *is revised*. >> Thus, for example, the list was changed on: >> 1989-12-05 (removed BU, added MM) > Your source, so a reader could verify this and other claims? Well, I could be cheeky and point at: http://www.davros.org/misc/iso3166.html The changes tagged 'c' to 'thorn' inclusive were added to the file contemporaneously with the publication of the MS newsletters. I haven't kept copies of the newsletters, but they may be online somewhere. > E.g. >> 1992-08-28 (removed DD, changed DD from 280 to 276) > Is a false claim, assuming the rule followed is, that there is one > numeric code for each alpha-2 code at any point in time since the > first publication of numeric codes. Typo: that should be "changed DE". There is no such rule as the one you hypothesize. On the contrary, the number was changed to show that the geographic area covered by 276 was significantly different to that covered by 280, even though they have the same Alpha-2 code. Conversely, when HV changed to BF they covered the same geographic area and so both were/are 854. >>> There are at least two pairs, namely DD/DE and YD/YE where there is >>> not "at least one name per ISO-3166 code" but only one per pair. >> When DD and DE were both in the list, they had separate names. DD is no >> longer in the 3166-1 list, though it is in 3166-3 (removed codes). > That's of no relevance for my claim. Then I'm not clear what your claim is. >>> When looking at the locations or location names, it follows that >>> "There should typically be at least one name per ISO-3166 code." was >>> never applied. >> I don't believe you've demonstrated that. > It didn't claim I have demonstrated it. Then what does "it follows that" mean? > As of today, the page > http://www.iso.org/iso/country_codes/iso_3166_code_lists/country_names_and_… > marked "Last updated: 2013-02-06" provides 249 country names. Nitpick: country and territory codes. > That results in 249*3=747 codes for ISO 3166-1:2006. That is, ISO 3166-1:2006 as revised by ISO 3166/MA. But that's 249 code triplets. > 548<747+31. What's the significance of 747? That should read: 548 > 249+31 -- Clive D.W. Feather | If you lie to the compiler, Email: clive(a)davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

1 0

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

[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

Value of data ...
by Lester Caine Sept. 3, 2013

Sept. 3, 2013

Norbert supplied a link to a ecma document which makes interesting reading ... From the section on 'Time Zone Names' > All registered Zone and Link names are allowed. Implementations must recognize all such names, and use > best available current and historical information about their offsets from UTC and their daylight saving time > rules in calculations. Note the use of 'and historical information' here. One has to bare in mind the target data set when deciding what data is useful and what can be thrown away, and for much day to day work a TZ database that only provides future 'estimated' data is probably more than adequate. Banks may be able to get away with 'it's ten years old so we can throw it away' and take control of dormant funds, but for some of us the history is as important as the present day. In fifty years time a large proportion of the data we are creating today will still be available. I dug out material going back 200+ years last night which has now been scanned and archived ... material on 'time' in the Isle of Man for the record ... which helps to clarify calculations for UTC time offsets for material in the early 1900's, which if now stored as UTC normalised data need to be 'corrected' using an historic version of the TZ data. If someone tries to use that data with a 'winnowed' data set, then the wrong times will be returned? Who is to say what an end user is going to be doing with their machine? All right you can reduce 440 zones down to 300 or so, but all of the original 440 names still need to be available, and in these days does saving a few bytes really matter? 'Simplification' of access is more to do with showing the appropriate subset of options by the application and historical ones may actually be the correct answer. So the data should be as complete a record of the 'best available current and historical information' that we have! Providing a version of the data that will be WRONG for some users is not an option? -- 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

2 2

[PATCH] Revert recent pre-1970 changes.
by Paul Eggert Sept. 3, 2013

Sept. 3, 2013

Other tz file readers had problems with the new pre1970 file, so remove it and related changes. To recover the pre-1970 data, instead change pre-1970 Zone entries in other files back to what they were. Perhaps we'll try to find a better way someday. * .gitignore: Remove back-pre1970. * Makefile (BACKWARD): Remove. All uses changed back to 'backward'. (AWK_SCRIPTS): Remove back-pre1970.awk. (back-pre1970): Remove. (clean_misc): Don't rm back-pre1970. (check_public): Remove special case for pre1970. * back-pre1970.awk, pre1970: Remove. * backward (America/Anguilla, America/Antigua, America/Aruba) (America/Atikokan, America/Blanc-Sablon, America/Cayman) (America/Creston, America/Curacao, America/Dominica, America/Grenada) (America/Guadeloupe, America/Montreal, America/Montserrat) (America/Nassau, America/Port_of_Spain, America/St_Kitts) (America/St_Lucia, America/St_Thomas, America/St_Vincent) (America/Tortola): Remove, as these are zones again. (America/Coral_Harbour, America/Kralendijk, America/Lower_Princes) (America/Marigot, America/St_Barthelemy, America/Virgin): Revert to previous links. * northamerica (Mont, America/Blanc-Sablon, America/Montreal) (America/Atikokan, America/Creston, America/Anguilla, America/Antigua) (Bahamas, America/Nassau, America/Cayman, America/Dominica) (America/Grenada, America/Guadeloupe, America/Montserrat) (America/St_Kitts, America/St_Lucia, America/St_Vincent) (America/Tortola, America/St_Thomas): * southamerica (America/Aruba, America/Curacao, America/Port_of_Spain): Restore these rules and zones. * .gitignore: Add back-pre1970. --- .gitignore | 1 - Makefile | 34 ++----- back-pre1970.awk | 18 ---- backward | 32 ++---- northamerica | 140 ++++++++++++++++++++------ pre1970 | 291 ------------------------------------------------------- southamerica | 20 +++- 7 files changed, 140 insertions(+), 396 deletions(-) delete mode 100644 back-pre1970.awk delete mode 100644 pre1970 diff --git a/.gitignore b/.gitignore index 28b1bc9..18dbbcc 100644 --- a/.gitignore +++ b/.gitignore @@ -4,7 +4,6 @@ *.txt *~ ChangeLog -back-pre1970 date leapseconds time.tab diff --git a/Makefile b/Makefile index ffddb08..e439055 100644 --- a/Makefile +++ b/Makefile @@ -49,22 +49,6 @@ POSIXRULES= America/New_York ZONETABTYPE= zone -# How to support obsolescent time zones in a backward-compatible way. -# This variable affects only pre-1970 time stamps, on hosts that support them. -# It has two possible values, 'backward' and 'pre1970 back-pre1970'. -# -# 'backward' is the traditional approach, and is simpler and more efficient; -# it is designed to generate one zone for each region where clocks have agreed -# since 1970. -# -# 'pre1970 back-pre1970' can generate more than one zone in that situation, -# which means it can preserve a bit of pre-1970 data that 'backward' does not; -# almost all pre-1970 data is missing, though, so don't get your hopes up. -# -# Sometimes 'backward' is more-compatible with earlier versions of this database, -# and sometimes 'pre1970 back-pre1970' is; it depends on the situation. -BACKWARD= backward - # Also see TZDEFRULESTRING below, which takes effect only # if the time zone files cannot be accessed. @@ -338,7 +322,7 @@ COMMON= Makefile DOCS= README Theory $(MANS) date.1 PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica -YDATA= $(PRIMARY_YDATA) pacificnew etcetera $(BACKWARD) +YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) @@ -346,10 +330,10 @@ TABDATA= iso3166.tab time.tab zone.tab DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) \ leap-seconds.list yearistype.sh WEB_PAGES= tz-art.htm tz-link.htm -AWK_SCRIPTS= back-pre1970.awk checktab.awk leapseconds.awk zone-time.awk +AWK_SCRIPTS= checktab.awk leapseconds.awk zone-time.awk MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ - $(WEB_PAGES) $(AWK_SCRIPTS) \ - workman.sh zoneinfo2tdf.pl + $(WEB_PAGES) $(AWK_SCRIPTS) workman.sh \ + zoneinfo2tdf.pl ENCHILADA= $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) # And for the benefit of csh users on systems that assume the user @@ -440,9 +424,6 @@ zones: $(REDO) time.tab: $(YDATA) zone.tab zone-time.awk $(AWK) -f zone-time.awk $(YDATA) >$@ -back-pre1970: pre1970 backward - $(AWK) -v pre1970=pre1970 -f $@.awk backward >$@ - $(TZLIB): $(LIBOBJS) -mkdir $(TOPDIR) $(LIBDIR) ar ru $@ $(LIBOBJS) @@ -477,7 +458,7 @@ check_web: $(WEB_PAGES) clean_misc: rm -f core *.o *.out \ - back-pre1970 time.tab \ + time.tab \ date leapseconds tzselect version.h zdump zic yearistype clean: clean_misc rm -f -r tzpublic @@ -509,7 +490,7 @@ set-timestamps: $$cmd || exit; \ done -# The zics below ensure that each non-pre1970 data file can stand on its own. +# The zics below ensure that each data file can stand on its own. # We also do an all-files run to catch links to links. check_public: $(ENCHILADA) @@ -517,8 +498,7 @@ check_public: $(ENCHILADA) make "CFLAGS=$(GCC_DEBUG_FLAGS)" mkdir tzpublic for i in $(TDATA) ; do \ - test $$i = pre1970 || $(zic) -v -d tzpublic $$i 2>&1 \ - || exit; \ + $(zic) -v -d tzpublic $$i 2>&1 || exit; \ done $(zic) -v -d tzpublic $(TDATA) rm -f -r tzpublic diff --git a/back-pre1970.awk b/back-pre1970.awk deleted file mode 100644 index f7c54fc..0000000 --- a/back-pre1970.awk +++ /dev/null @@ -1,18 +0,0 @@ -# Generate 'back-pre1970' from the two input files 'pre1970' and 'backward'. -# The output consists of all lines in 'backward' that are not links to -# files mentioned in 'pre1970'. Think of it as 'backward' minus 'pre1970'. - -# The 'backward' file is the input. -# The awk variable 'pre1970' contains the name of the pre1970 file. - -# This file is in the public domain. - -# Contributed by Paul Eggert. - -BEGIN { - while ((getline <pre1970) == 1) - if ($1 == "Zone") - pre1970_zone[$2] = 1 -} - -! (/^Link/ && pre1970_zone[$3]) { print } diff --git a/backward b/backward index efb5353..561e2ff 100644 --- a/backward +++ b/backward @@ -7,47 +7,27 @@ Link Africa/Asmara Africa/Asmera Link Africa/Bamako Africa/Timbuktu -Link America/Puerto_Rico America/Anguilla -Link America/Puerto_Rico America/Antigua Link America/Argentina/Catamarca America/Argentina/ComodRivadavia -Link America/Puerto_Rico America/Aruba -Link America/Panama America/Atikokan Link America/Adak America/Atka -Link America/Puerto_Rico America/Blanc-Sablon Link America/Argentina/Buenos_Aires America/Buenos_Aires Link America/Argentina/Catamarca America/Catamarca -Link America/Panama America/Cayman -Link America/Panama America/Coral_Harbour +Link America/Atikokan America/Coral_Harbour Link America/Argentina/Cordoba America/Cordoba -Link America/Phoenix America/Creston -Link America/Puerto_Rico America/Curacao -Link America/Puerto_Rico America/Dominica Link America/Tijuana America/Ensenada Link America/Indiana/Indianapolis America/Fort_Wayne -Link America/Puerto_Rico America/Grenada -Link America/Puerto_Rico America/Guadeloupe Link America/Indiana/Indianapolis America/Indianapolis Link America/Argentina/Jujuy America/Jujuy Link America/Indiana/Knox America/Knox_IN -Link America/Puerto_Rico America/Kralendijk +Link America/Curacao America/Kralendijk Link America/Kentucky/Louisville America/Louisville -Link America/Puerto_Rico America/Lower_Princes -Link America/Puerto_Rico America/Marigot +Link America/Curacao America/Lower_Princes +Link America/Guadeloupe America/Marigot Link America/Argentina/Mendoza America/Mendoza -Link America/Toronto America/Montreal -Link America/Puerto_Rico America/Montserrat -Link America/Toronto America/Nassau -Link America/Puerto_Rico America/Port_of_Spain Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Denver America/Shiprock -Link America/Puerto_Rico America/St_Barthelemy -Link America/Puerto_Rico America/St_Kitts -Link America/Puerto_Rico America/St_Lucia -Link America/Puerto_Rico America/St_Thomas -Link America/Puerto_Rico America/St_Vincent -Link America/Puerto_Rico America/Tortola -Link America/Puerto_Rico America/Virgin +Link America/Guadeloupe America/St_Barthelemy +Link America/St_Thomas America/Virgin Link Pacific/Auckland Antarctica/McMurdo Link Pacific/Auckland Antarctica/South_Pole Link Europe/Oslo Arctic/Longyearbyen diff --git a/northamerica b/northamerica index 6210318..418261f 100644 --- a/northamerica +++ b/northamerica @@ -1341,9 +1341,13 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # Quebec -# From Paul Eggert (2013-08-26): +# From Paul Eggert (2013-08-30): # Since 1970 most of Quebec has been like Toronto. -# See America/Toronto. +# However, because earlier versions of the tz database mistakenly relied on data +# from Shanks & Pottenger saying that Quebec differed from Ontario after 1970, +# a separate entry was created for most of Quebec. We're loath to lose +# its pre-1970 info, even though the tz database is normally limited to +# zones that differ after 1970, so keep this otherwise out-of-scope entry. # Matthews and Vincent (1998) also write that Quebec east of the -63 # meridian is supposed to observe AST, but residents as far east as @@ -1357,7 +1361,50 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # says this common practice was codified into law as of 2007. # For lack of better info, guess this practice began around 1970, contra to # Shanks & Pottenger who have this region observing AST/ADT. -# See America/Puerto_Rico. +# for post-1970 data America/Puerto_Rico. + +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Mont 1917 only - Mar 25 2:00 1:00 D +Rule Mont 1917 only - Apr 24 0:00 0 S +Rule Mont 1919 only - Mar 31 2:30 1:00 D +Rule Mont 1919 only - Oct 25 2:30 0 S +Rule Mont 1920 only - May 2 2:30 1:00 D +Rule Mont 1920 1922 - Oct Sun>=1 2:30 0 S +Rule Mont 1921 only - May 1 2:00 1:00 D +Rule Mont 1922 only - Apr 30 2:00 1:00 D +Rule Mont 1924 only - May 17 2:00 1:00 D +Rule Mont 1924 1926 - Sep lastSun 2:30 0 S +Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D +# The 1927-to-1937 rules can be expressed more simply as +# Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D +# Rule Mont 1927 1937 - Sep lastSat 24:00 0 S +# The rules below avoid use of 24:00 +# (which pre-1998 versions of zic cannot handle). +Rule Mont 1927 only - May 1 0:00 1:00 D +Rule Mont 1927 1932 - Sep lastSun 0:00 0 S +Rule Mont 1928 1931 - Apr lastSun 0:00 1:00 D +Rule Mont 1932 only - May 1 0:00 1:00 D +Rule Mont 1933 1940 - Apr lastSun 0:00 1:00 D +Rule Mont 1933 only - Oct 1 0:00 0 S +Rule Mont 1934 1939 - Sep lastSun 0:00 0 S +Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D +Rule Mont 1945 1948 - Sep lastSun 2:00 0 S +Rule Mont 1949 1950 - Oct lastSun 2:00 0 S +Rule Mont 1951 1956 - Sep lastSun 2:00 0 S +Rule Mont 1957 1973 - Oct lastSun 2:00 0 S + +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Blanc-Sablon -3:48:28 - LMT 1884 + -4:00 Canada A%sT 1970 + -4:00 - AST +Zone America/Montreal -4:54:16 - LMT 1884 + -5:00 Mont E%sT 1918 + -5:00 Canada E%sT 1919 + -5:00 Mont E%sT 1942 Feb 9 2:00s + -5:00 Canada E%sT 1946 + -5:00 Mont E%sT 1974 + -5:00 Canada E%sT + # Ontario @@ -1423,16 +1470,14 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # can say for certain that Atikokan has been practicing the current # time keeping since 1952, at least. -# From Paul Eggert (2013-08-26): +# From Paul Eggert (2006-07-17): # Shanks & Pottenger say that Atikokan has agreed with Rainy River # ever since standard time was introduced, but the information from # McKinnon sounds more authoritative. For now, assume that Atikokan # switched to EST immediately after WWII era daylight saving time # ended. This matches the old (less-populous) America/Coral_Harbour # entry since our cutoff date of 1970, so we can move -# America/Coral_Harbour to the 'backward' file. And Atikokan itself -# is the same as America/Panama since 1970, so we can move -# America/Atikokan to the 'backward' file as well. +# America/Coral_Harbour to the 'backward' file. # From Mark Brader (2010-03-06): # @@ -1590,6 +1635,11 @@ Zone America/Rainy_River -6:18:16 - LMT 1895 -6:00 Canada C%sT 1940 Sep 29 -6:00 1:00 CDT 1942 Feb 9 2:00s -6:00 Canada C%sT +Zone America/Atikokan -6:06:28 - LMT 1895 + -6:00 Canada C%sT 1940 Sep 29 + -6:00 1:00 CDT 1942 Feb 9 2:00s + -6:00 Canada C%sT 1945 Sep 30 2:00 + -5:00 - EST # Manitoba @@ -1824,8 +1874,7 @@ Zone America/Edmonton -7:33:52 - LMT 1906 Sep # period should be PDT rather than MST, but that doesn't seem important enough # (to anyone) to further complicate the rules. -# From Paul Eggert (2013-08-26): -# See America/Phoenix, since Creston has agreed with Phoenix since 1970. +# The transition dates (and times) are guesses. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Vanc 1918 only - Apr 14 2:00 1:00 D @@ -1845,6 +1894,10 @@ Zone America/Dawson_Creek -8:00:56 - LMT 1884 -8:00 Canada P%sT 1947 -8:00 Vanc P%sT 1972 Aug 30 2:00 -7:00 - MST +Zone America/Creston -7:46:04 - LMT 1884 + -7:00 - MST 1916 Oct 1 + -8:00 - PST 1918 Jun 2 + -7:00 - MST # Northwest Territories, Nunavut, Yukon @@ -2495,10 +2548,15 @@ Zone America/Santa_Isabel -7:39:28 - LMT 1922 Jan 1 0:20:32 ############################################################################### # Anguilla -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Anguilla -4:12:16 - LMT 1912 Mar 2 + -4:00 - AST # Antigua and Barbuda -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Antigua -4:07:12 - LMT 1912 Mar 2 + -5:00 - EST 1951 + -4:00 - AST # Bahamas # @@ -2508,8 +2566,14 @@ Zone America/Santa_Isabel -7:39:28 - LMT 1922 Jan 1 0:20:32 # The Bahamas announced about a month ago that they plan to change their DST # rules to sync with the U.S. starting in 2007.... # http://www.jonesbahamas.com/?c=45&a=10412 -# -# See America/Toronto. + +# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S +Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S +Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 + -5:00 Bahamas E%sT 1976 + -5:00 US E%sT # Barbados @@ -2559,7 +2623,10 @@ Zone Atlantic/Bermuda -4:19:18 - LMT 1930 Jan 1 2:00 # Hamilton -4:00 US A%sT # Cayman Is -# See America/Panama. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown + -5:07:12 - KMT 1912 Feb # Kingston Mean Time + -5:00 - EST # Costa Rica @@ -2805,7 +2872,9 @@ Zone America/Havana -5:29:28 - LMT 1890 -5:00 Cuba C%sT # Dominica -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau + -4:00 - AST # Dominican Republic @@ -2854,10 +2923,15 @@ Zone America/El_Salvador -5:56:48 - LMT 1921 # San Salvador -6:00 Salv C%sT # Grenada -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's + -4:00 - AST # Guadeloupe -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe a Pitre + -4:00 - AST +# Use America/Guadeloupe also for St Barthelemy and for St Martin (French part). # Guatemala # @@ -3027,7 +3101,9 @@ Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France # From Paul Eggert (2006-03-22): # In 1995 volcanic eruptions forced evacuation of Plymouth, the capital. # world.gazetteer.com says Cork Hill is the most populous location now. -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill + -4:00 - AST # Nicaragua # @@ -3108,17 +3184,16 @@ Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan -4:00 US A%sT 1946 -4:00 - AST -# St Barthelemy -# See America/Puerto_Rico. - # St Kitts-Nevis -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/St_Kitts -4:10:52 - LMT 1912 Mar 2 # Basseterre + -4:00 - AST # St Lucia -# See America/Puerto_Rico. - -# St Martin (French part) -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries + -4:04:00 - CMT 1912 # Castries Mean Time + -4:00 - AST # St Pierre and Miquelon # There are too many St Pierres elsewhere, so we'll use `Miquelon'. @@ -3129,7 +3204,10 @@ Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -3:00 Canada PM%sT # St Vincent and the Grenadines -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/St_Vincent -4:04:56 - LMT 1890 # Kingstown + -4:04:56 - KMT 1912 # Kingstown Mean Time + -4:00 - AST # Turks and Caicos # @@ -3163,7 +3241,11 @@ Zone America/Grand_Turk -4:44:32 - LMT 1890 -5:00 TC E%sT # British Virgin Is -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town + -4:00 - AST # Virgin Is -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie + -4:00 - AST diff --git a/pre1970 b/pre1970 deleted file mode 100644 index d8b8f34..0000000 --- a/pre1970 +++ /dev/null @@ -1,291 +0,0 @@ -# Pre-1970 data - -# This file is in the public domain. - -# This file contains zones that were formerly in other source files, -# but were later removed or replaced by backward-compatibility links -# as they differ from other zones only in pre-1970 time stamps. - -# Although the tz database focuses on post-1970 time stamps, these -# entries are retained here as they may be of some use to people -# interested in pre-1970 time stamps, even though they cover only a -# tiny sliver of pre-1970 data and are unreliable for that data. -# Also, these entries can help with backward compatibility with some -# old versions of the tz database. They are incompatible with other -# old versions of the database, though; it depends on which old -# version you're interested in. - -# Entries are sorted by Zone name. Each entry is preceded by the name -# of the country that the entry is in, along with any other commentary -# and rules associated with the entry. Some rules, e.g., 'Canada', -# are defined by other source files; this file is not intended to be -# used without those other files. - -# Zone NAME GMTOFF RULES FORMAT [UNTIL] - -# Mali -# no longer different from Bamako, but too famous to omit -Zone Africa/Timbuktu -0:12:04 - LMT 1912 - 0:00 - GMT - -# Anguilla -Zone America/Anguilla -4:12:16 - LMT 1912 Mar 2 - -4:00 - AST - -# Antigua and Barbuda -Zone America/Antigua -4:07:12 - LMT 1912 Mar 2 - -5:00 - EST 1951 - -4:00 - AST - -# Argentina -# Chubut (CH) -# The name "Comodoro Rivadavia" exceeds the 14-byte POSIX limit. -Zone America/Argentina/ComodRivadavia -4:30:00 - LMT 1894 Oct 31 - -4:16:48 - CMT 1920 May - -4:00 - ART 1930 Dec - -4:00 Arg AR%sT 1969 Oct 5 - -3:00 Arg AR%sT 1991 Mar 3 - -4:00 - WART 1991 Oct 20 - -3:00 Arg AR%sT 1999 Oct 3 - -4:00 Arg AR%sT 2000 Mar 3 - -3:00 - ART 2004 Jun 1 - -4:00 - WART 2004 Jun 20 - -3:00 - ART - -# Aruba -Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad - -4:30 - ANT 1965 # Netherlands Antilles Time - -4:00 - AST - -# Canada - -Zone America/Atikokan -6:06:28 - LMT 1895 - -6:00 Canada C%sT 1940 Sep 29 - -6:00 1:00 CDT 1942 Feb 9 2:00s - -6:00 Canada C%sT 1945 Sep 30 2:00 - -5:00 - EST - -Zone America/Blanc-Sablon -3:48:28 - LMT 1884 - -4:00 Canada A%sT 1970 - -4:00 - AST - -# Cayman Is -Zone America/Cayman -5:25:32 - LMT 1890 # Georgetown - -5:07:12 - 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 - -5:00 - EST - -# Curacao -Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad - -4:30 - ANT 1965 # Netherlands Antilles Time - -4:00 - AST - -# Dominica -Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau - -4:00 - AST - -# Mexico -Zone America/Ensenada -7:46:28 - LMT 1922 Jan 1 0:13:32 - -8:00 - PST 1927 Jun 10 23:00 - -7:00 - MST 1930 Nov 16 - -8:00 - PST 1942 Apr - -7:00 - MST 1949 Jan 14 - -8:00 - PST 1996 - -8:00 Mexico P%sT - -# US -Zone America/Fort_Wayne -5:00 US E%sT 1946 - -5:00 - EST # Always EST as of 1986 - -# Grenada -Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's - -4:00 - AST - -# Guadeloupe -Zone America/Guadeloupe -4:06:08 - LMT 1911 Jun 8 # Pointe a Pitre - -4:00 - AST - -# Canada -# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Mont 1917 only - Mar 25 2:00 1:00 D -Rule Mont 1917 only - Apr 24 0:00 0 S -Rule Mont 1919 only - Mar 31 2:30 1:00 D -Rule Mont 1919 only - Oct 25 2:30 0 S -Rule Mont 1920 only - May 2 2:30 1:00 D -Rule Mont 1920 1922 - Oct Sun>=1 2:30 0 S -Rule Mont 1921 only - May 1 2:00 1:00 D -Rule Mont 1922 only - Apr 30 2:00 1:00 D -Rule Mont 1924 only - May 17 2:00 1:00 D -Rule Mont 1924 1926 - Sep lastSun 2:30 0 S -Rule Mont 1925 1926 - May Sun>=1 2:00 1:00 D -# The 1927-to-1937 rules can be expressed more simply as -# Rule Mont 1927 1937 - Apr lastSat 24:00 1:00 D -# Rule Mont 1927 1937 - Sep lastSat 24:00 0 S -# The rules below avoid use of 24:00 -# (which pre-1998 versions of zic cannot handle). -Rule Mont 1927 only - May 1 0:00 1:00 D -Rule Mont 1927 1932 - Sep lastSun 0:00 0 S -Rule Mont 1928 1931 - Apr lastSun 0:00 1:00 D -Rule Mont 1932 only - May 1 0:00 1:00 D -Rule Mont 1933 1940 - Apr lastSun 0:00 1:00 D -Rule Mont 1933 only - Oct 1 0:00 0 S -Rule Mont 1934 1939 - Sep lastSun 0:00 0 S -Rule Mont 1946 1973 - Apr lastSun 2:00 1:00 D -Rule Mont 1945 1948 - Sep lastSun 2:00 0 S -Rule Mont 1949 1950 - Oct lastSun 2:00 0 S -Rule Mont 1951 1956 - Sep lastSun 2:00 0 S -Rule Mont 1957 1973 - Oct lastSun 2:00 0 S -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Montreal -4:54:16 - LMT 1884 - -5:00 Mont E%sT 1918 - -5:00 Canada E%sT 1919 - -5:00 Mont E%sT 1942 Feb 9 2:00s - -5:00 Canada E%sT 1946 - -5:00 Mont E%sT 1974 - -5:00 Canada E%sT - -# Montserrat -Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill - -4:00 - AST - -# Bahamas -# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Bahamas 1964 1975 - Oct lastSun 2:00 0 S -Rule Bahamas 1964 1975 - Apr lastSun 2:00 1:00 D -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Nassau -5:09:30 - LMT 1912 Mar 2 - -5:00 Bahamas E%sT 1976 - -5:00 US E%sT - -# Trinidad and Tobago -Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 - -4:00 - AST - -# Brazil -# Rio_Branco is too ambiguous, since there's a Rio Branco in Uruguay too. -Zone America/Porto_Acre -4:31:12 - LMT 1914 - -5:00 Brazil AC%sT 1988 Sep 12 - -5:00 - ACT - -# Argentina -# Santa Fe (SF), Entre Rios (ER), Corrientes (CN), Misiones (MN), Chaco (CC), -# Formosa (FM), La Pampa (LP), Chubut (CH) -Zone America/Rosario -4:02:40 - LMT 1894 Nov - -4:16:44 - CMT 1920 May - -4:00 - ART 1930 Dec - -4:00 Arg AR%sT 1969 Oct 5 - -3:00 Arg AR%sT 1991 Jul - -3:00 - ART 1999 Oct 3 0:00 - -4:00 Arg AR%sT 2000 Mar 3 0:00 - -3:00 - ART - -# St Kitts-Nevis -Zone America/St_Kitts -4:10:52 - LMT 1912 Mar 2 # Basseterre - -4:00 - AST - -# St Lucia -Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries - -4:04:00 - CMT 1912 # Castries Mean Time - -4:00 - AST - -# Virgin Is -Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie - -4:00 - AST - -# St Vincent and the Grenadines -Zone America/St_Vincent -4:04:56 - LMT 1890 # Kingstown - -4:04:56 - KMT 1912 # Kingstown Mean Time - -4:00 - AST - -# British Virgin Is -Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town - -4:00 - AST - -# McMurdo, Ross Island, since 1955-12 -Zone Antarctica/McMurdo 0 - zzz 1956 - 12:00 NZAQ NZ%sT - -# Japan -Zone Asia/Ishigaki 8:16:36 - LMT 1896 - 8:00 - CST - -# Israel -Zone Asia/Tel_Aviv 2:19:04 - LMT 1880 - 2:21 - JMT 1918 - 2:00 Zion I%sT - -# Russia -Zone Asia/Tomsk 5:39:52 - LMT 1924 May 2 - 6:00 - TSK 1957 Mar - 7:00 Russia TS%s 1991 Mar 31 2:00s - 6:00 1:00 TSD 1991 Sep 29 2:00s - 6:00 - TSK 1992 Jan 19 2:00s - 7:00 Russia TS%s - -# Svalbard & Jan Mayen -Zone Atlantic/Jan_Mayen -1:00 - EGT - -# Australia -Zone Australia/Canberra 9:56:32 - LMT 1895 Feb - 10:00 - EST 1917 Jan 1 0:01 - 10:00 Aus EST 1971 Oct 31 2:00 - 10:00 AN EST 1981 Oct 25 2:00 - 10:00 1:00 EST 1982 Apr 4 3:00 - 10:00 AN EST - -# UK -Zone Europe/Belfast -0:23:40 - LMT 1880 Aug 2 - -0:25:21 - DMT 1916 May 21 2:00 # Dublin/Dunsink MT - -0:25:21 1:00 IST 1916 Oct 1 2:00s # Irish Summer Time - 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 - -# Slovenia -Zone Europe/Ljubljana 0:58:04 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT - -# Bosnia and Herzegovina -Zone Europe/Sarajevo 1:13:40 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT - -# Macedonia -Zone Europe/Skopje 1:25:44 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT - -# Moldova -Zone Europe/Tiraspol 1:58:32 - LMT 1880 - 1:55 - CMT 1918 Feb 15 # Chisinau MT - 1:44:24 - BMT 1931 Jul 24 # Bucharest MT - 2:00 Romania EE%sT 1940 Aug 15 - 2:00 1:00 EEST 1941 Jul 17 - 1:00 C-Eur CE%sT 1944 Aug 24 - 3:00 Russia MSK/MSD 1991 Mar 31 2:00 - 2:00 Russia EE%sT 1992 Jan 19 2:00 - 3:00 Russia MSK/MSD - -# Croatia -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Europe/Zagreb 1:03:52 - LMT 1884 - 1:00 - CET 1941 Apr 18 23:00 - 1:00 C-Eur CE%sT 1945 May 8 2:00s - 1:00 1:00 CEST 1945 Sep 16 2:00s - 1:00 - CET 1982 Nov 27 - 1:00 EU CE%sT diff --git a/southamerica b/southamerica index 59f5fe7..ff47cef 100644 --- a/southamerica +++ b/southamerica @@ -631,7 +631,10 @@ Zone America/Argentina/Ushuaia -4:33:12 - LMT 1894 Oct 31 -3:00 - ART # Aruba -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Aruba -4:40:24 - LMT 1912 Feb 12 # Oranjestad + -4:30 - ANT 1965 # Netherlands Antilles Time + -4:00 - AST # Bolivia # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1325,7 +1328,7 @@ Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 # Curacao -# Milne gives 4:35:46.9 for Curacao mean time. +# Milne gives 4:35:46.9 for Curacao mean time; round to nearest. # # From Paul Eggert (2006-03-22): # Shanks & Pottenger say that The Bottom and Philipsburg have been at @@ -1341,7 +1344,14 @@ Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 # Netherlands as Kingdom Islands. This won't affect their time zones # though, as far as we know. # -# For all these regions, see America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Curacao -4:35:47 - LMT 1912 Feb 12 # Willemstad + -4:30 - ANT 1965 # Netherlands Antilles Time + -4:00 - AST + +# Sint Maarten +# Caribbean Netherlands +# Use America/Curacao. # Ecuador # @@ -1615,7 +1625,9 @@ Zone America/Paramaribo -3:40:40 - LMT 1911 -3:00 - SRT # Trinidad and Tobago -# See America/Puerto_Rico. +# Zone NAME GMTOFF RULES FORMAT [UNTIL] +Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 + -4:00 - AST # Uruguay # From Paul Eggert (1993-11-18): -- 1.8.1.2

7 38

winnowing stats
by Zefram Sept. 3, 2013

Sept. 3, 2013

Here are some stats on how much difference winnowing makes to the dataset. Baseline: the source files define 441 distinct zones. Winnowing then reduces the number of distinct zones thus: YEAR COUNT 0000 440 1880 440 1890 439 1900 439 1910 437 1920 435 1930 435 1940 434 1950 425 1960 423 1970 417 1980 391 1990 365 2000 339 2010 313 2020 305 The reduction by one zone for a threshold year of 0000 comes from Pacific/Johnston, a US minor outlying island, which is defined with data identical to the "HST" zone. (Contrary to the usual practice of using LMT for the first segment of geographical zones.) As the two tzfiles are byte-for-byte identical, tzwinnow will merge them regardless of date thresholds. The results for a threshold in the future set a lower limit on the size to which the database can be reduced by this mechanism. Relative to the present full database of 441 zones, it's only a modest gain. Using a threshold later than 1970 for installation purposes will probably only be attractive in a few more decades' time, when there have been many more zone splits arising from contemporary activity. A threshold later than 1970 is currently much more valuable for tzselect purposes. Here it's saving human cognitive load rather than storage space. The reduction in the number of zones is concentrated disproportionately in the countries that have the greatest complexity. This is particularly noticeable with the US zones, the list of which is quite unwieldy in unwinnowed form. Over the period where we attempt complete coverage (1970 to today), the rate at which the number of distinct zones changes is amazingly consistent at 26 per decade. A similar pattern emerges when winnowing with a varying upper date limit, showing that there's a long-term roughly constant rate of zone churn. The number of zones distinct within a single decade is also roughly constant, around 330. The number distinct within a single year hovers around 300, possibly showing a slight rising trend, but I suspect that's an artifact of incomplete data. This suggests that a strategy of winnowing with a moving threshold that remains N years ago will produce a roughly constant zone count. By contrast, the number of zones differing at any time post-1970 (currently 417), or from any other fixed threshold, can grow without bound, and it looks like it will. -zefram

2 1

scope of tz database, scholarship
by Steve Allen Sept. 2, 2013

Sept. 2, 2013

For the sake of the scholarship I would like to see a modification of the current text that reads As for leap seconds, we don't know the history of earth's rotation accurately enough to map SI seconds to historical solar time to more than about one-hour accuracy; see Stephenson FR (2003), Historical eclipses and Earth's rotation, A&G 44: 2.22-2.27 <http://dx.doi.org/10.1046/j.1468-4004.2003.44222.x>. A more complete reference to the accuracy of historical Delta T is in Historical values of the Earth's clock error Delta T and the calculation of eclipses Morrison, L. V. & Stephenson, F. R. Journal for the History of Astronomy (ISSN 0021-8286), Vol. 35, Part 3, No. 120, p. 327 - 336 (2004) as can be seen at http://articles.adsabs.harvard.edu/full/2004JHA....35..327M where, in particular, Table 1 gives uncertainty estimates back nearly 3000 years. For the oldest data there is an addendum Addendum: Historical values of the Earth's clock error Morrison, L. V. & Stephenson, F. R. Journal for the History of Astronomy (ISSN 0021-8286), Vol. 36, Part 3, No. 124, p. 339 (2005) http://adsabs.harvard.edu/full/2005JHA....36..339M In addition to that, for all practical purposes, civil time prior to 1972 did not use SI seconds, but rather mean solar seconds, and for dates prior to 1955 there cannot even be an argument. Therefore in the extended range of the tz database there is an arguably unspecified point when the kind of seconds counted changes from mean solar (UT) to atomic (SI). -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

3 2

Unacceptable recent changes [wasRe: [PATCH 2/4] Move obsolescent Americas entries to 'backward'.]
by Stephen Colebourne Aug. 30, 2013

Aug. 30, 2013

On 26 August 2013 18:16, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > # Shanks & Pottenger say that Atikokan has agreed with Rainy River > # ever since standard time was introduced, but the information from > # McKinnon sounds more authoritative. For now, assume that Atikokan > # switched to EST immediately after WWII era daylight saving time > # ended. This matches the old (less-populous) America/Coral_Harbour > # entry since our cutoff date of 1970, so we can move > -# America/Coral_Harbour to the 'backward' file. > +# America/Coral_Harbour to the 'backward' file. And Atikokan itself > +# is the same as America/Panama since 1970, so we can move > +# America/Atikokan to the 'backward' file as well. > -Zone America/Atikokan -6:06:28 - LMT 1895 > - -6:00 Canada C%sT 1940 Sep 29 > - -6:00 1:00 CDT 1942 Feb 9 2:00s > - -6:00 Canada C%sT 1945 Sep 30 2:00 > - -5:00 - EST So if I understand correctly, all changes to Atikokan before 1970 have just been lost? And they are supposed to use Panama from now on? Here is what JSR-310 can tell us about the two sets of rules: America/Atikokan Transition[Gap at 1895-01-01T00:00-06:06:28 to -06:00] Transition[Gap at 1918-04-14T02:00-06:00 to -05:00] Transition[Overlap at 1918-10-27T02:00-05:00 to -06:00] Transition[Gap at 1940-09-29T00:00-06:00 to -05:00] America/Panama Transition[Overlap at 1890-01-01T00:00-05:18:08 to -05:19:36] Transition[Gap at 1908-04-22T00:00-05:19:36 to -05:00] Merging these is clearly utterly RIDICULOUS. They contain completely different data, and the 1970 argument simply won't wash. Many users will have stored data in databases or other long term storage that refers to these time-zones being made obsolete. When they read the data back, they will get completely different times for historic events - utterly unacceptable. More broadly, no one can pretend that the IDs we use are meaningless. Whether they should or should not have been created this way is not relevent - what matters is that these IDs are meningful and getting rid of them would be a disaster. The IDs are clearly localized, and they have a huge and longstanding usage globally. Panama is nowhere near Atikokan, nor would any reasonable user connect the two. Paul, you need to STOP NOW. You need to reverse the vast majority of your recent changes. Focus on actual changes happening in 2013. Keep the rest of the database totally and utterly stable. And just accept that there is a measure of politics incumbent in time-zones. NONE of these changes should be happening. STABILITY is vital. Stephen

20 53

Proposal for new rules
by Stephen Colebourne Aug. 30, 2013

Aug. 30, 2013

A simple proposal to move forward from where we are with reliable new rules: 1) Each inhabited ISO-3166 region must have at least one fully defined zone (LMT, pre and post 1970) 2) Links must not cross ISO-3166 region bouindaries Some of the rules that would require reworking (not a complete list): Europe/Busingen America/Atikotan America/Aruba America/Anguilla America/Port_of_Spain Europe/Zagreb Europe/Vatican Note that America/Montreal does not require reworking as a result of the first two new rules, although since it looks to have detailed historical information it would be unwise to lose that. Therefore I would add a third rule: 3) Existing pre-1970 data shall be respected If accepted, then these rules would be encoded in the theory file. Stephen

13 27

Acre, Brazil will attempt to re-introduce its previous timezone
by Alexander Krivenyshev Aug. 29, 2013

Aug. 29, 2013

According to the news from Brazil, Acre, Brazil will attempt to re-introduce its previous timezone, excluding Amazonas. http://www.worldtimezone.com/dst_news/dst_news_brazil11.html Alexander Krivenyshev, http://www.WorldTimeZone.com

1 0

Introducing myself
by Stephen Colebourne Aug. 29, 2013

Aug. 29, 2013

On 29 August 2013 20:39, Kevin Lyda <kevin(a)ie.suberic.net> wrote: > No solution will avoid politics. And someone starting a number of threads on > this topic clearly has their own political agenda. I should introduce myself, as not everyone will know who I am, or what I represent. I am Stephen Colebourne - a Java developer of 15+ years - recognised as a Java Champion, a leader in the Java community - author of Joda-Time, the most widely adopted 3rd party API for date and time in Java - co-spec lead of JSR-310, the effort to write a better API for the Java JDK - have written APIs to parse the tzdb - have designed APIs to expose that data to developers - work very closely with Oracle, and have had conversations with CLDR in the past My "political agenda" is to avoid the effort I've put in over the last 12 years on date and time in Java being damaged. Recent changes give the appearance of a lack of understanding of the importance of pre-1970 data and of cross-border localization. I'm sorry that I've had to write so much and object so strongly. I want to find a solution we can all agree on. It seems harder than it should be. Stephen

3 2

Problematic/dubious commits in 2013
by Stephen Colebourne Aug. 29, 2013

Aug. 29, 2013

I have reviewed every commit since the end of 2012. Here are the ones I consider to be problematic. I suggest that others have another review of these, as it may be that not everyone has taken the time to do this. - One zone for each inhabited ISO-3166 region should not have been removed: https://github.com/eggert/tz/commit/d3b025adb25554ee10b986850371e573df92733… - Ensuing changes were wrong: https://github.com/eggert/tz/commit/df99923bde035a263493f3435db63db15df14d53 - Reversion did not revert everything, specifically the reverted links are still in the backward file, not the main file, indicating that they are deprecated which should not be the case (eg for Europe/Zagreb): https://github.com/eggert/tz/commit/ee40570d7d937de749fe89676dec2ff1526ee68b - Pre-1970 damage: https://github.com/eggert/tz/commit/5903db75e5974fbdede1fa05bcef53ff645ac13d https://github.com/eggert/tz/commit/9432f1d23d3c5bbcc14c26f781185c01679edeef - Montreal removal (looks like it changes pre-1970 history) https://github.com/eggert/tz/commit/45dcf69b45087cff50282d4da64b86a7d705ddf3 - Navajo - America/ShipRock removal https://github.com/eggert/tz/commit/d58b59dd8a1e4c10abdbab8857ae521f6c2d2536 https://github.com/eggert/tz/commit/81be53c16b97ce0bc561ce3891ce2503227e3369 - Other possibly dubious commits tzselect changes https://github.com/eggert/tz/commit/cc3f93886bcfe36dfedc8f340827fded6e43539c https://github.com/eggert/tz/commit/ebdf0c5d0ce06b20dcd7e984b7370548f74dc210 Not all of these cause damage, but some clearly do. I'm unhappy with most of them, as they break the principles I value. Stephen

1 0

Principles
by Stephen Colebourne Aug. 29, 2013

Aug. 29, 2013

It seems like there are conflicts in the principles behind the tzdb. Here are my thoughts: What is the tzdb? Generally accepted: - widely used - ubiquitous - reliable - accurate post-1970 - handles changes occurring now More controversial: - IDs used in GUIs (they are whether we like it or not) - IDs have meaning (they do whether we like it or not) - pre-1970 is in-scope (data is there whether we like it or not) - pre-1970 data may not be accurate (users like data, care less about its accuracy) - pre-1970 LMT is accurate for the location in the tzdb ID What do end users expect? (developers and non-developers) - users often pick zones based on raw tzdb ID - users don't know the history of zone rules in their location - users do know that they live in an area that might have special zone rules, eg. Busingen/Navajo - users want minimal cognitive effort, pick it and it works - users don't understand the nuances of a cross-border zone, they just associate with their region What do I expect? - Stability - No deletions of data, except where _proven_ wrong - Additions focussed on today and the future - Historical changes only following research - No new time-zones in the main files unless they differ post-1970 - At least one time-zone ID for each ISO-3166 region - Using all files except backward should meet goals above - Backward file is for deprecations only I don't think that any of this is unreasonable, or different from how the tzdb has previously worked. Stephen

1 0

Namibia Time Change
by Hank W. Aug. 26, 2013

Aug. 26, 2013

Reminder: The annual switch from West Africa Time (UTC+1) to West Africa Summer Time (UTC+2) in Namibia only is scheduled for this coming Sunday, 1 September, at 2 AM WAT (1 AM UTC).

2 2

Unable to get the tz database
by Peddi, Radhika (Radhika) Aug. 24, 2013

Aug. 24, 2013

Hi, This is Radhika from Avaya. When I am trying to get tz database from the link http://www.twinsun.com/tz/tz-link.htm, by using FTP distribution, I am getting Host Not Found error. Please find the attached screen shot for the same. When I am using below shell command on my linux setup wget 'ftp://elsie.nci.nih.gov/pub/tz*.tar.gz', I am getting below error --2013-08-20 03:14:03-- ftp://elsie.nci.nih.gov/pub/tz*.tar.gz => `.listing' Resolving elsie.nci.nih.gov... failed: Name or service not known. wget: unable to resolve host address `elsie.nci.nih.gov' Could you please help me how to get rid of this problem. Thanks & Regards, Radhika Peddi|Avaya India Pvt. Ltd.| Wing 'A', Level -5, Tower-11, Cybercity, Magarpatta City, Hadapsar | Pune, 411028|India Voice +91 20 4101 8311| Email: rpeddi<mailto:rpeddi@avaya.com>@avaya.com [ Please consider the environment before printing this email ]

2 3

infinite loop in time2sub
by enh Aug. 22, 2013

Aug. 22, 2013

i recently upgraded Android's copy of tzcode to be closer to tzcode2013d. with Android's signed 32-bit time_t i'm seeing a change in behavior for out-of-range dates. previously given something like this, mktime would return an error, but now it hangs in the binary search in time2sub. struct tm t; memset(&t, 0, sizeof(tm)); t.tm_year = 200; t.tm_mon = 2; t.tm_mday = 10; changing the if (t == lo) { ++t; if (t <= lo) return WRONG; ++lo; } else if (t == hi) { --t; if (t >= hi) return WRONG; --hi; } back to if (t == lo) { if (t == TIME_T_MAX) return WRONG; ++t; ++lo; } else if (t == hi) { if (t == TIME_T_MIN) return WRONG; --t; --hi; } fixes things. looking at the git history in https://github.com/eggert/tz.gitit looks like the old code, found in Android up to and including jb-mr2 (but no longer in AOSP ToT), was never in upstream tzcode. here's where the upstream tzcode's overflow checks were introduced: commit 46fa7e98177cae664f673c6034c9ac74d0ccd0ec Author: Arthur David Olson <olsona@elsie> Date: Tue Aug 9 09:55:06 2005 -0400 overflow work SCCS-file: localtime.c SCCS-SID: 7.96 diff --git a/localtime.c b/localtime.c index 1c3e9b0..d3edb5a 100644 --- a/localtime.c +++ b/localtime.c @@ -1616,9 +1616,13 @@ const int do_norm_secs; if (dir != 0) { if (t == lo) { ++t; + if (t <= lo) + return WRONG; ++lo; } else if (t == hi) { --t; + if (t >= hi) + return WRONG; --hi; } if (lo > hi) looking at the Android AOSP git history, it looks like we found and fixed this bug years ago but never talked to upstream about it: commit 2093d350be21ff086f9e145404877941b9a42c5c Author: David 'Digit' Turner <digit(a)google.com> Date: Wed Sep 9 17:41:59 2009 -0700 Fix an infinite loop in time2sub. The problem is that time_t is signed, and the original code relied on the fact that (X + c < X) in case of overflow for c >= 0. Unfortunately, this condition is only guaranteed by the standard for unsigned arithmetic, and the gcc 4.4.0 optimizer did completely remove the corresponding test from the code. This resulted in a missing boundary check, and an infinite loop. The problem is solved by testing explicitely for TIME_T_MIN and TIME_T_MAX in the loop that uses this. Also fix increment_overflow and long_increment_overflow which were buggy for exactly the same reasons. Note: a similar fix is needed for system/core/libcutils diff --git a/libc/tzcode/localtime.c b/libc/tzcode/localtime.c index 9c5f218..83c1011 100644 --- a/libc/tzcode/localtime.c +++ b/libc/tzcode/localtime.c @@ -75,6 +75,31 @@ static __inline__ void _tzUnlock(void) pthread_mutex_unlock(&_tzMutex); } +/* Complex computations to determine the min/max of time_t depending + * on TYPE_BIT / TYPE_SIGNED / TYPE_INTEGRAL. + * These macros cannot be used in pre-processor directives, so we + * let the C compiler do the work, which makes things a bit funky. + */ +static const time_t TIME_T_MAX = + TYPE_INTEGRAL(time_t) ? + ( TYPE_SIGNED(time_t) ? + ~((time_t)1 << (TYPE_BIT(time_t)-1)) + : + ~(time_t)0 + ) + : /* if time_t is a floating point number */ + ( sizeof(time_t) > sizeof(float) ? (time_t)DBL_MAX : (time_t)FLT_MAX ); + +static const time_t TIME_T_MIN = + TYPE_INTEGRAL(time_t) ? + ( TYPE_SIGNED(time_t) ? + ((time_t)1 << (TYPE_BIT(time_t)-1)) + : + 0 + ) + : + ( sizeof(time_t) > sizeof(float) ? (time_t)DBL_MIN : (time_t)FLT_MIN ); + #ifndef WILDABBR /* ** Someone might make incorrect use of a time zone abbreviation: @@ -1683,11 +1708,16 @@ increment_overflow(number, delta) int * number; int delta; { - int number0; + unsigned number0 = (unsigned)*number; + unsigned number1 = (unsigned)(number0 + delta); + + *number = (int)number1; - number0 = *number; - *number += delta; - return (*number < number0) != (delta < 0); + if (delta >= 0) { + return ((int)number1 < (int)number0); + } else { + return ((int)number1 > (int)number0); + } } static int @@ -1695,11 +1725,16 @@ long_increment_overflow(number, delta) long * number; int delta; { - long number0; + unsigned long number0 = (unsigned long)*number; + unsigned long number1 = (unsigned long)(number0 + delta); + + *number = (long)number1; - number0 = *number; - *number += delta; - return (*number < number0) != (delta < 0); + if (delta >= 0) { + return ((long)number1 < (long)number0); + } else { + return ((long)number1 > (long)number0); + } } static int @@ -1868,14 +1903,14 @@ const int do_norm_secs; } else dir = tmcomp(&mytm, &yourtm); if (dir != 0) { if (t == lo) { - ++t; - if (t <= lo) + if (t == TIME_T_MAX) return WRONG; + ++t; ++lo; } else if (t == hi) { - --t; - if (t >= hi) + if (t == TIME_T_MIN) return WRONG; + --t; --hi; } if (lo > hi) right now i'm going to work around this by building the tzcode part of the C library with -fno-strict-overflow (because i don't know how many other places are relying on this unspecified behavior), but i'll apply whatever patch goes into upstream as soon as it's available. --elliott

2 2

[PATCH] * .gitignore: Add 'date'.
by Paul Eggert Aug. 22, 2013

Aug. 22, 2013

--- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 5759d2a..18dbbcc 100644 --- a/.gitignore +++ b/.gitignore @@ -4,6 +4,7 @@ *.txt *~ ChangeLog +date leapseconds time.tab tzselect -- 1.7.11.7

1 0

[PATCH] tzselect: new options -c COORD and -n LIMIT
by Paul Eggert Aug. 22, 2013

Aug. 22, 2013

These let the user select TZ based on geographical coordinates. Combining '-c COORD' with '-t time' better insulates the user from issues of nationality. * tzselect.8 (SYNOPSIS, OPTIONS): Document the new options. * tzselect.ksh: Implement them, using the great-circle special case of the Vicenty formula for distances on ellipsoids. (LC_ALL): Set to C, since tzselect is English only. That way, we treat decimal-points in -c option operands the same in all environments. (usage): Document new options. Document existing ones better. (output_distances): New variable. --- tzselect.8 | 26 ++++++++++ tzselect.ksh | 162 +++++++++++++++++++++++++++++++++++++++++++++++++++++++---- 2 files changed, 177 insertions(+), 11 deletions(-) diff --git a/tzselect.8 b/tzselect.8 index b5e2c88..884af36 100644 --- a/tzselect.8 +++ b/tzselect.8 @@ -4,6 +4,12 @@ tzselect \- select a time zone .SH SYNOPSIS .B tzselect [ +.B \-c +.I coord +] [ +.B \-n +.I limit +] [ .B \-t .I zonetabtype ] [ @@ -21,6 +27,26 @@ The output is suitable as a value for the TZ environment variable. All interaction with the user is done via standard input and standard error. .SH OPTIONS .TP +.BI "\-c " coord +Instead of asking for continent and then country and then city, +ask for selection from time zones whose largest cities +are closest to the location with geographical coordinates +.IR coord . +Use ISO 6709 notation for +.IR coord , +for example, +.B "\-c\ \+42.391415\-071.570419" +for 42.391415\(de\|N, 71.570419\(de\|W, and +.B "\-c\ +404226\-0740319" +for 48\(de\|42\(fm\|26\(sd\|N, 74\(de\|3\(fm\|19\(sd\|W. +.TP +.BI "\-n " limit +When +.B \-c +is used, display the closest +.I limit +locations (default 10). +.TP .BI "\-t " zonetabtype Make selections from the time zone table of type .IR zonetabtype . diff --git a/tzselect.ksh b/tzselect.ksh index dc9f256..da6adb2 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -1,5 +1,7 @@ #!/bin/bash +export LC_ALL=C + PKGVERSION='(tzcode) ' TZVERSION=see_Makefile REPORT_BUGS_TO=tz(a)iana.org @@ -41,15 +43,43 @@ ZONETABTYPE=zone exit 1 } -usage="Usage: tzselect [--version] [--help] [-t ZONETABTYPE] +coord= +location_limit=10 + +usage="Usage: tzselect [--version] [--help] [-c COORD] [-n LIMIT] [-t ZONETABTYPE] Select a time zone interactively. -ZONETABTYPE should be one of 'time' or 'zone'. + +Options: + + -c COORD + Instead of asking for continent and then country and then city, + ask for selection from time zones whose largest cities + are closest to the location with geographical coordinates COORD. + COORD should use ISO 6709 notation, for example, '-c +4852+00220' + for Paris. + + -n LIMIT + Display at most LIMIT locations when -c is used (default $location_limit). + + -t ZONETABTYPE + Use time zone table ZONETABTYPE. ZONETABTYPE should be one of + 'time' or 'zone'. + + --version + Output version information. + + --help + Output this help. Report bugs to $REPORT_BUGS_TO." -while getopts t:-: opt +while getopts c:n:t:-: opt do case $opt$OPTARG in + c*) + coord=$OPTARG ;; + n*) + location_limit=$OPTARG ;; t*) ZONETABTYPE=$OPTARG ;; -help) @@ -90,6 +120,66 @@ case $(echo 1 | (select x in x; do break; done) 2>/dev/null) in ?*) PS3= esac +# Awk script to read a time zone table and output the same table, +# with each column preceded by its distance from 'here'. +output_distances=' + BEGIN { + FS = "\t" + while (getline <TZ_COUNTRY_TABLE) + if ($0 ~ /^[^#]/) + country[$1] = $2 + country["US"] = "US" # Otherwise the strings get too long. + } + function cvt1(coord, deg, min, ilen, sign, sec) { + ilen = length(coord) + sign = substr(coord, 1, 1) + if (coord ~ /\./) { + deg = coord + 0 + } else { + if (ilen <= 6) { + sec = 0 + } else { + sec = sign substr(coord, ilen - 1) + ilen -= 2 + } + min = sign substr(coord, ilen - 1, 2) + deg = substr(coord, 1, ilen - 2) + deg = (deg * 3600.0 + min * 60.0 + sec) / 3600.0 + } + return deg * 0.017453292519943295 + } + function convert_latitude(coord) { + match(coord, /..*[-+]/) + return cvt1(substr(coord, 1, RLENGTH - 1)) + } + function convert_longitude(coord) { + match(coord, /..*[-+]/) + return cvt1(substr(coord, RLENGTH)) + } + # Great-circle distance between points with given latitude and longitude. + # Inputs and output are in radians. This uses the great-circle special + # case of the Vicenty formula for distances on ellipsoids. + function dist(lat1, long1, lat2, long2, dlong, x, y, num, denom) { + dlong = long2 - long1 + x = cos (lat2) * sin (dlong) + y = cos (lat1) * sin (lat2) - sin (lat1) * cos (lat2) * cos (dlong) + num = sqrt (x * x + y * y) + denom = sin (lat1) * sin (lat2) + cos (lat1) * cos (lat2) * cos (dlong) + return atan2(num, denom) + } + BEGIN { + coord_lat = convert_latitude(coord) + coord_long = convert_longitude(coord) + } + /^[^#]/ { + here_lat = convert_latitude($2) + here_long = convert_longitude($2) + line = $1 "\t" $2 "\t" $3 "\t" country[$1] + if (NF == 4) + line = line " - " $4 + printf "%g\t%s\n", dist(coord_lat, coord_long, here_lat, here_long), line + } +' # Begin the main loop. We come back here if the user wants to retry. while @@ -101,10 +191,14 @@ while country= region= + case $coord in + ?*) + continent=coord;; + '') # Ask the user for continent or ocean. - echo >&2 'Please select a continent or ocean.' + echo >&2 'Please select a continent, ocean, "coord", or "TZ".' select continent in \ Africa \ @@ -117,7 +211,8 @@ while Europe \ 'Indian Ocean' \ 'Pacific Ocean' \ - 'none - I want to specify the time zone using the Posix TZ format.' + 'coord - I want to use geographical coordinates.' \ + 'TZ - I want to specify the time zone using the Posix TZ format.' do case $continent in '') @@ -130,10 +225,12 @@ while break esac done + esac + case $continent in '') exit 1;; - none) + TZ) # Ask the user for a Posix TZ string. Check that it conforms. while echo >&2 'Please enter the desired value' \ @@ -158,6 +255,45 @@ while done TZ_for_date=$TZ;; *) + case $continent in + coord) + case $coord in + '') + echo >&2 'Please enter coordinates' \ + 'in ISO 6709 notation.' + echo >&2 'For example, +4042-07403 stands for' + echo >&2 '40 degrees 42 minutes north,' \ + '74 degrees 3 minutes west.' + read coord;; + esac + distance_table=$($AWK \ + -v coord="$coord" \ + -v TZ_COUNTRY_TABLE="$TZ_COUNTRY_TABLE" \ + "$output_distances" <$TZ_ZONE_TABLE | + sort -n | + sed "${location_limit}q" + ) + regions=$(echo "$distance_table" | $AWK ' + BEGIN { FS = "\t" } + { print $NF } + ') + echo >&2 'Please select one of the following' \ + 'time zone regions,' + echo >&2 'listed roughly in increasing order' \ + "of distance from $coord". + select region in $regions + do + case $region in + '') echo >&2 'Please enter a number in range.';; + ?*) break;; + esac + done + TZ=$(echo "$distance_table" | $AWK -v region="$region" ' + BEGIN { FS="\t" } + $NF == region { print $4 } + ') + ;; + *) # Get list of names of countries in the continent or ocean. countries=$($AWK -F'\t' \ -v continent="$continent" \ @@ -185,7 +321,8 @@ while # If there's more than one country, ask the user which one. case $countries in *"$newline"*) - echo >&2 'Please select a country.' + echo >&2 'Please select a country' \ + 'whose clocks agree with yours.' select country in $countries do case $country in @@ -256,6 +393,7 @@ while } $1 == cc && $4 == region { print $3 } ' <$TZ_ZONE_TABLE) + esac # Make sure the corresponding zoneinfo file exists. TZ_for_date=$TZDIR/$TZ @@ -292,9 +430,11 @@ Universal Time is now: $UTdate." echo >&2 "" echo >&2 "The following information has been given:" echo >&2 "" - case $country+$region in - ?*+?*) echo >&2 " $country$newline $region";; - ?*+) echo >&2 " $country";; + case $country%$region%$coord in + ?*%?*%) echo >&2 " $country$newline $region";; + ?*%%) echo >&2 " $country";; + %?*%?*) echo >&2 " coord $coord$newline $region";; + %%?*) echo >&2 " coord $coord";; +) echo >&2 " TZ='$TZ'" esac echo >&2 "" @@ -313,7 +453,7 @@ Universal Time is now: $UTdate." '') exit 1;; Yes) break esac -do : +do coord= done case $SHELL in -- 1.8.1.2

3 7

[PATCH 1/3] Further removal of attempt to support floating-point time_t.
by Paul Eggert Aug. 19, 2013

Aug. 19, 2013

* localtime.c (timesub): * zdump.c (my_localtime): Don't worry about time_t being floating-point. * localtime.c (timesub): Avoid undefined behavior on integer overflow when assigning time_t to int. --- localtime.c | 5 +++-- zdump.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/localtime.c b/localtime.c index 5312ad9..f58b20a 100644 --- a/localtime.c +++ b/localtime.c @@ -1489,9 +1489,10 @@ timesub(const time_t *const timep, const int_fast32_t offset, register int leapdays; tdelta = tdays / DAYSPERLYEAR; - idelta = tdelta; - if (tdelta - idelta >= 1 || idelta - tdelta >= 1) + if (! ((! TYPE_SIGNED(time_t) || INT_MIN <= tdelta) + && tdelta <= INT_MAX)) return NULL; + idelta = tdelta; if (idelta == 0) idelta = (tdays < 0) ? -1 : 1; newy = y; diff --git a/zdump.c b/zdump.c index 36c1838..fa5f8d8 100644 --- a/zdump.c +++ b/zdump.c @@ -244,7 +244,7 @@ my_localtime(time_t *tp) tm = *tmp; t = mktime(&tm); - if (t - *tp >= 1 || *tp - t >= 1) { + if (t != *tp) { (void) fflush(stdout); (void) fprintf(stderr, "\n%s: ", progname); (void) fprintf(stderr, tformat(), *tp); -- 1.8.1.2

3 7

Re: [tz] Problem with Busingen
by Paul Eggert Aug. 19, 2013

Aug. 19, 2013

Luca Marzolla wrote: > It is possible to fix this minor inconvenience in the next release? Yes. The problem should already be fixed in the experimental version, which you can get from Github, here: https://github.com/eggert/tz It's fixed in a different way, by the way: the Busingen link got moved to a different file. See: https://github.com/eggert/tz/commit/df99923bde035a263493f3435db63db15df14d53

1 0

Mushroom clowds are forming…
by Steffen Daode Nurpmeso Aug. 17, 2013

Aug. 17, 2013

So if there is a button, someone surely is going to press it. --steffen

1 0

[PATCH] * date.c (nondigit): Add ATTRIBUTE_PURE, to pacify GCC 4.8.1.
by Paul Eggert Aug. 16, 2013

Aug. 16, 2013

--- date.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/date.c b/date.c index 4355a7b..d8ff50e 100644 --- a/date.c +++ b/date.c @@ -497,7 +497,7 @@ errensure(void) retval = EXIT_FAILURE; } -static const char * +static const char * ATTRIBUTE_PURE nondigit(register const char *cp) { while (is_digit(*cp)) -- 1.7.11.7

1 0

[PATCH] * zdump.c: Minor integer-size porting fixes.
by Paul Eggert Aug. 16, 2013

Aug. 16, 2013

(main): Don't assume SECSPERDAY <= INT_MAX here, since we try not to assume that sort of thing elsewhere in this file. Don't rely on undefined behavior in the weird case where cuthitime < absolute_min_time + SECSPERDAY / 2. --- zdump.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/zdump.c b/zdump.c index fa5f8d8..3d5ec64 100644 --- a/zdump.c +++ b/zdump.c @@ -452,7 +452,7 @@ main(int argc, char *argv[]) t = absolute_min_time; if (!Vflag) { show(argv[i], t, TRUE); - t += SECSPERHOUR * HOURSPERDAY; + t += SECSPERDAY; show(argv[i], t, TRUE); } if (t < cutlotime) @@ -463,9 +463,11 @@ main(int argc, char *argv[]) (void) strncpy(buf, abbr(&tm), (sizeof buf) - 1); } for ( ; ; ) { - if (t >= cuthitime || t >= cuthitime - SECSPERHOUR * 12) + newt = (t < absolute_max_time - SECSPERDAY / 2 + ? t + SECSPERDAY / 2 + : absolute_max_time); + if (cuthitime <= newt) break; - newt = t + SECSPERHOUR * 12; newtmp = localtime(&newt); if (newtmp != NULL) newtm = *newtmp; @@ -488,9 +490,9 @@ main(int argc, char *argv[]) } if (!Vflag) { t = absolute_max_time; - t -= SECSPERHOUR * HOURSPERDAY; + t -= SECSPERDAY; show(argv[i], t, TRUE); - t += SECSPERHOUR * HOURSPERDAY; + t += SECSPERDAY; show(argv[i], t, TRUE); } } -- 1.7.11.7

1 0

[PATCH] * zdump.c: Tune performance of -c with large numbers on 64-bit hosts.
by Paul Eggert Aug. 15, 2013

Aug. 15, 2013

On my platform (Ubuntu 13.04 x86-64, Xeon E3-1225 V2), this sped up 'zdump -V -c 2147483647,2147483648 America/Los_Angeles' from 13.880 to 0.000 seconds user+system time. (INTMAX_MAX): Define if the system doesn't. (SECSPER400YEARS): New macro. (SECSPER400YEARS_FITS): New constant. (yeartot): Speed up by using division instead of repeated subtraction. --- zdump.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 17 deletions(-) diff --git a/zdump.c b/zdump.c index 788020a..36c1838 100644 --- a/zdump.c +++ b/zdump.c @@ -60,9 +60,15 @@ typedef int int_fast32_t; # if defined LLONG_MAX || defined __LONG_LONG_MAX__ typedef long long intmax_t; # define PRIdMAX "lld" +# ifdef LLONG_MAX +# define INTMAX_MAX LLONG_MAX +# else +# define INTMAX_MAX __LONG_LONG_MAX__ +# endif # else typedef long intmax_t; # define PRIdMAX "ld" +# define INTMAX_MAX LONG_MAX # endif #endif #ifndef SCNdMAX @@ -140,6 +146,17 @@ typedef long intmax_t; #define SECSPERDAY ((int_fast32_t) SECSPERHOUR * HOURSPERDAY) #define SECSPERNYEAR (SECSPERDAY * DAYSPERNYEAR) #define SECSPERLYEAR (SECSPERNYEAR + SECSPERDAY) +#define SECSPER400YEARS (SECSPERNYEAR * (intmax_t) (300 + 3) \ + + SECSPERLYEAR * (intmax_t) (100 - 3)) + +/* +** True if SECSPER400YEARS is known to be representable as an +** intmax_t. It's OK that SECSPER400YEARS_FITS can in theory be false +** even if SECSPER400YEARS is representable, because when that happens +** the code merely runs a bit more slowly, and this slowness doesn't +** occur on any practical platform. +*/ +enum { SECSPER400YEARS_FITS = SECSPERLYEAR <= INTMAX_MAX / 400 }; #ifndef HAVE_GETTEXT #define HAVE_GETTEXT 0 @@ -490,30 +507,42 @@ main(int argc, char *argv[]) static time_t yeartot(const intmax_t y) { - register intmax_t myy; - register int_fast32_t seconds; + register intmax_t myy, seconds, years; register time_t t; myy = EPOCH_YEAR; t = 0; - while (myy != y) { - if (myy < y) { + while (myy < y) { + if (SECSPER400YEARS_FITS && 400 <= y - myy) { + intmax_t diff400 = (y - myy) / 400; + if (INTMAX_MAX / SECSPER400YEARS < diff400) + return absolute_max_time; + seconds = diff400 * SECSPER400YEARS; + years = diff400 * 400; + } else { seconds = isleap(myy) ? SECSPERLYEAR : SECSPERNYEAR; - ++myy; - if (t > absolute_max_time - seconds) { - t = absolute_max_time; - break; - } - t += seconds; + years = 1; + } + myy += years; + if (t > absolute_max_time - seconds) + return absolute_max_time; + t += seconds; + } + while (y < myy) { + if (SECSPER400YEARS_FITS && y + 400 <= myy && myy < 0) { + intmax_t diff400 = (myy - y) / 400; + if (INTMAX_MAX / SECSPER400YEARS < diff400) + return absolute_min_time; + seconds = diff400 * SECSPER400YEARS; + years = diff400 * 400; } else { - --myy; - seconds = isleap(myy) ? SECSPERLYEAR : SECSPERNYEAR; - if (t < absolute_min_time + seconds) { - t = absolute_min_time; - break; - } - t -= seconds; + seconds = isleap(myy - 1) ? SECSPERLYEAR : SECSPERNYEAR; + years = 1; } + myy -= years; + if (t < absolute_min_time + seconds) + return absolute_min_time; + t -= seconds; } return t; } -- 1.8.1.2

2 2

[PATCH 1/4] * date.c: Pacify GCC 4.7.3.
by Paul Eggert Aug. 15, 2013

Aug. 15, 2013

(atof, getlogin, mktime, strchr, time, strftime): Remove old-style declarations. GCC 4.7.3 warns about them, and they aren't needed nowadays anyway. (main) [HAVE_SETTIMEOFDAY != 2]: "Use" dsttime and minuteswest to pacify GCC 4.7.3. --- date.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/date.c b/date.c index 047969f..bae90f3 100644 --- a/date.c +++ b/date.c @@ -54,14 +54,9 @@ static char sccsid[] = "@(#)date.c 4.23 (Berkeley) 9/20/88"; #define SECSPERMIN 60 #endif /* !defined SECSPERMIN */ -extern double atof(); extern char ** environ; -extern char * getlogin(); -extern time_t mktime(); extern char * optarg; extern int optind; -extern char * strchr(); -extern time_t time(); extern char * tzname[2]; static int retval = EXIT_SUCCESS; @@ -270,6 +265,8 @@ _("date: error: multiple values in command line\n")); oops("settimeofday"); #endif /* HAVE_SETTIMEOFDAY == 2 */ #if HAVE_SETTIMEOFDAY != 2 + (void) dsttime; + (void) minuteswest; (void) fprintf(stderr, _("date: warning: kernel doesn't keep -d/-t information, option ignored\n")); #endif /* HAVE_SETTIMEOFDAY != 2 */ @@ -543,8 +540,6 @@ display(const char *const format) exit(retval); } -extern size_t strftime(); - #define INCR 1024 static void -- 1.8.1.2

15 32

[PATCH 1/2] * .gitignore: Add 'leapseconds'.
by Paul Eggert Aug. 14, 2013

Aug. 14, 2013

This follows up on the previous change, since 'leapseconds' is now generated automatically. --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 5edf101..21c798d 100644 --- a/.gitignore +++ b/.gitignore @@ -4,6 +4,7 @@ *.txt *~ ChangeLog +leapseconds tzselect version.h yearistype -- 1.7.11.7

1 1

Re: [tz] Proposal regarding tz DB and leap second updates
by Paul Eggert Aug. 13, 2013

Aug. 13, 2013

Bradley White privately sent a Perl script to generate 'leapseconds' from the NIST leap-seconds.list file. Since we use POSIX Awk for the other processing it's probably better to use Awk here, too, so here's a proposed patch with all the Makefile bells and whistles, which I pushed to the experimental github repository. The patch removes the file 'leapseconds' from the repository because it's now generated automatically. I took the liberty of removing the copy of the IERS announcement from the generated 'leapseconds' since its copyright status was unclear. The NIST leap-seconds.list file is public domain, so it's OK for us to redistribute it. >From 459b72d3edec98488e5132d4473c4678b4ed5a73 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert(a)cs.ucla.edu> Date: Mon, 12 Aug 2013 23:58:29 -0700 Subject: [PATCH] Generate the 'leapseconds' file automatically from leap-seconds.list. * leap-seconds.list: New file, copied from the NIST. * leapseconds: Remove from git; it's now generated. * leapseconds.awk: New file. * Makefile (DATA): Add leap-seconds.list. Remove leapseconds. (MISC): Add leapseconds.awk. (leapseconds): New rule. (right_posix, posix_right): Depend on leapseconds. (clean_misc): Remove leapseconds. --- Makefile | 14 ++-- leap-seconds.list | 231 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ leapseconds | 100 ----------------------- leapseconds.awk | 68 ++++++++++++++++ 4 files changed, 308 insertions(+), 105 deletions(-) create mode 100644 leap-seconds.list delete mode 100644 leapseconds create mode 100644 leapseconds.awk diff --git a/Makefile b/Makefile index db7f56e..68d7132 100644 --- a/Makefile +++ b/Makefile @@ -318,10 +318,11 @@ NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab -DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) leapseconds yearistype.sh +DATA= $(YDATA) $(NDATA) $(SDATA) $(TABDATA) \ + leap-seconds.list yearistype.sh WEB_PAGES= tz-art.htm tz-link.htm MISC= usno1988 usno1989 usno1989a usno1995 usno1997 usno1998 \ - $(WEB_PAGES) checktab.awk workman.sh \ + $(WEB_PAGES) checktab.awk leapseconds.awk workman.sh \ zoneinfo2tdf.pl ENCHILADA= $(COMMON) $(DOCS) $(SOURCES) $(DATA) $(MISC) @@ -375,6 +376,9 @@ yearistype: yearistype.sh cp yearistype.sh yearistype chmod +x yearistype +leapseconds: leapseconds.awk leap-seconds.list + $(AWK) -f leapseconds.awk leap-seconds.list >$@ + posix_only: zic $(TDATA) $(ZIC) -y $(YEARISTYPE) -d $(TZDIR) -L /dev/null $(TDATA) @@ -390,14 +394,14 @@ right_only: zic leapseconds $(TDATA) # Therefore, the other two directories are now siblings of $(TZDIR). # You must replace all of $(TZDIR) to switch from not using leap seconds # to using them, or vice versa. -right_posix: right_only +right_posix: right_only leapseconds rm -fr $(TZDIR)-leaps ln -s $(TZDIR_BASENAME) $(TZDIR)-leaps || \ $(ZIC) -y $(YEARISTYPE) \ -d $(TZDIR)-leaps -L leapseconds $(TDATA) $(ZIC) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) -posix_right: posix_only +posix_right: posix_only leapseconds rm -fr $(TZDIR)-posix ln -s $(TZDIR_BASENAME) $(TZDIR)-posix || \ $(ZIC) -y $(YEARISTYPE) \ @@ -440,7 +444,7 @@ check_web: $(WEB_PAGES) clean_misc: rm -f core *.o *.out \ - date tzselect version.h zdump zic yearistype + date leapseconds tzselect version.h zdump zic yearistype clean: clean_misc rm -f -r tzpublic diff --git a/leap-seconds.list b/leap-seconds.list new file mode 100644 index 0000000..7df3de6 --- /dev/null +++ b/leap-seconds.list @@ -0,0 +1,231 @@ +# +# In the following text, the symbol '#' introduces +# a comment, which continues from that symbol until +# the end of the line. A plain comment line has a +# whitespace character following the comment indicator. +# There are also special comment lines defined below. +# A special comment will always have a non-whitespace +# character in column 2. +# +# A blank line should be ignored. +# +# The following table shows the corrections that must +# be applied to compute International Atomic Time (TAI) +# from the Coordinated Universal Time (UTC) values that +# are transmitted by almost all time services. +# +# The first column shows an epoch as a number of seconds +# since 1900.0 and the second column shows the number of +# seconds that must be added to UTC to compute TAI for +# any timestamp at or after that epoch. The value on +# each line is valid from the indicated initial instant +# until the epoch given on the next one or indefinitely +# into the future if there is no next line. +# (The comment on each line shows the representation of +# the corresponding initial epoch in the usual +# day-month-year format. The epoch always begins at +# 00:00:00 UTC on the indicated day. See Note 5 below.) +# +# Important notes: +# +# 1. Coordinated Universal Time (UTC) is often referred to +# as Greenwich Mean Time (GMT). The GMT time scale is no +# longer used, and the use of GMT to designate UTC is +# discouraged. +# +# 2. The UTC time scale is realized by many national +# laboratories and timing centers. Each laboratory +# identifies its realization with its name: Thus +# UTC(NIST), UTC(USNO), etc. The differences among +# these different realizations are typically on the +# order of a few nanoseconds (i.e., 0.000 000 00x s) +# and can be ignored for many purposes. These differences +# are tabulated in Circular T, which is published monthly +# by the International Bureau of Weights and Measures +# (BIPM). See www.bipm.fr for more information. +# +# 3. The current defintion of the relationship between UTC +# and TAI dates from 1 January 1972. A number of different +# time scales were in use before than epoch, and it can be +# quite difficult to compute precise timestamps and time +# intervals in those "prehistoric" days. For more information, +# consult: +# +# The Explanatory Supplement to the Astronomical +# Ephemeris. +# or +# Terry Quinn, "The BIPM and the Accurate Measurement +# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905, +# July, 1991. +# +# 4. The insertion of leap seconds into UTC is currently the +# responsibility of the International Earth Rotation Service, +# which is located at the Paris Observatory: +# +# Central Bureau of IERS +# 61, Avenue de l'Observatoire +# 75014 Paris, France. +# +# Leap seconds are announced by the IERS in its Bulletin C +# +# See hpiers.obspm.fr or www.iers.org for more details. +# +# All national laboratories and timing centers use the +# data from the BIPM and the IERS to construct their +# local realizations of UTC. +# +# Although the definition also includes the possibility +# of dropping seconds ("negative" leap seconds), this has +# never been done and is unlikely to be necessary in the +# foreseeable future. +# +# 5. If your system keeps time as the number of seconds since +# some epoch (e.g., NTP timestamps), then the algorithm for +# assigning a UTC time stamp to an event that happens during a positive +# leap second is not well defined. The official name of that leap +# second is 23:59:60, but there is no way of representing that time +# in these systems. +# Many systems of this type effectively stop the system clock for +# one second during the leap second and use a time that is equivalent +# to 23:59:59 UTC twice. For these systems, the corresponding TAI +# timestamp would be obtained by advancing to the next entry in the +# following table when the time equivalent to 23:59:59 UTC +# is used for the second time. Thus the leap second which +# occurred on 30 June 1972 at 23:59:59 UTC would have TAI +# timestamps computed as follows: +# +# ... +# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds +# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds +# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds +# ... +# +# If your system realizes the leap second by repeating 00:00:00 UTC twice +# (this is possible but not usual), then the advance to the next entry +# in the table must occur the second time that a time equivlent to +# 00:00:00 UTC is used. Thus, using the same example as above: +# +# ... +# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds +# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds +# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds +# ... +# +# in both cases the use of timestamps based on TAI produces a smooth +# time scale with no discontinuity in the time interval. +# +# This complexity would not be needed for negative leap seconds (if they +# are ever used). The UTC time would skip 23:59:59 and advance from +# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by +# 1 second at the same instant. This is a much easier situation to deal +# with, since the difficulty of unambiguously representing the epoch +# during the leap second does not arise. +# +# Questions or comments to: +# Judah Levine +# Time and Frequency Division +# NIST +# Boulder, Colorado +# jlevine(a)boulder.nist.gov +# +# Last Update of leap second values: 11 January 2012 +# +# The following line shows this last update date in NTP timestamp +# format. This is the date on which the most recent change to +# the leap second data was added to the file. This line can +# be identified by the unique pair of characters in the first two +# columns as shown below. +# +#$ 3535228800 +# +# The NTP timestamps are in units of seconds since the NTP epoch, +# which is 1900.0. The Modified Julian Day number corresponding +# to the NTP time stamp, X, can be computed as +# +# X/86400 + 15020 +# +# where the first term converts seconds to days and the second +# term adds the MJD corresponding to 1900.0. The integer portion +# of the result is the integer MJD for that day, and any remainder +# is the time of day, expressed as the fraction of the day since 0 +# hours UTC. The conversion from day fraction to seconds or to +# hours, minutes, and seconds may involve rounding or truncation, +# depending on the method used in the computation. +# +# The data in this file will be updated periodically as new leap +# seconds are announced. In addition to being entered on the line +# above, the update time (in NTP format) will be added to the basic +# file name leap-seconds to form the name leap-seconds.<NTP TIME>. +# In addition, the generic name leap-seconds.list will always point to +# the most recent version of the file. +# +# This update procedure will be performed only when a new leap second +# is announced. +# +# The following entry specifies the expiration date of the data +# in this file in units of seconds since 1900.0. This expiration date +# will be changed at least twice per year whether or not a new leap +# second is announced. These semi-annual changes will be made no +# later than 1 June and 1 December of each year to indicate what +# action (if any) is to be taken on 30 June and 31 December, +# respectively. (These are the customary effective dates for new +# leap seconds.) This expiration date will be identified by a +# unique pair of characters in columns 1 and 2 as shown below. +# In the unlikely event that a leap second is announced with an +# effective date other than 30 June or 31 December, then this +# file will be edited to include that leap second as soon as it is +# announced or at least one month before the effective date +# (whichever is later). +# If an announcement by the IERS specifies that no leap second is +# scheduled, then only the expiration date of the file will +# be advanced to show that the information in the file is still +# current -- the update time stamp, the data and the name of the file +# will not change. +# +# Updated through IERS Bulletin C46 +# File expires on: 28 June 2014 +# +#@ 3612902400 +# +2272060800 10 # 1 Jan 1972 +2287785600 11 # 1 Jul 1972 +2303683200 12 # 1 Jan 1973 +2335219200 13 # 1 Jan 1974 +2366755200 14 # 1 Jan 1975 +2398291200 15 # 1 Jan 1976 +2429913600 16 # 1 Jan 1977 +2461449600 17 # 1 Jan 1978 +2492985600 18 # 1 Jan 1979 +2524521600 19 # 1 Jan 1980 +2571782400 20 # 1 Jul 1981 +2603318400 21 # 1 Jul 1982 +2634854400 22 # 1 Jul 1983 +2698012800 23 # 1 Jul 1985 +2776982400 24 # 1 Jan 1988 +2840140800 25 # 1 Jan 1990 +2871676800 26 # 1 Jan 1991 +2918937600 27 # 1 Jul 1992 +2950473600 28 # 1 Jul 1993 +2982009600 29 # 1 Jul 1994 +3029443200 30 # 1 Jan 1996 +3076704000 31 # 1 Jul 1997 +3124137600 32 # 1 Jan 1999 +3345062400 33 # 1 Jan 2006 +3439756800 34 # 1 Jan 2009 +3550089600 35 # 1 Jul 2012 +# +# the following special comment contains the +# hash value of the data in this file computed +# use the secure hash algorithm as specified +# by FIPS 180-1. See the files in ~/pub/sha for +# the details of how this hash value is +# computed. Note that the hash computation +# ignores comments and whitespace characters +# in data lines. It includes the NTP values +# of both the last modification time and the +# expiration time of the file, but not the +# white space on those lines. +# the hash line is also ignored in the +# computation. +# +#h 1151a8f e85a5069 9000fcdb 3d5e5365 1d505b37 diff --git a/leapseconds b/leapseconds deleted file mode 100644 index 5b5c70e..0000000 --- a/leapseconds +++ /dev/null @@ -1,100 +0,0 @@ -# <pre> -# This file is in the public domain, so clarified as of -# 2009-05-17 by Arthur David Olson. - -# Allowance for leapseconds added to each timezone file. - -# The International Earth Rotation Service periodically uses leap seconds -# to keep UTC to within 0.9 s of UT1 -# (which measures the true angular orientation of the earth in space); see -# Terry J Quinn, The BIPM and the accurate measure of time, -# Proc IEEE 79, 7 (July 1991), 894-905. -# There were no leap seconds before 1972, because the official mechanism -# accounting for the discrepancy between atomic time and the earth's rotation -# did not exist until the early 1970s. - -# The correction (+ or -) is made at the given time, so lines -# will typically look like: -# Leap YEAR MON DAY 23:59:60 + R/S -# or -# Leap YEAR MON DAY 23:59:59 - R/S - -# If the leapsecond is Rolling (R) the given time is local time -# If the leapsecond is Stationary (S) the given time is UTC - -# Leap YEAR MONTH DAY HH:MM:SS CORR R/S -Leap 1972 Jun 30 23:59:60 + S -Leap 1972 Dec 31 23:59:60 + S -Leap 1973 Dec 31 23:59:60 + S -Leap 1974 Dec 31 23:59:60 + S -Leap 1975 Dec 31 23:59:60 + S -Leap 1976 Dec 31 23:59:60 + S -Leap 1977 Dec 31 23:59:60 + S -Leap 1978 Dec 31 23:59:60 + S -Leap 1979 Dec 31 23:59:60 + S -Leap 1981 Jun 30 23:59:60 + S -Leap 1982 Jun 30 23:59:60 + S -Leap 1983 Jun 30 23:59:60 + S -Leap 1985 Jun 30 23:59:60 + S -Leap 1987 Dec 31 23:59:60 + S -Leap 1989 Dec 31 23:59:60 + S -Leap 1990 Dec 31 23:59:60 + S -Leap 1992 Jun 30 23:59:60 + S -Leap 1993 Jun 30 23:59:60 + S -Leap 1994 Jun 30 23:59:60 + S -Leap 1995 Dec 31 23:59:60 + S -Leap 1997 Jun 30 23:59:60 + S -Leap 1998 Dec 31 23:59:60 + S -Leap 2005 Dec 31 23:59:60 + S -Leap 2008 Dec 31 23:59:60 + S -Leap 2012 Jun 30 23:59:60 + S - -# INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) -# -# SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE -# -# -# SERVICE DE LA ROTATION TERRESTRE -# OBSERVATOIRE DE PARIS -# 61, Av. de l'Observatoire 75014 PARIS (France) -# Tel. : 33 (0) 1 40 51 22 26 -# FAX : 33 (0) 1 40 51 22 91 -# e-mail : (E-Mail Removed) -# http://hpiers.obspm.fr/eop-pc -# -# Paris, 5 January 2012 -# -# -# Bulletin C 43 -# -# To authorities responsible -# for the measurement and -# distribution of time -# -# -# UTC TIME STEP -# on the 1st of July 2012 -# -# -# A positive leap second will be introduced at the end of June 2012. -# The sequence of dates of the UTC second markers will be: -# -# 2012 June 30, 23h 59m 59s -# 2012 June 30, 23h 59m 60s -# 2012 July 1, 0h 0m 0s -# -# The difference between UTC and the International Atomic Time TAI is: -# -# from 2009 January 1, 0h UTC, to 2012 July 1 0h UTC : UTC-TAI = - 34s -# from 2012 July 1, 0h UTC, until further notice : UTC-TAI = - 35s -# -# Leap seconds can be introduced in UTC at the end of the months of December -# or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every -# six months, either to announce a time step in UTC or to confirm that there -# will be no time step at the next possible date. -# -# -# Daniel GAMBIS -# Head -# Earth Orientation Center of IERS -# Observatoire de Paris, France diff --git a/leapseconds.awk b/leapseconds.awk new file mode 100644 index 0000000..732db99 --- /dev/null +++ b/leapseconds.awk @@ -0,0 +1,68 @@ +# Generate the 'leapseconds' file from 'leap-seconds.list'. + +# This file is in the public domain. + +BEGIN { + printf "%s", "\ +# Allowance for leapseconds added to each timezone file.\n\ +\n\ +# This file is in the public domain.\n\ +\n\ +# This file is generated automatically from the data in the public-domain\n\ +# leap-seconds.list file available from most NIST time servers.\n\ +# If the URL <ftp://time.nist.gov/pub/leap-seconds.list> does not work,\n\ +# you should be able to pick up leap-seconds.list from a secondary NIST server.\n\ +# For more about leap-seconds.list, please see\n\ +# The NTP Timescale and Leap Seconds\n\ +# <http://www.eecis.udel.edu/~mills/leap.html>.\n\ +\n\ +# The International Earth Rotation Service periodically uses leap seconds\n\ +# to keep UTC to within 0.9 s of UT1\n\ +# (which measures the true angular orientation of the earth in space); see\n\ +# Terry J Quinn, The BIPM and the accurate measure of time,\n\ +# Proc IEEE 79, 7 (July 1991), 894-905 <http://dx.doi.org/10.1109/5.84965>.\n\ +# There were no leap seconds before 1972, because the official mechanism\n\ +# accounting for the discrepancy between atomic time and the earth's rotation\n\ +# did not exist until the early 1970s.\n\ +\n\ +# The correction (+ or -) is made at the given time, so lines\n\ +# will typically look like:\n\ +# Leap YEAR MON DAY 23:59:60 + R/S\n\ +# or\n\ +# Leap YEAR MON DAY 23:59:59 - R/S\n\ +\n\ +# If the leapsecond is Rolling (R) the given time is local time.\n\ +# If the leapsecond is Stationary (S) the given time is UTC.\n\ +\n\ +# Leap YEAR MONTH DAY HH:MM:SS CORR R/S\n\ +" +} + +/^ *$/ { next } +/^#/ { next } + +{ + NTP_timestamp = $1 + TAI_minus_UTC = $2 + hash_mark = $3 + one = $4 + month = $5 + year = $6 + if (old_TAI_minus_UTC) { + if (old_TAI_minus_UTC < TAI_minus_UTC) { + sign = "23:59:60\t+" + } else { + sign = "23:59:59\t-" + } + if (month == "Jan") { + year--; + month = "Dec"; + day = 31 + } else if (month == "Jul") { + month = "Jun"; + day = 30 + } + printf "Leap\t%s\t%s\t%s\t%s\tS\n", year, month, day, sign + } + old_TAI_minus_UTC = TAI_minus_UTC +} -- 1.8.1.2

2 1

Proposal regarding tz DB and leap second updates
by Martin Burnicki Aug. 12, 2013

Aug. 12, 2013

Hi everybody, here are some thoughts about ways to make timekeeping simpler, especially with regards to DST, and leap seconds. Some time ago there was a discussion on the tz mailing list about frequently changing DST dates in Morocco, and that the Moroc government determines the beginning and end of DST only a very short period before the changes are to come into effect. A major problem is the short time period admins have available to deploy tz data base updates to machines in a mixed environment e.g. consisting of several Unix flavors, and Windows systems. I know Windows systems don't use the tz DB directly, but unlike older Windows version which could only provide DST information for the current year, current Windows version can at least provide DST settings for several years in their registry, and I could imagine some MS engineer has written a script which generates those registry settings from the tz DB. ;-) Updates of those registry settings are usually deployed as Windows patches. AFAIK even for Unix systems the tz DB updates are usually deployed as software updates, e.g. updated .rpm or .deb packages for Linux. So whenever there's a change in the DST specs for some country, a server admin responsible for different types of machines has to wait until all manufacturers or distributors of all the OS types and versions he is running on his machines have become aware of a tz DB update, and have provided software update packages for all their systems, before all machines can be updated consistently, each system type using its own update procedure. This may not be a big deal for users in the United States, or in Europe, where DST rules are changing only very rarely. If you don't install tz database updates then there's a good chance everything keeps working fine since no DST rules have changed. However, for people in Morocco, or Israel, or some other countries it seems to be quite a challenge to keep everything up to date, if there are changes once every year. We at Meinberg are manufacturing NTP time servers, and there are often requests from customers to use NTP to send local time to the clients. Of course this is no reliable solution and caused many sorts of other problems which are not obvious at the first glance. However, this shows the importance for a way to simplify tz DB updates. My proposal is to use some sort of network protocol to deploy the contents of the tz DB, either for a single time zone used on a system, or even for all time zones supported by the tz database. In my opinion this is similar to DNS or DHCP, or even NTP services. So a machine could simply run a TZ client daemon which periodically contacts a TZ server to check if there is an update available, and download the updated data if this is the case. A mechanism like the serial numbers used for DNS zone transfers could be used to do this. Of course the tz information must be deployed in a secure way, but this is a common requirement for all kind of network services today, using crypto mechanisms, etc. This would also simplify the update of tz data in embedded systems which often don't see any software updates anymore after they have been put into operation. Another important thing which could be implemented in the same protocol is handling of leap second information. I don't want to restart the discussion whether leap seconds are useful and required, or not, but the following suggestions can help to simplify handling of future leap seconds, if they should occur, and they don't hurt but help to handle historic leap seconds, if required to evaluate archived data, etc. Actually the NIST provides a leap second file providing current and historic leap second information. This file can directly be handled and evaluated by the standard NTP daemon. There are plans to implement this also in the open source PTP daemon, since PTP by default uses TAI for the timestamps in the network packets, and a leap second file is a good resource to convert between TAI and UTC. I know the tz DB also includes a leap second file, which is used for the "right" timezones. As far as I know this file provides similar information as the NIST file but has a slightly different format. My proposal is to change the TZ code and DB in a first step so that they also use the NIST leap second file format. I'm not aware of any operating system which uses the "right" timezones by default now, but as far as I can see such modification can be done consistently and transparently for the users, since both the tz code and the file can be updated consistently. So there should be no problems for folks who use the "right" timezones. Many types of hardware refclocks used to set up stratum-1 NTP servers don't provide the NTP daemon with leap second warnings, so those NTP servers often have to rely on a leap second file which needs to be updated if a leap second has been scheduled. Usually there are about 6 months time to do so. Also future versions of the PTP daemon will have this requirement. So if the same leap second file format was used for all applications then the same file could be shared, and for now, it could be updated within any tz database update. If in the future there should be a network protocol which could be used to deploy tz updates, then the same protocol could also be used to update the leap second file, if required, and life could become much easier for many admins. ;-) Any comments are welcome. [I'm also going to send this to the leapsecond mailing list, even though some folks may be subscribed on both lists] Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany

6 5

[PATCH] Remove attempt to support floating-point time_t.
by Paul Eggert Aug. 12, 2013

Aug. 12, 2013

Here's a proposed patch to remove the tz code's attempt to support floating-point time_t. This has the benefit of simplifying the code and making maintenance easier. Comments welcome (particularly if you know of any real systems that have floating-point time_t!). I've pushed this to the experimental github repository. ----- It wasn't tested and probably never worked, no platform used it, and the latest POSIX no longer allows it. * Makefile (typecheck): Don't check time_t being 'double'. * Theory: Document the change. * difftime.c (difftime): * localtime.c (differ_by_repeat, tzload, timesub, time2sub): * private.h (time_t_min, time_t_max): * zdump.c (absolute_min_time, absolute_max_time, tformat): Don't try to support floating-point time_t. * localtime.c, private.h, zdump.c: Don't include float.h. * localtime.c (truncate_time, double_to_time): * private.h (TYPE_INTEGRAL): * zdump.c (checkabsolutes): Remove; no longer needed. All uses removed. * zdump.8 (LIMITATIONS): Remove discussion of floating-point time_t. --- Makefile | 3 +-- Theory | 9 ++++----- difftime.c | 10 +--------- localtime.c | 62 ++++++------------------------------------------------------- private.h | 28 ++-------------------------- zdump.8 | 7 ------- zdump.c | 37 ++---------------------------------- 7 files changed, 16 insertions(+), 140 deletions(-) diff --git a/Makefile b/Makefile index 8b033a6..db7f56e 100644 --- a/Makefile +++ b/Makefile @@ -121,7 +121,6 @@ LDLIBS= # -DNO_RUN_TIME_WARNINGS_ABOUT_YEAR_2000_PROBLEMS_THANK_YOU=1 # if you do not want run time warnings about formats that may cause # year 2000 grief -# -DTIME_T_FLOATING=1 if your time_t (or time_tz) is floating point # -Dtime_tz=\"T\" to use T as the time_t type, rather than the system time_t # -DTZ_DOMAIN=\"foo\" to use "foo" for gettext domain name; default is "tz" # -TTZ_DOMAINDIR=\"/path\" to use "/path" for gettext directory; @@ -541,7 +540,7 @@ tzdata$(VERSION).tar.gz.asc: tzdata$(VERSION).tar.gz typecheck: make clean - for i in "long long" unsigned double; \ + for i in "long long" unsigned; \ do \ make CFLAGS="-DTYPECHECK -D__time_t_defined -D_TIME_T \"-Dtime_t=$$i\"" ; \ ./zdump -v Europe/Rome ; \ diff --git a/Theory b/Theory index 1b5374a..b4bd4c2 100644 --- a/Theory +++ b/Theory @@ -104,11 +104,10 @@ POSIX has the following properties and limitations. new implementations these days typically use a signed 64-bit integer. Unsigned 32-bit integers are used on one or two platforms, and 36-bit integers are also used occasionally. - Although POSIX.1-2013 requires time_t to be an integer type, - earlier POSIX versions also allowed time_t to be a floating-point type. - No known platforms have a floating-point time_t and although - the tz code attempts to support floating-point time_t this has not - been tested and will probably be removed at some point. + Although earlier POSIX versions allowed time_t to be a + floating-point type, this was not supported by any practical + systems, and POSIX.1-2013 and the tz code both require time_t + to be an integer type. These are the extensions that have been made to the POSIX functions: diff --git a/difftime.c b/difftime.c index fcd18ce..449cdf0 100644 --- a/difftime.c +++ b/difftime.c @@ -5,7 +5,7 @@ /*LINTLIBRARY*/ -#include "private.h" /* for time_t, TYPE_INTEGRAL, and TYPE_SIGNED */ +#include "private.h" /* for time_t and TYPE_SIGNED */ double ATTRIBUTE_CONST difftime(const time_t time1, const time_t time0) @@ -16,15 +16,8 @@ difftime(const time_t time1, const time_t time0) */ if (sizeof (double) > sizeof (time_t)) return (double) time1 - (double) time0; - if (!TYPE_INTEGRAL(time_t)) { - /* - ** time_t is floating. - */ - return time1 - time0; - } if (!TYPE_SIGNED(time_t)) { /* - ** time_t is integral and unsigned. ** The difference of two unsigned values can't overflow ** if the minuend is greater than or equal to the subtrahend. */ @@ -33,7 +26,6 @@ difftime(const time_t time1, const time_t time0) else return -(double) (time0 - time1); } /* - ** time_t is integral and signed. ** Handle cases where both time1 and time0 have the same sign ** (meaning that their difference cannot overflow). */ diff --git a/localtime.c b/localtime.c index 9600901..5312ad9 100644 --- a/localtime.c +++ b/localtime.c @@ -13,7 +13,6 @@ #include "private.h" #include "tzfile.h" #include "fcntl.h" -#include "float.h" /* for FLT_MAX and DBL_MAX */ #ifndef TZ_ABBR_MAX_LEN #define TZ_ABBR_MAX_LEN 16 @@ -318,9 +317,8 @@ settzname(void) static int differ_by_repeat(const time_t t1, const time_t t0) { - if (TYPE_INTEGRAL(time_t) && - TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) - return 0; + if (TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) + return 0; return t1 - t0 == SECSPERREPEAT; } @@ -527,9 +525,9 @@ tzload(register const char *name, register struct state *const sp, for (i = 0; i < nread; ++i) up->buf[i] = p[i]; /* - ** If this is a narrow integer time_t system, we're done. + ** If this is a narrow time_t system, we're done. */ - if (stored >= (int) sizeof(time_t) && TYPE_INTEGRAL(time_t)) + if (stored >= (int) sizeof(time_t)) break; } if (doextend && nread > 2 && @@ -1254,35 +1252,6 @@ tzset(void) settzname(); } -/* Return T with any fractional part discarded. */ -static time_t -truncate_time(time_t t) -{ - /* - ** If time_t is floating-point, convert it to integer and - ** back; this discards the fraction. Avoid using <math.h> - ** functions, as we don't want to depend on <math.h>. Use <, - ** not <=, when comparing against *_MIN and *_MAX values, as - ** this avoids undefined behavior when, for example, - ** INTMAX_MAX is converted to a larger time_t value before it - ** is compared. - ** - ** On all platforms that we know of (1) it is safe to compare - ** INTMAX_MIN and INTMAX_MAX to floating-point values without - ** worrying about undefined behavior due to floating-point - ** overflow on conversion, and (2) any time_t value outside - ** intmax_t range is an integer so we can simply return it. - ** We know of no simple, portable way to check these assumptions. - ** If you know of a counterexample platform, please report a bug. - */ - if (!TYPE_INTEGRAL(time_t) && INTMAX_MIN < t && t < INTMAX_MAX) { - intmax_t i = t; - return i; - } - - return t; -} - /* ** The easy way to behave "as if no library function calls" localtime ** is to not call it--so we drop its guts into "localsub", which can be @@ -1318,8 +1287,7 @@ localsub(const time_t *const timep, const int_fast32_t offset, seconds = sp->ats[0] - t; else seconds = t - sp->ats[sp->timecnt - 1]; --seconds; - years = (truncate_time (seconds / SECSPERREPEAT + 1) - * YEARSPERREPEAT); + years = (seconds / SECSPERREPEAT + 1) * YEARSPERREPEAT; seconds = years * AVGSECSPERYEAR; if (t < sp->ats[0]) newt += seconds; @@ -1457,18 +1425,6 @@ offtime(const time_t *const timep, const long offset) #endif /* defined STD_INSPIRED */ /* -** Convert T to time_t, truncating toward zero if time_t is integral. -** On most platforms, double_to_time(0.5) returns 0; the exceptions are -** the rare platforms where time_t is floating. -*/ - -static time_t -double_to_time(double t) -{ - return t; -} - -/* ** Return the number of leap years through the end of the given year ** where, to make the math easy, the answer for year zero is defined as zero. */ @@ -1549,9 +1505,8 @@ timesub(const time_t *const timep, const int_fast32_t offset, } { register int_fast32_t seconds; - register time_t half_second = double_to_time(0.5); - seconds = tdays * SECSPERDAY + half_second; + seconds = tdays * SECSPERDAY; tdays = seconds / SECSPERDAY; rem += seconds - tdays * SECSPERDAY; } @@ -1811,11 +1766,6 @@ time2sub(struct tm *const tmp, if (!TYPE_SIGNED(time_t)) { lo = 0; hi = lo - 1; - } else if (!TYPE_INTEGRAL(time_t)) { - if (sizeof(time_t) > sizeof(float)) - hi = (time_t) DBL_MAX; - else hi = (time_t) FLT_MAX; - lo = -hi; } else { lo = 1; for (i = 0; i < (int) TYPE_BIT(time_t) - 1; ++i) diff --git a/private.h b/private.h index 5f4384e..8c1cda7 100644 --- a/private.h +++ b/private.h @@ -74,7 +74,6 @@ #include "sys/types.h" /* for time_t */ #include "stdio.h" #include "errno.h" -#include "float.h" /* for FLT_MAX and DBL_MAX */ #include "string.h" #include "limits.h" /* for CHAR_BIT et al. */ #include "time.h" @@ -318,37 +317,14 @@ const char * scheck(const char * string, const char * format); /* The minimum and maximum finite time values. */ static time_t const time_t_min = - ((time_t) 0.5 == 0.5 - ? (sizeof (time_t) == sizeof (float) ? (time_t) -FLT_MAX - : sizeof (time_t) == sizeof (double) ? (time_t) -DBL_MAX - : sizeof (time_t) == sizeof (long double) ? (time_t) -LDBL_MAX - : 0) -#ifndef TIME_T_FLOATING - : (time_t) -1 < 0 + (TYPE_SIGNED(time_t) ? (time_t) -1 << (CHAR_BIT * sizeof (time_t) - 1) -#endif : 0); static time_t const time_t_max = - ((time_t) 0.5 == 0.5 - ? (sizeof (time_t) == sizeof (float) ? (time_t) FLT_MAX - : sizeof (time_t) == sizeof (double) ? (time_t) DBL_MAX - : sizeof (time_t) == sizeof (long double) ? (time_t) LDBL_MAX - : -1) -#ifndef TIME_T_FLOATING - : (time_t) -1 < 0 + (TYPE_SIGNED(time_t) ? - (~ 0 < 0) - ((time_t) -1 << (CHAR_BIT * sizeof (time_t) - 1)) -#endif : -1); -/* -** Since the definition of TYPE_INTEGRAL contains floating point numbers, -** it cannot be used in preprocessor directives. -*/ - -#ifndef TYPE_INTEGRAL -#define TYPE_INTEGRAL(type) (((type) 0.5) != 0.5) -#endif /* !defined TYPE_INTEGRAL */ - #ifndef INT_STRLEN_MAXIMUM /* ** 302 / 1000 is log10(2.0) rounded up. diff --git a/zdump.8 b/zdump.8 index f253e81..af3277d 100644 --- a/zdump.8 +++ b/zdump.8 @@ -57,13 +57,6 @@ the program cuts off verbose output near the starts of the years \-500 and 2500. Cut off verbose output at the start of the given time(s), given in decimal seconds since 1970-01-01 00:00:00 UTC. .SH LIMITATIONS -The -.B \-v -and -.B \-V -options may not be used on systems with floating-point time_t values -that are neither float nor double. -.PP Time discontinuities are found by sampling the results returned by localtime at twelve-hour intervals. This works in all real-world cases; diff --git a/zdump.c b/zdump.c index be0a496..788020a 100644 --- a/zdump.c +++ b/zdump.c @@ -23,7 +23,6 @@ #include "sys/types.h" /* for time_t */ #include "time.h" /* for struct tm */ #include "stdlib.h" /* for exit, malloc, atoi */ -#include "float.h" /* for FLT_MAX and DBL_MAX */ #include "limits.h" /* for CHAR_BIT, LLONG_MAX */ #include "ctype.h" /* for isalpha et al. */ #ifndef isascii @@ -193,26 +192,12 @@ extern char * tzname[2]; /* The minimum and maximum finite time values. */ static time_t const absolute_min_time = - ((time_t) 0.5 == 0.5 - ? (sizeof (time_t) == sizeof (float) ? (time_t) -FLT_MAX - : sizeof (time_t) == sizeof (double) ? (time_t) -DBL_MAX - : sizeof (time_t) == sizeof (long double) ? (time_t) -LDBL_MAX - : 0) -#ifndef TIME_T_FLOATING - : (time_t) -1 < 0 + ((time_t) -1 < 0 ? (time_t) -1 << (CHAR_BIT * sizeof (time_t) - 1) -#endif : 0); static time_t const absolute_max_time = - ((time_t) 0.5 == 0.5 - ? (sizeof (time_t) == sizeof (float) ? (time_t) FLT_MAX - : sizeof (time_t) == sizeof (double) ? (time_t) DBL_MAX - : sizeof (time_t) == sizeof (long double) ? (time_t) LDBL_MAX - : -1) -#ifndef TIME_T_FLOATING - : (time_t) -1 < 0 + ((time_t) -1 < 0 ? - (~ 0 < 0) - ((time_t) -1 << (CHAR_BIT * sizeof (time_t) - 1)) -#endif : -1); static size_t longest; static char * progname; @@ -223,7 +208,6 @@ static void abbrok(const char * abbrp, const char * zone); static intmax_t delta(struct tm * newp, struct tm * oldp) ATTRIBUTE_PURE; static void dumptime(const struct tm * tmp); static time_t hunt(char * name, time_t lot, time_t hit); -static void checkabsolutes(void); static void show(char * zone, time_t t, int v); static const char * tformat(void); static time_t yeartot(intmax_t y) ATTRIBUTE_PURE; @@ -383,7 +367,6 @@ main(int argc, char *argv[]) exit(EXIT_FAILURE); } } - checkabsolutes(); if (cutarg != NULL || cuttimes == NULL) { cutlotime = yeartot(cutloyear); cuthitime = yeartot(cuthiyear); @@ -504,17 +487,6 @@ main(int argc, char *argv[]) return EXIT_FAILURE; } -static void -checkabsolutes(void) -{ - if (absolute_max_time < absolute_min_time) { - (void) fprintf(stderr, -_("%s: use of -v on system with floating time_t other than float or double\n"), - progname); - exit(EXIT_FAILURE); - } -} - static time_t yeartot(const intmax_t y) { @@ -666,11 +638,6 @@ abbr(struct tm *tmp) static const char * tformat(void) { - if (0.5 == (time_t) 0.5) { /* floating */ - if (sizeof (time_t) > sizeof (double)) - return "%Lg"; - return "%g"; - } if (0 > (time_t) -1) { /* signed */ if (sizeof (time_t) == sizeof (intmax_t)) return "%"PRIdMAX; -- 1.8.1.2

1 0

[PATCH] Use symbolic links to deduplicate installed files.
by Paul Eggert Aug. 11, 2013

Aug. 11, 2013

* Makefile (TZDIR_BASENAME): New macro. (TZDIR): Use it. (other_two): Remove. (right_posix, posix_right): Use a symbolic link if supported. This saves about 2 megabytes' worth of installed files. --- Makefile | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 3659378..8b033a6 100644 --- a/Makefile +++ b/Makefile @@ -51,7 +51,8 @@ TOPDIR= /usr/local # (and subdirectories). # Use an absolute path name for TZDIR unless you're just testing the software. -TZDIR= $(TOPDIR)/etc/zoneinfo +TZDIR_BASENAME= zoneinfo +TZDIR= $(TOPDIR)/etc/$(TZDIR_BASENAME) # Types to try, as an alternative to time_t. int64_t should be first. TIME_T_ALTERNATIVES= int64_t int32_t uint32_t uint64_t @@ -390,15 +391,21 @@ right_only: zic leapseconds $(TDATA) # Therefore, the other two directories are now siblings of $(TZDIR). # You must replace all of $(TZDIR) to switch from not using leap seconds # to using them, or vice versa. -other_two: zic leapseconds $(TDATA) +right_posix: right_only + rm -fr $(TZDIR)-leaps + ln -s $(TZDIR_BASENAME) $(TZDIR)-leaps || \ + $(ZIC) -y $(YEARISTYPE) \ + -d $(TZDIR)-leaps -L leapseconds $(TDATA) $(ZIC) -y $(YEARISTYPE) -d $(TZDIR)-posix -L /dev/null $(TDATA) + +posix_right: posix_only + rm -fr $(TZDIR)-posix + ln -s $(TZDIR_BASENAME) $(TZDIR)-posix || \ + $(ZIC) -y $(YEARISTYPE) \ + -d $(TZDIR)-posix -L /dev/null $(TDATA) $(ZIC) -y $(YEARISTYPE) \ -d $(TZDIR)-leaps -L leapseconds $(TDATA) -posix_right: posix_only other_two - -right_posix: right_only other_two - zones: $(REDO) $(TZLIB): $(LIBOBJS) -- 1.8.1.2

1 0

[PATCH] Move McMurdo and South Pole to 'backward'.
by Paul Eggert Aug. 11, 2013

Aug. 11, 2013

This continues in the series of moving entries to 'backward' if they exist only because of obsolete tz rules about country codes. This change does not affect any time stamps after 1970. Unlike the previous change in this series, this one does affect time stamps before 1970, but that's OK as pre-1970 time stamps are out of scope for the tz database. * antarctica (Antarctica/McMurdo, Antarctica/South_Pole): Move to 'backward' and link to Pacific/Auckland. * backward: Move links here from 'antarctica'. * zone.tab: Coalesce McMurdo and South Pole, and add Scott Base to the description. --- antarctica | 18 ++++++------------ backward | 2 ++ zone.tab | 3 +-- 3 files changed, 9 insertions(+), 14 deletions(-) diff --git a/antarctica b/antarctica index 9bf2494..4cb7476 100644 --- a/antarctica +++ b/antarctica @@ -228,7 +228,8 @@ Zone Antarctica/Syowa 0 - zzz 1957 Jan 29 # Scott Island (never inhabited) # # year-round base -# Scott, Ross Island, since 1957-01, is like Antarctica/McMurdo. +# Scott Base, Ross Island, since 1957-01. +# See Pacific/Auckland. # # These rules for New Zealand are stolen from the `australasia' file. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S @@ -337,16 +338,11 @@ Zone Antarctica/Palmer 0 - zzz 1965 -4:00 ChileAQ CL%sT # # -# McMurdo, Ross Island, since 1955-12 -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/McMurdo 0 - zzz 1956 - 12:00 NZAQ NZ%sT -# -# Amundsen-Scott, South Pole, continuously occupied since 1956-11-20 +# McMurdo Station, Ross Island, since 1955-12 +# See Pacific/Auckland. # -# From Paul Eggert (1996-09-03): -# Normally it wouldn't have a separate entry, since it's like the -# larger Antarctica/McMurdo since 1970, but it's too famous to omit. +# Amundsen-Scott South Pole Station, continuously occupied since 1956-11-20 +# See Pacific/Auckland. # # From Chris Carrier (1996-06-27): # Siple, the first commander of the South Pole station, @@ -367,5 +363,3 @@ Zone Antarctica/McMurdo 0 - zzz 1956 # makes all of the clocks run fast. So every couple of days, # we have to go around and set them back 5 minutes or so. # Maybe if we let them run fast all of the time, we'd get to leave here sooner!! -# -Link Antarctica/McMurdo Antarctica/South_Pole diff --git a/backward b/backward index 791db0c..c8c184e 100644 --- a/backward +++ b/backward @@ -27,6 +27,8 @@ Link America/Rio_Branco America/Porto_Acre Link America/Argentina/Cordoba America/Rosario Link America/Guadeloupe America/St_Barthelemy Link America/St_Thomas America/Virgin +Link Pacific/Auckland Antarctica/McMurdo +Link Pacific/Auckland Antarctica/South_Pole Link Europe/Oslo Arctic/Longyearbyen Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Kolkata Asia/Calcutta diff --git a/zone.tab b/zone.tab index a6146f7..d9f9e4b 100644 --- a/zone.tab +++ b/zone.tab @@ -45,8 +45,7 @@ AI +1812-06304 America/Anguilla AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan AO -0848+01314 Africa/Luanda -AQ -7750+16636 Antarctica/McMurdo McMurdo Station, Ross Island -AQ -9000+00000 Antarctica/South_Pole Amundsen-Scott Station, South Pole +AQ -7750+16636 Pacific/Auckland McMurdo, South Pole, Scott (New Zealand time) AQ -6734-06808 Antarctica/Rothera Rothera Station, Adelaide Island AQ -6448-06406 Antarctica/Palmer Palmer Station, Anvers Island AQ -6736+06253 Antarctica/Mawson Mawson Station, Holme Bay -- 1.8.1.2

1 0

[PATCH] Change Indonesian time zone names to reflect common practice.
by Paul Eggert Aug. 11, 2013

Aug. 11, 2013

Catching up on some old business, I've pushed this proposed patch to the experimental repository. Comments welcome. ----- * asia (Asia/Dili, Asia/Jakarta, Asia/Pontianak, Asia/Makassar) (Asia/Jayapura): Use WIB/WITA/WIT rather than WIT/CIT/EIT, since it's typical to use Indonesian-language abbreviations even when writing in English. I surveyed the Internet and Google Books and found several independent English-language sources using WIB/WITA/WIT, whereas it seemed only tz-inspired sources used WIT/CIT/EIT. Problem reported several times, by George Ziegler, Priyadi Iman Nurcahyo, Zakaria, Jason Grimes, Martin Pitt, and Benny Lin; see Lin's summary of the reports in <http://mm.icann.org/pipermail/tz/2013-February/018609.html>. This change does not affect time zone offsets, just alphabetic abbreviations, such as tm_zone in the BSD-style struct tm. (Asia/Jakarta): Use BMT, not JMT, for mean time from 1923 to 1932, as Jakarta was called Batavia back then. --- asia | 59 ++++++++++++++++++++++++++++++++++++++--------------------- 1 file changed, 38 insertions(+), 21 deletions(-) diff --git a/asia b/asia index 79cfc48..5a824f8 100644 --- a/asia +++ b/asia @@ -6,7 +6,7 @@ # go ahead and edit the file (and please send any changes to # tz(a)iana.org for general use in the future). -# From Paul Eggert (2013-02-21): +# From Paul Eggert (2013-08-11): # # A good source for time zone historical data outside the U.S. is # Thomas G. Shanks and Rique Pottenger, The International Atlas (6th edition), @@ -44,11 +44,11 @@ # 4:00 GST Gulf* # 5:30 IST India # 7:00 ICT Indochina* -# 7:00 WIT west Indonesia -# 8:00 CIT central Indonesia +# 7:00 WIB west Indonesia (Waktu Indonesia Barat) +# 8:00 WITA central Indonesia (Waktu Indonesia Tengah) # 8:00 CST China # 9:00 CJT Central Japanese Time (1896/1937)* -# 9:00 EIT east Indonesia +# 9:00 WIT east Indonesia (Waktu Indonesia Timur) # 9:00 JST JDT Japan # 9:00 KST KDT Korea # 9:30 CST (Australian) Central Standard Time @@ -756,7 +756,7 @@ Zone Asia/Dili 8:22:20 - LMT 1912 8:00 - TLT 1942 Feb 21 23:00 # E Timor Time 9:00 - JST 1945 Sep 23 9:00 - TLT 1976 May 3 - 8:00 - CIT 2000 Sep 17 00:00 + 8:00 - WITA 2000 Sep 17 00:00 9:00 - TLT # India @@ -793,36 +793,53 @@ Zone Asia/Kolkata 5:53:28 - LMT 1880 # Kolkata # (Hollandia). For now, assume all Indonesian locations other than Jayapura # switched on 1945-09-23. # +# From Paul Eggert (2013-08-11): +# Normally the tz database uses English-language abbreviations, but in +# Indonesia it's typical to use Indonesian-language abbreviations even +# when writing in English. For example, see the English-language +# summary published by the Time and Frequency Laboratory of the +# Research Center for Calibration, Instrumentation and Metrology, +# Indonesia, <http://time.kim.lipi.go.id/time-eng.php> (2006-09-29). +# The abbreviations are: +# +# WIB - UTC+7 - Waktu Indonesia Barat (Indonesia western time) +# WITA - UTC+8 - Waktu Indonesia Tengah (Indonesia central time) +# WIT - UTC+9 - Waktu Indonesia Timur (Indonesia eastern time) +# # Zone NAME GMTOFF RULES FORMAT [UNTIL] +# Java, Sumatra Zone Asia/Jakarta 7:07:12 - LMT 1867 Aug 10 # Shanks & Pottenger say the next transition was at 1924 Jan 1 0:13, # but this must be a typo. - 7:07:12 - JMT 1923 Dec 31 23:47:12 # Jakarta + 7:07:12 - BMT 1923 Dec 31 23:47:12 # Batavia 7:20 - JAVT 1932 Nov # Java Time - 7:30 - WIT 1942 Mar 23 + 7:30 - WIB 1942 Mar 23 9:00 - JST 1945 Sep 23 - 7:30 - WIT 1948 May - 8:00 - WIT 1950 May - 7:30 - WIT 1964 - 7:00 - WIT + 7:30 - WIB 1948 May + 8:00 - WIB 1950 May + 7:30 - WIB 1964 + 7:00 - WIB +# west and central Borneo Zone Asia/Pontianak 7:17:20 - LMT 1908 May 7:17:20 - PMT 1932 Nov # Pontianak MT - 7:30 - WIT 1942 Jan 29 + 7:30 - WIB 1942 Jan 29 9:00 - JST 1945 Sep 23 - 7:30 - WIT 1948 May - 8:00 - WIT 1950 May - 7:30 - WIT 1964 - 8:00 - CIT 1988 Jan 1 - 7:00 - WIT + 7:30 - WIB 1948 May + 8:00 - WIB 1950 May + 7:30 - WIB 1964 + 8:00 - WITA 1988 Jan 1 + 7:00 - WIB +# Sulawesi, Lesser Sundas, east and south Borneo Zone Asia/Makassar 7:57:36 - LMT 1920 7:57:36 - MMT 1932 Nov # Macassar MT - 8:00 - CIT 1942 Feb 9 + 8:00 - WITA 1942 Feb 9 9:00 - JST 1945 Sep 23 - 8:00 - CIT + 8:00 - WITA +# Maluku Islands, West Papua, Papua Zone Asia/Jayapura 9:22:48 - LMT 1932 Nov - 9:00 - EIT 1944 Sep 1 + 9:00 - WIT 1944 Sep 1 9:30 - CST 1964 - 9:00 - EIT + 9:00 - WIT # Iran -- 1.8.1.2

1 0

can struct definitions from localtime.c be moved to private.h ?
by Alois Treindl Aug. 8, 2013

Aug. 8, 2013

The source file localtime.c includes the definitions for structures used in the binary (compiled) zone files. I am writing code which accesses these compiled zone files. It would be most convenient to have the struct definitions moved from localtime.c to a header file, e.g. private.h which I can include in other code. struct ttinfo struct lsinfo struct state struct rule

2 2

source code question regarding localtime.c PS
by Alois Treindl Aug. 7, 2013

Aug. 7, 2013

In localtime.c, function localsub() are these three lines of code: 1295 icycles = tcycles; 1296 if (tcycles - icycles >= 1 || icycles - tcycles >= 1) 1297 return NULL; I do not understand the reason why lines 1296 and 1297 exist. icycles and tcycles are equal. Their difference is always zero. Why test for it being not zero? PS: the reason why I am asking: I try to understand the source code of zdump.c It calls localtime() frequently, and has some cryptic code which depends on whether localtime() returned NULL. Therefore, I try to understand the conditions under which localtime() returns NULL. If that would be documented somewhee (I may have overlooked it), it would be great, as it is rather hard to understand it out of the terse code.

6 10

source code question regarding localtime.c
by Alois Treindl Aug. 7, 2013

Aug. 7, 2013

In localtime.c, function localsub() are these three lines of code: 1295 icycles = tcycles; 1296 if (tcycles - icycles >= 1 || icycles - tcycles >= 1) 1297 return NULL; I do not understand the reason why lines 1296 and 1297 exist. icycles and tcycles are equal. Their difference is always zero. Why test for it being not zero?

1 0

Timezone in Suse?
by Donald MacQueen Aug. 1, 2013

Aug. 1, 2013

Does anyone know where the currently selected system time zone in stored on Suse? I thought it was in /etc/localtime, but apparently not. Perhaps I need to call a c routine and ask the system? Thanks in advance. -- Donald [|] Joel Cairo: "You always have a very smooth explanation." Sam Spade: "What do you want me to do? Learn to stutter?" - The Maltese Falcom

2 2

localtime.c issue
by Andy Heninger July 21, 2013

July 21, 2013

This compilation error from the localtime.c in 2013d looks like an actual problem. I think time_t is generally an integer type of some sort. Built using the clang compiler on Linux. localtime.c:1517:34: error: implicit conversion from 'double' to 'time_t' (aka 'long') changes value from 0.5 to 0 [-Werror,-Wliteral-conversion] register time_t half_second = 0.5; ~~~~~~~~~~~ ^~~ 1 error generated. Thanks, -- Andy Heninger

10 20

Re: [tz] tz Digest, Vol 22, Issue 13
by ruggety＠ovi.com July 20, 2013

July 20, 2013

Why the change? ---------- Sent from my Nokia phone ------Original message------ From: <tz-request(a)iana.org> To: <tz(a)iana.org> Date: Tuesday, July 16, 2013 12:00:03 PM GMT+0000 Subject: tz Digest, Vol 22, Issue 13 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..." Today's Topics: 1. Day length in the news (Arthur David Olson) 2. Saving electricity via horizontal time zones (Paul Eggert) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Jul 2013 16:42:33 -0400 From: Arthur David Olson <arthurdavidolson(a)gmail.com> To: "tz(a)iana.org" <tz(a)iana.org> Subject: [tz] Day length in the news Message-ID: <CAJvZEYkKfJOnvs=ZbaHv6sVCDa+kQ4fTFbF+aYe4DfCFOKgJBw(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" (Probably of marginal interest to most folks on the list.) >From the on-line Washington Post: "Stutters in Earth's spin changed length of days slightly" http://www.washingtonpost.com/national/health-science/stutters-in-earths-sp… The Post article stems from R. Holme & O. de Viron, "Characterization and implications of intradecadal variations in length of day," Nature 499, 202-204 (11 July 2013); http://www.nature.com/nature/journal/v499/n7457/full/nature12282.html (only abstract is available for free). --ado

1 0

Informing ICANN about IANA time zone database status of Jerusalem
by Tobias Conradi July 17, 2013

July 17, 2013

---------- Forwarded message ---------- From: ICANN <do-not-reply(a)icann.org> Date: Sat, May 4, 2013 at 7:34 PM Subject: Form submission confirmation To: ...(a)tobiasconradi.com This is a copy for your records: Submitted on 4 May 2013 Submitted by user: Submitted values are: First Name: Last Name: Email Address: ...(a)tobiasconradi.com Affiliation: Country of Current Residence: Germany Please Select a Category: General - for general questions and comments Subject: ICANN vs UN and international practice - Status of Jerusalem Message: ICANN puts Jerusalem as Israel territory. The issue has been posted to the IANA time zone mailing list, but the maintainer did not reply. http://mm.icann.org/pipermail/tz/2013-April/019134.html http://mm.icann.org/pipermail/tz/2013-May/019227.html -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

9 11

Re: [tz] Number of active tz regions?
by David Patte ₯ July 17, 2013

July 17, 2013

Thank you all. This is what I understood as well. On 2013-07-17 13:32, Tim Parenti wrote: > > On 17 July 2013 12:53, David Patte ₯ <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > Am I correct to say, that for every lat/lng there (theoretically) > exists a zone in that country and/or region that represents its > timezone rules since 1970; that if no tz zone exists in that > country and/or region that represents it clock rules since 1970 > correctly, that a new zone is to be created in tz for it? > > > In theory, yes, that is my understanding. Of course, in international > waters, the zone that "correctly" represents the local rules would be, > e.g., Etc/GMT-3, but in general, if an existing set of rules does not > properly cover a region (for all timepoints since 1970), a new zone is > to be created. > > On 17 July 2013 12:53, David Patte ₯ <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > I am looking at this from the perspective of timezone boundaries; > that tz boundaries (theoretically) don't change unless new tz > zones are created, or it is discovered that a latlng's clock > 'rules' since 1970 can be more accurately be described by a > different tz zone? > > > The tz project neither defines nor tracks zone boundaries; however, it > is sometimes helpful to think of zones in this manner. Obviously such > boundaries would change upon the creation of a new zone. You could > make the case that such boundaries would also change if it is > discovered at some point that location A better matches zone X than > zone Y, but as long as location A is not itself defined in zone.tab, > this does not affect tz data, and thus does not concern the tz project > beyond documenting appropriate commentary. > > -- > Tim Parenti --

1 0

Saving electricity via horizontal time zones
by Paul Eggert July 15, 2013

July 15, 2013

A recent paper by Felix Weinhardt of the Spatial Economics Research Centre of the London School of Economics and Political Science argues that daylight saving time increases electricity use in the northern part of the U.S., but decreases its use in the south. Weinhardt proposes horizontal time zones to ameliorate this, and estimates that their use would save the U.S. about 0.1% of its total GDP. Weinhardt F. The importance of time zone assignment: evidence from residential electricity consumption. SERC Discussion Paper 126 (January 2013). http://www.lse.ac.uk/GranthamInstitute/events/docs/The-importance-of-time-z…

1 0

Day length in the news
by Arthur David Olson July 15, 2013

July 15, 2013

(Probably of marginal interest to most folks on the list.) >From the on-line Washington Post: "Stutters in Earth's spin changed length of days slightly" http://www.washingtonpost.com/national/health-science/stutters-in-earths-sp… The Post article stems from R. Holme & O. de Viron, "Characterization and implications of intradecadal variations in length of day," Nature 499, 202-204 (11 July 2013); http://www.nature.com/nature/journal/v499/n7457/full/nature12282.html (only abstract is available for free). --ado

1 0

400-year-repeat edge cases
by Zefram July 14, 2013

July 14, 2013

The attached patch tweaks zic's explicit-400-years hack to better handle some edge cases. It's based on current github source. -zefram

1 0

re DST in Russia 2011
by Trevor North July 11, 2013

July 11, 2013

I note in the iana time zone database for Europe that it states the following # From Alexander Krivenyshev (2011-06-14): # According to Kremlin press service, Russian President Dmitry Medvedev # signed a federal law "On calculation of time" on June 9, 2011. # According to the law Russia is abolishing daylight saving time. # # Medvedev signed a law "On the Calculation of Time" (in russian): # <a href="http://bmockbe.ru/events/?ID=7583"> # http://bmockbe.ru/events/?ID=7583 # </a> # # Medvedev signed a law on the calculation of the time (in russian): # <a href="http://www.regnum.ru/news/polit/1413906.html"> # http://www.regnum.ru/news/polit/1413906.html # </a> # From Arthur David Olson (2011-06-15): # Take "abolishing daylight saving time" to mean that time is now considered # to be standard. Note that an Oracle Support document (reference Russia abandons DST in 2011 - Impact on Oracle RDBMS [ID 1335999.1]) relating to the change in Russia includes the following information Russian State Duma passed the third reading of the bill 509727-5 "On the Calculation of Time" (in Russia) and adopted a law abolishing the transition to daylight saving time. The old rule was to move back on last Sunday of October (30 October 2011) The Russian timezones will stay on the "summertime". For Questions/official statements about the DST change itself, please contact the Russian Government I think this is contrary to Mr Olsons assertion that abolishing now means standard. Regards Trevor ___________________________ Trevor North Oracle Retail Principal Consultant Sterling Endeavours Limited 128 Wilmington Close, Watford Hertfordshire, WD18 0FQ, UK Mobile (UK): +447773377050 Mobile (SE): +46702455040 Skype: twjnorth LinkedIn: <http://uk.linkedin.com/in/oracleretailconsultant/> uk.linkedin.com/in/oracleretailconsultant/ Oracle Retail Q&A: <http://www.linkedin.com/groups/Oracle-Retail-Q-4926078/about> http://www.linkedin.com/groups/Oracle-Retail-Q-4926078/about

6 6

IERS Bulletin C 46
by Garrett Wollman July 9, 2013

July 9, 2013

Yesterday, IERS issued a new Bulletin C, annoncing that no leap second will be introduced at the end of this year. Reference: http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat -GAWollman

1 0

Israel Daylight Saving Time -- Proposed Changes [2013 and beyond]
by Ephraim Silverberg July 9, 2013

July 9, 2013

The following is a translation of a news flash from a few minutes ago: The Minister of Interior, Gideon Saar, adopted the proposals of the committee he appointed last month to examine the daylight saving time regulations. Saar will publish a draft of a [new] law that will be brought before the government and the Knesset next month so that the new daylight saving time will start already this year and will continue for more than 200 days until the end of October. When details of the proposed draft law come to light, I will update the list. _____________________________________ Ephraim Silverberg, CSE System Group, Hebrew University, Jerusalem, Israel. Phone/Fax number: +972-2-5494521

2 5

Morocco DST Interruption
by Chandrashekhar Karmarkar July 8, 2013

July 8, 2013

The Moroccan government has recently announced that the country will return to standard time at 3:00 a.m. (03:00) on Sunday, July 7, 2013 local time. Clocks will be turned back one hour. DST will resume again at 2:00 a.m. (02:00) on Saturday, August 10, 2013, when one hour will be added again to the local time. The end and resumption of DST was originally planned to coincide with the beginning and end of Ramadan, which lasts from July 9 to August 8, 2013. Has IANA published these changes? Regards, Chandrashekhar Karmarkar Disclaimer: This email (including any attachments) is intended for the sole use of the recipient/s and may contain material that is CONFIDENTIAL. Any unauthorized disclosure / copying / distribution or forwarding of this message or part is STRICTLY PROHIBITED. If you have erroneously received this message, please delete it immediately and notify the sender. No liability is assumed for any errors and/or omissions in the contents of this message. Information in this message that does not relate to the official business of this Company shall be understood as neither given nor endorsed by it. If verification is required please request a hard-copy version. To know more about Accelya Kale Solutions Ltd, visit www.accelyakale.com

4 5

minor problem in www.iana.org
by Denis Excoffier July 8, 2013

July 8, 2013

Hello, The file http://www.iana.org/time-zones/repository/releases/tzcode2013c.tar.gz indicated in http://www.iana.org/time-zones as being of size 132.4kb is in fact in un-gzipped format and its size is 522240 bytes (i mean: this is the file i get when i wget the path). For the content of it, no problem. Same for tzdata. I suppose that this has been correct at the end of April, since my personal copy has the right format (and small size). Regards, Denis Excoffier.

5 6

morroco infos
by Sebastien WILLEMIJNS July 7, 2013

July 7, 2013

Hello, i think you know that but it can be useful (fr text) http://biladi.ma/1138865-retour-gmt-le-maroc-de-prepare-au-ramadan.html

1 0

tz-announce list is incorrectly configured
by Alan Barrett July 7, 2013

July 7, 2013

Once again, a message has appeared on the tz-announce list without also appearing on the tz list. In this case, it was an announcement that the 2013d releases of txcode and tzdata are available. Please could the tz-announce list be configured such that it is impossible for a message to go to tz-announce(a)iana.org without also going to tz(a)iana.org. tz-announce was always intended to carry a subset of the messages sent to the tz list, not to carry some disjoint or partially-overlapping set of messages. It's unreasonable to expect readers to subscribe to both lists in order to see all messages, and it's also unreasonable to expect people who send announcements to CC both lists to ensure that the tz list receives all messages. This really should be fixed at the mailing list server side. --apb (Alan Barrett)

2 2

[PATCH] Update link page.
by Paul Eggert July 3, 2013

July 3, 2013

* tz-link.htm: Add commentary section. Update URLs and titles. Add links to Firefox OS, Bill Seymour's intro, Jon Udell's appreciation, W3C's "Working with Time Zones". --- tz-link.htm | 41 ++++++++++++++++++++++++++++------------- 1 file changed, 28 insertions(+), 13 deletions(-) diff --git a/tz-link.htm b/tz-link.htm index 008946e..9eea060 100644 --- a/tz-link.htm +++ b/tz-link.htm @@ -8,7 +8,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"'> <meta name="DC.Creator" content="Eggert, Paul"> <meta name="DC.Contributor" content="Olson, Arthur David"> -<meta name="DC.Date" content="2013-05-10"> +<meta name="DC.Date" content="2013-07-03"> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time"> <meta name="DC.Identifier" @@ -31,8 +31,7 @@ href="http://en.wikipedia.org/wiki/Coordinated_Universal_Time"><abbr title="Coordinated Universal Time">UTC</abbr></a> offsets, and <a href="http://en.wikipedia.org/wiki/Daylight_saving">daylight-saving</a> rules. -This database (often called <code>zoneinfo</code> or <a -href="http://en.wikipedia.org/wiki/Tz_database"><code>tz</code></a>) +This database (often called <code>zoneinfo</code> or <code>tz</code>) is used by several implementations, including <a href="http://www.gnu.org/software/libc/">the @@ -40,6 +39,8 @@ including C Library</a> (used in <a href="http://www.linux.org/"><abbr>GNU</abbr>/Linux</a>), <a href="http://www.android.com/">Android</a>, +<a href="https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS">Firefox +OS</a>, <a href="http://www.freebsd.org/">FreeBSD</a>, <a href="http://netbsd.org/">NetBSD</a>, <a href="http://openbsd.org/">OpenBSD</a>, @@ -134,6 +135,17 @@ For Comments">RFC</abbr> 6557).</p> The Web has several other sources for time zone and daylight saving time data. Here are some links that may be of interest. </p> +<h2>Commentary on the <code>tz</code> database</h2> +<ul> +<li>The article +<a href="http://en.wikipedia.org/wiki/Tz_database">tz database</a> is +an encyclopedic summary.</li> +<li><a href="http://www.cstdbill.com/tzdb/tz-how-to.html">How to Read the +tz Database Source Files</a> explains the tz database format.</li> +<li><a href="http://blog.jonudell.net/2009/10/23/a-literary-appreciation-of-the-olsonzon…">A +literary appreciation of the Olson/Zoneinfo/tz database</a> comments on the +database's style.</li> +</ul> <h2>Web sites using recent versions of the <code>tz</code> database</h2> <p> These are listed roughly in ascending order of complexity and fanciness. @@ -176,8 +188,8 @@ href="http://calconnect.org/publications/icalendartimezoneproblemsandrecommendat TIMEZONE Problems and Recommendations</a> offers guidelines and recommendations for the use of VTIMEZONE and <code>tz</code>.</li> <li><a href="http://calconnect.org/dstlinks.shtml">Extended Daylight -Saving Time Links, Advisories and Changes</a> lists vendor material on recent -daylight saving time changes.</li> +Saving Time Links, Advisories and Changes</a> lists vendor material on 2007 +U.S. daylight saving time changes.</li> <li><a href="http://calconnect.org/publications/timezoneregistryandservicerecommendation…">Timezone Registry and Service Recommendations</a> discusses a @@ -235,16 +247,16 @@ contains a class <code>org.joda.time.tz.ZoneInfoCompiler</code> that compiles <code>tz</code> source into a Joda-specific binary format. Joda Time is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a href="http://pytz.sourceforge.net">PyTZ - Python Time -Zone Library</a> compiles <code>tz</code> source into +<li><a href="http://pytz.sourceforge.net">pytz - World Timezone +Definitions for Python</a> compiles <code>tz</code> source into <a href="http://python.org/">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license.</li> <li><a href="http://tzinfo.rubyforge.org/">TZInfo - Ruby Timezone Library</a> compiles <code>tz</code> source into -<a href="http://ruby-lang.org">Ruby</a>. +<a href="http://www.ruby-lang.org/en/">Ruby</a>. It is freely available under the <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> -<li>The <a href="http://chronos-st.org/">Chronos Date/Time +<li>The <a href="http://www.squeaksource.com/Chronos/">Chronos Date/Time Library</a> is a <a href="http://en.wikipedia.org/wiki/Smalltalk">Smalltalk</a> class library that compiles <code>tz</code> source into a time zone repository whose format @@ -331,7 +343,7 @@ time zone history atlases published in both <a href="http://astrocom.com/astrology-products/software/acs-atlas-software">computer</a> and book form (<a href="http://www.astrocom.com/astrology/books/american-atlas">one volume -for the USA</a>, and <a +for the U.S.</a>, and <a href="http://www.astrocom.com/astrology/books/international-atlas">one for other locations</a>) by <a href="http://astrocom.com/">Astro Computing Services</a>.</li> @@ -421,6 +433,9 @@ surveys the evolution of timekeeping.</li> <li><a href="http://webexhibits.org/daylightsaving/">About Daylight Saving Time - History, rationale, laws & dates</a> is an overall history of <abbr>DST</abbr>.</li> +<li><a href="http://www.w3.org/TR/timezone/">Working with Time Zones</a> +contains guidelines and best practices for software applications that +deal with civil time.</li> <li><a href="http://energy.ca.gov/daylightsaving.html">Saving Time, Saving Energy</a> discusses a primary justification for <abbr>DST</abbr>.</li> <li><a href="http://seizethedaylight.com/dst/">A Brief @@ -499,7 +514,7 @@ href="http://www.polyomino.org.uk/british-time/">History of legal time in Britain</a> discusses in detail the country with perhaps the best-documented history of clock adjustments. The National Physical Laboratory also maintains an <a -href="http://www.npl.co.uk/educate-explore/what-is-the-time/archive-of-summer-tim…">Archive +href="http://www.npl.co.uk/educate-explore/what-is-time/archive-of-summer-time-da…">Archive of Summer time dates</a>.</dd> </dl> <h2>Precision timekeeping</h2> @@ -578,8 +593,8 @@ contentious issue.</li> <h2>Time notation</h2> <ul> <li> -<a href="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">A Summary of -the International Standard Date and Time Notation</a> is a good +<a href="http://www.cl.cam.ac.uk/~mgk25/iso-time.html">A summary of +the international standard date and time notation</a> is a good summary of <a href="http://www.iso.org/iso/catalogue_detail?csnumber=40874"><abbr -- 1.8.1.2

1 0

[PATCH] Morocco 2013 DST transitions
by Andrew Paprocki July 2, 2013

July 2, 2013

I've attached a patch for the announced DST transitions to help speed things along. -Andrew

2 1

Morocco 2013 dates incorrect?
by Andrew Paprocki July 2, 2013

July 2, 2013

Currently I see these rules: Rule Morocco 2013 only - Jul 9 3:00 0 - Rule Morocco 2013 only - Aug 8 2:00 1:00 S I was just informed from the Casablanca Bourse that the exchange will return to standard time on July 7th and that Ramadan will start on July 9th or 10th. Are the current rules incorrectly assuming that return to standard time coincides with the start of Ramadan? Can anyone from Morocco confirm? Thanks, -Andrew

1 1

Time zone for Kosovo?
by Andy Heninger June 4, 2013

June 4, 2013

Are there plans to add a time zone for Kosovo? http://en.wikipedia.org/wiki/Republic_of_Kosovo An increasing number of organizations and countries are recognizing Kosovo as a country, and having a representative zone for it would be convenient. It looks like it would be Europe/Pristina, cloned from Europe/Belgrade Thanks, -- Andy

27 60

unsubscribe
by jeff＠rf-specialist.com June 1, 2013

June 1, 2013

Best regards, Jeff Pison 770-776-8563 jeff(a)rf-specialist.com This electronic message is intended only for the addressee (s) indicated above. It may contain information that is privileged, confidential, or otherwise protected from disclosure. If you receive this e-mail in error, notify the sender by reply e-mail, and destroy all copies of the email. You are not permitted to further divulge any information not intended for you, including the senders' source email address. Identity theft is a crime punishable by law; violations will be prosecuted to the fullest extent of the law.

1 0

[PATCH] Speling fixs
by Kevin Lyda May 31, 2013

May 31, 2013

Not a huge difference, but misspellings now runs a bit more cleanly. diff --git a/asia b/asia index e544fcc..3043d55 100644 --- a/asia +++ b/asia @@ -2548,7 +2548,7 @@ Rule Syria 2007 only - Mar lastFri 0:00 1:00 S # From Jesper Norgard (2007-10-27): # The sister center ICARDA of my work CIMMYT is confirming that Syria DST will # not take place 1.st November at 0:00 o'clock but 1.st November at 24:00 or -# rather Midnight between Thursday and Friday. This does make more sence than +# rather Midnight between Thursday and Friday. This does make more sense than # having it between Wednesday and Thursday (two workdays in Syria) since the # weekend in Syria is not Saturday and Sunday, but Friday and Saturday. So now # it is implemented at midnight of the last workday before weekend... diff --git a/australasia b/australasia index 48aeef6..6a31b69 100644 --- a/australasia +++ b/australasia @@ -1486,7 +1486,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # improve productivity and reduce road accidents. But correspondents say it # also hopes the move will boost Fiji's ability to compete with other pacific # islands in the effort to attract tourists to witness the dawning of the new -# millenium. +# millennium. # http://www.fiji.gov.fj/press/2000_09/2000_09_13-05.shtml (2000-09-13) # reports that Fiji has discontinued DST. @@ -1631,7 +1631,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901 # Shanks & Pottenger say the transition was on 1968-10-01; go with Mundell. # From Eric Ulevik (1999-05-03): -# Tonga's director of tourism, who is also secretary of the National Millenium +# Tonga's director of tourism, who is also secretary of the National Millennium # Committee, has a plan to get Tonga back in front. # He has proposed a one-off move to tropical daylight saving for Tonga from # October to March, which has won approval in principle from the Tongan diff --git a/europe b/europe index 5081a52..2e2d8b5 100644 --- a/europe +++ b/europe @@ -523,7 +523,7 @@ Rule C-Eur 1944 only - Oct 2 2:00s 0 - # It seems that Paris, Monaco, Rule France, Rule Belgium all agree on # 2:00 standard time, e.g. 3:00 local time. However there are no # countries that use C-Eur rules in September 1945, so the only items -# affected are apparently these ficticious zones that translates acronyms +# affected are apparently these fictitious zones that translates acronyms # CET and MET: # # Zone CET 1:00 C-Eur CE%sT @@ -2779,9 +2779,9 @@ Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. # Ukraine # -# From Igor Karpov, who works for the Ukranian Ministry of Justice, +# From Igor Karpov, who works for the Ukrainian Ministry of Justice, # via Garrett Wollman (2003-01-27): -# BTW, I've found the official document on this matter. It's goverment +# BTW, I've found the official document on this matter. It's government # regulations number 509, May 13, 1996. In my poor translation it says: # "Time in Ukraine is set to second timezone (Kiev time). Each last Sunday # of March at 3am the time is changing to 4am and each last Sunday of @@ -2815,7 +2815,7 @@ Link Europe/Istanbul Asia/Istanbul # Istanbul is in both continents. # time this year after all. # # From Udo Schwedt (2011-10-18): -# As far as I understand, the recent change to the Ukranian time zone +# As far as I understand, the recent change to the Ukrainian time zone # (Europe/Kiev) to introduce permanent daylight saving time (similar # to Russia) was reverted today: # diff --git a/southamerica b/southamerica index 3c2f82a..0d8ed7a 100644 --- a/southamerica +++ b/southamerica @@ -971,7 +971,7 @@ Rule Brazil 2007 only - Feb 25 0:00 0 - # adopted by the same states as before. Rule Brazil 2007 only - Oct Sun>=8 0:00 1:00 S # From Frederico A. C. Neves (2008-09-10): -# Acording to this decree +# According to this decree # <a href="http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm"> # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm # </a> @@ -1203,7 +1203,7 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # http://www.emol.com/noticias/nacional/detalle/detallenoticias.asp?idnoticia… # </a> # -# This is not yet reflected in the offical "cambio de hora" site, but +# This is not yet reflected in the official "cambio de hora" site, but # probably will be soon: # <a href="http://www.horaoficial.cl/cambio.htm"> # http://www.horaoficial.cl/cambio.htm diff --git a/tz-art.htm b/tz-art.htm index 046b6ee..5738d60 100644 --- a/tz-art.htm +++ b/tz-art.htm @@ -235,7 +235,7 @@ Supernaw.</td></tr> <tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:3bftxzw0ldhe">AMG Rating</a></td><td>3.5 stars</td></tr> <tr><td>ADO Rating</td><td>2.5 stars</td></tr> <tr><td>Notes<td>Includes the song "Fire and Wood" with the lyric -"The clocks were turned back you remeber/Think it's still November." +"The clocks were turned back you remember/Think it's still November." </td></tr> <tr><td> </td></tr> <tr><td>Artist</td><td>Ken Nordine</td></tr> @@ -431,7 +431,7 @@ hilarity ensues. <hr> <ul> <li> -"We're been using the five-cent nickle in this country since 1492. +"We're been using the five-cent nickel in this country since 1492. Now that's pretty near 100 years, daylight savings [sic]." (Groucho Marx as Captain Spaulding in "Animal Crackers", 1930, as noted by Will Fitzerald) diff --git a/usno1995 b/usno1995 index e39aa52..a5ee0ae 100644 --- a/usno1995 +++ b/usno1995 @@ -25,7 +25,7 @@ Australia Lord Howe Island: +10.5 hours (Local summer +11 hours) Australia New South Wales: +10 hours (Local summer +11 hours) Australia Queensland: +10 hours Australia Victoria: +10 hours (Local summer +11 hours) -Australia Australian Captial Territory: +10 hours (Local summer +11 hours) +Australia Australian Capital Territory: +10 hours (Local summer +11 hours) Australia South: +9.5 hours (Local summer +10.5 hours) Australia Tasmania: +10 hours (Local summer +11 hours) Australia Western: +8 hours @@ -97,7 +97,7 @@ Ecuador: -5 hours Egypt: +2 hours (Local summer +3 hours) El Salvador: -6 hours England: 0 hours (Local summer +1 hours) -Equitorial Guinea: +1 hours +Equatorial Guinea: +1 hours Eritrea: +3 hours Estonia: +2 hours (Local summer +3 hours) Ethiopia: +3 hours diff --git a/usno1997 b/usno1997 index ac63df5..b90be86 100644 --- a/usno1997 +++ b/usno1997 @@ -25,7 +25,7 @@ Australia Lord Howe Island: +10.5 hours (Local summer +11 hours) Australia New South Wales: +10 hours (Local summer +11 hours) Australia Queensland: +10 hours Australia Victoria: +10 hours (Local summer +11 hours) -Australia Australian Captial Territory: +10 hours (Local summer +11 hours) +Australia Australian Capital Territory: +10 hours (Local summer +11 hours) Australia South: +9.5 hours (Local summer +10.5 hours) Australia Tasmania: +10 hours (Local summer +11 hours) Australia Western: +8 hours @@ -97,7 +97,7 @@ Ecuador: -5 hours Egypt: +2 hours (Local summer +3 hours) El Salvador: -6 hours England: 0 hours (Local summer +1 hours) -Equitorial Guinea: +1 hours +Equatorial Guinea: +1 hours Eritrea: +3 hours Estonia: +2 hours (Local summer +3 hours) Ethiopia: +3 hours diff --git a/usno1998 b/usno1998 index 62264a1..d77d255 100644 --- a/usno1998 +++ b/usno1998 @@ -25,7 +25,7 @@ Australia Lord Howe Island: +10.5 hours (Local summer +11 hours) Australia New South Wales: +10 hours (Local summer +11 hours) Australia Queensland: +10 hours Australia Victoria: +10 hours (Local summer +11 hours) -Australia Australian Captial Territory: +10 hours (Local summer +11 hours) +Australia Australian Capital Territory: +10 hours (Local summer +11 hours) Australia South: +9.5 hours (Local summer +10.5 hours) Australia Tasmania: +10 hours (Local summer +11 hours) Australia Western: +8 hours @@ -97,7 +97,7 @@ Ecuador: -5 hours Egypt: +2 hours (Local summer +3 hours) El Salvador: -6 hours England: 0 hours (Local summer +1 hours) -Equitorial Guinea: +1 hours +Equatorial Guinea: +1 hours Eritrea: +3 hours Estonia: +2 hours (Local summer +3 hours) Ethiopia: +3 hours Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/

4 4

x32
by James Cloos May 30, 2013

May 30, 2013

Given the recent note about 32-bit long vs 64-bit time_t on x32: zdump(8), run on gentoo x32, gives the same output as when run on amd64, with zdump -v America/New_York ending with: ,----< zdump -v America/New_York | tail -n 6 > | America/New_York Sun Mar 8 06:59:59 2499 UTC = Sun Mar 8 01:59:59 2499 EST isdst=0 | America/New_York Sun Mar 8 07:00:00 2499 UTC = Sun Mar 8 03:00:00 2499 EDT isdst=1 | America/New_York Sun Nov 1 05:59:59 2499 UTC = Sun Nov 1 01:59:59 2499 EDT isdst=1 | America/New_York Sun Nov 1 06:00:00 2499 UTC = Sun Nov 1 01:00:00 2499 EST isdst=0 | America/New_York 9223372036854689407 = NULL | America/New_York 9223372036854775807 = NULL `---- The Gentoo ebuild has a patch(5) for Makefile to install things where they prefer, but makes no changes to the code. So, based on that one datapoint ☺, 32-bit long and 64-bit time_t should work out of the box. -JimC -- James Cloos <cloos(a)jhcloos.com> OpenPGP: 1024D/ED7DAEA6

2 2

[PATCH] Adjust commentary to try to defuse recent issues somewhat.
by Paul Eggert May 30, 2013

May 30, 2013

This change stemmed from a long discussion on the tz mailing list about what country the Jerusalem zone entry is in. The idea of this change is to deemphasize the role of countries in the tz database, to lessen the amount of controversy in the future. Due to backward compatibility concerns this change does not eliminate the role of countries entirely. With one minor exception this change does not alter any code or data, just comments. * Theory, zone.tab: Deemphasize the role of countries in choosing location names, as they tend to introduce political conflict during maintenance, and country information isn't needed for typical uses of the database. * Theory: Say that names should differ in more than just case, and why; and explain why 'backward' means old names will continue to work. (thanks to Norbert Lindenberg for spotting these issues). Update citation date and URL. * iso3166.tab: Mention latest maintenance update. Update citation URL. Add missing comma for BQ. Be more consistent about abbreviating Sint like Saint. Mention SX "Dutch part" for consistency with MF "French part". * iso3166.tab, zone.tab: Add legal/territorial disclaimer. * zone.tab: Say that country/zone overlaps can occur in both directions, and that column 2 need not lie within column 1. (Asia/Jerusalem): Change the coordinates from a sloppy value, taken from an old astrology book, to a more-precise value, the site of city hall. The sloppy value sparked some controversy and the hope is that the more-precise value will be a bit less controversial. --- Theory | 27 ++++++++++++++------------- iso3166.tab | 21 ++++++++++----------- zone.tab | 17 ++++++++++++----- 3 files changed, 36 insertions(+), 29 deletions(-) diff --git a/Theory b/Theory index b00a492..751b12d 100644 --- a/Theory +++ b/Theory @@ -264,12 +264,12 @@ in decreasing order of importance: TZ strings. A file name component must not exceed 14 characters or start with `-'. E.g., prefer `Brunei' to `Bandar_Seri_Begawan'. - Include at least one location per time zone rule set per country. - One such location is enough. Use ISO 3166 (see the file - iso3166.tab) to help decide whether something is a country. - However, uninhabited ISO 3166 regions like Bouvet Island + Do not use names that differ only in case. Although the reference + implementation is case-sensitive, some other implementations + are not, and they would mishandle names differing only in case. + 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 country's region have agreed since 1970, + 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. Otherwise these tables would become annoyingly large. @@ -283,7 +283,7 @@ in decreasing order of importance: Use mainstream English spelling, e.g. prefer `Rome' to `Roma', and prefer `Athens' to the true name (which uses Greek letters). The POSIX file name restrictions encourage this rule. - Use the most populous among locations in a country's time zone, + Use the most populous among locations in a zone, e.g. prefer `Shanghai' to `Beijing'. Among locations with similar populations, pick the best-known location, e.g. prefer `Rome' to `Milan'. @@ -302,10 +302,11 @@ in decreasing order of importance: Milan's population has grown to be somewhat greater than Rome's. If a name is changed, put its old spelling in the `backward' file. + This means old spellings will continue to work. The file `zone.tab' lists the geographical locations used to name time zone rule files. It is intended to be an exhaustive list -of canonical names for geographic regions. +of names for geographic regions as described above. Older versions of this package used a different naming scheme, and these older names are still supported. @@ -359,14 +360,13 @@ in decreasing order of importance: If this is not available or is a phrase mentioning the country (e.g. ``Cape Verde Time''), then: - When a country has a single or principal time zone region, + When a country is identified with a single or principal zone, append `T' to the country's ISO code, e.g. `CVT' for Cape Verde Time. For summer time append `ST'; for double summer time append `DST'; etc. - When a country has multiple time zones, take the first three - letters of an English place name identifying each zone - and then append `T', `ST', etc. as before; - e.g. `VLAST' for VLAdivostok Summer Time. + Otherwise, take the first three letters of an English place + name identifying each zone and append 'T', 'ST', etc. + as before; e.g. 'VLAST' for VLAdivostok Summer Time. Use UTC (with time zone abbreviation "zzz") for locations while uninhabited. The "zzz" mnemonic is that these locations are, @@ -587,7 +587,8 @@ Sources: Michael Allison and Robert Schmunk, "Technical Notes on Mars Solar Time as Adopted by the Mars24 Sunclock" -<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2004-07-30). +<http://www.giss.nasa.gov/tools/mars24/help/notes.html> (2012-08-08). Jia-Rui Chong, "Workdays Fit for a Martian", Los Angeles Times +<http://articles.latimes.com/2004/jan/14/science/sci-marstime14> (2004-01-14), pp A1, A20-A21. diff --git a/iso3166.tab b/iso3166.tab index b952ca1..c184a81 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -1,16 +1,14 @@ -# <pre> +# ISO 3166 alpha-2 country codes +# # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. -# ISO 3166 alpha-2 country codes # -# From Paul Eggert (2006-09-27): +# From Paul Eggert (2013-05-27): # # This file contains a table with the following columns: # 1. ISO 3166-1 alpha-2 country code, current as of -# ISO 3166-1 Newsletter VI-1 (2007-09-21). See: -# <a href="http://www.iso.org/iso/en/prods-services/iso3166ma/index.html"> -# ISO 3166 Maintenance agency (ISO 3166/MA) -# </a>. +# ISO 3166-1 Newsletter VI-15 (2013-05-10). See: Updates on ISO 3166 +# http://www.iso.org/iso/home/standards/country_codes/updates_on_iso_3166.htm # 2. The usual English name for the country, # chosen so that alphabetic sorting of subsets produces helpful lists. # This is not the same as the English name in the ISO 3166 tables. @@ -20,8 +18,9 @@ # # Lines beginning with `#' are comments. # -# From Arthur David Olson (2011-08-17): -# Resynchronized today with the ISO 3166 site (adding SS for South Sudan). +# This table is intended as an aid for users, to help them select time +# zone data appropriate for their practical needs. It is not intended +# to take or endorse any position on legal or territorial claims. # #country- #code country name @@ -54,7 +53,7 @@ BL St Barthelemy BM Bermuda BN Brunei BO Bolivia -BQ Bonaire Sint Eustatius & Saba +BQ Bonaire, St Eustatius & Saba BR Brazil BS Bahamas BT Bhutan @@ -235,7 +234,7 @@ SR Suriname SS South Sudan ST Sao Tome & Principe SV El Salvador -SX Sint Maarten +SX St Maarten (Dutch part) SY Syria SZ Swaziland TC Turks & Caicos Is diff --git a/zone.tab b/zone.tab index 6b98520..3ec24a7 100644 --- a/zone.tab +++ b/zone.tab @@ -1,18 +1,21 @@ -# <pre> +# TZ zone descriptions +# # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. # -# TZ zone descriptions -# -# From Paul Eggert (1996-08-05): +# From Paul Eggert (2013-05-27): # # This file contains a table with the following columns: # 1. ISO 3166 2-character country code. See the file `iso3166.tab'. +# This identifies a country that overlaps the zone. The country may +# overlap other zones and the zone may overlap other countries. # 2. Latitude and longitude of the zone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS, # first latitude (+ is north), then longitude (+ is east). +# This location need not lie within the column-1 country. # 3. Zone name used in value of TZ environment variable. +# Please see the 'Theory' file for how zone names are chosen. # 4. Comments; present if and only if the country has multiple rows. # # Columns are separated by a single tab. @@ -22,6 +25,10 @@ # # Lines beginning with `#' are comments. # +# This table is intended as an aid for users, to help them select time +# zone data appropriate for their practical needs. It is not intended +# to take or endorse any position on legal or territorial claims. +# #country- #code coordinates TZ comments AD +4230+00131 Europe/Andorra @@ -216,7 +223,7 @@ ID -0002+10920 Asia/Pontianak west & central Borneo ID -0507+11924 Asia/Makassar east & south Borneo, Sulawesi (Celebes), Bali, Nusa Tengarra, west Timor ID -0232+14042 Asia/Jayapura west New Guinea (Irian Jaya) & Malukus (Moluccas) IE +5320-00615 Europe/Dublin -IL +3146+03514 Asia/Jerusalem +IL +314650+0351326 Asia/Jerusalem IM +5409-00428 Europe/Isle_of_Man IN +2232+08822 Asia/Kolkata IO -0720+07225 Indian/Chagos -- 1.8.1.2

2 1

[PATCH] * zdump.8: Fix minor typos in recent changes.
by Paul Eggert May 30, 2013

May 30, 2013

--- zdump.8 | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/zdump.8 b/zdump.8 index 85e9641..f253e81 100644 --- a/zdump.8 +++ b/zdump.8 @@ -5,12 +5,15 @@ zdump \- time zone dumper .B zdump [ .B \-\-version -] -[ +] [ .B \-v ] [ +.B \-V +] [ .B \-c -[loyear,]hiyear ] [ zonename ... ] +[loyear,]hiyear ] [ +.B \-t +[lotime,]hitime ] [ zonename ... ] .SH DESCRIPTION .I Zdump prints the current time in each @@ -37,6 +40,7 @@ Each line ends with if the given time is Daylight Saving Time or .B isdst=0 otherwise. +.TP .B \-V Like .BR \-v , @@ -46,13 +50,12 @@ implementations with different time representations. .TP .BI "\-c " [loyear,]hiyear Cut off verbose output near the start of the given year(s). +By default, +the program cuts off verbose output near the starts of the years \-500 and 2500. .TP .BI "\-t " [lotime,]hitime Cut off verbose output at the start of the given time(s), -given in seconds since 1970-01-01 00:00:00 UTC. -By default, -the program cuts off verbose output near the starts of the years -\-500 and 2500. +given in decimal seconds since 1970-01-01 00:00:00 UTC. .SH LIMITATIONS The .B \-v -- 1.8.1.2

1 0

problems with unsigned 32-bit time_t coming up
by Paul Eggert May 29, 2013

May 29, 2013

I vaguely recalled someone reporting trouble with the tz database on NetBSD or some other BSD in the past few months. The gist of it was that this platform has 32-bit 'long' and 64-bit 'time_t', and the tz code didn't play nicely on such a system. To try to catch this sort of thing I'd like to add support for trying different time_t types, even if they disagree with the system's time_t. I'll send a couple of proposed patches to the list to do that. I'll then follow up with a report of a bug in the reference implementation that is discovered by the patches, when configured to run with an unsigned 32-bit time_t. This isn't the NetBSD problem, but hey! at least there's an easy-to-run test case that illustrates the bug.

4 6

[PATCH] Port to NetBSD, where, e.g., 'time_t' is wider than 'long'.
by Paul Eggert May 27, 2013

May 27, 2013

Here's a proposed porting patch, which I've also pushed into the experimental version on github. As usual, comments welcome. I audited the code and fixed as many width-asssumptions as I could find, including several places where the code assumed that 'time_t' was no wider than 'long'; this assumption is not true on 32-bit NetBSD platforms. This caught every problem that is already fixed in the NetBSD zic.c, and caught quite a few more. * Makefile: Add comments re HAVE_DOS_FILE_NAMES and HAVE_INTTYPES_H. * date.c (checkfinal, netsettime): Don't use 'long' where 'int' will do. * difftime.c (difftime): Mark with ATTRIBUTE_CONST. Use uintmax_t, not unsigned long, for the widest unsigned integer type. Use long double, not double, if time_t is wider than uintmax_t; this can in theory help on nonstandard platforms, such as GCC with 64-bit uintmax_t and 128-bit __int128_t. * localtime.c (struct ttinfo.tt_gmtoff, struct rule.r_time) (detzcode, getsecs, getoffset, gmtsub, localsub, increment_overflow32) (normalize_overflow32, time1, time2, timesub, transtime, tzparse) (time2sub, timeoff, gtime): * tzfile.h (SECSPERDAY): * zdump.c (SECSPERDAY): * zic.c (convert, puttzcode): Use int_fast32_t, not long, when all we care is that values up to 2**31 can be stored. This doesn't fix any bugs, but it allows more opportunity for compiler optimization. (struct lsinfo.ls_corr, timesub, leapcorr): Use int_fast64_t, not long, when values up to 2**63 can be stored. (timesub): Make it clearer when we are truncating 0.5 to 0. (increment_overflow32): Rename from long_increment_overflow. All uses changed. (normalize_overflow32): Rename from long_normalize_overflow. All uses changed. * private.h (HAVE_INTTYPES_H, ATTRIBUTE_CONST): New macros. Include <inttypes.h> if HAVE_INTTYPES_H. (INT_FAST64_MIN, INT_FAST64_MAX, SCNdFAST64, int_fast32_t, PRIdMAX) (uintmax_t, PRIuMAX, _Noreturn): Define to reasonable values if it's an older compiler. * scheck.c (scheck): Add support for arbitrary formats, such as those that SCNdFAST64 can expand to, at the price of no longer supporting weird conversion specs like "%[%]". * strftime.c (_fmt): Use intmax_t and uintmax_t to format time_t, not long and unsigned long. * zdump.c (int_fast32_t, intmax_t, PRIdMAX, SCNdMAX): Define for pre-C99 compilers, like private.h does. (delta, yeartot, main): Use intmax_t, not long. (hunt): Use time_t, not long, since the diff must be nonnegative. (tformat): Allow for time_t wider than long. * zic.c (ZIC_MIN, ZIC_MAX, SCNdZIC): New macros. (OFFSET_STRLEN_MAXIMUM, RULE_STRLEN_MAXIMUM): Remove. (struct rule): Make r_loyear, r_hiyear, r_tod, r_stdoff, z_gmtoff, z_stdoff zic_t, not long. (addtype, gethms, oadd, rpytime, tadd, gmtoffs, corr, inleap) (stringoffset, stringrule, outzone, addtype, adjleap, rpytime) (LDAYSPERWEEK): Use zic_t, not long. (leapminyear, leapmaxyear, min_year, max_year, rulesub, updateminmax) (outzone, rpytime): Use zic_t, not int. (usage): Now _Noreturn. (main): Use S_IWGRP, not 'unix', to determine whether to call umask. (writezone): Omit unnecessary cast. (mkdirs): Use HAVE_DOS_FILE_NAMES, not 'unix', to determine whether to parse DOS file anmes. (eitol): Remove; no longer needed. --- Makefile | 2 + date.c | 6 +- difftime.c | 21 +++---- localtime.c | 132 ++++++++++++++++++++------------------- private.h | 58 +++++++++++++++++- scheck.c | 29 ++++++--- strftime.c | 8 +-- tzfile.h | 2 +- zdump.c | 88 +++++++++++++++++++------- zic.c | 201 ++++++++++++++++++++++++++++-------------------------------- 10 files changed, 323 insertions(+), 224 deletions(-) diff --git a/Makefile b/Makefile index 912bab6..2532d4d 100644 --- a/Makefile +++ b/Makefile @@ -101,9 +101,11 @@ LDLIBS= # Add the following to the end of the "CFLAGS=" line as needed. # -DHAVE_ADJTIME=0 if `adjtime' does not exist (SVR0?) +# -DHAVE_DOS_FILE_NAMES if file names have drive specifiers etc. (MS-DOS) # -DHAVE_GETTEXT=1 if `gettext' works (GNU, Linux, Solaris); also see LDLIBS # -DHAVE_INCOMPATIBLE_CTIME_R=1 if your system's time.h declares # ctime_r and asctime_r incompatibly with the POSIX standard (Solaris 8). +# -DHAVE_INTTYPES_H=1 if you have a pre-C99 compiler with "inttypes.h" # -DHAVE_SETTIMEOFDAY=0 if settimeofday does not exist (SVR0?) # -DHAVE_SETTIMEOFDAY=1 if settimeofday has just 1 arg (SVR4) # -DHAVE_SETTIMEOFDAY=2 if settimeofday uses 2nd arg (4.3BSD) diff --git a/date.c b/date.c index b721ad9..047969f 100644 --- a/date.c +++ b/date.c @@ -708,8 +708,7 @@ checkfinal(const char * const value, time_t othert; struct tm tm; struct tm othertm; - register int pass; - register long offset; + register int pass, offset; /* ** See if there's both a USG and a BSD interpretation. @@ -807,8 +806,7 @@ iffy(const time_t thist, const time_t thatt, static int netsettime(struct timeval ntv) { - int s, length, port, timed_ack, found, err; - long waittime; + int s, length, port, timed_ack, found, err, waittime; fd_set ready; char hostname[MAXHOSTNAMELEN]; struct timeval tout; diff --git a/difftime.c b/difftime.c index c8c85b3..fcd18ce 100644 --- a/difftime.c +++ b/difftime.c @@ -7,13 +7,12 @@ #include "private.h" /* for time_t, TYPE_INTEGRAL, and TYPE_SIGNED */ -double +double ATTRIBUTE_CONST difftime(const time_t time1, const time_t time0) { /* ** If (sizeof (double) > sizeof (time_t)) simply convert and subtract ** (assuming that the larger type has more precision). - ** This is the common real-world case circa 2004. */ if (sizeof (double) > sizeof (time_t)) return (double) time1 - (double) time0; @@ -30,8 +29,8 @@ difftime(const time_t time1, const time_t time0) ** if the minuend is greater than or equal to the subtrahend. */ if (time1 >= time0) - return time1 - time0; - else return -((double) (time0 - time1)); + return time1 - time0; + else return -(double) (time0 - time1); } /* ** time_t is integral and signed. @@ -42,16 +41,16 @@ difftime(const time_t time1, const time_t time0) return time1 - time0; /* ** time1 and time0 have opposite signs. - ** Punt if unsigned long is too narrow. + ** Punt if uintmax_t is too narrow. + ** This suffers from double rounding; attempt to lessen that + ** by using long double temporaries. */ - if (sizeof (unsigned long) < sizeof (time_t)) - return (double) time1 - (double) time0; + if (sizeof (uintmax_t) < sizeof (time_t)) + return (long double) time1 - (long double) time0; /* ** Stay calm...decent optimizers will eliminate the complexity below. */ if (time1 >= 0 /* && time0 < 0 */) - return (unsigned long) time1 + - (unsigned long) (-(time0 + 1)) + 1; - return -(double) ((unsigned long) time0 + - (unsigned long) (-(time1 + 1)) + 1); + return (uintmax_t) time1 + (uintmax_t) (-1 - time0) + 1; + return -(double) ((uintmax_t) time0 + (uintmax_t) (-1 - time1) + 1); } diff --git a/localtime.c b/localtime.c index f90415e..7db8ceb 100644 --- a/localtime.c +++ b/localtime.c @@ -78,7 +78,7 @@ static const char gmt[] = "GMT"; #endif /* !defined TZDEFDST */ struct ttinfo { /* time type information */ - long tt_gmtoff; /* UTC offset in seconds */ + int_fast32_t tt_gmtoff; /* UTC offset in seconds */ int tt_isdst; /* used to set tm_isdst */ int tt_abbrind; /* abbreviation list index */ int tt_ttisstd; /* TRUE if transition is std time */ @@ -87,7 +87,7 @@ struct ttinfo { /* time type information */ struct lsinfo { /* leap second information */ time_t ls_trans; /* transition time */ - long ls_corr; /* correction to apply */ + int_fast64_t ls_corr; /* correction to apply */ }; #define BIGGEST(a, b) (((a) > (b)) ? (a) : (b)) @@ -120,7 +120,7 @@ struct rule { int r_day; /* day number of rule */ int r_week; /* week number of rule */ int r_mon; /* month number of rule */ - long r_time; /* transition time of rule */ + int_fast32_t r_time; /* transition time of rule */ }; #define JULIAN_DAY 0 /* Jn - Julian day */ @@ -131,7 +131,7 @@ struct rule { ** Prototypes for static functions. */ -static long detzcode(const char * codep); +static int_fast32_t detzcode(const char * codep); static time_t detzcode64(const char * codep); static int differ_by_repeat(time_t t1, time_t t0); static const char * getzname(const char * strp) ATTRIBUTE_PURE; @@ -139,40 +139,40 @@ static const char * getqzname(const char * strp, const int delim) ATTRIBUTE_PURE; static const char * getnum(const char * strp, int * nump, int min, int max); -static const char * getsecs(const char * strp, long * secsp); -static const char * getoffset(const char * strp, long * offsetp); +static const char * getsecs(const char * strp, int_fast32_t * secsp); +static const char * getoffset(const char * strp, int_fast32_t * offsetp); static const char * getrule(const char * strp, struct rule * rulep); static void gmtload(struct state * sp); -static struct tm * gmtsub(const time_t * timep, long offset, +static struct tm * gmtsub(const time_t * timep, int_fast32_t offset, struct tm * tmp); -static struct tm * localsub(const time_t * timep, long offset, +static struct tm * localsub(const time_t * timep, int_fast32_t offset, struct tm * tmp); static int increment_overflow(int * number, int delta); static int leaps_thru_end_of(int y) ATTRIBUTE_PURE; -static int long_increment_overflow(long * number, int delta); -static int long_normalize_overflow(long * tensptr, +static int increment_overflow32(int_fast32_t * number, int delta); +static int normalize_overflow32(int_fast32_t * tensptr, int * unitsptr, int base); static int normalize_overflow(int * tensptr, int * unitsptr, int base); static void settzname(void); static time_t time1(struct tm * tmp, struct tm * (*funcp)(const time_t *, - long, struct tm *), - long offset); + int_fast32_t, struct tm *), + int_fast32_t offset); static time_t time2(struct tm *tmp, struct tm * (*funcp)(const time_t *, - long, struct tm*), - long offset, int * okayp); + int_fast32_t, struct tm*), + int_fast32_t offset, int * okayp); static time_t time2sub(struct tm *tmp, struct tm * (*funcp)(const time_t *, - long, struct tm*), - long offset, int * okayp, int do_norm_secs); -static struct tm * timesub(const time_t * timep, long offset, + int_fast32_t, struct tm*), + int_fast32_t offset, int * okayp, int do_norm_secs); +static struct tm * timesub(const time_t * timep, int_fast32_t offset, const struct state * sp, struct tm * tmp); static int tmcomp(const struct tm * atmp, const struct tm * btmp); static time_t transtime(time_t janfirst, int year, - const struct rule * rulep, long offset) + const struct rule * rulep, int_fast32_t offset) ATTRIBUTE_PURE; static int typesequiv(const struct state * sp, int a, int b); static int tzload(const char * name, struct state * sp, @@ -224,13 +224,13 @@ int daylight = 0; time_t altzone = 0; #endif /* defined ALTZONE */ -static long +static int_fast32_t detzcode(const char *const codep) { - register long result; - register int i; + register int_fast32_t result; + register int i; - result = (codep[0] & 0x80) ? ~0L : 0; + result = (codep[0] & 0x80) ? -1 : 0; for (i = 0; i < 4; ++i) result = (result << 8) | (codep[i] & 0xff); return result; @@ -732,7 +732,7 @@ getnum(register const char *strp, int *const nump, const int min, const int max) */ static const char * -getsecs(register const char *strp, long *const secsp) +getsecs(register const char *strp, int_fast32_t *const secsp) { int num; @@ -745,7 +745,7 @@ getsecs(register const char *strp, long *const secsp) strp = getnum(strp, &num, 0, HOURSPERDAY * DAYSPERWEEK - 1); if (strp == NULL) return NULL; - *secsp = num * (long) SECSPERHOUR; + *secsp = num * (int_fast32_t) SECSPERHOUR; if (*strp == ':') { ++strp; strp = getnum(strp, &num, 0, MINSPERHOUR - 1); @@ -772,7 +772,7 @@ getsecs(register const char *strp, long *const secsp) */ static const char * -getoffset(register const char *strp, long *const offsetp) +getoffset(register const char *strp, int_fast32_t *const offsetp) { register int neg = 0; @@ -850,7 +850,7 @@ getrule(const char *strp, register struct rule *const rulep) static time_t transtime(const time_t janfirst, const int year, - register const struct rule *const rulep, const long offset) + register const struct rule *const rulep, const int_fast32_t offset) { register int leapyear; register time_t value; @@ -948,8 +948,8 @@ tzparse(const char *name, register struct state *const sp, const char * dstname; size_t stdlen; size_t dstlen; - long stdoffset; - long dstoffset; + int_fast32_t stdoffset; + int_fast32_t dstoffset; register time_t * atp; register unsigned char * typep; register char * cp; @@ -1067,12 +1067,12 @@ tzparse(const char *name, register struct state *const sp, janfirst = newfirst; } } else { - register long theirstdoffset; - register long theirdstoffset; - register long theiroffset; - register int isdst; - register int i; - register int j; + register int_fast32_t theirstdoffset; + register int_fast32_t theirdstoffset; + register int_fast32_t theiroffset; + register int isdst; + register int i; + register int j; if (*name != '\0') return -1; @@ -1265,7 +1265,8 @@ tzset(void) /*ARGSUSED*/ static struct tm * -localsub(const time_t *const timep, const long offset, struct tm *const tmp) +localsub(const time_t *const timep, const int_fast32_t offset, + struct tm *const tmp) { register struct state * sp; register const struct ttinfo * ttisp; @@ -1370,7 +1371,8 @@ localtime_r(const time_t *const timep, struct tm *tmp) */ static struct tm * -gmtsub(const time_t *const timep, const long offset, struct tm *const tmp) +gmtsub(const time_t *const timep, const int_fast32_t offset, + struct tm *const tmp) { register struct tm * result; @@ -1424,7 +1426,7 @@ gmtime_r(const time_t *const timep, struct tm *tmp) #ifdef STD_INSPIRED struct tm * -offtime(const time_t *const timep, const long offset) +offtime(const time_t *const timep, const int_fast32_t offset) { return gmtsub(timep, offset, &tm); } @@ -1444,17 +1446,17 @@ leaps_thru_end_of(register const int y) } static struct tm * -timesub(const time_t *const timep, const long offset, +timesub(const time_t *const timep, const int_fast32_t offset, register const struct state *const sp, register struct tm *const tmp) { register const struct lsinfo * lp; register time_t tdays; register int idays; /* unsigned would be so 2003 */ - register long rem; + register int_fast64_t rem; int y; register const int * ip; - register long corr; + register int_fast64_t corr; register int hit; register int i; @@ -1511,9 +1513,10 @@ timesub(const time_t *const timep, const long offset, y = newy; } { - register long seconds; + register int_fast32_t seconds; + register time_t half_second = 0.5; - seconds = tdays * SECSPERDAY + 0.5; + seconds = tdays * SECSPERDAY + half_second; tdays = seconds / SECSPERDAY; rem += seconds - tdays * SECSPERDAY; } @@ -1630,11 +1633,11 @@ increment_overflow(int *const ip, int j) } static int -long_increment_overflow(long *const lp, int const m) +increment_overflow32(int_fast32_t *const lp, int const m) { - register long const l = *lp; + register int_fast32_t const l = *lp; - if ((l >= 0) ? (m > LONG_MAX - l) : (m < LONG_MIN - l)) + if ((l >= 0) ? (m > INT_FAST32_MAX - l) : (m < INT_FAST32_MIN - l)) return TRUE; *lp += m; return FALSE; @@ -1653,7 +1656,8 @@ normalize_overflow(int *const tensptr, int *const unitsptr, const int base) } static int -long_normalize_overflow(long *const tensptr, int *const unitsptr, const int base) +normalize_overflow32(int_fast32_t *const tensptr, int *const unitsptr, + const int base) { register int tensdelta; @@ -1661,7 +1665,7 @@ long_normalize_overflow(long *const tensptr, int *const unitsptr, const int base (*unitsptr / base) : (-1 - (-1 - *unitsptr) / base); *unitsptr -= tensdelta * base; - return long_increment_overflow(tensptr, tensdelta); + return increment_overflow32(tensptr, tensdelta); } static int @@ -1681,8 +1685,8 @@ tmcomp(register const struct tm *const atmp, static time_t time2sub(struct tm *const tmp, - struct tm *(*const funcp)(const time_t *, long, struct tm *), - const long offset, + struct tm *(*const funcp)(const time_t *, int_fast32_t, struct tm *), + const int_fast32_t offset, int *const okayp, const int do_norm_secs) { @@ -1690,10 +1694,10 @@ time2sub(struct tm *const tmp, register int dir; register int i, j; register int saved_seconds; - register long li; + register int_fast32_t li; register time_t lo; register time_t hi; - long y; + int_fast32_t y; time_t newt; time_t t; struct tm yourtm, mytm; @@ -1710,16 +1714,16 @@ time2sub(struct tm *const tmp, if (normalize_overflow(&yourtm.tm_mday, &yourtm.tm_hour, HOURSPERDAY)) return WRONG; y = yourtm.tm_year; - if (long_normalize_overflow(&y, &yourtm.tm_mon, MONSPERYEAR)) + if (normalize_overflow32(&y, &yourtm.tm_mon, MONSPERYEAR)) return WRONG; /* ** Turn y into an actual year number for now. ** It is converted back to an offset from TM_YEAR_BASE later. */ - if (long_increment_overflow(&y, TM_YEAR_BASE)) + if (increment_overflow32(&y, TM_YEAR_BASE)) return WRONG; while (yourtm.tm_mday <= 0) { - if (long_increment_overflow(&y, -1)) + if (increment_overflow32(&y, -1)) return WRONG; li = y + (1 < yourtm.tm_mon); yourtm.tm_mday += year_lengths[isleap(li)]; @@ -1727,7 +1731,7 @@ time2sub(struct tm *const tmp, while (yourtm.tm_mday > DAYSPERLYEAR) { li = y + (1 < yourtm.tm_mon); yourtm.tm_mday -= year_lengths[isleap(li)]; - if (long_increment_overflow(&y, 1)) + if (increment_overflow32(&y, 1)) return WRONG; } for ( ; ; ) { @@ -1737,11 +1741,11 @@ time2sub(struct tm *const tmp, yourtm.tm_mday -= i; if (++yourtm.tm_mon >= MONSPERYEAR) { yourtm.tm_mon = 0; - if (long_increment_overflow(&y, 1)) + if (increment_overflow32(&y, 1)) return WRONG; } } - if (long_increment_overflow(&y, -TM_YEAR_BASE)) + if (increment_overflow32(&y, -TM_YEAR_BASE)) return WRONG; yourtm.tm_year = y; if (yourtm.tm_year != y) @@ -1864,8 +1868,8 @@ label: static time_t time2(struct tm * const tmp, - struct tm * (*const funcp)(const time_t *, long, struct tm *), - const long offset, + struct tm * (*const funcp)(const time_t *, int_fast32_t, struct tm *), + const int_fast32_t offset, int *const okayp) { time_t t; @@ -1881,8 +1885,8 @@ time2(struct tm * const tmp, static time_t time1(struct tm *const tmp, - struct tm *(*const funcp) (const time_t *, long, struct tm *), - const long offset) + struct tm *(*const funcp) (const time_t *, int_fast32_t, struct tm *), + const int_fast32_t offset) { register time_t t; register const struct state * sp; @@ -1981,7 +1985,7 @@ timegm(struct tm *const tmp) } time_t -timeoff(struct tm *const tmp, const long offset) +timeoff(struct tm *const tmp, const int_fast32_t offset) { if (tmp != NULL) tmp->tm_isdst = 0; @@ -1997,7 +2001,7 @@ timeoff(struct tm *const tmp, const long offset) ** previous versions of the CMUCS runtime library. */ -long +int_fast32_t gtime(struct tm *const tmp) { const time_t t = mktime(tmp); @@ -2023,7 +2027,7 @@ gtime(struct tm *const tmp) ** when exchanging timestamps with POSIX conforming systems. */ -static long +static int_fast64_t leapcorr(time_t *timep) { register struct state * sp; diff --git a/private.h b/private.h index 05ddba0..a31a26e 100644 --- a/private.h +++ b/private.h @@ -124,19 +124,65 @@ #include "stdint.h" #endif /* !HAVE_STDINT_H */ +#ifndef HAVE_INTTYPES_H +# define HAVE_INTTYPES_H HAVE_STDINT_H +#endif +#if HAVE_INTTYPES_H +# include <inttypes.h> +#endif + #ifndef INT_FAST64_MAX /* Pre-C99 GCC compilers define __LONG_LONG_MAX__ instead of LLONG_MAX. */ #if defined LLONG_MAX || defined __LONG_LONG_MAX__ typedef long long int_fast64_t; +# ifdef LLONG_MAX +# define INT_FAST64_MIN LLONG_MIN +# define INT_FAST64_MAX LLONG_MAX +# else +# define INT_FAST64_MIN __LONG_LONG_MIN__ +# define INT_FAST64_MAX __LONG_LONG_MAX__ +# endif +# define SCNdFAST64 "lld" #else /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */ #if (LONG_MAX >> 31) < 0xffffffff Please use a compiler that supports a 64-bit integer type (or wider); you may need to compile with "-DHAVE_STDINT_H". #endif /* (LONG_MAX >> 31) < 0xffffffff */ typedef long int_fast64_t; +# define INT_FAST64_MIN LONG_MIN +# define INT_FAST64_MAX LONG_MAX +# define SCNdFAST64 "ld" #endif /* ! (defined LLONG_MAX || defined __LONG_LONG_MAX__) */ #endif /* !defined INT_FAST64_MAX */ +#ifndef INT_FAST32_MAX +# if INT_MAX >> 31 == 0 +typedef long int_fast32_t; +# else +typedef int int_fast32_t; +# endif +#endif + +#ifndef INTMAX_MAX +# if defined LLONG_MAX || defined __LONG_LONG_MAX__ +typedef long long intmax_t; +# define PRIdMAX "lld" +# else +typedef long intmax_t; +# define PRIdMAX "ld" +# endif +#endif + +#ifndef UINTMAX_MAX +# if defined ULLONG_MAX || defined __LONG_LONG_MAX__ +typedef unsigned long long uintmax_t; +# define PRIuMAX "llu" +# else +typedef unsigned long uintmax_t; +# define PRIuMAX "lu" +# endif +#endif + #ifndef INT32_MAX #define INT32_MAX 0x7fffffff #endif /* !defined INT32_MAX */ @@ -144,12 +190,22 @@ typedef long int_fast64_t; #define INT32_MIN (-1 - INT32_MAX) #endif /* !defined INT32_MIN */ -#if 2 < __GNUC__ || (__GNUC__ == 2 && 96 <= __GNUC_MINOR__) +#if 2 < __GNUC__ + (96 <= __GNUC_MINOR__) +# define ATTRIBUTE_CONST __attribute__ ((const)) # define ATTRIBUTE_PURE __attribute__ ((__pure__)) #else +# define ATTRIBUTE_CONST /* empty */ # define ATTRIBUTE_PURE /* empty */ #endif +#if !defined _Noreturn && __STDC_VERSION__ < 201112 +# if 2 < __GNUC__ + (8 <= __GNUC_MINOR__) +# define _Noreturn __attribute__ ((__noreturn__)) +# else +# define _Noreturn +# endif +#endif + #if __STDC_VERSION__ < 199901 && !defined restrict # define restrict /* empty */ #endif diff --git a/scheck.c b/scheck.c index ed60980..8bd01a8 100644 --- a/scheck.c +++ b/scheck.c @@ -25,26 +25,35 @@ scheck(const char *const string, const char *const format) return result; fp = format; tp = fbuf; + + /* + ** Copy directives, suppressing each conversion that is not + ** already suppressed. Scansets containing '%' are not + ** supported; e.g., the conversion specification "%[%]" is not + ** supported. Also, multibyte characters containing a + ** non-leading '%' byte are not supported. + */ while ((*tp++ = c = *fp++) != '\0') { if (c != '%') continue; - if (*fp == '%') { - *tp++ = *fp++; - continue; + if (is_digit(*fp)) { + char const *f = fp; + char *t = tp; + do { + *t++ = c = *f++; + } while (is_digit(c)); + if (c == '$') { + fp = f; + tp = t; + } } *tp++ = '*'; if (*fp == '*') ++fp; - while (is_digit(*fp)) - *tp++ = *fp++; - if (*fp == 'l' || *fp == 'h') - *tp++ = *fp++; - else if (*fp == '[') - do *tp++ = *fp++; - while (*fp != '\0' && *fp != ']'); if ((*tp++ = *fp++) == '\0') break; } + *(tp - 1) = '%'; *tp++ = 'c'; *tp = '\0'; diff --git a/strftime.c b/strftime.c index 2c3cef8..821ce7f 100644 --- a/strftime.c +++ b/strftime.c @@ -317,10 +317,10 @@ label: tm = *t; mkt = mktime(&tm); if (TYPE_SIGNED(time_t)) - (void) sprintf(buf, "%ld", - (long) mkt); - else (void) sprintf(buf, "%lu", - (unsigned long) mkt); + (void) sprintf(buf, "%"PRIdMAX, + (intmax_t) mkt); + else (void) sprintf(buf, "%"PRIuMAX, + (uintmax_t) mkt); pt = _add(buf, pt, ptlim); } continue; diff --git a/tzfile.h b/tzfile.h index 0f6c687..d04fe04 100644 --- a/tzfile.h +++ b/tzfile.h @@ -122,7 +122,7 @@ struct tzhead { #define DAYSPERNYEAR 365 #define DAYSPERLYEAR 366 #define SECSPERHOUR (SECSPERMIN * MINSPERHOUR) -#define SECSPERDAY ((long) SECSPERHOUR * HOURSPERDAY) +#define SECSPERDAY ((int_fast32_t) SECSPERHOUR * HOURSPERDAY) #define MONSPERYEAR 12 #define TM_SUNDAY 0 diff --git a/zdump.c b/zdump.c index 8118091..be0a496 100644 --- a/zdump.c +++ b/zdump.c @@ -30,6 +30,47 @@ #define isascii(x) 1 #endif /* !defined isascii */ +/* +** Substitutes for pre-C99 compilers. +** Much of this section of code is stolen from private.h. +*/ + +#ifndef HAVE_STDINT_H +# define HAVE_STDINT_H \ + (199901 <= __STDC_VERSION__ || 2 < (__GLIBC__ + (0 < __GLIBC_MINOR__))) +#endif +#if HAVE_STDINT_H +# include "stdint.h" +#endif +#ifndef HAVE_INTTYPES_H +# define HAVE_INTTYPES_H HAVE_STDINT_H +#endif +#if HAVE_INTTYPES_H +# include <inttypes.h> +#endif + +#ifndef INT_FAST32_MAX +# if INT_MAX >> 31 == 0 +typedef long int_fast32_t; +# else +typedef int int_fast32_t; +# endif +#endif + +#ifndef INTMAX_MAX +# if defined LLONG_MAX || defined __LONG_LONG_MAX__ +typedef long long intmax_t; +# define PRIdMAX "lld" +# else +typedef long intmax_t; +# define PRIdMAX "ld" +# endif +#endif +#ifndef SCNdMAX +# define SCNdMAX PRIdMAX +#endif + + #ifndef ZDUMP_LO_YEAR #define ZDUMP_LO_YEAR (-500) #endif /* !defined ZDUMP_LO_YEAR */ @@ -97,7 +138,7 @@ #define isleap_sum(a, b) isleap((a) % 400 + (b) % 400) #endif /* !defined isleap_sum */ -#define SECSPERDAY ((long) SECSPERHOUR * HOURSPERDAY) +#define SECSPERDAY ((int_fast32_t) SECSPERHOUR * HOURSPERDAY) #define SECSPERNYEAR (SECSPERDAY * DAYSPERNYEAR) #define SECSPERLYEAR (SECSPERNYEAR + SECSPERDAY) @@ -179,13 +220,13 @@ static int warned; static char * abbr(struct tm * tmp); static void abbrok(const char * abbrp, const char * zone); -static long delta(struct tm * newp, struct tm * oldp) ATTRIBUTE_PURE; +static intmax_t delta(struct tm * newp, struct tm * oldp) ATTRIBUTE_PURE; static void dumptime(const struct tm * tmp); static time_t hunt(char * name, time_t lot, time_t hit); static void checkabsolutes(void); static void show(char * zone, time_t t, int v); static const char * tformat(void); -static time_t yeartot(long y) ATTRIBUTE_PURE; +static time_t yeartot(intmax_t y) ATTRIBUTE_PURE; #ifndef TYPECHECK #define my_localtime localtime @@ -324,15 +365,15 @@ main(int argc, char *argv[]) arg_processing_done:; if (vflag | Vflag) { - long lo; - long hi; - char dummy; - register long cutloyear = ZDUMP_LO_YEAR; - register long cuthiyear = ZDUMP_HI_YEAR; + intmax_t lo; + intmax_t hi; + char dummy; + register intmax_t cutloyear = ZDUMP_LO_YEAR; + register intmax_t cuthiyear = ZDUMP_HI_YEAR; if (cutarg != NULL) { - if (sscanf(cutarg, "%ld%c", &hi, &dummy) == 1) { + if (sscanf(cutarg, "%"SCNdMAX"%c", &hi, &dummy) == 1) { cuthiyear = hi; - } else if (sscanf(cutarg, "%ld,%ld%c", + } else if (sscanf(cutarg, "%"SCNdMAX",%"SCNdMAX"%c", &lo, &hi, &dummy) == 2) { cutloyear = lo; cuthiyear = hi; @@ -348,13 +389,13 @@ main(int argc, char *argv[]) cuthitime = yeartot(cuthiyear); } if (cuttimes != NULL) { - if (sscanf(cuttimes, "%ld%c", &hi, &dummy) == 1) { + if (sscanf(cuttimes, "%"SCNdMAX"%c", &hi, &dummy) == 1) { if (hi < cuthitime) { if (hi < absolute_min_time) hi = absolute_min_time; cuthitime = hi; } - } else if (sscanf(cuttimes, "%ld,%ld%c", + } else if (sscanf(cuttimes, "%"SCNdMAX",%"SCNdMAX"%c", &lo, &hi, &dummy) == 2) { if (cutlotime < lo) { if (absolute_max_time < lo) @@ -475,11 +516,11 @@ _("%s: use of -v on system with floating time_t other than float or double\n"), } static time_t -yeartot(const long y) +yeartot(const intmax_t y) { - register long myy; - register long seconds; - register time_t t; + register intmax_t myy; + register int_fast32_t seconds; + register time_t t; myy = EPOCH_YEAR; t = 0; @@ -509,7 +550,6 @@ static time_t hunt(char *name, time_t lot, time_t hit) { time_t t; - long diff; struct tm lotm; register struct tm * lotmp; struct tm tm; @@ -522,7 +562,7 @@ hunt(char *name, time_t lot, time_t hit) (void) strncpy(loab, abbr(&lotm), (sizeof loab) - 1); } for ( ; ; ) { - diff = (long) (hit - lot); + time_t diff = hit - lot; if (diff < 2) break; t = lot; @@ -552,11 +592,11 @@ hunt(char *name, time_t lot, time_t hit) ** Thanks to Paul Eggert for logic used in delta. */ -static long +static intmax_t delta(struct tm * newp, struct tm *oldp) { - register long result; - register int tmy; + register intmax_t result; + register int tmy; if (newp->tm_year < oldp->tm_year) return -delta(oldp, newp); @@ -632,12 +672,18 @@ tformat(void) return "%g"; } if (0 > (time_t) -1) { /* signed */ + if (sizeof (time_t) == sizeof (intmax_t)) + return "%"PRIdMAX; if (sizeof (time_t) > sizeof (long)) return "%lld"; if (sizeof (time_t) > sizeof (int)) return "%ld"; return "%d"; } +#ifdef PRIuMAX + if (sizeof (time_t) == sizeof (uintmax_t)) + return "%"PRIuMAX; +#endif if (sizeof (time_t) > sizeof (unsigned long)) return "%llu"; if (sizeof (time_t) > sizeof (unsigned int)) diff --git a/zic.c b/zic.c index f277edc..1715c4a 100644 --- a/zic.c +++ b/zic.c @@ -11,6 +11,9 @@ #define ZIC_VERSION '2' typedef int_fast64_t zic_t; +#define ZIC_MIN INT_FAST64_MIN +#define ZIC_MAX INT_FAST64_MAX +#define SCNdZIC SCNdFAST64 #ifndef ZIC_MAX_ABBR_LEN_WO_WARN #define ZIC_MAX_ABBR_LEN_WO_WARN 6 @@ -38,9 +41,6 @@ typedef int_fast64_t zic_t; #define isascii(x) 1 #endif -#define OFFSET_STRLEN_MAXIMUM (7 + INT_STRLEN_MAXIMUM(long)) -#define RULE_STRLEN_MAXIMUM 8 /* "Mdd.dd.d" */ - #define end(cp) (strchr((cp), '\0')) struct rule { @@ -48,8 +48,8 @@ struct rule { int r_linenum; const char * r_name; - int r_loyear; /* for example, 1986 */ - int r_hiyear; /* for example, 1986 */ + zic_t r_loyear; /* for example, 1986 */ + zic_t r_hiyear; /* for example, 1986 */ const char * r_yrtype; int r_lowasnum; int r_hiwasnum; @@ -60,12 +60,12 @@ struct rule { int r_dayofmonth; int r_wday; - long r_tod; /* time from midnight */ + zic_t r_tod; /* time from midnight */ int r_todisstd; /* above is standard time if TRUE */ /* or wall clock time if FALSE */ int r_todisgmt; /* above is GMT if TRUE */ /* or local time if FALSE */ - long r_stdoff; /* offset from standard time */ + zic_t r_stdoff; /* offset from standard time */ const char * r_abbrvar; /* variable part of abbreviation */ int r_todo; /* a rule to do (used in outzone) */ @@ -85,11 +85,11 @@ struct zone { int z_linenum; const char * z_name; - long z_gmtoff; + zic_t z_gmtoff; const char * z_rule; const char * z_format; - long z_stdoff; + zic_t z_stdoff; struct rule * z_rules; int z_nrules; @@ -105,16 +105,15 @@ extern char * optarg; extern int optind; static void addtt(zic_t starttime, int type); -static int addtype(long gmtoff, const char * abbr, int isdst, +static int addtype(zic_t gmtoff, const char * abbr, int isdst, int ttisstd, int ttisgmt); static void leapadd(zic_t t, int positive, int rolling, int count); static void adjleap(void); static void associate(void); static void dolink(const char * fromfield, const char * tofield); -static long eitol(int i); static char ** getfields(char * buf); -static long gethms(const char * string, const char * errstrng, - int signable); +static zic_t gethms(const char * string, const char * errstrng, + int signable); static void infile(const char * filename); static void inleap(char ** fields, int nfields); static void inlink(char ** fields, int nfields); @@ -126,14 +125,14 @@ static int itsdir(const char * name); static int lowerit(int c); static int mkdirs(char * filename); static void newabbr(const char * abbr); -static long oadd(long t1, long t2); +static zic_t oadd(zic_t t1, zic_t t2); static void outzone(const struct zone * zp, int ntzones); -static zic_t rpytime(const struct rule * rp, int wantedy); +static zic_t rpytime(const struct rule * rp, zic_t wantedy); static void rulesub(struct rule * rp, const char * loyearp, const char * hiyearp, const char * typep, const char * monthp, const char * dayp, const char * timep); -static zic_t tadd(zic_t t1, long t2); +static zic_t tadd(zic_t t1, zic_t t2); static int yearistype(int year, const char * type); static int charcnt; @@ -141,13 +140,13 @@ static int errors; static const char * filename; static int leapcnt; static int leapseen; -static int leapminyear; -static int leapmaxyear; +static zic_t leapminyear; +static zic_t leapmaxyear; static int linenum; static int max_abbrvar_len; static int max_format_len; -static int max_year; -static int min_year; +static zic_t max_year; +static zic_t min_year; static int noise; static const char * rfilename; static int rlinenum; @@ -338,14 +337,14 @@ static struct attype { zic_t at; unsigned char type; } attypes[TZ_MAX_TIMES]; -static long gmtoffs[TZ_MAX_TYPES]; +static zic_t gmtoffs[TZ_MAX_TYPES]; static char isdsts[TZ_MAX_TYPES]; static unsigned char abbrinds[TZ_MAX_TYPES]; static char ttisstds[TZ_MAX_TYPES]; static char ttisgmts[TZ_MAX_TYPES]; static char chars[TZ_MAX_CHARS]; static zic_t trans[TZ_MAX_LEAPS]; -static long corr[TZ_MAX_LEAPS]; +static zic_t corr[TZ_MAX_LEAPS]; static char roll[TZ_MAX_LEAPS]; /* @@ -419,7 +418,7 @@ warning(const char *const string) --errors; } -static void +static _Noreturn void usage(FILE *stream, int status) { (void) fprintf(stream, _("%s: usage is %s \ @@ -444,9 +443,9 @@ main(int argc, char **argv) register int j; register int c; -#ifdef unix +#ifdef S_IWGRP (void) umask(umask(S_IWGRP | S_IWOTH) | (S_IWGRP | S_IWOTH)); -#endif /* defined unix */ +#endif #if HAVE_GETTEXT (void) setlocale(LC_ALL, ""); #ifdef TZ_DOMAINDIR @@ -854,10 +853,10 @@ _("%s: panic: Invalid l_value %d\n"), ** Call error with errstring and return zero on errors. */ -static long +static zic_t gethms(const char *string, const char *const errstring, const int signable) { - long hh; + zic_t hh; int mm, ss, sign; if (string == NULL || *string == '\0') @@ -868,11 +867,11 @@ gethms(const char *string, const char *const errstring, const int signable) sign = -1; ++string; } else sign = 1; - if (sscanf(string, scheck(string, "%ld"), &hh) == 1) + if (sscanf(string, scheck(string, "%"SCNdZIC), &hh) == 1) mm = ss = 0; - else if (sscanf(string, scheck(string, "%ld:%d"), &hh, &mm) == 2) + else if (sscanf(string, scheck(string, "%"SCNdZIC":%d"), &hh, &mm) == 2) ss = 0; - else if (sscanf(string, scheck(string, "%ld:%d:%d"), + else if (sscanf(string, scheck(string, "%"SCNdZIC":%d:%d"), &hh, &mm, &ss) != 3) { error(errstring); return 0; @@ -883,7 +882,7 @@ gethms(const char *string, const char *const errstring, const int signable) error(errstring); return 0; } - if (LONG_MAX / SECSPERHOUR < hh) { + if (ZIC_MAX / SECSPERHOUR < hh) { error(_("time overflow")); return 0; } @@ -892,8 +891,8 @@ gethms(const char *string, const char *const errstring, const int signable) if (noise && (hh > HOURSPERDAY || (hh == HOURSPERDAY && (mm != 0 || ss != 0)))) warning(_("values over 24 hours not handled by pre-2007 versions of zic")); - return oadd(eitol(sign) * hh * eitol(SECSPERHOUR), - eitol(sign) * (eitol(mm) * eitol(SECSPERMIN) + eitol(ss))); + return oadd(sign * hh * SECSPERHOUR, + sign * (mm * SECSPERMIN + ss)); } static void @@ -1058,8 +1057,9 @@ inleap(register char ** const fields, const int nfields) register const char * cp; register const struct lookup * lp; register int i, j; - int year, month, day; - long dayoff, tod; + zic_t year; + int month, day; + zic_t dayoff, tod; zic_t t; if (nfields != LEAP_FIELDS) { @@ -1068,7 +1068,7 @@ inleap(register char ** const fields, const int nfields) } dayoff = 0; cp = fields[LP_YEAR]; - if (sscanf(cp, scheck(cp, "%d"), &year) != 1) { + if (sscanf(cp, scheck(cp, "%"SCNdZIC), &year) != 1) { /* ** Leapin' Lizards! */ @@ -1089,7 +1089,7 @@ inleap(register char ** const fields, const int nfields) --j; i = -len_years[isleap(j)]; } - dayoff = oadd(dayoff, eitol(i)); + dayoff = oadd(dayoff, i); } if ((lp = byword(fields[LP_MONTH], mon_names)) == NULL) { error(_("invalid month name")); @@ -1099,7 +1099,7 @@ inleap(register char ** const fields, const int nfields) j = TM_JANUARY; while (j != month) { i = len_months[isleap(year)][j]; - dayoff = oadd(dayoff, eitol(i)); + dayoff = oadd(dayoff, i); ++j; } cp = fields[LP_DAY]; @@ -1108,7 +1108,7 @@ inleap(register char ** const fields, const int nfields) error(_("invalid day of month")); return; } - dayoff = oadd(dayoff, eitol(day - 1)); + dayoff = oadd(dayoff, day - 1); if (dayoff < 0 && !TYPE_SIGNED(zic_t)) { error(_("time before zero")); return; @@ -1233,17 +1233,17 @@ rulesub(register struct rule *const rp, rp->r_lowasnum = lp == NULL; if (!rp->r_lowasnum) switch ((int) lp->l_value) { case YR_MINIMUM: - rp->r_loyear = INT_MIN; + rp->r_loyear = ZIC_MIN; break; case YR_MAXIMUM: - rp->r_loyear = INT_MAX; + rp->r_loyear = ZIC_MAX; break; default: /* "cannot happen" */ (void) fprintf(stderr, _("%s: panic: Invalid l_value %d\n"), progname, lp->l_value); exit(EXIT_FAILURE); - } else if (sscanf(cp, scheck(cp, "%d"), &rp->r_loyear) != 1) { + } else if (sscanf(cp, scheck(cp, "%"SCNdZIC), &rp->r_loyear) != 1) { error(_("invalid starting year")); return; } @@ -1252,10 +1252,10 @@ rulesub(register struct rule *const rp, rp->r_hiwasnum = lp == NULL; if (!rp->r_hiwasnum) switch ((int) lp->l_value) { case YR_MINIMUM: - rp->r_hiyear = INT_MIN; + rp->r_hiyear = ZIC_MIN; break; case YR_MAXIMUM: - rp->r_hiyear = INT_MAX; + rp->r_hiyear = ZIC_MAX; break; case YR_ONLY: rp->r_hiyear = rp->r_loyear; @@ -1265,7 +1265,7 @@ rulesub(register struct rule *const rp, _("%s: panic: Invalid l_value %d\n"), progname, lp->l_value); exit(EXIT_FAILURE); - } else if (sscanf(cp, scheck(cp, "%d"), &rp->r_hiyear) != 1) { + } else if (sscanf(cp, scheck(cp, "%"SCNdZIC), &rp->r_hiyear) != 1) { error(_("invalid ending year")); return; } @@ -1330,7 +1330,7 @@ rulesub(register struct rule *const rp, } static void -convert(const long val, char *const buf) +convert(const int_fast32_t val, char *const buf) { register int i; register int shift; @@ -1352,7 +1352,7 @@ convert64(const zic_t val, char *const buf) } static void -puttzcode(const long val, FILE *const fp) +puttzcode(const int_fast32_t val, FILE *const fp) { char buf[4]; @@ -1639,12 +1639,12 @@ writezone(const char *const name, const char *const string) tzh = tzh0; (void) strncpy(tzh.tzh_magic, TZ_MAGIC, sizeof tzh.tzh_magic); tzh.tzh_version[0] = ZIC_VERSION; - convert(eitol(thistypecnt), tzh.tzh_ttisgmtcnt); - convert(eitol(thistypecnt), tzh.tzh_ttisstdcnt); - convert(eitol(thisleapcnt), tzh.tzh_leapcnt); - convert(eitol(thistimecnt), tzh.tzh_timecnt); - convert(eitol(thistypecnt), tzh.tzh_typecnt); - convert(eitol(thischarcnt), tzh.tzh_charcnt); + convert(thistypecnt, tzh.tzh_ttisgmtcnt); + convert(thistypecnt, tzh.tzh_ttisstdcnt); + convert(thisleapcnt, tzh.tzh_leapcnt); + convert(thistimecnt, tzh.tzh_timecnt); + convert(thistypecnt, tzh.tzh_typecnt); + convert(thischarcnt, tzh.tzh_charcnt); DO(tzh_magic); DO(tzh_version); DO(tzh_reserved); @@ -1657,7 +1657,7 @@ writezone(const char *const name, const char *const string) #undef DO for (i = thistimei; i < thistimelim; ++i) if (pass == 1) - puttzcode((long) ats[i], fp); + puttzcode(ats[i], fp); else puttzcode64(ats[i], fp); for (i = thistimei; i < thistimelim; ++i) { unsigned char uc; @@ -1751,7 +1751,7 @@ doabbr(char *const abbr, const char *const format, const char *const letters, } static void -updateminmax(const int x) +updateminmax(const zic_t x) { if (min_year > x) min_year = x; @@ -1760,7 +1760,7 @@ updateminmax(const int x) } static int -stringoffset(char *result, long offset) +stringoffset(char *result, zic_t offset) { register int hours; register int minutes; @@ -1790,10 +1790,10 @@ stringoffset(char *result, long offset) } static int -stringrule(char *result, const struct rule *const rp, const long dstoff, - const long gmtoff) +stringrule(char *result, const struct rule *const rp, const zic_t dstoff, + const zic_t gmtoff) { - register long tod; + register zic_t tod; result = end(result); if (rp->r_dycode == DC_DOM) { @@ -1856,7 +1856,7 @@ stringzone(char *result, const struct zone *const zpfirst, const int zonecount) stdrp = dstrp = NULL; for (i = 0; i < zp->z_nrules; ++i) { rp = &zp->z_rules[i]; - if (rp->r_hiwasnum || rp->r_hiyear != INT_MAX) + if (rp->r_hiwasnum || rp->r_hiyear != ZIC_MAX) continue; if (rp->r_yrtype != NULL) continue; @@ -1931,10 +1931,10 @@ outzone(const struct zone * const zpfirst, const int zonecount) register int i, j; register int usestart, useuntil; register zic_t starttime, untiltime; - register long gmtoff; - register long stdoff; - register int year; - register long startoff; + register zic_t gmtoff; + register zic_t stdoff; + register zic_t year; + register zic_t startoff; register int startttisstd; register int startttisgmt; register int type; @@ -1968,7 +1968,7 @@ outzone(const struct zone * const zpfirst, const int zonecount) min_year = max_year = EPOCH_YEAR; if (leapseen) { updateminmax(leapminyear); - updateminmax(leapmaxyear + (leapmaxyear < INT_MAX)); + updateminmax(leapmaxyear + (leapmaxyear < ZIC_MAX)); } /* ** Reserve type 0. @@ -2003,12 +2003,12 @@ wp = ecpyalloc(_("no POSIX environment variable for zone")); free(wp); } if (envvar[0] == '\0') { - if (min_year >= INT_MIN + YEARSPERREPEAT) + if (min_year >= ZIC_MIN + YEARSPERREPEAT) min_year -= YEARSPERREPEAT; - else min_year = INT_MIN; - if (max_year <= INT_MAX - YEARSPERREPEAT) + else min_year = ZIC_MIN; + if (max_year <= ZIC_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; - else max_year = INT_MAX; + else max_year = ZIC_MAX; /* ** Regardless of any of the above, ** for a "proDSTic" zone which specifies that its rules @@ -2074,7 +2074,7 @@ wp = ecpyalloc(_("no POSIX environment variable for zone")); for ( ; ; ) { register int k; register zic_t jtime, ktime; - register long offset; + register zic_t offset; INITIALIZE(ktime); if (useuntil) { @@ -2216,7 +2216,7 @@ addtt(const zic_t starttime, int type) } static int -addtype(const long gmtoff, const char *const abbr, const int isdst, +addtype(const zic_t gmtoff, const char *const abbr, const int isdst, const int ttisstd, const int ttisgmt) { register int i, j; @@ -2295,7 +2295,7 @@ leapadd(const zic_t t, const int positive, const int rolling, int count) roll[j] = roll[j - 1]; } trans[i] = t; - corr[i] = positive ? 1L : eitol(-count); + corr[i] = positive ? 1 : -count; roll[i] = rolling; ++leapcnt; } while (positive && --count != 0); @@ -2305,7 +2305,7 @@ static void adjleap(void) { register int i; - register long last = 0; + register zic_t last = 0; /* ** propagate leap seconds forward @@ -2439,10 +2439,10 @@ getfields(register char *cp) return array; } -static ATTRIBUTE_PURE long -oadd(const long t1, const long t2) +static ATTRIBUTE_PURE zic_t +oadd(const zic_t t1, const zic_t t2) { - if (t1 < 0 ? t2 < LONG_MIN - t1 : LONG_MAX - t1 < t2) { + if (t1 < 0 ? t2 < ZIC_MIN - t1 : ZIC_MAX - t1 < t2) { error(_("time overflow")); exit(EXIT_FAILURE); } @@ -2450,7 +2450,7 @@ oadd(const long t1, const long t2) } static ATTRIBUTE_PURE zic_t -tadd(const zic_t t1, const long t2) +tadd(const zic_t t1, const zic_t t2) { if (t1 == max_time && t2 > 0) return max_time; @@ -2469,15 +2469,15 @@ tadd(const zic_t t1, const long t2) */ static zic_t -rpytime(register const struct rule *const rp, register const int wantedy) +rpytime(register const struct rule *const rp, register const zic_t wantedy) { - register int y, m, i; - register long dayoff; /* with a nod to Margaret O. */ - register zic_t t; + register int m, i; + register zic_t dayoff; /* with a nod to Margaret O. */ + register zic_t t, y; - if (wantedy == INT_MIN) + if (wantedy == ZIC_MIN) return min_time; - if (wantedy == INT_MAX) + if (wantedy == ZIC_MAX) return max_time; dayoff = 0; m = TM_JANUARY; @@ -2490,11 +2490,11 @@ rpytime(register const struct rule *const rp, register const int wantedy) --y; i = -len_years[isleap(y)]; } - dayoff = oadd(dayoff, eitol(i)); + dayoff = oadd(dayoff, i); } while (m != rp->r_month) { i = len_months[isleap(y)][m]; - dayoff = oadd(dayoff, eitol(i)); + dayoff = oadd(dayoff, i); ++m; } i = rp->r_dayofmonth; @@ -2507,12 +2507,12 @@ rpytime(register const struct rule *const rp, register const int wantedy) } } --i; - dayoff = oadd(dayoff, eitol(i)); + dayoff = oadd(dayoff, i); if (rp->r_dycode == DC_DOWGEQ || rp->r_dycode == DC_DOWLEQ) { - register long wday; + register zic_t wday; -#define LDAYSPERWEEK ((long) DAYSPERWEEK) - wday = eitol(EPOCH_WDAY); +#define LDAYSPERWEEK ((zic_t) DAYSPERWEEK) + wday = EPOCH_WDAY; /* ** Don't trust mod of negative numbers. */ @@ -2523,7 +2523,7 @@ rpytime(register const struct rule *const rp, register const int wantedy) if (wday < 0) wday += LDAYSPERWEEK; } - while (wday != eitol(rp->r_wday)) + while (wday != rp->r_wday) if (rp->r_dycode == DC_DOWGEQ) { dayoff = oadd(dayoff, 1); if (++wday >= LDAYSPERWEEK) @@ -2598,7 +2598,7 @@ mp = _("time zone abbreviation differs from POSIX standard"); exit(EXIT_FAILURE); } (void) strcpy(&chars[charcnt], string); - charcnt += eitol(i); + charcnt += i; } static int @@ -2612,7 +2612,7 @@ mkdirs(char *argname) cp = name = ecpyalloc(argname); while ((cp = strchr(cp + 1, '/')) != 0) { *cp = '\0'; -#ifndef unix +#ifdef HAVE_DOS_FILE_NAMES /* ** DOS drive specifier? */ @@ -2621,7 +2621,7 @@ mkdirs(char *argname) *cp = '/'; continue; } -#endif /* !defined unix */ +#endif if (!itsdir(name)) { /* ** It doesn't seem to exist, so we try to create it. @@ -2647,21 +2647,6 @@ _("%s: Can't create directory %s: %s\n"), return 0; } -static ATTRIBUTE_PURE long -eitol(const int i) -{ - long l; - - l = i; - if ((i < 0 && l >= 0) || (i == 0 && l != 0) || (i > 0 && l <= 0)) { - (void) fprintf(stderr, - _("%s: %d did not sign extend correctly\n"), - progname, i); - exit(EXIT_FAILURE); - } - return l; -} - /* ** UNIX was a registered trademark of The Open Group in 2003. */ -- 1.8.1.2

1 0

On merging timezones - a radical proposal.
by random832＠fastmail.us May 24, 2013

May 24, 2013

Or, more precisely, on the subject evicting redundant timezones from the user selection menu, since of course all current names will continue to exist as links if nothing else. I've thought about this some more, and I don't think it goes far enough. A user installing a new system doesn't _care_ about (my own proper time zone) America/Indianapolis, they don't have any need to accurately convert times from before _2006_ let alone 1970. Most users could probably be served just as well with America/New_York. I think it would be useful - particularly if we're abandoning being able to narrow it down by country - to define a heavily cut down set of "basic" time zones, that define each set of rules that exists _now_ without care for maintaining the past back to 1970, and then offer an "advanced" option for the rest. -- Random832

20 33

minor cleaning in Makefile
by Denis Excoffier May 23, 2013

May 23, 2013

Hello, Now that NOID is gone, there is no point to keep it in Makefile (patch attached). Regards, Denis Excoffier.

2 1

Unable to compile Antarctica/Macquarie
by Alan Gutierrez May 23, 2013

May 23, 2013

I'm compiling the TZ database using the using the `zic` from the source distributed with the database checked out from GitHub. I'm using the commit that relates to the `tz2013c` release. I'm not able to get an Australian EST timezone offset for dates before October 1916 for Antarctica/Macquarie. I'm using both Ruby 1.9.3p392 and GNU date 8.15. When I compile the TZ database at commit 188b29d966; "Fix times of habitation for Macquarie to agree with Tasmania history" I get the unhabited offset and abbreviation. % TZ="$PWD/build/zoneinfo/Antarctica/Macquarie" date -d "1916/09/30 16:00 UTC" Sun Oct 1 03:00:00 EST 1916 % TZ="$PWD/build/zoneinfo/Antarctica/Macquarie" date -d "1916/09/30 15:59 UTC" Sat Sep 30 15:59:00 zzz 1916 When I compile the TZ database at commit a676f5ad3b; "Macquarie Island is politically part of Australia, not Antarctica" I get the correct offset and abbreviation. % TZ="$PWD/build/zoneinfo/Antarctica/Macquarie" date -d "1916/09/30 16:00 UTC" Sun Oct 1 03:00:00 EST 1916 % TZ="$PWD/build/zoneinfo/Antarctica/Macquarie" date -d "1916/09/30 15:59 UTC" Sun Oct 1 01:59:00 EST 1916 Using this commit, if I change the date of the first line of the Zone from "1899 Nov" back to "1911", it starts to work again. Here is the change set that causes the confusion. https://github.com/eggert/tz/commit/188b29d9664cfcf0384e515c69f94a2dfc27c673 I am on a 32-bit system but in my experience, I'm always able to get a correct timezone offset for dates in 1916 regardless of whether or not the zone begins before the range of a 32-bit POSIX time. -- Alan Gutierrez ~ @bigeasy

3 3

Re: [tz] [tzdb] Re: Dropping iso3166.tab
by random832＠fastmail.us May 23, 2013

May 23, 2013

On Thu, May 23, 2013, at 11:13, Tobias Conradi wrote: > IL-JM is for the Jerusalem District says > http://www.statoids.com/uil.html > > PS-JEM for the Jerusalem Governorate says > http://www.iso.org/iso/iso_3166-2_newsletter_ii-3_2011-12-13.pdf > > None is for the city. Both of them contain disputed territory - as far as I can tell, IL-JM consists of nothing but disputed territory.

1 0

Re: [tz] tz Digest, Vol 20, Issue 28
by Shawn Steele May 21, 2013

May 21, 2013

> Say that Floofy (fl) and Fnord (fn) claim ownership of the large city of Fubar. I don't see anything > wrong with putting Fubar in fl and fn. This way people in Floofy and Fnord see the city they expect > to be there. And at the end of the day that's what tzinfo is for. Logically, that makes sense, however geopolitically, people will figure out a way to object. The Fnordians would complain that Fubar doesn't belong in Floofy because it's part of Fnord. How would you or I feel if New York showed up in Canada? At the very least you'd report the bug. If the vendor pushed back on the bug, we'd probably push back with "what, are you crazy? NY is clearly in the US, not Canada." Geopolitics isn't about logic. That said, it might be possible in some cases to attach a city to two region codes. Or to create two cities for the same place. > My goal is to reduce the political debate on this list, and leave it to the diplomats and the standards committees > that are under their control, to determine what is a country, and what city is in a country - > then reflect those decisions in the database. That works a bit. However it breaks down when someone wants to ship software that depends on the data. Then their customers push the same problems. And, note, that the IANA Timezone Database *IS* the standard, and we *ARE* the standard committee. It should be perfectly acceptable to point to ISO for the ISO standards though. The timezone data shouldn't pick & choose from other standards, if someone expresses a concern with another standard that the tzdb depends on, they should be pointed to the other standard to address it there. Worse, if someone objects to another standard's behavior, they could attempt to use the timezone effort to pressure the other standard, assuming they can get the timezone effort to see their viewpoint. IMO we should leave external standards alone, and focus on the timezone parts. A rather obvious alternate mapping would be to map to zones rather than cities, however that'd undoubtedly have it's own geopolitical problems. - Shawn

1 0

Re: [tz] Dropping iso3166.tab
by Benjamin Kerensa May 20, 2013

May 20, 2013

On 05/20/13 22:27, Paul Eggert wrote: > I have been thinking of proposing to drop iso3166.tab from the > tz distribution, and to drop all uses of country codes. > This would help simplify maintenance, as it would mean > that the database would be unaffected by political > issues such as whether Kosovo is a country, what country > Jerusalem is in, what country Taipei is in, etc. The idea > is to simplify the database to help us focus on our charter > (namely, civil time) and to be less distracted by political > issues that do not affect the clocks. > > As part of this change, the first column of zone.tab > would change from its current role (a country code) > to be just a comment. > > I was thinking of changing the comment to be just "--", > for every entry in zone.tab. How would this change > affect FreeBSD's use of zone.tab? I'm unsure how this might affect FreeBSD but notably some Linux Distros including Ubuntu use this data and it could possibly impact Ubuntu's ubiquity installer. -- Benjamin Kerensa http://benjaminkerensa.com "I am what I am because of who we all are" - Ubuntu

1 0

Re: [tz] Dropping iso3166.tab [SEC=UNOFFICIAL]
by Timothy Arceri May 20, 2013

May 20, 2013

> Please don't drop it. PHP's date/time support makes use of the country codes to allow selection of possible timezones per country: > http://us2.php.net/manual/en/datetimezone.listidentifiers.php I'm pretty sure Ubuntus installer (ubiquity) does the same thing.

1 0

Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
by Ephraim Silverberg May 13, 2013

May 13, 2013

With regard to the populations of Jerusalem and Tel Aviv, there are two municipal entities: the Municipality of Jerusalem and the Municipality of Tel-Aviv-Jafo (note that Tel-Aviv and Jafo are one municipal entity so perhaps Asia/Tel_Aviv_Jafo would be a better way to express this alias to Asia/Jerusalem) -- see http://www.tel-aviv.gov.il/ There concepts Greater/Metro Jerusalem and Greater/Metro Tel-Aviv are literary and, perhaps, political concepts but do not represent any real municipal boundaries. The term "Greater Jerusalem" would include cities such as Bethlehem, Mevaseret Zion and perhaps the "E1" areas between Jerusalem and Ma'ale Adumin. So too "Greater Tel Aviv" would include the adjacent cities Givatayim, Ramat Gan, Bnei Brak and perhaps Petach Tikva. However, these concepts have no actual governing bodies and each of the adjacent cities have there own distinct and independent municipality. The Central Bureau of Statistics records the population of Jerusalem as 772,982 while the population of Tel-Aviv-Jafo is 403,738. The whole discussion of the de jure status of Jerusalem is disingenuous since the vast majority of the world countries de facto have regarded the west portion of Jerusalem not only as part of Israel but the seat of its government since February 1949. Foreign dignitaries and heads of state are received at government offices in western Jerusalem. Presidents Carter, Clinton and George W. Bush have addressed the Knesset directly as well as German Chancellor Angela Merkel. Moreover, Egyptian President Anwar Sadat addressed the Knesset in November 1977 _prior_ to the signing of the Camp David peace accords. All ambassadors to Israel present their credentials to Israel's President at the Presidential Residence in western Jerusalem. It is correct that most foreign officials avoiding meeting Israeli officials at offices in eastern Jerusalem although this rule too has its exceptions as in the case of Canada's Foreign Minister John Baird meeting with Israel's Justice Minister Tzipi Livni at her eastern Jerusalem office last month. I could bring a wealth of quotes that foreign officials have stated with regard to Jerusalem and western Jerusalem in particular over the years. However, I regards this forum as a professional forum for discussing timezone changes past, present and future as well as the maintenance of the timezone files themselves and the C code for the timezone software and, hence, view all discussions of a political nature as raising the noise/signal ration here. There are a plethora of forums for debating such issues for those who wish to do so. _____________________________________ Ephraim Silverberg, CSE System Group, Hebrew University, Jerusalem, Israel. Phone/Fax number: +972-2-5494521

4 3

Old CLDR tz chart link in tz-link.htm
by yoshito_umaoka＠us.ibm.com May 10, 2013

May 10, 2013

tz-link.html in tzcode2013c contains a link to the CLDR tzid chart page as below: <li>Some Microsoft Windows versions contain time zone information in an undocumented format, with IDs that can be mapped to <code>TZ</code> values using the <a href=" http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/zone_tzid.html ">Zone → Tzid table</a> maintained by the <abbr title="Common Locale Data Repository">CLDR</abbr> data mentioned below.</li> The URL is not permanent (cldr-tmp) and the linked page contains out of date information (CLDR 21 - latest version is 23). The correct URL is http://unicode.org/cldr/charts/supplemental/zone_tzid.html Please fix the link in the next tz version. Thanks, Yoshito

2 1

Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
by Marc Lehmann May 9, 2013

May 9, 2013

On Tue, May 07, 2013 at 05:15:04PM -0400, random832(a)fastmail.us wrote: > On Tue, May 7, 2013, at 16:01, Marc Lehmann wrote: > > Yes, at least one timezone exists for any region, by definition, as > > long as that region actually has a physical location, as the timezone > > identifiers are meant to (roughly) identify the largest city within a > > region (where region is not defined by political boundaries). > > This is where you are mistaken. You surely have some evidence to back this up? The timezone database has always defined timezone regions that way. Saying it ain't so doesn't make it so. > The regions are _absolutely_ defined by political boundaries. It's why That is your _goal_, yes, but where does it say so? For one thing, the ISO 3166 codes do not define regions nor political boundaries, nor do the timezone identifier define political boundaries (but regions). It really seems to me that you want to unilaterally redefine the meaning of timezones and regions to further your political agenda - if you interpret the timezone database data traditionally and without prejuduice it doesn't say what you wish it to say. The political interpretation of the data is yours alone. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp(a)schmorp.de -=====/_/_//_/\_,_/ /_/\_\

2 3

Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
by Tobias Conradi May 8, 2013

May 8, 2013

== Current IANA time zone database situation == ftp://ftp.iana.org/tz/data/zone.tab contains one zone for ISO country code "IL" named Asia/Jerusalem. IL decodes to ISRAEL http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_tab… == Problem == Jerusalem is internationally not recognized as part of Israel. Using Jerusalem as reference location for Israel in the IANA time zone database may thus violate UN resolutions. == Solution == ftp://ftp.iana.org/tz/code/Theory reads "Use the most populous among locations in a country's time zone", this seems to be Tel Aviv. That would mean using Asia/Tel_Aviv. == Information on the status of Jerusalem == No UN member has an embassy in Jerusalem says: http://en.wikipedia.org/wiki/Positions_on_Jerusalem There is no UN LOCODE for Jerusalem in the IL-file: http://www.unece.org/fileadmin/DAM/cefact/locode/il.htm The page http://www.un.org/Depts/dpi/palestine/ links to "The Status of Jerusalem" http://www.un.org/Depts/dpi/palestine/ch12.pdf The penultimate paragraph reads: "The General Assembly revisited the question of Jerusalem at its fifty-fifth session. In a resolution adopted on 1 December 2000, the Assembly determined that the decision of Israel to impose its laws, jurisdiction and administration on the Holy City of Jerusalem was illegal and, therefore, null and void. The Assembly also deplored the transfer by some States of their diplomatic missions to Jerusalem in violation of Security Council resolution 478 (1980)." The UN SC Resolution 478 can be found at http://www.un.org/documents/sc/res/1980/scres80.htm -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

21 40

tabs vs spaces
by David Muir Sharnoff May 8, 2013

May 8, 2013

I wanted to extract some of the data from the timezone files so I wrote a quick parser for them. In the process I discovered 1,477 lines that have spaces where they should have tabs. Do you care? If so, do you want to fix them with (a) my fixup script (b) a patch that I generate; (c) by hand -- I can list the file names and line numbers? -Dave

18 62

Israel
by David Patte ₯ May 7, 2013

May 7, 2013

I will suggest, as I did a month ago for Australia, that we prepare an alternate patch for the tz database - this time for Israel. We can prepare it offline, to cut down on the noise here, and submit it for approval to the maintainers of the tz database, for their perusal. In the mean time, I am willing to host the preparation and patch on my own site and ftp server. The goal in the patch will be to try to follow the decisions re Jerusalem mandated by the UN security council, the UN general assembly, and accepted by all countries in the world (save Israel), which is to consider Israel's unilateral declaration of Jerusalem as its own as 'null and void', and fully remove Jerusalem as being listed within Israel. Those that consider this decision valuable could then apply it to the tz database themselves. Please contact me offline if you would like more information on how to contribute to this patch, or how to access the result.

1 0

Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
by SM May 7, 2013

May 7, 2013

Hi Malcolm, At 09:55 07-05-2013, Wallace, Malcolm wrote: >One technical point worth considering is that a goodly proportion of >the clocks in Jerusalem do not show the time that the tz database >would claim they do. Given rough current estimates that the Arab >population of (East) Jerusalem is upwards of 35%, and the likelihood >that many of their clocks follow the Palestinian rules for DST >rather than the Israeli rules, it seems awkward and inaccurate to >use the name of the city for one set of rules but not the other. Thanks for the link. It's difficult to pick a source from that part of the world without bias. It's an unusual case. It's easier to leave it as it is until someone figures out how people at that location keep track of time. Regards, -sm

2 1

Tobias Conradi blocked for six months
by Paul Eggert May 5, 2013

May 5, 2013

Recent emails to the tz mailing list by Tobias Conradi are an inappropriate and disruptive use of the list. I privately warned him about this earlier, to no avail. I will therefore block him posting for a period of six months.

3 2

suprfsat@hotmail.com - Fwd:
by Tobias Conradi May 4, 2013

May 4, 2013

And this was the first. I assume they are all from Paul Eggert. ---------- Forwarded message ---------- From: supr fsat <suprfsat(a)hotmail.com> Date: Sat, May 26, 2012 at 8:33 PM Subject: To: tobias.conradi(a)gmail.com shut the fuck up -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

2 1

suprfsat@hotmail.com - Fwd: you fucking psychopath
by Tobias Conradi May 4, 2013

May 4, 2013

Is this email coming from Paul Eggert? Last time I got such an email around the time my emails got censored by the tz mailing list administrators. ---------- Forwarded message ---------- From: supr fsat <suprfsat(a)hotmail.com> Date: Sat, May 4, 2013 at 9:13 PM Subject: you fucking psychopath To: Tobias Conradi <mail.2012(a)tobiasconradi.com> don't you have a life? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

2 1

History of zone name changes
by Tobias Conradi May 4, 2013

May 4, 2013

2 1

suprfsat@hotmail.com Fwd: ACTIONS
by Tobias Conradi May 4, 2013

May 4, 2013

That was the last email by suprfsat(a)hotmail.com before the one I received today. ---------- Forwarded message ---------- From: supr fsat <suprfsat(a)hotmail.com> Date: Wed, Jun 6, 2012 at 2:44 PM Subject: ACTIONS To: tobias.conradi(a)gmail.com CONSEQUENCES -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Position of Arthur David Olson and Paul Eggert regarding the status of Jerusalem
by Tobias Conradi May 4, 2013

May 4, 2013

1) https://github.com/eggert/tz/commit/65a7988fe8b4007023ef2130064421eacd263e4c says "Arthur David Olson authored 17 years ago" "+IL +3146+03514 Asia/Jerusalem most locations" Was Arthur David Olson the one who first declared Jerusalem to be Israel territory? Maybe the one who put that in, could state the reasons for doing so and provide a patch if he thinks this should be changed now. 2) The current IANA time zone database maintainer is Paul Eggert. There is no reply to the proposal to change the zone identifying location for the Israel zone from Jerusalem to Tel Aviv. http://mm.icann.org/pipermail/tz/2013-April/019134.html "Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel" Does Paul Eggert endorse the decision to have Jerusalem (in fact even parts or all of East Jerusalem) declared Israel territory in the IANA time zone database? If so, what is the reason? Support of occupation, annexation and population exchange? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

East Jerusalem as Israel territory in IANA zone.tab, demographics since occupation by Israel
by Tobias Conradi May 4, 2013

May 4, 2013

ftp://ftp.iana.org/tz/data/zone.tab has IL +3146+03514 Asia/Jerusalem http://www.wolframalpha.com/input/?i=%2B31deg+46N+%2B035+deg+14E computes 31.7667°N, 35.2333°E https://maps.google.com/maps?q=31.7667,35.2333 shows a dashed line labeled "1949 Armistice Agreement Line" to the West of that location. ------ http://unispal.un.org/unispal.nsf/f45643a78fcba719852560f6005987ad/3077feeb… "The 1967 census conducted by the Israeli authorities indicated that 66,000 Palestinians resided in East Jerusalem, 44,000 of whom resided in the area known before the June war as East Jerusalem and 22,000 in the West Bank area annexed after the war. At the time there were a few hundred Jews living in East Jerusalem. In June 1993, the Israeli Government was able to proudly announce that a Jewish majority had been achieved in East Jerusalem; at the same time, 155,000 Jews were officially-registered residents, as compared to 150,000 Palestinians." ------- -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Re: [tz] tabs vs spaces
by Shawn Steele May 4, 2013

May 4, 2013

> Actually, I suggest that we should really be discouraging people from creating alternate parsers for the zone input files than zic - those two should remain closely tied together. From time to time we discover the need to add some new feature to the input language, doing that is really hard if all kinds of other implementations will suddenly break. That makes it even harder? Because presumably the code behavior changes too, which would be harder to adapt to. IMO this seems like a further argument for XML as it's pretty easy to extend some things w/o breaking other stuff > Further, the input file format is rather quirky, and hard to explain completely in a way that makes a lot of sense (though it is perfectly fine for zic). I don't find that comforting or reassuring. -Shawn

4 3

Re: [tz] tabs vs spaces
by SM May 3, 2013

May 3, 2013

At 09:36 03-05-2013, random832(a)fastmail.us wrote: >The RFC itself is very inadequate to the task. It does not once define >what "the TZ database" actually contains, or the format of any files >within. To the extent that it defines it by reference, one could >interpret it as giving official standing to all of the documentation >files within the project. Or maybe all that authority is delegated to >the TZ coordinator. Please do not consider anything in this message as authoritative. The RFC was written to find a host for the TZ database. The TZ coordinator keeps things running. Regards, -sm

1 0

Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect
by Tobias Conradi May 3, 2013

May 3, 2013

On Sun, Mar 31, 2013 at 1:24 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > For example, you gave a link to the > NSW Dept of Attorney General & Justice saying that in summer, eastern time > is abbreviated "AEDT". But that very web page also says, in another > place, that the abbreviation is "EDST". So this single source contradicts > the assertion that abbreviations are consistently used by the NSW > government. > > Here's that URL again: > > http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight/definitions_o… > > And the EDST-related quote from that page: > > "Daylight saving or summer time is commonly expressed as EDST (Eastern Daylight Saving Time)." For the record: 2013-03-31 Tobias Conradi sent via http://www.lawlink.nsw.gov.au/feedback/LawlinkCaselawFeedback.nsf/frmWebFee… --------------- Two abbreviations used for what looks like one thing at http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight/definitions_o… 1) EDST: Daylight saving or summer time is commonly expressed as EDST (Eastern Daylight Saving Time). 2) AEDT: NSW, ACT,Vic and Tas move from AEST to Australian Eastern Daylight Time (AEDT), ... --------------- 2013-04-30 communityrelations.lawlink.nsw.gov.au emailed (to a wrong email address, so that's why I sent it today): --------------- 30/04/2013 10:54 AM Please respond to .... agd.nsw.gov.au To .... tobiasconradi.com cc Subject Your online feedback about daylight saving (matter13/002220) Dear Mr Conradi Thank you for the feedback, which you submitted regarding abbreviations that are used on the Department's website for daylight saving. You may be interested to know that the Department has noted your concerns and has updated its website accordingly. Thank you for taking the time to make your concerns known. .... Yours faithfully for Director Community Relations Unit NSW Department of Attorney General & Justice Locked Bag 5111, Parramatta NSW 2124 ....... --------------- -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Fwd: offtopic? csail.mit.edu - tabs vs spaces
by Tobias Conradi May 2, 2013

May 2, 2013

Garrett Wollman has question that involves copyright. I am not a lawyer, maybe someone else can help. ---------- Forwarded message ---------- From: Garrett Wollman <wollman(a)csail.mit.edu> Date: Fri, May 3, 2013 at 1:37 AM Subject: [tz] offtopic? csail.mit.edu - tabs vs spaces To: Tobias Conradi <mail.2012(a)tobiasconradi.com> <<On Fri, 3 May 2013 01:10:29 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: > Can someone help GAWollman how to only get emails that he wants? What part of "do not post private email to public mailing-lists without the copyright owner's permission" don't you understand? -GAWollman -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

offtopic? csail.mit.edu - tabs vs spaces
by Tobias Conradi May 2, 2013

May 2, 2013

Can someone help GAWollman how to only get emails that he wants? On Fri, May 3, 2013 at 1:03 AM, Garrett Wollman <wollman(a)csail.mit.edu> wrote: > <<On Fri, 3 May 2013 00:53:22 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: > >> On Fri, May 3, 2013 at 12:02 AM, Garrett Wollman <wollman(a)csail.mit.edu> wrote: >>> <<On Thu, 2 May 2013 22:18:50 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: >>> >>>>> you seem to be >>>>> being deliberately disingenuous. >>>> To you. >>> >>> No, to everyone. >> Not to me. > >>> Please go away. >> What BCP or Theory rule you are referring to? > > There is no BCP rule that says "don't be a twit in public"; you are > expected to have learned this in primary school. > >>> You are wasting everyone's valuable >>> time and attention. >> You cannot know that. > > You are certainly wasting my valuable time and attention, and I don't > believe that I am atypical. > > I do not recall giving you permission to repost my email to a public > mailing-list. > > -GAWollman -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Re: [tz] tabs vs spaces
by Tobias Conradi May 2, 2013

May 2, 2013

On Fri, May 3, 2013 at 12:02 AM, Garrett Wollman <wollman(a)csail.mit.edu> wrote: > <<On Thu, 2 May 2013 22:18:50 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: > >>> you seem to be >>> being deliberately disingenuous. >> To you. > > No, to everyone. Not to me. > Please go away. What BCP or Theory rule you are referring to? > You are wasting everyone's valuable > time and attention. You cannot know that. > -GAWollman -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

2 1

Russian Asia/Khandyga Asia/Ust-Nera
by Marvel, Jim (CPCOE) April 30, 2013

April 30, 2013

Hi, Will there be a new shapefile due to the tz_data change? Thanks Jim Marvel Software Engineer II Honeywell ESEA/CMS/CP/CoE 8323 Lindbergh Court Sarasota FL 34243 Phone - 941.360.6209 (alt: 941.360.6213) Fax - 941.355.9241 Jim.Marvel(a)Honeywell.com<mailto:nancy.ramm@honeywell.com>

4 4

Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Timothy Arceri April 29, 2013

April 29, 2013

On 31/03/13 01:24, Paul Eggert wrote: >On 03/30/13 03:34, Timothy Arceri wrote: >> The links that I have presented in the other thread make it fairly clear that >> all states *are* using a consistent format for abbreviations. >I'm afraid that doesn't follow. One can easily find disagreements >with the contents of those links. For example, you gave a link to the >NSW Dept of Attorney General & Justice saying that in summer, eastern time >is abbreviated "AEDT". But that very web page also says, in another >place, that the abbreviation is "EDST". So this single source contradicts >the assertion that abbreviations are consistently used by the NSW >government. >Here's that URL again: >http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight/definitions_o… >And the EDST-related quote from that page: >"Daylight saving or summer time is commonly expressed as EDST (Eastern Daylight Saving Time)." Just FYI I contacted the Department to enquire as to why they had included different abbreviations on that page and if they could clarify what abbreviation is officially used. While I did not get a direct response to my questions I did get a reply today: "Thank you for the feedback which you submitted regarding abbreviations the Department uses for daylight saving on its website. You may be interested to know that the Department has noted your concerns and has updated its website accordingly." Looking at the page they have now removed all reference to EDST and have also additionally added abbreviations for all other states mentioned. Tim

1 0

FTP server down?
by enh April 23, 2013

April 23, 2013

i haven't been able to contact the FTP server this morning. i added support for getting updates from the HTTP server ( https://android-review.googlesource.com/57332) but FTP is still the preferred method because: 1. you can get a directory listing via FTP but not HTTP, so if you miss a couple of changes, my script can't take you through the intermediates so the git history remains complete. 2. you can't get the .asc files via HTTP, so no verification. if HTTP is the preferred download method going forward, could we get .asc files on there and have directory listings turned on for the releases directory? --elliott (Android tzdata maintainer)

3 4

Proposal to change Macquarie Island to be Australian territory
by Tobias Conradi April 22, 2013

April 22, 2013

UNESCO http://whc.unesco.org/en/list/629 lists it as Australia | State of Tasmania http://www.iso.org/iso/iso-3166-1_decoding_table does not contain a code for Tasmania, thus Australia "AU" is the applicable code. ftp://ftp.iana.org/tz/data/zone.tab Change AQ -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island To AU -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island ftp://ftp.iana.org/tz/data/antarctica Move Antarctica/Macquarie content to ftp://ftp.iana.org/tz/data/australasia in analogy to Turkey and Russia, ISO countries that are not split between two files. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

15 28

World map showing IANA zone area by colored zone labels
by Tobias Conradi April 22, 2013

April 22, 2013

A map showing the area-part of the time zone with differently colored zone labels has been published, since the image URL may change, here is only an indirect link: http://anna.info/wiki/ANNA_time_zone_maps Areas, as defined in the Theory file, having at least one labeled zone in the map are: America, Europe, Africa, Asia, Australia, Antarctic, Arctic, Atlantic, Indian The unique three character codes have been chosen over the tzids to get more zone labels on the map. All codes that do not contain the character "0" or "1" represent the location part of an UN/LOCODE in that zone, mostly the location. The map is based on data in tz_world_mp.zip from http://efele.net/maps/tz/world/ projected with qgis. I had no time yet to color the zones and did not manage to get higher resolution or SVG. I could make an SVG, but not with the labels. The parallels are multiple of 30 degree from the poles, so the equator is shown as well as the Antartic Treaty boundary. Antarctica/Macquarie and Arctic/Longyearbyen are shown in gray and are the only location labels shown for their area. Looking at the map I found South Georgia, which located in ocean water and has almost the same latitude as Macquarie The coordinates in zone.tab are: -5416-03632 Atlantic/South_Georgia -5430+15857 Antarctica/Macquarie -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

CLDR UN/LOCODE usage
by Tobias Conradi April 21, 2013

April 21, 2013

Was: Re: [tz] Proposal to change Macquarie Island to be Australian territory A reply to :http://mm.icann.org/pipermail/tz/2013-April/019135.html First LOCODE message in the thread was at http://mm.icann.org/pipermail/tz/2013-April/019114.html ------------ On Sat, Apr 20, 2013 at 3:53 PM, Mark Davis ☕ <mark(a)macchiato.com> wrote: > On Fri, Apr 19, 2013 at 12:35 PM, Tobias Conradi > <mail.2012(a)tobiasconradi.com> wrote: >> On Fri, Apr 19, 2013 at 11:17 AM, Mark Davis ☕ <mark(a)macchiato.com> wrote: >> >> Variable length and inconsistent country code usage: >> > >> > This is a misunderstanding. >> Of the UN LOCODE system, on the side of CLDR designers. >> >> > CLDR is specified to use 5 letter UN LOCODEs where they exist. Where >> > they do >> > not exist, it is specified to use a non-5-letter code, precisely so that >> > they do not overlap with future UN LOCODEs. >> That could have been easily achieved with 5-letter codes, as has been >> shown at: >> http://mm.icann.org/pipermail/tz/2012-May/017974.html and >> http://mm.icann.org/pipermail/tz/2012-May/017980.html >> >> If overlap prevention the goal, then there was misunderstanding of the >> UN LOCODE system on the side of CLDR. > > > The only way that there would be a problem for CLDR is if the UN LOCODEs > could be other than 5 alphanumerics. It may be true that there is no /problem for CLDR/ - but the claim was that CLDR has "Variable length and inconsistent country code usage" > > According to > http://www.unece.org/fileadmin/DAM/cefact/locode/unlocode_manual.pdf, the UN > LOCODE would be 5 letters and possibly numbers (in positions 3-5). As long > as any additional CLDR identifiers did not match that, there wouldn't be an > overlap. > > So I don't understand your contention. Are you saying that UN LOCODEs, can > in fact consist of other than 5 alphanumerics? I don't say so, and AFAICS never said so. >> > When the codes are not 5 >> > letters, the first two letters have no meaning. >> Except where they have. And for some from the US, even the first 4 >> have a meaning: >> debsngn: de = Germany >> gldkshvn: gl = Greenland >> mxstis: mx = Mexico >> rukhndg: ru = Russia >> ruunera: ru = Russia >> usinvev: us = US (usin = Indiana) >> usnavajo: us = US >> usndcnt: us = US (usnd = North Dakota) >> usndnsl: us = US (usnd = North Dakota) > > > I should have said: When the codes are not 5 alphanumerics, the first two > letters do not *necessarily* denote a country code. That was my starting claim: "inconsistent country code usage" >> > The codes are stablized, meaning that they will not change no matter >> > what >> > changes happen in the base codes. So if Hawaii leaves the US and joins >> > Canada as a new province, "ushnl" would not change in CLDR even if the >> > UN >> > LOCODE changes to "cahnl" or something else. >> And combining this with "When the codes are not 5 letters, the first >> two letters have no meaning.", assuming that, if they have 5 letters >> they /may/ have a meaning, leads to the fact that the meaning in CLDR >> would be different from the meaning in the UN LOCODE system. > > > I don't understand what you are saying: that would only be an issue if there > were overlaps. What don't you understand in : "the meaning in CLDR would be different from the meaning in the UN LOCODE system"? The meaning of the first two letters in the UN/LOCODE system, except for private range codes, is to show the current valid ISO 3166-1 alpha-2 country code for the country the location identified by the UN/LOCODE is located in. >> A statement on why a country relation was not seen suitable for time >> zone identifiers can be found at: >> ftp://ftp.iana.org/tz/code/Theory >> "Be robust in the presence of political changes." > > > That's fine for TZ codes. As far as CLDR is concerned, however, the main > goal is to have an unambiguous, stable ID that is from 3-8 ASCII > alphanumerics long and maps to TZ codes. The 3-8 ASCII limitation is imposed > by BCP47, so we could not use the TZ codes unmodified. We could have chosen > to simply number them, but decided that the UN LOCODEs would be a bit > simpler to deal with. A "3-8 ASCII limitation [...] imposed by BCP47" would have allowed for fixed length 5-digit codes. As emailed here: http://mm.icann.org/pipermail/tz/2013-April/019117.html "It is common for identifiers created by ISO to have fixed length, e.g. ISWC, ISSN, ISMN, ISRC, ISBN, ISNI, ISAN, ISO country codes, ISO language codes." But CLDR for an unstated reason did choose variable length. If one lists them in a table, the column containing them is unnecessarily wider. If one puts them as labels on a map, they are harder to fit. In both cases, the non-5-character codes draw extra attention by the reader to them. Maybe all new assignments can be restricted to 5-character codes? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
by SM April 20, 2013

April 20, 2013

At 06:21 20-04-2013, Tobias Conradi wrote: >== Problem == >Jerusalem is internationally not recognized as part of Israel. Using >Jerusalem as reference location for Israel in the IANA time zone >database may thus violate UN resolutions. If I recall correctly the argument was to use population size. Regards, -sm

3 3

tzcode2013c and tzdata2013c available
by Paul Eggert April 19, 2013

April 19, 2013

The 2013c release of the tz code and data is available. It reflects the following changes circulated on the tz mailing list: Changes affecting current and future time stamps: Palestine observed DST starting March 29, 2013. (Thanks to Steffen Thorsen.) From 2013 on, Gaza and Hebron both observe DST, with the predicted rules being the last Thursday in March at 24:00 to the first Friday on or after September 21 at 01:00. Assume that the recent change to Paraguay's DST rules is permanent, by moving the end of DST to the 4th Sunday in March every year. (Thanks to Carlos Raúl Perasso.) Changes affecting past time stamps: Fix some historical data for Palestine to agree with that of timeanddate.com, as follows: The spring 2008 change in Gaza and Hebron was on 00:00 Mar 28, not 00:00 Apr 1. The fall 2009 change in Gaza and Hebron on Sep 4 was at 01:00, not 02:00. The spring 2010 change in Hebron was 00:00 Mar 26, not 00:01 Mar 27. The spring 2011 change in Gaza was 00:01 Apr 1, not 12:01 Apr 2. The spring 2011 change in Hebron on Apr 1 was at 00:01, not 12:01. The fall 2011 change in Hebron on Sep 30 was at 00:00, not 03:00. Fix times of habitation for Macquarie to agree with the Tasmania Parks & Wildlife Service history, which indicates that permanent habitation was 1899-1919 and 1948 on. Changing affecting metadata only: Macquarie Island is politically part of Australia, not Antarctica. (Thanks to Tobias Conradi.) Sort Macquarie more-consistently with other parts of Australia. (Thanks to Tim Parenti.) Here are links to the release files: http://www.iana.org/time-zones/repository/releases/tzcode2013c.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2013c.tar.gz ftp://ftp.iana.org/tz/releases/tzcode2013c.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2013c.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. 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 This release corresponds to commit f599ad15ce247473d28c179ff4d836dfcdbd0ca5 dated 2013-04-19 in the unofficial github repository at <https://github.com/eggert/tz>. Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJRcdDFAAoJEO2X6Q5iqn409ZYP/jNMuGfRb/3qwqDeUaiMUKrS yBWCYkME/oYLWSHdThGNKCRBhS8Hyr1qgOCm5YfYRTP2ZRKKOIAYPEWFUm5BvRYs r1nVmJVTea6/6jJq3yx5rAunb2C1ZRnyvHBBONRYEpAOm2EMiCMeDAXtXIpwqP7e VaAX5TFAKnxn6WJFZduU6TkCr1oWcNoFu7mZN0jy/9K1K8SLT95TLNtGAI9LtETk 3Ra9omCGy9hn/cV+PQcRa1P62uVYtyQat9Vx+nsYWluAbEofcK2wsdcIeqPlBY4X EdN66JmTrfJTrkZN425/0WIFxhr6X/nrS9LuQidzMy1PrU+0dvIWFxyUx0vE5bL5 p4NB41nu/jGs8H5ziEzDgLzMnKrMv+FzvWtcP9mYGVEzokUujxIARdUUiXoy/o4h xU111amQuDb/bmQJzdef1/SrTFqKJNwRikamDGdV+XmOJUKg1I/xP7U18c8J3qJd bgahir1f49jcglmN/W+/ViKVFZiJE/XeMSG3dGVcf3Ji9J1CHIlNjrTeTAHeilGI B+6gl/KPi6xrP8MtWs6jBVrGwzOL1zS7o+AFigWSEVU7a3UcqhGim18GXS4VjjTy lck/baoHF85mS9pig0lMxYLFa0+g/x5X7+nFAC8b6fLT/zmxwYXfuEOp35LixVC/ o330alvZudQDmy0vvwVY =h5yf -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJRcdDFAAoJEO2X6Q5iqn40p78P/371Lir9rfTXas0Z6lvp3Lp9 KRv7+yzpNMh1toxsUmkeswvdRxn7v+r+l7F5G0oLlK7CN88nW8uUua+R/YNvMcRG v4UOxaIhCRrM2PG/JGiXF/6kjHP9m0l3206HJzxnhW1atl8DCVEz93jyUbVXtf20 IYlDv7DOqLj9GW5VoK8KlExnymUKgtGBuLlyROoKomGlWt851d05mrAMLTeVQ/Nh RasevczuqFhpGgB444/mJZ4KOTCElYyl9sau9qXXr5MfA5MmtOKaeg8O2r3PZl2x 0oto97okGITNu5hrhJ1dYk7WjM27HfDUHcIvGdsmXmdebA703O5sk4M2R3F/dYNL 79N+sFOfs8qBp4Knclv8eMVoptKJ/ARLkkdduU2ZE/I4oai4YaIYNLi+r9NFQWdU ihVsYdcPTvRAK/6+RaINPwS6JhHsbKWBqyFS+80q268WyC/gfPPH61/ZrJ+fiRiT FeBD1LYs+n1LO9gvtUzsVpJipc07OMWUR8RTFuhkBXMhRuOKk0ClkulV50bMDll9 M27pr4DlRohiCbCUVLIUkOYJNUfcLGGCfN33EWQf2h9E+9DEgsKcnYwv7y3384vQ lj0xHcGLwYj9xBnVQZwiVBIkeblzToWJ4pYSu7Lv0bUd/CE3paBTN1vSh8RmeMQc JV78TcXpv14qn9s04/n6 =ID32 -----END PGP SIGNATURE-----

1 0

Proposal to change Antarctica/Macquarie to Pacific/Macquarie
by Tobias Conradi April 19, 2013

April 19, 2013

Some repition of former emails and one use case/practical implication. Correctness: 1) Macquarie is outside the territory covered by The Antarctic Treaty 1959-12-01 http://www.ats.aq/documents/ats/treaty_original.pdf "The provisions of the present Treaty shall apply to the area south of 60° South Latitude" 2) Macquarie is the only location to have the Area Antarctic and be not south of 60° South Latitude Fix: 3) The distance from Macquarie to Australian mainland (~2000 km) is larger than from Madagascar to Africa. Madagascar is placed in the surrounding ocean under Indian/ , so Macquarie can be placed in the surrounding ocean. 4) TZ identifiers have been changed if localities have been renamed. That is, the identifiers have been adapted to new real world situation. Here, the adaption would be a correction in the data, as is the change for Macquarie from ISO country AQ to AU. It has been wrong from the beginning. If one wants to freeze the identifiers, then please not for actual errors, especially not before a freeze is officially announced and data be checked. The location part of the tzid is not necessarily matching anything in the real world, since there is the 14 character limit and some limits in the choice of characters. But the area part normally matches the real world name of the area. Problem: 5) I just opened tz_world_mp in QGis and when opening the Attribute Table and sorting by TZID Macquarie is listed out of place. This will happen in any environment that does sorting by TZID. Here it is special, since geographic Antarctica is not included in tz_world_mp leading to only one TZID under Antarctica/.... In map projections Antarctica often gets a special treatment. It may also be excluded as in * tz_world_mp (no time zones for Antarctica) * http://unstats.un.org/unsd/methods/m49/m49regin.htm In programming a simple string matching on the IDs could remove time zones located in geographic Antarctica, if Macquarie would be moved out of Antarctica/.... So this has an effect on programming work. Summary: Fixing it now will avoid many discussions or annoyances caused by Macquarie being placed in an, as far as general definitions of Antarctica are concerned wrong area. It will help programmers and other people that work with the data. This is a very special case of tzid change. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

2 1

tzcode for windows?
by random832＠fastmail.us April 19, 2013

April 19, 2013

It came up as an aside in the earlier discussion about moving to uintmax_t, but I was wondering - is there any interest in a port to windows? I've got most of the way to a successful zic port (other tools don't work so well yet - everything compiles, but there are subtle incompatibilities that cause problems for the library functions) -- Random832

5 7

Not sure how to add to thread...
by Marvel, Jim (CPCOE) April 19, 2013

April 19, 2013

Hi, I posted before about Asia/Khandyga and Asia/Ust-Nera, wondering if they will show up in the efele tz_database with their own Tzid Can't find them as of October 8th file. Please let me know which polygons to be assigned to each of these Tzid. Thanks Jim Marvel Software Engineer II Honeywell ESEA/CMS/CP/CoE 8323 Lindbergh Court Sarasota FL 34243 Phone - 941.360.6209 (alt: 941.360.6213) Fax - 941.355.9241 Jim.Marvel(a)Honeywell.com<mailto:nancy.ramm@honeywell.com>

3 5

Re: [tz] EST/EDT vs AEST/AEDT in AQ [SEC=UNCLASSIFIED]
by Timothy Arceri April 18, 2013

April 18, 2013

>From: tobias.conradi(a)gmail.com [mailto:tobias.conradi@gmail.com] On Behalf Of Tobias Conradi > >>> This is a vote to use AEST/AEDT, or switch completely to Internationalized time point unique abbreviations. >> >> I have been very clear since my very first email that may main concern is with the daylight savings abbreviations. >>Again switching completely to Internationalized time point unique abbreviations is outside the scope of the tz database. >Again? Where did you say it is outside the scope of the tz database before? >Where is the scope defined to have EDT? Going for "out of scope" >without citing policy looks like trying to conceal that fact that it is only outside your scope. For the scope of changes that can be made to the tz database please read: http://www.iana.org/go/rfc6557 No one is trying to conceal anything I'm simply following the procedures outlined in that document. > You seem to not care about anything outside Australia and deteriorating the database by introducing new meanings of D is not problem for you. I can accuse you of trying to introduce a new meaning to Australians. Please show me where it says that we must use the abbreviations used elsewhere in the database. Your own table shows that the abbreviations letters can mean different things. AGAIN you are trying to enforce unique and standardised abbreviations, as I have said this would be great if the world as a whole decided to use such standards but there is no such thing currently, if I'm wrong please enlighten me. Again: "Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry." >> We are simply trying to get the daylight savings abbreviations changed >> to what is *actually* used in Australia. >Macquarie Island in the IANA time zone database is AQ and not Australia. Macquarie island is part of Australia: http://en.wikipedia.org/wiki/Macquarie_Island Timothy Arceri

13 40

Request to apply patch for Russian Siberia and create Asia/Tomsk Asia/Barnaul
by Tobias Conradi April 18, 2013

April 18, 2013

Patch was mailed 2012-05-05 http://mm.icann.org/pipermail/tz/2012-May/017696.html -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

2 2

[PATCH0/1] Propose new zone for Crozet Islands
by Antoine Leca April 18, 2013

April 18, 2013

Hi Paul, I also have a patch submitted some time ago which seems to have been forgotten. I reworked it to match git workflow. For easier work, I have also put it as a new branch on my github repository: https://github.com/antoineL/tz/commits/crozet About the content from the former discussion <http://mm.icann.org/pipermail/tz/2012-May/017804.html> that I scrapped from the commit message, there were a reference to an official reference (in French) that can be read at the bottom of page 30 of <http://www.taaf.fr/IMG/pdf/guidehivernant2011.pdf< (taaf.fr is the official site of the territory), which spells the rules using the old GMT+4 moniker, and as a reference to the Europe/Paris rules. Since that URL is likely to change (!) you might want to refer to http://www.taaf.fr instead; or just drop it completely, which was my option. Antoine

1 0

Re: [tz] EST/EDT vs AEST/AEDT in AQ [SEC=UNCLASSIFIED]
by Tobias Conradi April 18, 2013

April 18, 2013

On Wed, Apr 17, 2013 at 10:07 PM, Garrett Wollman <wollman(a)csail.mit.edu> wrote: > <<On Wed, 17 Apr 2013 21:22:47 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: > >>> It is entirely unimportant to "avoid ambiguity". >> How did you come to this conclusion? > > By watching you make an ass of yourself. How is that relevant for the IANA time zone database? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Abreviation(s) for Daylight Saving Time in Australia [SEC=UNCLASSIFIED]
by Peter Stagg April 17, 2013

April 17, 2013

I have one simple question that I'm hoping to get a straight forward answer to. Has enough been done by Timothy, Myself and other contributors to convince the coordinators that the current situation where Daylight Saving Time (for Australian time zones) is abbreviated as ST = Summer Time is in error and should be changed? Regards, Peter Stagg | Web Developer, Radar Systems Bureau of Meteorology Australian Meteorological Data Information Services System (AMDISS) Bureau of Meteorology GPO Box 1289 Melbourne VIC 3001 Level 6, 700 Collins Street, Docklands VIC 3008 Tel: +61 3 9669 4232 | Fax: +61 3 9669 4128 www.bom.gov.au

2 1

Re: [tz] EST/EDT vs AEST/AEDT in AQ [SEC=UNCLASSIFIED]
by Tobias Conradi April 17, 2013

April 17, 2013

On Wed, Apr 17, 2013 at 8:53 PM, Garrett Wollman <wollman(a)csail.mit.edu> wrote: > <<On Wed, 17 Apr 2013 20:38:42 +0200, Tobias Conradi <mail.2012(a)tobiasconradi.com> said: > > >> And one of them is important to avoid ambiguity (D means 1:00) and the >> other (1:00 has to be D) is not. > > It is entirely unimportant to "avoid ambiguity". How did you come to this conclusion? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Complete list of IANA time zone abbreviations
by Tobias Conradi April 16, 2013

April 16, 2013

Is a complete list of IANA time zone abbreviations available in the WWW? I found: * http://en.wikipedia.org/wiki/List_of_time_zone_abbreviations * http://www.timeanddate.com/library/abbreviations/timezones/ * http://www.timegenie.com/timezones.php All list ACDT which, as of today, is not an IANA abbreviation, so these listings are not what I am looking for. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Suggesting an ISO standard for time zone identification - possible replacement of IANA abbreviations
by Tobias Conradi April 16, 2013

April 16, 2013

Dear Mr. Carpenter, this email is send to you, because you are listed as the secretary for the "TC 46/SC 9 Identification and description". Maybe you can forward it to the relevant office or tell me where else I can email to. I suggest that the ISO creates an ISO standard for time zone identification. Current abbreviations in the IANA time zone database are ambiguous, e.g. IST may refer to Israel Standard Time or India Standard Time. The standard could be used in the IANA time zone database and projects that collect time zone related data, e.g. laws and translations of names. Since time zone law is country related one could look whether ISO 3166 can be used. The IANA time zone database has the stated aim of being correct for all regions in the world after the year 1970. Although the earliest ISO 3166 country code standard on the ISO website is ISO 3166:1981, web search for ISO 3166 1974 gives several hits claiming the first publication was in 1974. If there have been countries between 1970 and 1974 that have no ISO 3166 code one can use codes from the user-assigned code space. So the first two letters might be ISO 3166-1 alpha-2 country code based. But I suggest checking whether the alpha-3 codes or numeric codes are a better fit. Further letters may then mark regions inside a country and special restricted time shifts, e.g. daylight saving time. Such a structured set could look like: AUEDT - Australia Eastern Daylight saving Time AUCDT - United States Central Daylight saving Time AUWDT - Australia Western Daylight saving Time EUEDT - EU Eastern Daylight saving Time EUCDT - EU Central Daylight saving Time EUWDT - EU Western Daylight saving Time IDEST - Indonesia Eastern Standard Time IDCST - Indonesia Central Standard Time IDWST - Indonesia Western Standard Time USEDT - United States Eastern Daylight saving Time USCDT - United States Central Daylight saving Time USPDT - United States Pacific Daylight saving Time Kind regards Tobias Conradi -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Palestine DST starts on 2013-03-29
by Steffen Thorsen April 14, 2013

April 14, 2013

The following news sources tells that Palestine will " start daylight saving time from midnight on Friday, March 29, 2013" (translated). http://www.samanews.com/index.php?act=Show&id=154120 (Gaza) http://safa.ps/details/news/99844/%D8%B1%D8%A7%D9%85-%D8%A7%D9%84%D9%84%D9%… (Ramallah, West Bank) No end date given, but we assume it will end the last Sunday of September. Our background info: http://www.timeanddate.com/news/time/palestine-starts-dst-2013.html Best regards, Steffen Thorsen - timeanddate.com

4 6

morroco in summer time the 28th april
by Sebastien WILLEMIJNS April 13, 2013

April 13, 2013

Hello, Morocco was a thread here so i speak again about it / saw on google: http://www.lemag.ma/Le-Maroc-passe-a-l-heure-d-ete-le-dimanche-28-avril_a69… H+60 the 28th april at 2am. this time will be suspended during the ramadan month.

2 1

Patch use LHDT/LHST/LHHDT since HD HS DD DS are common practice
by Tobias Conradi April 12, 2013

April 12, 2013

Patch australasia.20130411.withLHHDT is linked from http://anna.info/wiki/ANNA_time_zone_database - I don't link to the actual location, because that may change. And I don't email, because I don't know what the email client does with the file. The patch includes AEST/AEDT ACST/ACDT AWST/AWDT CWST/CWDT LHDT/LHST/LHHDT -------- The bom.gov.au-patch introduces new syntax, which for itself might be fine, but this new syntax is less informative than the established one and might be seen as deterioration to the whole database. No single use of single "D" for non-1:00 saving has been found by me. There is one single "D" in a LHDT but there it referred to a 1:00 saving. Be consistent, apply common practice established by the maintainers and use: HD 0:30 LHHDT Australia/Lord_Howe For non 1:00 DST offsets the database contains: DD 2:00 NDDT America/St_Johns IDDT Asia/Jerusalem DS 2:00 MDST - Moscow Double Summer Time, BDST - British Double Summer Time HD 0:30 CHDT America/Belize CHDT EHDT America/Santo_Domingo HS 0:30 UYHST America/Montevideo IHST Asia/Colombo CKHST Pacific/Rarotonga HS 0:20 GHST Africa/Accra -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

3 5

Re: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]
by Peter Stagg April 12, 2013

April 12, 2013

I would like to offer (again) the following evidence in support of Timothy's request for a patch to eliminate the ambiguous time zone abbreviations from the TZ Database. The assertion from John Mackin that "We in Australia have _never_ referred to DST as `daylight' time." is patently untrue - the video from four corners (posted previously - see below) is clear evidence that the term is used and has been in use since well before John Mackin's statement from 1991. Language is a living thing it changes and evolves over time so it is possible that in 1991 "summer time" was in vogue. It is also possible that John Mackin comes from the culture of British migrants that may well have used this term due to their British heritage. Either way the Google searches of government web sites show that the phrase "daylight saving" is used, formally, more frequently then "summer time". There are many problems with searching the broader context of .au web sites for frequency of use of "EST" vs. "EDT" and "summer time" vs. "daylight saving": "EST" vs. "EDT" Only tree of the four states in the "Eastern Standard Timezone" have daylight savings and they only have it for aprox. four of the twelve months in the year. And as someone pointed out before many web sites unwittingly use the TZ Database data to automatically timestamp pages. So the frequency of use of "EST" is destined to be much higher then "EDT" and therefore the search is meaningless. "summer time" vs. "daylight saving" "daylight saving" has, pretty much, one unambiguous meaning where as "summer time" (summertime) has so many that have nothing what so ever to do with "daylight saving": - "Summertime" is an aria composed by George Gershwin for the 1935 opera Porgy and Bess. - Summertime is a 1955 American/British Technicolor drama film directed by David Lean - May refer to "British summer time"; given Australia's long association with the mother country old newspapers etc. online often refer to "British summer time" - It may refer to (as it does in many countries) the *seasonal* time of summer as in "summer time and the living is easy". As evidence of this I searched Trove (the National Library of Australia's online collection of digitised Newspapers etc.) <http://trove.nla.gov.au> for these phrases separately "EST", "EDT", "summer time" and "daylight saving". I searched only Australian content and only the Digitised newspapers section, the results were as follows: "EST" = 2,049,093 "EDT" = 27,401 "Summer time" = 55,120 "daylight saving" = 11,960 The only one of these which returns relatively unambiguous results is "daylight saving" and here is why: The first full page of the search for "EST" does not contain a single reference to time. "EST" (Est.) is a very commonly used abbreviation for Established for one thing. "EDT" is just as ambiguous. "daylight saving", is much less ambiguous all-though searching for it will return the likes of "Nothing but fair weather and daylight saved". The earliest use of the term (we never use) is in 1908 referring to the "Daylight Saving Bill" it is referred to in more than a dozen daily newspapers of the time. "Mr. Robert Pearce, tbe member for the Leek division of Staffordshire, is a humorist. To the intense amusement of the House the other day he gravely introducedva measure called the "Daylight_ Saving Bill," by which he proposes, bv an ingenious juggling with' the hoursof the clock, to actually give us more daylight! Mr. Pcarce's project is on the first four Sundays in April to put on the clock 20 minutes between 2 a.m. and 3 p.m., each hour, therefore consisting of only 40 minutes. Similarly it is propo^d in September that the same hour in the morning should consist of 80 minutes. The annual gain of daylight Mr. Pearce esti-mates at 210 hours." [sic.] "Summer time" very rarely refers to Australian "daylight saving time" as can be seen from a selection of results from the first page of the search... ----- Sunday Times (Perth, WA : 1902 - 1954) Sunday 2 November 1947 p 2 Article ... Summertime LONDON, Sat: British summertime time ends tomorrow, when G.M.T. will be restored. Change officially occurs at 3.30 a.m. ----- The Daily News (Perth, WA : 1882 - 1950) Saturday 22 August 1936 Edition: GOLDFIELDS EDITION p 16 Article ... Summertime Summertime is coming near; I heard a blowfly yesterday. Mosquitoes buzzing here and there Are signs that summer's on the way. People talk about the flowers In bloom, and skies of azure blue. I can tell that winter's hours Are few another way, can't you? Winter jumpers are not seen So ... ----- Examiner (Launceston, Tas. : 1900 - 1954) Saturday 24 February 1917 Edition: DAILY p 7 Article ... SUMMER TIME. It is understood that the Government will introduce summer time to operate between April 8 and September 23. ... ----- Oh. Before you jump on that last one look at the dates then realise that it was in a section of the paper headed "British Parliament." In conclusion there is little real unambiguous evidence out there that prooves "summer time" is more commonly used in Australia *to refer to* "Daylight Saving(s) Time" than the phrase "Daylight Saving(s) Time". In actual fact there is more evidence to prove the oposite. Formally the majority of Australian government websites refer to "Daylight Saving(s) Time" and this is the part of the TZ Database that we Australian users disagree with and wish to have changed. ----- search: legislation "standard time" "daylight saving" site:.gov.au About 25,600 results (0.21 seconds) search: legislation "standard time" "summer time" site:.gov.au About 15,600 results (0.14 seconds) N.B. ".gov.au" searches all state and federal official sites as they all use this domain. (e.g. Federal = just .gov.au, State i.e. Victoria = .vic.gov.au ). ----- An interesting video from the 1970's Four Corners program on the ABC (Australia's national broadcaster, ICYDK) on the introduction of "Daylight Saving" in Tasmania. Note the consistent use of that term "Daylight Saving", "Summer Time" is never mentioned (FYI It's a predominantly British term) and take a look at the flight attendant's bonnet! http://www.abc.net.au/archives/80days/stories/2012/01/19/3415208.htm Regards, Peter Stagg Web Developer - Radar Systems, AMDIS, +61 3 9669-4232, www.bom.gov.au ----- Date: Thu, 11 Apr 2013 09:50:04 +1000 From: Timothy Arceri <T.Arceri(a)bom.gov.au> Subject: [tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED] To: "'tz(a)iana.org' (tz(a)iana.org)" <tz(a)iana.org> Message-ID: <7F491A8A71010C4E8B0266E3478C047A0220B1760322(a)BOM-VMBX-HO.bom.gov.au> Content-Type: text/plain; charset="us-ascii" <delitia> The reason for the current situation is documented in the Australasia data file: >From John Mackin (1991-03-06): "We in Australia have _never_ referred to DST as `daylight' time. It is called `summer' time. Now by a happy coincidence, `summer' and `standard' happen to start with the same letter; hence, the abbreviation does _not_ change..." -----

9 17

Gaza DST
by Keith Harris April 12, 2013

April 12, 2013

Hi All, Sorry I couldn't find a way to bump this issue via the original thread. Just wondering what the latest is on getting this change released. I've tested the latest version of the db from the repository and it has jodatime reporting the correct time for Gaza today. Be great to get this in place as I've got people missing their conference calls by an hour! (Thanks so much for all the hard work by everyone on the list - wonderful to see at least one bit of the world's technology just working the way it should :-D ) Keith Harris SoftlySoftware <http://softlysoftware.com>

2 1

Macquarie Island - ISO 3166-1 code AQ vs AU
by Tobias Conradi April 12, 2013

April 12, 2013

Was Re: [tz] EST/EDT vs AEST/AEDT in AQ [SEC=UNCLASSIFIED] I think the research for the correct ISO country for Macquarie Island is easier followable if kept in a separate thread. On Fri, Apr 12, 2013 at 10:45 AM, Tobias Conradi <mail.2012(a)tobiasconradi.com> wrote: > On Fri, Apr 12, 2013 at 5:35 AM, Timothy Arceri <T.Arceri(a)bom.gov.au> wrote: >>>From: tobias.conradi(a)gmail.com [mailto:tobias.conradi@gmail.com] On Behalf Of Tobias >>>> We are simply trying to get the daylight savings abbreviations changed >>>> to what is *actually* used in Australia. >>>Macquarie Island in the IANA time zone database is AQ and not Australia. >> >> Macquarie island is part of Australia: http://en.wikipedia.org/wiki/Macquarie_Island > > In Wikipedia, not in the IANA time zone database. > > ftp://ftp.iana.org/tz/data/zone.tab > > AQ -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island http://en.wikipedia.org/wiki/Macquarie_Island categorized as belonging to Tasmania, which in turn is given as part of Australia. What is the reason to have Macquarie Island as AQ Antartica in the IANA time zone database? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

3 4

[PATCH 1/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]
by Timothy Arceri April 12, 2013

April 12, 2013

--- australasia 2013-02-21 07:00:40.000000000 +0000 +++ australasia_new 2013-04-10 00:39:26.000000000 +0000 @@ -13,13 +13,13 @@ # Please see the notes below for the controversy about "EST" versus "AEST" etc. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule Aus 1917 only - Jan 1 0:01 1:00 - -Rule Aus 1917 only - Mar 25 2:00 0 - -Rule Aus 1942 only - Jan 1 2:00 1:00 - -Rule Aus 1942 only - Mar 29 2:00 0 - -Rule Aus 1942 only - Sep 27 2:00 1:00 - -Rule Aus 1943 1944 - Mar lastSun 2:00 0 - -Rule Aus 1943 only - Oct 3 2:00 1:00 - +Rule Aus 1917 only - Jan 1 0:01 1:00 D +Rule Aus 1917 only - Mar 25 2:00 0 S +Rule Aus 1942 only - Jan 1 2:00 1:00 D +Rule Aus 1942 only - Mar 29 2:00 0 S +Rule Aus 1942 only - Sep 27 2:00 1:00 D +Rule Aus 1943 1944 - Mar lastSun 2:00 0 S +Rule Aus 1943 only - Oct 3 2:00 1:00 D # Go with Whitman and the Australian National Standards Commission, which # says W Australia didn't use DST in 1943/1944. Ignore Whitman's claim that # 1944/1945 was just like 1943/1944. @@ -28,25 +28,25 @@ # Northern Territory Zone Australia/Darwin 8:43:20 - LMT 1895 Feb 9:00 - CST 1899 May - 9:30 Aus CST + 9:30 Aus C%sT # Western Australia # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AW 1974 only - Oct lastSun 2:00s 1:00 - -Rule AW 1975 only - Mar Sun>=1 2:00s 0 - -Rule AW 1983 only - Oct lastSun 2:00s 1:00 - -Rule AW 1984 only - Mar Sun>=1 2:00s 0 - -Rule AW 1991 only - Nov 17 2:00s 1:00 - -Rule AW 1992 only - Mar Sun>=1 2:00s 0 - -Rule AW 2006 only - Dec 3 2:00s 1:00 - -Rule AW 2007 2009 - Mar lastSun 2:00s 0 - -Rule AW 2007 2008 - Oct lastSun 2:00s 1:00 - +Rule AW 1974 only - Oct lastSun 2:00s 1:00 D +Rule AW 1975 only - Mar Sun>=1 2:00s 0 S +Rule AW 1983 only - Oct lastSun 2:00s 1:00 D +Rule AW 1984 only - Mar Sun>=1 2:00s 0 S +Rule AW 1991 only - Nov 17 2:00s 1:00 D +Rule AW 1992 only - Mar Sun>=1 2:00s 0 S +Rule AW 2006 only - Dec 3 2:00s 1:00 D +Rule AW 2007 2009 - Mar lastSun 2:00s 0 S +Rule AW 2007 2008 - Oct lastSun 2:00s 1:00 D Zone Australia/Perth 7:43:24 - LMT 1895 Dec - 8:00 Aus WST 1943 Jul - 8:00 AW WST + 8:00 Aus W%sT 1943 Jul + 8:00 AW W%sT Zone Australia/Eucla 8:35:28 - LMT 1895 Dec - 8:45 Aus CWST 1943 Jul - 8:45 AW CWST + 8:45 Aus CW%sT 1943 Jul + 8:45 AW CW%sT # Queensland # @@ -62,42 +62,42 @@ # so use Lindeman. # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AQ 1971 only - Oct lastSun 2:00s 1:00 - -Rule AQ 1972 only - Feb lastSun 2:00s 0 - -Rule AQ 1989 1991 - Oct lastSun 2:00s 1:00 - -Rule AQ 1990 1992 - Mar Sun>=1 2:00s 0 - -Rule Holiday 1992 1993 - Oct lastSun 2:00s 1:00 - -Rule Holiday 1993 1994 - Mar Sun>=1 2:00s 0 - +Rule AQ 1971 only - Oct lastSun 2:00s 1:00 D +Rule AQ 1972 only - Feb lastSun 2:00s 0 S +Rule AQ 1989 1991 - Oct lastSun 2:00s 1:00 D +Rule AQ 1990 1992 - Mar Sun>=1 2:00s 0 S +Rule Holiday 1992 1993 - Oct lastSun 2:00s 1:00 D +Rule Holiday 1993 1994 - Mar Sun>=1 2:00s 0 S Zone Australia/Brisbane 10:12:08 - LMT 1895 - 10:00 Aus EST 1971 - 10:00 AQ EST + 10:00 Aus E%sT 1971 + 10:00 AQ E%sT Zone Australia/Lindeman 9:55:56 - LMT 1895 - 10:00 Aus EST 1971 - 10:00 AQ EST 1992 Jul - 10:00 Holiday EST + 10:00 Aus E%sT 1971 + 10:00 AQ E%sT 1992 Jul + 10:00 Holiday E%sT # South Australia # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AS 1971 1985 - Oct lastSun 2:00s 1:00 - -Rule AS 1986 only - Oct 19 2:00s 1:00 - -Rule AS 1987 2007 - Oct lastSun 2:00s 1:00 - -Rule AS 1972 only - Feb 27 2:00s 0 - -Rule AS 1973 1985 - Mar Sun>=1 2:00s 0 - -Rule AS 1986 1990 - Mar Sun>=15 2:00s 0 - -Rule AS 1991 only - Mar 3 2:00s 0 - -Rule AS 1992 only - Mar 22 2:00s 0 - -Rule AS 1993 only - Mar 7 2:00s 0 - -Rule AS 1994 only - Mar 20 2:00s 0 - -Rule AS 1995 2005 - Mar lastSun 2:00s 0 - -Rule AS 2006 only - Apr 2 2:00s 0 - -Rule AS 2007 only - Mar lastSun 2:00s 0 - -Rule AS 2008 max - Apr Sun>=1 2:00s 0 - -Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 - +Rule AS 1971 1985 - Oct lastSun 2:00s 1:00 D +Rule AS 1986 only - Oct 19 2:00s 1:00 D +Rule AS 1987 2007 - Oct lastSun 2:00s 1:00 D +Rule AS 1972 only - Feb 27 2:00s 0 S +Rule AS 1973 1985 - Mar Sun>=1 2:00s 0 S +Rule AS 1986 1990 - Mar Sun>=15 2:00s 0 S +Rule AS 1991 only - Mar 3 2:00s 0 S +Rule AS 1992 only - Mar 22 2:00s 0 S +Rule AS 1993 only - Mar 7 2:00s 0 S +Rule AS 1994 only - Mar 20 2:00s 0 S +Rule AS 1995 2005 - Mar lastSun 2:00s 0 S +Rule AS 2006 only - Apr 2 2:00s 0 S +Rule AS 2007 only - Mar lastSun 2:00s 0 S +Rule AS 2008 max - Apr Sun>=1 2:00s 0 S +Rule AS 2008 max - Oct Sun>=1 2:00s 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Adelaide 9:14:20 - LMT 1895 Feb 9:00 - CST 1899 May - 9:30 Aus CST 1971 - 9:30 AS CST + 9:30 Aus C%sT 1971 + 9:30 AS C%sT # Tasmania # @@ -106,106 +106,106 @@ # says King Island didn't observe DST from WWII until late 1971. # # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AT 1967 only - Oct Sun>=1 2:00s 1:00 - -Rule AT 1968 only - Mar lastSun 2:00s 0 - -Rule AT 1968 1985 - Oct lastSun 2:00s 1:00 - -Rule AT 1969 1971 - Mar Sun>=8 2:00s 0 - -Rule AT 1972 only - Feb lastSun 2:00s 0 - -Rule AT 1973 1981 - Mar Sun>=1 2:00s 0 - -Rule AT 1982 1983 - Mar lastSun 2:00s 0 - -Rule AT 1984 1986 - Mar Sun>=1 2:00s 0 - -Rule AT 1986 only - Oct Sun>=15 2:00s 1:00 - -Rule AT 1987 1990 - Mar Sun>=15 2:00s 0 - -Rule AT 1987 only - Oct Sun>=22 2:00s 1:00 - -Rule AT 1988 1990 - Oct lastSun 2:00s 1:00 - -Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 - -Rule AT 1991 2005 - Mar lastSun 2:00s 0 - -Rule AT 2000 only - Aug lastSun 2:00s 1:00 - -Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 - -Rule AT 2006 only - Apr Sun>=1 2:00s 0 - -Rule AT 2007 only - Mar lastSun 2:00s 0 - -Rule AT 2008 max - Apr Sun>=1 2:00s 0 - +Rule AT 1967 only - Oct Sun>=1 2:00s 1:00 D +Rule AT 1968 only - Mar lastSun 2:00s 0 S +Rule AT 1968 1985 - Oct lastSun 2:00s 1:00 D +Rule AT 1969 1971 - Mar Sun>=8 2:00s 0 S +Rule AT 1972 only - Feb lastSun 2:00s 0 S +Rule AT 1973 1981 - Mar Sun>=1 2:00s 0 S +Rule AT 1982 1983 - Mar lastSun 2:00s 0 S +Rule AT 1984 1986 - Mar Sun>=1 2:00s 0 S +Rule AT 1986 only - Oct Sun>=15 2:00s 1:00 D +Rule AT 1987 1990 - Mar Sun>=15 2:00s 0 S +Rule AT 1987 only - Oct Sun>=22 2:00s 1:00 D +Rule AT 1988 1990 - Oct lastSun 2:00s 1:00 D +Rule AT 1991 1999 - Oct Sun>=1 2:00s 1:00 D +Rule AT 1991 2005 - Mar lastSun 2:00s 0 S +Rule AT 2000 only - Aug lastSun 2:00s 1:00 D +Rule AT 2001 max - Oct Sun>=1 2:00s 1:00 D +Rule AT 2006 only - Apr Sun>=1 2:00s 0 S +Rule AT 2007 only - Mar lastSun 2:00s 0 S +Rule AT 2008 max - Apr Sun>=1 2:00s 0 S # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Hobart 9:49:16 - LMT 1895 Sep 10:00 - EST 1916 Oct 1 2:00 - 10:00 1:00 EST 1917 Feb - 10:00 Aus EST 1967 - 10:00 AT EST + 10:00 1:00 EDT 1917 Feb + 10:00 Aus E%sT 1967 + 10:00 AT E%sT Zone Australia/Currie 9:35:28 - LMT 1895 Sep 10:00 - EST 1916 Oct 1 2:00 - 10:00 1:00 EST 1917 Feb - 10:00 Aus EST 1971 Jul - 10:00 AT EST + 10:00 1:00 EDT 1917 Feb + 10:00 Aus E%sT 1971 Jul + 10:00 AT E%sT # Victoria # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AV 1971 1985 - Oct lastSun 2:00s 1:00 - -Rule AV 1972 only - Feb lastSun 2:00s 0 - -Rule AV 1973 1985 - Mar Sun>=1 2:00s 0 - -Rule AV 1986 1990 - Mar Sun>=15 2:00s 0 - -Rule AV 1986 1987 - Oct Sun>=15 2:00s 1:00 - -Rule AV 1988 1999 - Oct lastSun 2:00s 1:00 - -Rule AV 1991 1994 - Mar Sun>=1 2:00s 0 - -Rule AV 1995 2005 - Mar lastSun 2:00s 0 - -Rule AV 2000 only - Aug lastSun 2:00s 1:00 - -Rule AV 2001 2007 - Oct lastSun 2:00s 1:00 - -Rule AV 2006 only - Apr Sun>=1 2:00s 0 - -Rule AV 2007 only - Mar lastSun 2:00s 0 - -Rule AV 2008 max - Apr Sun>=1 2:00s 0 - -Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 - +Rule AV 1971 1985 - Oct lastSun 2:00s 1:00 D +Rule AV 1972 only - Feb lastSun 2:00s 0 S +Rule AV 1973 1985 - Mar Sun>=1 2:00s 0 S +Rule AV 1986 1990 - Mar Sun>=15 2:00s 0 S +Rule AV 1986 1987 - Oct Sun>=15 2:00s 1:00 D +Rule AV 1988 1999 - Oct lastSun 2:00s 1:00 D +Rule AV 1991 1994 - Mar Sun>=1 2:00s 0 S +Rule AV 1995 2005 - Mar lastSun 2:00s 0 S +Rule AV 2000 only - Aug lastSun 2:00s 1:00 D +Rule AV 2001 2007 - Oct lastSun 2:00s 1:00 D +Rule AV 2006 only - Apr Sun>=1 2:00s 0 S +Rule AV 2007 only - Mar lastSun 2:00s 0 S +Rule AV 2008 max - Apr Sun>=1 2:00s 0 S +Rule AV 2008 max - Oct Sun>=1 2:00s 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Melbourne 9:39:52 - LMT 1895 Feb - 10:00 Aus EST 1971 - 10:00 AV EST + 10:00 Aus E%sT 1971 + 10:00 AV E%sT # New South Wales # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule AN 1971 1985 - Oct lastSun 2:00s 1:00 - -Rule AN 1972 only - Feb 27 2:00s 0 - -Rule AN 1973 1981 - Mar Sun>=1 2:00s 0 - -Rule AN 1982 only - Apr Sun>=1 2:00s 0 - -Rule AN 1983 1985 - Mar Sun>=1 2:00s 0 - -Rule AN 1986 1989 - Mar Sun>=15 2:00s 0 - -Rule AN 1986 only - Oct 19 2:00s 1:00 - -Rule AN 1987 1999 - Oct lastSun 2:00s 1:00 - -Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 - -Rule AN 1996 2005 - Mar lastSun 2:00s 0 - -Rule AN 2000 only - Aug lastSun 2:00s 1:00 - -Rule AN 2001 2007 - Oct lastSun 2:00s 1:00 - -Rule AN 2006 only - Apr Sun>=1 2:00s 0 - -Rule AN 2007 only - Mar lastSun 2:00s 0 - -Rule AN 2008 max - Apr Sun>=1 2:00s 0 - -Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 - +Rule AN 1971 1985 - Oct lastSun 2:00s 1:00 D +Rule AN 1972 only - Feb 27 2:00s 0 S +Rule AN 1973 1981 - Mar Sun>=1 2:00s 0 S +Rule AN 1982 only - Apr Sun>=1 2:00s 0 S +Rule AN 1983 1985 - Mar Sun>=1 2:00s 0 S +Rule AN 1986 1989 - Mar Sun>=15 2:00s 0 S +Rule AN 1986 only - Oct 19 2:00s 1:00 D +Rule AN 1987 1999 - Oct lastSun 2:00s 1:00 D +Rule AN 1990 1995 - Mar Sun>=1 2:00s 0 S +Rule AN 1996 2005 - Mar lastSun 2:00s 0 S +Rule AN 2000 only - Aug lastSun 2:00s 1:00 D +Rule AN 2001 2007 - Oct lastSun 2:00s 1:00 D +Rule AN 2006 only - Apr Sun>=1 2:00s 0 S +Rule AN 2007 only - Mar lastSun 2:00s 0 S +Rule AN 2008 max - Apr Sun>=1 2:00s 0 S +Rule AN 2008 max - Oct Sun>=1 2:00s 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Australia/Sydney 10:04:52 - LMT 1895 Feb - 10:00 Aus EST 1971 - 10:00 AN EST + 10:00 Aus E%sT 1971 + 10:00 AN E%sT Zone Australia/Broken_Hill 9:25:48 - LMT 1895 Feb 10:00 - EST 1896 Aug 23 9:00 - CST 1899 May - 9:30 Aus CST 1971 - 9:30 AN CST 2000 - 9:30 AS CST + 9:30 Aus C%sT 1971 + 9:30 AN C%sT 2000 + 9:30 AS C%sT # Lord Howe Island # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S -Rule LH 1981 1984 - Oct lastSun 2:00 1:00 - -Rule LH 1982 1985 - Mar Sun>=1 2:00 0 - -Rule LH 1985 only - Oct lastSun 2:00 0:30 - -Rule LH 1986 1989 - Mar Sun>=15 2:00 0 - -Rule LH 1986 only - Oct 19 2:00 0:30 - -Rule LH 1987 1999 - Oct lastSun 2:00 0:30 - -Rule LH 1990 1995 - Mar Sun>=1 2:00 0 - -Rule LH 1996 2005 - Mar lastSun 2:00 0 - -Rule LH 2000 only - Aug lastSun 2:00 0:30 - -Rule LH 2001 2007 - Oct lastSun 2:00 0:30 - -Rule LH 2006 only - Apr Sun>=1 2:00 0 - -Rule LH 2007 only - Mar lastSun 2:00 0 - -Rule LH 2008 max - Apr Sun>=1 2:00 0 - -Rule LH 2008 max - Oct Sun>=1 2:00 0:30 - +Rule LH 1981 1984 - Oct lastSun 2:00 1:00 D +Rule LH 1982 1985 - Mar Sun>=1 2:00 0 S +Rule LH 1985 only - Oct lastSun 2:00 0:30 D +Rule LH 1986 1989 - Mar Sun>=15 2:00 0 S +Rule LH 1986 only - Oct 19 2:00 0:30 D +Rule LH 1987 1999 - Oct lastSun 2:00 0:30 D +Rule LH 1990 1995 - Mar Sun>=1 2:00 0 S +Rule LH 1996 2005 - Mar lastSun 2:00 0 S +Rule LH 2000 only - Aug lastSun 2:00 0:30 D +Rule LH 2001 2007 - Oct lastSun 2:00 0:30 D +Rule LH 2006 only - Apr Sun>=1 2:00 0 S +Rule LH 2007 only - Mar lastSun 2:00 0 S +Rule LH 2008 max - Apr Sun>=1 2:00 0 S +Rule LH 2008 max - Oct Sun>=1 2:00 0:30 D Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb 10:00 - EST 1981 Mar - 10:30 LH LHST + 10:30 LH LH%sT # Australian miscellany # @@ -841,39 +841,15 @@ # Implementation Dates of Daylight Saving Time within Australia # </a> summarizes daylight saving issues in Australia. -# From Arthur David Olson (2005-12-12): -# <a href="http://www.lawlink.nsw.gov.au/lawlink/Corporate/ll_agdinfo.nsf/pages/commun…"> -# Lawlink NSW:Daylight Saving in New South Wales -# </a> covers New South Wales in particular. - -# From John Mackin (1991-03-06): -# We in Australia have _never_ referred to DST as `daylight' time. -# It is called `summer' time. Now by a happy coincidence, `summer' -# and `standard' happen to start with the same letter; hence, the -# abbreviation does _not_ change... -# The legislation does not actually define abbreviations, at least -# in this State, but the abbreviation is just commonly taken to be the -# initials of the phrase, and the legislation here uniformly uses -# the phrase `summer time' and does not use the phrase `daylight -# time'. -# Announcers on the Commonwealth radio network, the ABC (for Australian -# Broadcasting Commission), use the phrases `Eastern Standard Time' -# or `Eastern Summer Time'. (Note, though, that as I say in the -# current australasia file, there is really no such thing.) Announcers -# on its overseas service, Radio Australia, use the same phrases -# prefixed by the word `Australian' when referring to local times; -# time announcements on that service, naturally enough, are made in UTC. - -# From Arthur David Olson (1992-03-08): -# Given the above, what's chosen for year-round use is: -# CST for any place operating at a GMTOFF of 9:30 -# WST for any place operating at a GMTOFF of 8:00 -# EST for any place operating at a GMTOFF of 10:00 +# From Timothy Arceri (2013-04-09) +# Webpage that lists the Australian Governments recommended time zone names and abbreviations: +# http://australia.gov.au/about-australia/our-country/time +# +# NSW Goverment time definitions (covers time zones and abbreviations): +# http://www.communityrelations.lawlink.nsw.gov.au/cru/daylight/definitions_o… # From Chuck Soper (2006-06-01): -# I recently found this Australian government web page on time zones: -# <http://www.australia.gov.au/about-australia-13time> -# And this government web page lists time zone names and abbreviations: +# This government web page lists time zone names and abbreviations: # <http://www.bom.gov.au/climate/averages/tables/daysavtm.shtml> # From Paul Eggert (2001-04-05), summarizing a long discussion about "EST" @@ -957,6 +933,33 @@ # saying that both AEST/AEDT and EST/EST are widely used and # understood in Australia. +# From Timothy Arceri (2013-04-09), results from a long discussion about +# "EST" - Eastern Summer Time versus "EDT" - Eastern Daylight Time etc.: +# +# * Do Australians more often use "EDT" or "EST"? +# +# 875,000 "Eastern Standard Time (EST)" site:.au +# 655,000 "Eastern Standard Time (AEST)" site:.au +# +# 6 "Eastern Summer Time (EST)" site:.au +# 64 "Eastern Summer Time (AEST)" site:.au +# 30,500 "Eastern Daylight Time (EDT)" site:.au +# 180,000 "Eastern Daylight Time (AEDT)" site:.au +# +# 357,000 "Central Standard Time (CST)" site:.au +# 316 "Central Standard Time (ACST)" site:.au +# +# 4 "Central Summer Time (CST)" site:.au +# 0 "Central Summer Time (ACST)" site:.au +# +# 19,600 "Central Daylight Time (CDT)" site:.au +# 157 "Central Daylight Time (ACDT)" site:.au +# +# Here we are only looking at cases where the time zone abbreviation +# has been defined. These results show that the abbreviation for Daylight +# time EDT/AEDT/CDT/ACDT is overwhelmingly greater than the usage of the +# abbreviation for Summer time EST/AEST/CST/ACST + # From Paul Eggert (1995-12-19): # Shanks & Pottenger report 2:00 for all autumn changes in Australia and NZ. # Mark Prior writes that his newspaper

3 6

EST/EDT vs AEST/AEDT in AQ
by Tobias Conradi April 11, 2013

April 11, 2013

To use "EST/EDT" instead of "AEST/AEDT" in Antartica as is by this patch: http://mm.icann.org/pipermail/tz/2013-April/018994.html and EST as is done by the IANA time zone database, could be a source of future confusion and discussion. Especially if other countries that have an EST/EDT abbreviated time inherited their abbreviations to AQ-zones. This is a vote to use AEST/AEDT, or switch completely to Internationalized time point unique abbreviations. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

[PATCH 2/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]
by Timothy Arceri April 10, 2013

April 10, 2013

--- antarctica 2013-02-21 07:40:23.000000000 +0000 +++ antarctica_new 2013-04-10 00:50:55.000000000 +0000 @@ -54,32 +54,32 @@ Rule ChileAQ 2012 max - Sep Sun>=2 4:00u 1:00 S # These rules are stolen from the `australasia' file. -Rule AusAQ 1917 only - Jan 1 0:01 1:00 - -Rule AusAQ 1917 only - Mar 25 2:00 0 - -Rule AusAQ 1942 only - Jan 1 2:00 1:00 - -Rule AusAQ 1942 only - Mar 29 2:00 0 - -Rule AusAQ 1942 only - Sep 27 2:00 1:00 - -Rule AusAQ 1943 1944 - Mar lastSun 2:00 0 - -Rule AusAQ 1943 only - Oct 3 2:00 1:00 - -Rule ATAQ 1967 only - Oct Sun>=1 2:00s 1:00 - -Rule ATAQ 1968 only - Mar lastSun 2:00s 0 - -Rule ATAQ 1968 1985 - Oct lastSun 2:00s 1:00 - -Rule ATAQ 1969 1971 - Mar Sun>=8 2:00s 0 - -Rule ATAQ 1972 only - Feb lastSun 2:00s 0 - -Rule ATAQ 1973 1981 - Mar Sun>=1 2:00s 0 - -Rule ATAQ 1982 1983 - Mar lastSun 2:00s 0 - -Rule ATAQ 1984 1986 - Mar Sun>=1 2:00s 0 - -Rule ATAQ 1986 only - Oct Sun>=15 2:00s 1:00 - -Rule ATAQ 1987 1990 - Mar Sun>=15 2:00s 0 - -Rule ATAQ 1987 only - Oct Sun>=22 2:00s 1:00 - -Rule ATAQ 1988 1990 - Oct lastSun 2:00s 1:00 - -Rule ATAQ 1991 1999 - Oct Sun>=1 2:00s 1:00 - -Rule ATAQ 1991 2005 - Mar lastSun 2:00s 0 - -Rule ATAQ 2000 only - Aug lastSun 2:00s 1:00 - -Rule ATAQ 2001 max - Oct Sun>=1 2:00s 1:00 - -Rule ATAQ 2006 only - Apr Sun>=1 2:00s 0 - -Rule ATAQ 2007 only - Mar lastSun 2:00s 0 - -Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 - +Rule AusAQ 1917 only - Jan 1 0:01 1:00 D +Rule AusAQ 1917 only - Mar 25 2:00 0 S +Rule AusAQ 1942 only - Jan 1 2:00 1:00 D +Rule AusAQ 1942 only - Mar 29 2:00 0 S +Rule AusAQ 1942 only - Sep 27 2:00 1:00 D +Rule AusAQ 1943 1944 - Mar lastSun 2:00 0 S +Rule AusAQ 1943 only - Oct 3 2:00 1:00 D +Rule ATAQ 1967 only - Oct Sun>=1 2:00s 1:00 D +Rule ATAQ 1968 only - Mar lastSun 2:00s 0 S +Rule ATAQ 1968 1985 - Oct lastSun 2:00s 1:00 D +Rule ATAQ 1969 1971 - Mar Sun>=8 2:00s 0 S +Rule ATAQ 1972 only - Feb lastSun 2:00s 0 S +Rule ATAQ 1973 1981 - Mar Sun>=1 2:00s 0 S +Rule ATAQ 1982 1983 - Mar lastSun 2:00s 0 S +Rule ATAQ 1984 1986 - Mar Sun>=1 2:00s 0 S +Rule ATAQ 1986 only - Oct Sun>=15 2:00s 1:00 D +Rule ATAQ 1987 1990 - Mar Sun>=15 2:00s 0 S +Rule ATAQ 1987 only - Oct Sun>=22 2:00s 1:00 D +Rule ATAQ 1988 1990 - Oct lastSun 2:00s 1:00 D +Rule ATAQ 1991 1999 - Oct Sun>=1 2:00s 1:00 D +Rule ATAQ 1991 2005 - Mar lastSun 2:00s 0 S +Rule ATAQ 2000 only - Aug lastSun 2:00s 1:00 D +Rule ATAQ 2001 max - Oct Sun>=1 2:00s 1:00 D +Rule ATAQ 2006 only - Apr Sun>=1 2:00s 0 S +Rule ATAQ 2007 only - Mar lastSun 2:00s 0 S +Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 S # Argentina - year-round bases # Belgrano II, Confin Coast, -770227-0343737, since 1972-02-05 @@ -167,9 +167,9 @@ 5:00 - MAWT Zone Antarctica/Macquarie 0 - zzz 1911 10:00 - EST 1916 Oct 1 2:00 - 10:00 1:00 EST 1917 Feb - 10:00 AusAQ EST 1967 - 10:00 ATAQ EST 2010 Apr 4 3:00 + 10:00 1:00 EDT 1917 Feb + 10:00 AusAQ E%sT 1967 + 10:00 ATAQ E%sT 2010 Apr 4 3:00 11:00 - MIST # Macquarie Island Time # References: # <a href="http://www.antdiv.gov.au/aad/exop/sfo/casey/casey_aws.html">

1 0

Patched file australasia - time point unique abbreviations for Australia
by Tobias Conradi April 10, 2013

April 10, 2013

A public domain patched australasia file can be found via: http://anna.info/wiki/ANNA_time_zone_database The new abbreviations are: AEST/AEDT ACST/ACDT AWST/AWDT and currently without "A" prefix: CWST/CWDT - Eucla LHST/LHDT/LHHT - Lord Howe The letters before the final T mean: S - no daylight saving D - one hour daylight saving H - half hour daylight saving Error reports are welcome. Maybe someone can create a patch file. Some may favor using internationally disambiguated abbreviations, since AE might be interpreted as United Arab Emirates, AC as Ascension Island and AW as Aruba. It could also be desired to have constant length. Such internationally time point unique abbreviations could be used by CLDR for localization. The format could be "<country code><location><type>T" and a set for Australia, covering - except for LMTs (LMT=local mean time) - all times in the IANA time zone database could be: AUEST/AUEDT - East AUCST/AUCDT - Central AUWST/AUWDT - West AUUST/AUUDT - Eucla AUHST/AUHDT/AUHHT - Lord Howe -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

6 11

Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Peter Stagg April 9, 2013

April 9, 2013

So I see the patronising attitude of the TZ database coordinators rages on :-) It has been said that their are inconsistencies in both Australian Federal & State legislation and common usage. This point can be conceded even though it is based on an assessment far removed from the actual situation. It has also been stated that the aim is to use labels and abbreviations for timezones that are most commonly used and understood. A good point as the intention is to make sure they are widely understood (FYI irony). However the basis for the decision to use the ambiguous terms and abbreviations 'Eastern Standard Time'; 'EST' and 'Eastern Summer Time'; 'EST' is a highly unscientific internet search and the paternalistic opinions of the coordinators. As there appears to be a fondness for search engine results in decision making why not try this one: australia EDT site:http://mm.icann.org/pipermail/tz/ Take a look at the number of times that, mostly Australians, have asked for the terms and abbreviations used for Australian time zones (esp. *D*aylight Saving Time) to be disambiguated. You might also look at the amount of frustration and acrimony the one-eyed, condescending responses of the coordinators and mostly non-Australian list members cause and consider how often this stops people from bothering to voice opinions and endeavouring to resolve issues. ----- On a lighter note and at the risk of hindering my own argument I'm surprised none of you jokers from out-of-town have pointed out 'ESST'; 'Eastern Standard Summer Time'. "Eastern Standard Summer Time" "ESST" site:.au about 1,810 results PS An interesting video from the 1970's Four Corners program on the ABC (Australia's national broadcaster, ICYDK) on the introduction of "Daylight Saving" in Tasmania. Note the consistent use of that term "Daylight Saving", "Summer Time" is never mentioned (FYI It's a predominantly British term) and take a look at the flight attendant's bonnet! http://www.abc.net.au/archives/80days/stories/2012/01/19/3415208.htm Peter Stagg

9 13

Letter/s for half hour daylight saving
by Tobias Conradi April 8, 2013

April 8, 2013

I just discovered that there is some precedence to use different lettering for half hour saving time. ftp://ftp.iana.org/tz/data/australasia Rule Cook 1978 only - Nov 12 0:00 0:30 HS Rule Cook 1979 1991 - Mar Sun>=1 0:00 0 - Rule Cook 1979 1990 - Oct lastSun 0:00 0:30 HS # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Pacific/Rarotonga -10:39:04 - LMT 1901 # Avarua -10:30 - CKT 1978 Nov 12 # Cook Is Time -10:00 Cook CK%sT So the recent LHHT did only deviate insofar as to use one letter (H) instead of two (HS). I added HS to the IANA time zone database documentation of abbreviations hosted at anna.info : http://anna.info/x/wiki/w/index.php?title=IANA_time_zone_database&diff=82&o… -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

TimeZine Info Problem
by dcernosia＠aol.com April 8, 2013

April 8, 2013

Guys, Ran into a little problem when I tried to process the latest TimeZone files ... a few rules, such as the one listed below, didn't process correctly ... I think there are extra tabs separating the data ... have you had any other complaints? Morocco 2013 only - Jul 9 3:00 0 Morocco 2013 only - Aug 8 2:00 1:00 S Morocco 2016 only - Jun 7 3:00 0 Morocco 2016 only - Jul 7 2:00 1:00 S Morocco 2019 only - May 6 3:00 0 - Morocco 2019 only - Jun 5 2:00 1:00 S Morocco 2022 only - May 3 2:00 1:00 S Thanks, - Dennis

3 2

Rule based management vs TZ Coordinator will or voting / fork reason
by Tobias Conradi April 7, 2013

April 7, 2013

Emails such as the recent ones about ambiguous time zone acronyms can be avoided if the management of the database would be more rule based. It seems there is no rule prohibiting one abbreviation from referring to two offsets within one country at a given point in time. So adding a rule to the Theory file prohibiting this would be one step. The other issue is, that if rules exists, e.g. ftp://ftp.iana.org/tz/code/Theory ----- Scope of the tz database ----- The tz database attempts to record the history and predicted future of all computer-based clocks that track civil time. To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). that they are also enforced. But the TZ Coordinator is sometimes not enforcing them, as the Siberia bug (Asia/Tomsk and Asia/Barnaul patch was provided to the list) shows. Arbitrary application of rules can be a fork reason. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Peter Stagg April 7, 2013

April 7, 2013

Thanks to David et al for taking this initiative. In respons to the specific questions posed: - would the preference be to preceed the abbreviations with A, or not? I think the 'A' is most apropriate and is in keeping with my understanding of conventioned followed in Australia. It would also be very easy to deal with in the situation where a programer may want to drop the 'A' - historically, how far back should we apply the patch to the abbreviations. I'm in favour of retro-fitting it to the start of Daylight Savings in Australia (sate-based dependancies taken into account). After all its a bit like BC and AD. If you we're wandering around in 200BC you had no idea it was 200BC but today we would not refer to it as anything else (unless you don't use the christian calendar, of course). ________________________________________ Date: Sun, 07 Apr 2013 21:19:36 -0400 From: David Patte ? <dpatte(a)relativedata.com> Subject: Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED] To: tz(a)iana.org Message-ID: <51621B28.4030105(a)relativedata.com> Content-Type: text/plain; charset=UTF-8; format=flowed A group of us from the list have decided to put together a proposed patch to change the Australian abbreviations to S/D abbreviations. We are hoping, that the maintainers of tz decide to implement the patch in the tz database. In the mean time: - would the preference be to preceed the abbreviations with A, or not? - historically, how far back should we apply the patch to the abbreviations. We will submit the patch to the list for review, and hope it is implemented. But if it is not, we have decided to fork tz and provide a new distribution with the new abbreviations applied. David Patte Relative Data, Inc. _______________________________________________

1 0

Re: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect [SEC=UNCLASSIFIED]
by Peter Stagg April 7, 2013

April 7, 2013

"Lies, damned lies, and statistics" - I guess it depends on how you cut the cloth: search: legislation "standard time" "daylight saving" site:.gov.au About 25,600 results (0.21 seconds) search: legislation "standard time" "summer time" site:.gov.au About 15,600 results (0.14 seconds) Yes in some cases you will find the following: 'daylight saving time ("summer time")'; that to me supports the notion of "daylight saving" ahead of "summer time". N.B. ".gov.au" searches all state and federal official sites as they all use this domain. (e.g. Federal = just .gov.au, State i.e. Victoria = .vic.gov.au ). I've noticed through my various searches of government websites that whilst the legislative instruments for time may often use the term "Summer Time" (Vic & NSW only) their public facing information sites use the term "Daylight Saving". http://www.nsw.gov.au/daylight-saving http://www.business.vic.gov.au/operating-a-business/how-to-start/trading-ho… http://australia.gov.au/about-australia/our-country/time http://www.dpac.tas.gov.au/divisions/policy/daylightsavings http://www.cmd.act.gov.au/communication/holidays http://www.safework.sa.gov.au/show_page.jsp?id=2675 WA, QLD and NT do not have daylight savings but still: http://www.premiers.qld.gov.au/publications/categories/reports/daylight-sav… http://www.parliament.wa.gov.au/parliament/bills.nsf/BillProgressPopup?open… And yes these are cherry-picked - to the most part these ar all public facing official government pages communicating to the Australian populous about "Daylight Saving" not "Summer Time" - if "Summer Time" was lingua franca, don't you think they (we) would use it? Peter Stagg

1 0

Please remove ambiguous time zone abreviations for Australia [SEC=UNCLASSIFIED]
by Robert Greenwood April 7, 2013

April 7, 2013

Hi all, I know this might sound like a broken record to some, but could we please remove ambiguous time zone abreviations for Australia? I can't for the life of me understand why anyone would want to keep the Australian zones as EST/EST and CST/CST rather than EST/EDT and CST/CDT or AEST/AEDT and ACST/ACDT. Stating that there in no need to change it is nonsensical. It is obvious that using the abbreviation Eastern Standard Time (EST) and Eastern Summer Time (EST) is useless at best. The fact that if you have time zones you need them to be unambiguous is self evident, otherwise why have them. Stating that there are conflicting messages from state and federal government regarding the use of time zones in Australia is misleading. No State or federal government proposes the use of EST/EST and CST/CST as the correct usage of time zone abbreviations. Whilst there is some inconsistency in the usage of AEDT/EDT/EDST within those sites when they explicitly state which time zone should be used it is AEST/AEDT and ACST/ACDT. Finally, the arguments around the usage of Eastern/Central Summer Time (EST/CST) being the status Quo amongst Australians based off the survey conducted in the following linked is flawed: http://mm.icann.org/pipermail/tz/2012-October/018364.html searching for EDT or EST by themselves will return a number of things that have no relation to time zones. Similarly, "Eastern Summer Time" and "Eastern Daylight Time" do not necessarily relate to the usage of a particular abbreviation. Searching for the number of hits for the following strings gives a better understanding of the usage of the relevant time zone acronyms in Australia: Google results for au domain: 45,100: "Eastern Standard Time (EST)" 82,400: "Eastern Standard Time (AEST)" 34,900: "Eastern Summer Time (EST)" 117: "Eastern Summer Time (AEST)" 72,100: "Eastern Daylight Time (EDT)" 218,000: "Eastern Daylight Time (AEDT)" 387,000: "Central Standard Time (CST)" 8,030: "Central Standard Time (ACST)" 3: "Central Summer Time (CST)" 3: "Central Summer Time (ACST)" 22,300: "Central Daylight Time (CDT)" 1,460: "Central Daylight Time (ACDT)" Here we are only looking at cases where the time zone abbreviation has been defined. These results show that the abbreviation for Daylight time EDT/AEDT/CDT/ACDT is overwhelmingly greater than the usage of the abbreviation for Summer time EST/AEST/CST/ACST. Furthermore, varients of the search for "Eastern Daylight Saving/s Time (A/EDT)" give another ~3,000 hits and variants of "Eastern Daylight Saving/s Time (A/EDST)" only give ~ 500 results. However, a cursory glance still shows that many of these results are not related to Australia. So this method is still flawed but I cannot think of a better way of searching for the status Quo. Please change the time zone abbreviations in Australia to EST/EDT and CST/CDT or AEST/AEDT and ACST/ACDT. ----------------------------------------------------------------------------- Dr Robert Greenwood | Tsunami Modelling Support National Meteorological and Oceanographic Centre Bureau of Meteorology GPO Box 1289 Melbourne VIC 3001 Level 11, 700 Collins Street, Docklands VIC 3008 Tel: +61 3 9616 8455 | r.greenwood(a)bom.gov.au<mailto:r.greenwood@bom.gov.au> -----------------------------------------------------------------------------

2 1

White House petitioned to end DST
by Arthur David Olson April 4, 2013

April 4, 2013

An electronic petition to "Eliminate the bi-annual time change caused by Daylight Savings [sic] Time" appears at... https://petitions.whitehouse.gov/petition/eliminate-bi-annual-time-change-c… ...and as of this writing has about 6,000 of the 100,000 electronic signatures required for an official White House response. @dashdashado

3 3

How to compute the moment of the next DST change
by Simon Perreault April 4, 2013

April 4, 2013

Dear time experts, I want to write a cron job or similar that activates one week prior to daylight saving time changes. (Or, more generically, one week prior to any time jumps, for any reason, DST or else.) Any pointers? I have looked at the usual places: POSIX time functions, various date/time modules on CPAN, etc. Nothing seems to do that computation. Do I need to parse the tz database myself? Thanks, Simon

14 20

Ambiguous abbreviations for Australian timezones when daylight savings is in affect
by Timothy Arceri April 3, 2013

April 3, 2013

Hi All, I’d like to bring this very important issue back up for discussion. I’m going to attempt to address the reason why this change is needed as clearly as possible while addressing the concerns from previous discussions. The issue is with both EST (Tasmania, Victoria, New South Wales, Queensland) and CST (South Australia, Northern Territory) It's well past time the Australian abbreviations were updated to reflect the current terms and usage. Stop the confusion and use the abbreviations recommended by the Australian government to try to avoid this mess. http://australia.gov.au/about-australia/our-country/time#daylightsaving As others have posted I’m not too concerned about the 'A' but as you will see differentiating between daylight savings times is extremely important when you are using this information in a system that crosses state boundaries and in our case an emergency warning system. Previous Post: --------------------- “I'm not a big fan of change for change's sake; once the database is one way I like to leave it alone. For phrases, the new statistics seem to be quite strong; for whatever reason, Australians seem to be voting with their feet (or fingers) and are adopting American terminology with an "Australian", when the time zone names are spelled out. For abbreviations, it's not clear whether "AEDT" or "EDT" is more common, though I suppose "AEDT" has a slight edge. I'd like to hear more from Australian correspondents on this before thinking about specific changes, though.” - Paul Eggert (26 Aug 2008) I don’t think anyone here cares deeply enough about time zone abbreviations enough to be arguing about change for change’s sake. The fact is the ambiguity of the current abbreviations for time zones is causing real world problems. Previous Post: --------------------- “Alphabetic time zone abbreviations should not be used as unique identifiers for UTC offsets as they are ambiguous in practice. For example, "EST" denotes 5 hours behind UTC in English-speaking North America, but it denotes 10 or 11 hours ahead of UTC in Australia; and French-speaking North Americans prefer "HNE" to "EST".” - Paul Eggert (26 Aug 2008) The issue is not that the identifiers are not unique worldwide. The problem is that they are not unique to bordering states in the same country which run along the same time zone. Most apply daylight savings time, one (Queensland) does not, this is what causes the confusion. Simply using UTC +10 or UTC +11 is not good enough as the general public has no idea what UTC is. Previous Post: --------------------- “I have always assumed that the common abbreviation (EST for standard time, and EST for summer time) was a very deliberate choice, chosen so that if it ever was appropriate to specify a time with an abbreviated zone name, then the time specified would apply year around, which is almost always what is intended” - Robert Elz (5 Jan 2009) If all states that used EST applied daylight saving then this would be convenient but as stated above they do not. The problem can be seen in the delivery example where it would appear an Australian company does delivery’s via time travel. Previous Post: --------------------- “Queensland don't have Daylight Saving Time. New South Wales (across the border from Queensland) do have Daylight Saving Time. Due to the fact that the Olsen data uses EST for both 'Eastern Summer Time' (New South Wales) and 'Eastern Standard Time' (Queensland), a delivery from New South Wales to Queensland can have a pickup time of 10.30am EST and a delivery time of 10.00am EST. We like to be efficient but we're not that good. System users only see the EST and get horribly confused.” - Mick Johnston (26 Aug 2008) So obviously I’m pushing this for my own reason also. We currently use unix based systems to produce tsunami arrival times for the Australian Tsunami Warning System. This information is displayed on a public webpage (and as described above cannot use UTC convention). The issue comes into play when listing arrival times for the east coast of Australia, simply listing all arrival times as EST will obviously cause confusion especially for towns located near the border of NSW/QLD where it would appear to take a tsunami an extra hour to arrive only a couple of kilometres away. Currently we cannot use the default unix time zone commands and must rely on the use of a script to parse the time zone files and produce EST/EDT abbreviations. Obviously the ideal solution is to fix the EST/CST abbreviations once and for all so the all Australians can finally have software that produces time zones abbreviations that can be read by the general public and be used without having to provide added context. Note: In our organisation alone this issue has been brought up independently by multiple areas. Timothy Arceri

28 98

Acronyms - localization - more CLDR failures
by Tobias Conradi April 3, 2013

April 3, 2013

On Wed, Apr 3, 2013 at 12:56 AM, Derick Rethans <tz(a)derickrethans.nl> wrote: >> I disagree. I think it's natural to want to abbreviate, especially >> with things that are repeated a lot. > > But that has to be done in a localized way anyway. With the default local being English in the IANA time zone database. > In the Netherlands, > nobody uses CEST or CET, but rather MEZT and MET... Sure? https://www.google.com/search?q=cet+central+site%3Anl And CLDR does not even have MEZT and MET for the Dutch language as you claim is exclusively used in the Netherlands: http://www.unicode.org/repos/cldr/trunk/common/main/nl.xml <metazone type="Europe_Central"> <long> <generic>Midden-Europese tijd</generic> <standard>Midden-Europese standaardtijd</standard> <daylight>Midden-Europese zomertijd</daylight> </long> <short> <generic>CET</generic> <standard>CET</standard> <daylight>CEST</daylight> </short> </metazone> > but the tz database > doesn't have those either. The localization and naming is done very well > in CLDR. Counter evidence (Failure on Mexico / Tiempo del Pacifico) has been shown. > I have implemented the Date/Time support (utilizing this > database) in PHP, and have given many presentations about the subject. Ever in front of Mexicans showing Spanish localization for Mexico or in front of Dutch speakers showing Dutch localization for Central Europe? > I > always hammer in two things: .... never > rely or use an abbreviation for anything. Why not? CET in the context of Europe always refers to "Central European Time", doesn't it? Same may go for WAT in Africa and West Africa Time. As seen with AxT representing AxST/AxDT in Australia, the acronyms are not all usable in the IANA time zone database, but duplicating information and inventing new IDs like Europe_Central (=CET), America_Pacific (US and CA = America?) as is done in http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml seems like creating a field for having more bugs. Let's check Shanghai: http://en.wikipedia.org/wiki/Time_in_China In mainland China standard time is called Beijing Time (北京时间) https://www.google.com/search?q="北京时间" ~ 57 mio results http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml <timezone type="Asia/Shanghai"> <usesMetazone mzone="China"/> </timezone> http://www.unicode.org/repos/cldr/trunk/common/main/zh.xml <metazone type="China"> <long> <generic>中国时间</generic> <standard>中国标准时间</standard> <daylight>中国夏令时间</daylight> </long> </metazone> 中国 = China https://www.google.com/search?q="中国时间" ~ 1 mio results https://www.google.com/search?q="中国标准时间" ~ 230 000 results http://www.unicode.org/repos/cldr/trunk/common/main/en.xml <metazone type="China"> <long> <generic>China Time</generic> <standard>China Standard Time</standard> <daylight>China Daylight Time</daylight> </long> </metazone> No acronyms at all! -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

A failure - CLDR as an IANA time zone database extension for Mexico
by Tobias Conradi April 2, 2013

April 2, 2013

Tiempo del Pacifico http://es.wikipedia.org/wiki/Zonas_horarias_de_M%C3%A9xico#Tiempo_del_Pac.C… Tiempo del Pacifico -6/-7 confirmed by http://www.cenam.mx/hora_oficial/ Tiempo del Pacífico = UTC(CNM) – (N+1) Donde N es 6 horas para el horario de invierno y 5 horas para el horario de verano. ==Test 1 - Tijuana== The only Pacific that I can find in http://www.unicode.org/repos/cldr/trunk/common/main/es.xml outside the Area/Locations names are in that section: <metazone type="America_Pacific"> <long> <generic>Hora del Pacífico</generic> <standard>Hora estándar del Pacífico</standard> <daylight>Hora de verano del Pacífico</daylight> </long> </metazone> An example zone for America_Pacific from http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml mapZone other="America_Pacific" territory="MX" type="America/Tijuana"/ Look America/Tijuana up in ftp://ftp.iana.org/tz/data/zone.tab America/Tijuana US Pacific Time - Baja California near US border ftp://ftp.iana.org/tz/data/northamerica -8:00 Mexico P%sT 2010 -8:00 US P%sT ==Example 2 - Hermosillo== ftp://ftp.iana.org/tz/data/zone.tab America/Hermosillo Mountain Standard Time - Sonora -7:00 Mexico M%sT 1999 -7:00 - MST That is "Tiempo del Pacífico", using http://www.cenam.mx/hora_oficial/ Tiempo del Pacífico = UTC(CNM) – (N+1) Donde N es 6 horas para el horario de invierno .... http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml <timezone type="America/Hermosillo"> <usesMetazone to="1970-01-01 08:00" mzone="America_Pacific"/> <usesMetazone from="1970-01-01 08:00" mzone="America_Mountain"/> </timezone> http://www.unicode.org/repos/cldr/trunk/common/main/es.xml <metazone type="America_Mountain"> <long> <generic>Hora de las Montañas</generic> <standard>Hora estándar de Montaña</standard> <daylight>Hora de verano de Montaña</daylight> </long> </metazone> -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

3 2

Scheduling - use case for acronyms
by Tobias Conradi April 2, 2013

April 2, 2013

Was: [tz] Ambiguous abbreviations for Australian timezones when daylight savings is in affect On Tue, Apr 2, 2013 at 7:08 PM, Russ Allbery <rra(a)stanford.edu> wrote: > Humans don't need the abbreviation and don't care. False - as numerous emails and usages demonstrate. > They either schedule > the meeting in local time That might be unknown or ambiguous. > or in the current time in some other time zone Exactly, and that would be communicated how, in a brief manner - as Mark used in "Mondays at 8:00 PT" > (or possibly in UTC) UTC might be unknown at time of scheduling or not decipherable by the receiver. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

3 4

Blame it on Caesar, talk from PyCon 2013
by Stuart Bishop April 2, 2013

April 2, 2013

People on this list may be interested in this talk from PyCon 2013, available on YouTube at http://www.youtube.com/watch?v=GBKqRhn0ekM In it Lennart Regebro provides an overview of historical calendars before moving onto the modern real world issues developers face when dealing with calendaring. -- Stuart Bishop <stuart(a)stuartbishop.net> http://www.stuartbishop.net/

1 0

Australian Timezone Abreviations (Daylight Savings Time) [SEC=UNOFFICIAL]
by Peter Stagg March 30, 2013

March 30, 2013

I have resently had the clasic issue at work with strftime returning only EST, CST (Standard Time) etc. as the timezone abreviation for Australian time zones even when where in daylight savings time. Given that the Australian Government now has offical advice as to what these abreviations should be <http://australia.gov.au/about-australia/our-country/time#daylightsaving> would it not be possible to include them in the data now? Regards, Peter Stagg | Web Developer, Radar Systems Bureau of Meteorology Australian Meteorological Data Information Services System (AMDISS) Bureau of Meteorology GPO Box 1289 Melbourne VIC 3001 Level 6, 700 Collins Street, Docklands VIC 3008 Tel: +61 3 9669 4232 | Fax: +61 3 9669 4128 www.bom.gov.au

15 19

Ukraine time changes
by Michael Hustwait March 25, 2013

March 25, 2013

Hi there As a reader of your website I understand ukraine is due to scrap dst from end march 2013 and stay on winter trime permanently Is this still the case? Regards Michael Hustwait Watford London England

3 2

Praguay DST Update
by Juan Carlos YJ. Lin March 25, 2013

March 25, 2013

Dear Paul Eggert I will like to contribute to update Paraguay DST timezone info. At 2013-b (Released 2013-03-11 ) Paraguay DST is set as no permanent change. Since there is a decree 10.780 ( 2013-03-15 ) that make the change permanent, the database should be updated. Summary # From Juan Carlos YJ Lin ( 2013-03-25 ) # A decree by President was issued in Paraguay (no. 10780) on 2013-03-15 that changed the # DST method to be from the first Sunday in October to the fourth Sunday in March (60 minutes) # So the change is permanent. Attached the decree pdf issued by Paraguay President You can find it out in by searching 10780 decree at http://www.presidencia.gov.py/decretos.php Juan Carlos Lin Unisoft S.A. +595-993-288330 --------------------------------------------------- "Antes de imprimir, recuC)rdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisiC3n del contenido no estC! autorizada fuera del contexto de su envC-o y a quien corresponde. El uso no autorizado de la informaciC3n en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bC3rrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias."

2 1

Paraguay DST Changes
by Juan Carlos YJ. Lin March 25, 2013

March 25, 2013

Dear Paul Eggert I will like to contribute to update Paraguay DST timezone info. At 2013-b (Released 2013-03-11) Paraguay DST is set as no permanent change. Since there is a decree 10.780 (2013-03-15) that make the change permanent, the database should be updated. Summary # From Juan Carlos YJ Lin (2013-03-25) # A decree by President was issued in Paraguay (no. 10780) on 2013-03-15 that changed the # DST method to be from the first Sunday in October to the fourth Sunday in March (60 minutes) # So the change is permanent. Attached the decree pdf issued by Paraguay President You can find it out in by searching 10780 decree at http://www.presidencia.gov.py/decretos.php JUAN CARLOS YJ LIN Tecnología de la Información MONALISA Internacional SA Boquerón 310 Ciudad del Este – PARAGUAY Tel + 595 61 500 645 Fax + 595 61 512 695 lin(a)monalisa.com.py www.monalisa.com.py --------------------------------------------------- "Antes de imprimir, recuérdese de su compromiso con el Medio Ambiente" "Aviso: Este mensaje es dirigido para su destinatario y contiene informaciones que no pueden ser usadas por otras personas que no sean su(s) destinatario(s). La retransmisión del contenido no está autorizada fuera del contexto de su envío y a quien corresponde. El uso no autorizado de la información en este mensaje se halla penado por las leyes vigentes en todo el mundo. Si ha recibido este mensaje por error, por favor bórrala y notifique al remitente en la brevedad posible. El contenido de este mensaje no es responsabilidad de la Empresa y debe ser atribuido siempre a su autor. Gracias."

1 0

Turkey DST time
by Serkan Kaba March 25, 2013

March 25, 2013

Hi, The time at night where Turkey switches to DST is different from rest of the Europe. Please check http://www.timeanddate.com/worldclock/clockchange.html?n=19&year=2013 for details. Regards, Serkan

3 3

Re: [tz] Turkey DST time
by Serkan Kaba March 24, 2013

March 24, 2013

Merhaba, Yes apparently that's the case. Thanks for validating this. There are plans for fixing the timezone to UTC+3 in 2014 but we'll see. Regards, Serkan ________________________________ From: Even Scharning <tzdb(a)time.is> To: Serkan Kaba <serkan_kaba(a)yahoo.com> Sent: Monday, March 25, 2013 7:05 AM Subject: Re: [tz] Turkey DST time Merhaba Serkan, Turkey is constantly one hour ahead of most of Europe, but the DST switch occurs simultaneously in Turkey and Europe. The rules in the Time Zone Database are correct. This page illustrates the upcoming DST switch: http://time.is/compare/0000_31_Mar_2013_UTC/CET/Turkey Sincerely, Even Scharning Time.is - exact time, any time zone http://time.is/ On 2013-03-25 7:18, Serkan Kaba wrote: > Hi, > > The time at night where Turkey switches to DST is different from rest > of the Europe. Please check > http://www.timeanddate.com/worldclock/clockchange.html?n=19&year=2013 > [1] for details. > > Regards, > Serkan

1 0

Chile DST
by Carlos Moffat March 22, 2013

March 22, 2013

Hi Guys, It looks like the announcment of 2013-B has Chile going from GMT-3 to GMT-4 on April 23rd and the opposite on Sep 2nd. However, the correct dates are April 28th and Sep 7th. An official source for this stuff in Chile is the Navy's "Hora Oficial" website: http://www.horaoficial.cl/cambio.htm All the best, Carlos

2 2

Missing functionality (general question) - C11 functions, Localization, etc...
by random832＠fastmail.us March 21, 2013

March 21, 2013

In working on a windows/MSVC port of tzcode, I have run into the issue of functions that MSVCRT implements that tzcode does not, and the question of how much of it to implement. Part of the reason you haven't heard anything more from me even though I've had the code itself building for weeks is that it's hard to really determine when I can declare it "finished". Some of it are newer standard functions (wcstime from C95, localtime_s from C11), some are functions created by microsoft that no-one else has (_dstbias to match timezone and daylight, _mkgmtime which is their name for timegm, _wctime which is a wide character version of ctime), some of it is an artifact of them simultaneously supporting 32- and 64-bit time_t, and some of it are old unix functions (e.g. ftime) that MS happens to implement and tzcode does not. Some of these functions are problematic to implement in a third-party library. The means by which localtime_s and others in that family are meant to call their error handlers is not specified in C11, and MSVC uses a different (and nonstandard even though the standard was proposed by microsoft) mechanism from slibc. There's also miscellaneous other bits of missing functionality. strftime provides some localization functionality for months and weekdays, but not for e.g. %E and %O or for timezone abbreviations. Also, since the tzdata file format itself contains no provision for localization, I can't think of any C implementation that _does_ implement localized timezone abbreviations (I think there are some in other languages that use the tz data in combination with the CLDR data) As an aside, support for localized timezone abbreviations might be a solution to the AEST/EST half of the australian timezone debate. I get the impression (based on a comment in the section on Canadian timezones) that it was decided in 1994 that localization would be someone else's problem, and this was never revisited, nor actually became anyone else's problem. More than this, my main question is - what is the role of tzcode - the library functions, that is, not the tools - itself? Is it simply a reference implementation, to be used by libc maintainers and integrated into their libraries as they see fit? Is it meant to be used as a drop-in replacement for the system libc's time functions by application developers who need consistent timezone handling? In short - is there a roadmap for adding new functionality to tzcode, and/or is there any reason _not_ to do so besides not having anyone volunteering to work on it (I can look at it, but I don't want to if it's going to be rejected, or if there's no point) -- Random832

3 5

Error with America/Santiago?
by Jonathan Berger March 15, 2013

March 15, 2013

I originally mailed tz(a)elsie.nci.nih.gov, the address listed at the top of http://www.twinsun.com/tz/tz-link.htm but the address bounced. Is this the correct email address? Hello, I believe there might be an error with the definition for 'America/Santiago'. Actual Behavior As of March 12, 2013 at 10:30pm UTC the tz database reports 'America/Santiago' to be CLT-0400. Expected Behavior >From looking at Wikipedia, WorldTime.com, and TimeAndDate.com, all three agree that 'America/Santiago' should be at CLST-0300 for March 12, 2013 at 10:30pm UTC. I'm basing this report on the version of the tz database included in the Python library pytz-2012j which was released on 2013-01-03. I have not yet checked the source tz database files. I'm hoping someone on this list can help. Thanks, Jonathan

5 5

Paraguay DST ends earlier
by Steffen Thorsen March 15, 2013

March 15, 2013

A user tipped us that Paraguay will end DST on 2013-03-24 00:00. We've been able to find a government source that confirms this, along with news from media, but the final decree might not be out yet. They do not tell if this will be a permanent change or just this year. Government source (Spanish): http://www.ande.gov.py/interna.php?id=1075 Translated by Google: "The president of the Directors National of Electricity (ANDE), Carlos Heisele, announced the change of schedule for the next 24 March, with which the clocks of the country should fall behind 60 minutes . This action is performed normally in the second week of the month of April, however forward the change of schedule by request of the citizens." We will keep this page updated: (Permanent link, English) http://www.timeanddate.com/news/time/paraguay-dst-march-2013.html Best regards, Steffen Thorsen - timeanddate.com

3 4

Haiti on DST
by Steffen Thorsen March 14, 2013

March 14, 2013

It appears that Haiti is observing DST this year as well, same rules as US/Canada. They did it last year as well, and it looks like they are going to observe DST every year now (based on the sources listed below). A user tipped us, we found these sources that verifies it: http://radiovision2000haiti.net/public/haiti-avis-changement-dheure-dimanch… http://www.canalplushaiti.net/?p=6714 Best regards, Steffen Thorsen - timeanddate.com

10 13

windows [MSVC] port progress
by random832＠fastmail.us March 13, 2013

March 13, 2013

I've made a makefile that can build the library functions (64-bit time_t only, and haven't done anything yet about MSVCRT functions showing up through names that tzcode doesn't define such as localtime_s or _ftime [or the 32-bit names]), and successfully compiled zdump. I was wondering if anyone had any ideas which approach would be best for implementing the 32-bit functions. Some background: MSVC defines two sets of time functions: for 32-bit and 64-bit time_t. But some functions (e.g. tzset and strftime) are shared between them. (VC2003 defines the default names as 32-bit, and I don't know if VC6 has the 64-bit functions at all - making it work on these versions may be somewhat more difficult) I could: A. Compile separate 32 and 64 bit versions of the library (what happens if a single program tries to call both?) B. Compile a single library with 32 and 64 bit versions of functions, a custom tzset function that calls both (this will pull in most of the 64-bit library when compiling a 32-bit program, but I can avoid pulling in the 32-bit objects when compiling a 64-bit program) C. Write wrapper 32-bit functions for 64-bit functions - a bit less bloated than solution B, but more work. D. ??? I want to eventually customize tzset anyway, to get the local time zone from the system settings when TZ is not set (CLDR contains a mapping from Windows time zone names to tzdata ones). Speaking of which, does anyone on the list have a non-English version of Windows to test something with?

1 0

DST in the news
by Arthur David Olson March 11, 2013

March 11, 2013

After the weekend start of DST in the US, "Metro riders pay for extended peak period" per the Washington (DC) Post: http://www.washingtonpost.com/local/trafficandcommuting/metro-riders-pay-fo… @dashdashado

3 2

[PATCH] Update URLs in tz-link page.
by Paul Eggert March 10, 2013

March 10, 2013

* tz-link.htm: Add URLs for webOS, BB10, iOS. Update URL for Solaris. Mention Internet RFC 6557. Update Internet RFCs 2445->5545, 2822->5322. Switch from FTP to HTTP for Internet RFCs. --- tz-link.htm | 35 ++++++++++++++++++----------------- 1 file changed, 18 insertions(+), 17 deletions(-) diff --git a/tz-link.htm b/tz-link.htm index 67b2433..5e24fed 100644 --- a/tz-link.htm +++ b/tz-link.htm @@ -8,7 +8,7 @@ <meta http-equiv="Content-type" content='text/html; charset="US-ASCII"'> <meta name="DC.Creator" content="Eggert, Paul"> <meta name="DC.Contributor" content="Olson, Arthur David"> -<meta name="DC.Date" content="2013-02-21"> +<meta name="DC.Date" content="2013-03-11"> <meta name="DC.Description" content="Sources of information about time zones and daylight saving time"> <meta name="DC.Identifier" @@ -37,8 +37,8 @@ is used by several implementations, including <a href="http://www.gnu.org/software/libc/">the <abbr title="GNU's Not Unix">GNU</abbr> -C Library</a> used in -<a href="http://www.linux.org/"><abbr>GNU</abbr>/Linux</a>, +C Library</a> (used in +<a href="http://www.linux.org/"><abbr>GNU</abbr>/Linux</a>), <a href="http://www.android.com/">Android</a>, <a href="http://www.freebsd.org/">FreeBSD</a>, <a href="http://netbsd.org/">NetBSD</a>, @@ -46,11 +46,14 @@ C Library</a> used in <a href="http://cygwin.com/">Cygwin</a>, <a href="http://www.delorie.com/djgpp/"><abbr title="DJ's GNU Programming Platform">DJGPP</abbr></a>, +<a href="http://en.wikipedia.org/wiki/WebOS">webOS</a>, <a href="http://ibm.com/aix">AIX</a>, +<a href="http://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, +<a href="http://www.apple.com/ios/">iOS</a>, <a href="http://h71000.www7.hp.com/">OpenVMS</a>, <a href="http://oracle.com/database">Oracle Database</a>, <a href="http://www.apple.com/osx/">OS X</a>, -<a href="http://sun.com/software/solaris">Solaris</a>, +<a href="http://oracle.com/solaris">Solaris</a>, <a href="http://h30097.www3.hp.com/">Tru64</a>, and <a href="http://sco.com/products/unixware">UnixWare</a>.</p> <p> @@ -123,7 +126,10 @@ messages</a> sent to the mailing list, <a href="https://mm.icann.org/mailman/listinfo/tz">subscribe</a> to it, and browse the <a href="http://mm.icann.org/pipermail/tz/">archive of old -messages</a>.</p> +messages</a>. For further information about updates, please see +<a href="http://tools.ietf.org/html/rfc6557">Procedures for +Maintaining the Time Zone Database</a> (Internet <abbr title="Request +For Comments">RFC</abbr> 6557).</p> <p> The Web has several other sources for time zone and daylight saving time data. Here are some links that may be of interest. @@ -159,14 +165,9 @@ tz data files.</li> </ul> <h2>Other time zone database formats</h2> <ul> -<li>The <a href="ftp://ftp.rfc-editor.org/in-notes/rfc2445.txt"> +<li>The <a href="http://tools.ietf.org/html/rfc5545"> Internet Calendaring and Scheduling Core Object Specification -(iCalendar)</a>, Internet <abbr title="Request For -Comments">RFC</abbr> 2445, published by the (now-concluded) <a -href="http://ietf.org/html.charters/OLD/calsch-charter.html"><abbr -title="Internet Engineering Task Force">IETF</abbr> -Calendaring and Scheduling Working Group (<abbr -title="Calendaring and Scheduling Working Group">calsch</abbr>)</a> +(iCalendar)</a>, Internet <abbr>RFC</abbr> 5445 covers time zone data; see its VTIMEZONE calendar component. <a href="http://calconnect.org/">CalConnect, The Calendaring and Scheduling @@ -513,7 +514,7 @@ Time Protocol</a> discusses how to synchronize clocks of Internet hosts.</li> <li><a -href="ftp://ftp.rfc-editor.org/in-notes/rfc4833.txt">Timezone +href="http://tools.ietf.org/html/rfc4833">Timezone Options for <abbr title="Dynamic Host Configuration Protocol">DHCP</abbr></a> (Internet <abbr>RFC</abbr> 4833) specifies a <a @@ -590,13 +591,13 @@ interchange -- Representation of dates and times</a>.</li> Schema: Datatypes - dateTime</a> specifies a format inspired by <abbr>ISO</abbr> 8601 that is in common use in XML data.</li> <li> -<a href="ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt">Internet -Message Format</a> (Internet <abbr>RFC</abbr> 2822) §3.3 +<a href="http://tools.ietf.org/html/rfc5322">Internet +Message Format</a> (Internet <abbr>RFC</abbr> 5322) §3.3 specifies the time notation used in email and <a -href="ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt"><abbr>HTTP</abbr></a> +href="http://tools.ietf.org/html/rfc2616"><abbr>HTTP</abbr></a> headers.</li> <li> -<a href="ftp://ftp.rfc-editor.org/in-notes/rfc3339.txt">Date and Time +<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a> (Internet <abbr>RFC</abbr> 3339) specifies an <abbr>ISO</abbr> 8601 profile for use in new Internet -- 1.7.10.4

1 0

Re: [tz] Haiti on DST
by Steve Jones March 10, 2013

March 10, 2013

At 09:33 3/10/2013, Steffen Thorsen wrote: >It appears that Haiti is observing DST this year as well, same rules >as US/Canada. >They did it last year as well, and it looks like they are going to >observe DST every year... So, the island of Hispaniola is divided in its DST observance. The Dominican Republic does not observe DST. Before this change, crossing the Haiti/DR border meant a transition between UTC-4 and UTC-5 all year long. Now, during DST, they are both UTC-4. Regards, Steve Jones OnTimeZone.com

1 0

Ukraine Time Change
by Wong Ren March 10, 2013

March 10, 2013

Alexander Krivenyshev had written: "The Ministry of Economic Development and Trade of Ukraine has submitted a bill to abolish the daylight saving time. If approved, new bill will go into effect on March 1, 2013 and Ukraine will use UTC+2 year around" Does anyone know what will be new time zone abbreviation since Ukraine used to have EET ? Also, the tz2013a does not have the Ukraine time change, was the bill approved and any update soon? Regards, Ren Wong ________________________________ "This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Technology or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security(a)comverse.com. Thank You."

3 2

Cuba DST start as US/Canada
by Steffen Thorsen March 8, 2013

March 8, 2013

FYI: Granma, the official organ of the government confirms a 2013-03-10 DST start this year. The database already assumes this, so no change is necessary, but Cuba has had different rules the past two years, so it was not obvious that this would be the start date this year. http://www.granma.cubaweb.cu/2013/03/04/nacional/artic10.html Best regards, Steffen Thorsen - timeanddate.com

3 2

Re: [tz] tzcode for windows?
by random832＠fastmail.us March 8, 2013

March 8, 2013

On Fri, Mar 8, 2013, at 15:53, Arthur David Olson wrote: > > Haven't looked at zdump yet, and it's less useful without the library > > functions anyway. > > In theory at least, zdump is independent of everything else in the package; > > as long as the functions it calls are available all should be well. Well, yes, but it's just dumping the MSVC implementation of timezones, which is less useful than if I could get it to link against the tzcode library. I did have to switch from environ-manipulation to putenv (need to make it do that conditionally then I'll make a patch) and call tzset. How exactly was it working before without ever calling tzset? Am I missing something? Or is it just that most unix implementations, and the tzcode implementation, happen to be tolerant of calling localtime without calling tzset?

1 0

Timezones Morocco 2013 incorrect
by Erik Homoet March 7, 2013

March 7, 2013

Hi, For our internet airline booking engine of flights we¹re using the tzdata2012j version. In this version the DST timing for Morroco is not correct. We¹re facing a lot of problems because of this, this because a large amount of flights are departing from Morocco between 23:00 and 24:00. Morocco is also on Wintertime during the month of Ramadan. The correct timezone should be: WET DST starts on Sunday, 28 April 2013, 02:00 local standard time. DST ends on Tuesday, 9 July 2013, 03:00 local daylight time. DST starts on Thursday, 8 August 2013, 02:00 local standard time. DST ends on Sunday, 29 September 2013, 03:00 local daylight time. Source: http://www.timeanddate.com/worldclock/city.html?n=60 Would you please be so kind to give me an indication when this can be changed? Best regards and thanks, Erik Erik Homoet Business Consultant quintessence consulting AMS mobile: +31 614534022 email: ehomoet(a)quintessence.net skype: erik_qc_ams

8 18

dead code in zic
by christos＠zoulas.com March 7, 2013

March 7, 2013

On LP32 machines, the following code is dead: dayoff is long min_time is zic_t -> int_fast64_t if (dayoff < min_time / SECSPERDAY) { error(_("time too small")); return; } if (dayoff > max_time / SECSPERDAY) { error(_("time too large")); return; } The vax gcc-4.1 detects this; later versions of gcc don't. But all of them will warn, if you change min_time and max_time from const zic_t to #define's. What's the correct fix here? http://releng.netbsd.org/builds/HEAD/201303041020Z/vax.build.failed christos

7 14

Paraguay may move out of DST earlier this year
by Carlos Raúl Perasso March 6, 2013

March 6, 2013

The Paraguayan Electric Company (ANDE) plans to move out of DST a couple of weeks earlier this year. There is nothing final yet. An article from a local newspaper: http://www.abc.com.py/nacionales/ande-quiere-adelantar-el-atraso-de-los-rel… I'll will report changes on this subject. Carlos Perasso

1 0

Re: [tz] Discussion in ECMA about tz identifiers in JavaScript
by SM March 6, 2013

March 6, 2013

Hi Paul, At 13:07 05-03-2013, Paul_Koning(a)Dell.com wrote: >I don't agree. Such material would be "informational" exactly as it >is today, not "normative" -- it gives background, it doesn't create >any new requirements. The only consequence of having it in an RFC >is that it would be visible rather than buried. And based on the >discussion we've been having, that is clearly a needed improvement. There is an indirect link [1] between my comment and things that happened. It's useful to keep the project going [2]. Regards, -sm 1. http://mm.icann.org/pipermail/tz/2009-August/015750.html 2. http://mm.icann.org/pipermail/tz/2011-October/016898.html

1 0

Discussion in ECMA about tz identifiers in JavaScript
by Shawn Steele March 5, 2013

March 5, 2013

In case anyone’s interested, there’s a discussion on es-discuss(a)mozilla.org<mailto:es-discuss@mozilla.org> (the ecmascript discussion list) about time zone identifiers in Javascript. -Shawn   http://blogs.msdn.com/shawnste

9 16

Re: [tz] Discussion in ECMA about tz identifiers in JavaScript
by SM March 5, 2013

March 5, 2013

Hi Norbert, At 10:28 05-03-2013, Norbert Lindenberg wrote: >I wasn't aware of the Theory file, but found it after some digging. >Would it be possible to put the content of the "Names of time zone >rule files" section into a more prominent place? The best solution >for external references to the time zone database would actually be >an RFC containing that information - section 3 of RFC 6557 would >have been a good place. Has that been considered before? See http://www.ietf.org/timezones/code/Theory In my opinion there will be a loss of flexibility if the information is published as a RFC. Regards, -sm

2 1

Re: [tz] Discussion in ECMA about tz identifiers in JavaScript
by SM March 5, 2013

March 5, 2013

Hi Mark, At 00:22 05-03-2013, Mark Davis â wrote: >Some of these are simply rocks with no permanent >inhabitants, but for testing completeness it is useful to have them. As an example, see http://mm.icann.org/pipermail/tz/2012-May/017799.html Regards, -sm

1 0

[PATCH] Updates for Chile 2013
by Petr Machata March 4, 2013

March 4, 2013

--- Hi there, this is a patch for the Chile update that others have brought up. I decided to apply the transition dates to single years only--the DST policy is reevaluated every year anyway. Thanks, PM antarctica | 4 ++-- southamerica | 21 +++++++++++++++++++-- 2 files changed, 21 insertions(+), 4 deletions(-) diff --git a/antarctica b/antarctica index f55cbde..83d6826 100644 --- a/antarctica +++ b/antarctica @@ -52,8 +52,8 @@ Rule ChileAQ 2011 only - May Sun>=2 3:00u 0 - Rule ChileAQ 2011 only - Aug Sun>=16 4:00u 1:00 S Rule ChileAQ 2012 only - Apr Sun>=23 3:00u 0 - Rule ChileAQ 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule ChileAQ 2013 max - Mar Sun>=9 3:00u 0 - -Rule ChileAQ 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule ChileAQ 2013 only - Apr 28 3:00u 0 - +Rule ChileAQ 2013 only - Sep 8 4:00u 1:00 S # These rules are stolen from the `australasia' file. Rule AusAQ 1917 only - Jan 1 0:01 1:00 - diff --git a/southamerica b/southamerica index e4c8720..331c2fd 100644 --- a/southamerica +++ b/southamerica @@ -1237,6 +1237,23 @@ Zone America/Rio_Branco -4:31:12 - LMT 1914 # Note that...this is yet another "temporary" change that will be reevaluated # AGAIN in 2013. +# From Glenn Eychaner (2013-02-15): +# The article: +# <a href="http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013"> +# http://www.diarioeldia.cl/articulo/entregan-fechas-cambio-hora-este-2013 +# </a> +# +# In English: +# [At] midnight Saturday April 27. That day, the clocks should be +# delayed by 60 minutes, that is, being 23:59 hours and 59 seconds, +# instead of going at 0:00 pm, the time should be adjusted to be the +# same day 23:00. +# +# Turn, will resume DST midnight Saturday September 7. That day, the +# clocks will move forward in 60 minutes, that is, being 23:59 hours +# and 59 seconds, instead of going at 00:00 pm, will adjust the time +# to be 01:00 hours on 8 September. + # NOTE: ChileAQ rules for Antarctic bases are stored separately in the # 'antarctica' file. @@ -1280,8 +1297,8 @@ Rule Chile 2011 only - May Sun>=2 3:00u 0 - Rule Chile 2011 only - Aug Sun>=16 4:00u 1:00 S Rule Chile 2012 only - Apr Sun>=23 3:00u 0 - Rule Chile 2012 only - Sep Sun>=2 4:00u 1:00 S -Rule Chile 2013 max - Mar Sun>=9 3:00u 0 - -Rule Chile 2013 max - Oct Sun>=9 4:00u 1:00 S +Rule Chile 2013 only - Apr 28 3:00u 0 - +Rule Chile 2013 only - Sep 8 4:00u 1:00 S # IATA SSIM anomalies: (1992-02) says 1992-03-14; # (1996-09) says 1998-03-08. Ignore these. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -- 1.7.6.5

13 24

tzcode2013a and tzdata2013a available
by Paul Eggert March 3, 2013

March 3, 2013

For details, please see the recent tz-announce message, archived at: http://mm.icann.org/pipermail/tz-announce/2013-March/000009.html

2 2