[PATCH 1/4] northamerica: move America/Shiprock to 'backward'
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
This continues in the series of moving entries to 'backward' if they exist only because of obsolete tz rules about country codes. In this case, Zone entries are changed to Links; this doesn't affect any post-1970 time stamps, and the pre-1970 time stamps are out of scope and are often of dubious reliability. * backward, northamerica, southamerica (America/Anguilla) (America/Antigua, America/Aruba, America/Blanc-Sablon) (America/Cayman, America/Curacao, America/Dominica) (America/Grenada, America/Guadeloupe, America/Montserrat) (America/Port_of_Spain, America/St_Kitts, America/St_Lucia) (America/St_Thomas, America/St_Vincent, America/Tortola): Now 'backward' links to America/Puerto_Rico. (America/Atikokan): Now a 'backward' link to America/Panama. (America/Creston): Now a 'backward' link to America/Phoenix. (America/Nassau): Now a 'backward' link to America/Toronto. * backward (America/Coral_Harbour, America/Kralendijk) (America/Lower_Princes, America/Marigot, America/St_Barthelemy) (America/Virgin): Adjust to avoid link-to-a-link. --- backward | 31 +++++++++++++---- northamerica | 110 +++++++++++++++++++---------------------------------------- southamerica | 20 +++-------- 3 files changed, 64 insertions(+), 97 deletions(-) diff --git a/backward b/backward index 561e2ff..2ee440d 100644 --- a/backward +++ b/backward @@ -7,27 +7,46 @@ 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/Atikokan America/Coral_Harbour +Link America/Panama America/Cayman +Link America/Panama 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/Curacao America/Kralendijk +Link America/Puerto_Rico America/Kralendijk Link America/Kentucky/Louisville America/Louisville -Link America/Curacao America/Lower_Princes -Link America/Guadeloupe America/Marigot +Link America/Puerto_Rico America/Lower_Princes +Link America/Puerto_Rico America/Marigot Link America/Argentina/Mendoza America/Mendoza +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/Guadeloupe America/St_Barthelemy -Link America/St_Thomas America/Virgin +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 Pacific/Auckland Antarctica/McMurdo Link Pacific/Auckland Antarctica/South_Pole Link Europe/Oslo Arctic/Longyearbyen diff --git a/northamerica b/northamerica index 7676c77..5d8ad63 100644 --- a/northamerica +++ b/northamerica @@ -1341,25 +1341,23 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # Quebec -# From Paul Eggert (2006-07-09): +# From Paul Eggert (2013-08-26): # Shanks & Pottenger write that since 1970 most of Quebec has been # like Montreal. -# From Paul Eggert (2006-06-27): # Matthews and Vincent (1998) also write that Quebec east of the -63 # meridian is supposed to observe AST, but residents as far east as # Natashquan use EST/EDT, and residents east of Natashquan use AST. -# In "Official time in Quebec" the Quebec department of justice writes in -# http://www.justice.gouv.qc.ca/english/publications/generale/temps-regl-1-a.h... -# that "The residents of the Municipality of the -# Cote-Nord-du-Golfe-Saint-Laurent and the municipalities of Saint-Augustin, -# Bonne-Esperance and Blanc-Sablon apply the Official Time Act as it is -# written and use Atlantic standard time all year round. The same applies to -# the residents of the Native facilities along the lower North Shore." -# <http://www.assnat.qc.ca/eng/37legislature2/Projets-loi/Publics/06-a002.htm> +# The Quebec department of justice writes in +# "The situation in Minganie and Basse-Cote-Nord" +# http://www.justice.gouv.qc.ca/english/publications/generale/temps-minganie-a... +# that the coastal strip from just east of Natashquan to Blanc-Sablon +# observes Atlantic standard time all year round. +# http://www.assnat.qc.ca/Media/Process.aspx?MediaId=ANQ.Vigie.Bll.DocumentGen... # 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. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Mont 1917 only - Mar 25 2:00 1:00 D @@ -1392,9 +1390,6 @@ 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 @@ -1468,14 +1463,16 @@ Zone America/Montreal -4:54:16 - LMT 1884 # can say for certain that Atikokan has been practicing the current # time keeping since 1952, at least. -# From Paul Eggert (2006-07-17): +# From Paul Eggert (2013-08-26): # 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. # From Mark Brader (2010-03-06): # @@ -1633,11 +1630,6 @@ 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 @@ -1872,7 +1864,8 @@ 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. -# The transition dates (and times) are guesses. +# From Paul Eggert (2013-08-26): +# See America/Phoenix, since Creston has agreed with Phoenix since 1970. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Vanc 1918 only - Apr 14 2:00 1:00 D @@ -1892,10 +1885,6 @@ 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 @@ -2546,15 +2535,10 @@ Zone America/Santa_Isabel -7:39:28 - LMT 1922 Jan 1 0:20:32 ############################################################################### # Anguilla -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Anguilla -4:12:16 - LMT 1912 Mar 2 - -4:00 - AST +# See America/Puerto_Rico. # Antigua and Barbuda -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Antigua -4:07:12 - LMT 1912 Mar 2 - -5:00 - EST 1951 - -4:00 - AST +# See America/Puerto_Rico. # Bahamas # @@ -2564,14 +2548,8 @@ Zone America/Antigua -4:07:12 - LMT 1912 Mar 2 # 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 - -# 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 +# +# See America/Toronto. # Barbados @@ -2617,14 +2595,11 @@ Zone America/Belize -5:52:48 - LMT 1912 Apr # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Atlantic/Bermuda -4:19:18 - LMT 1930 Jan 1 2:00 # Hamilton -4:00 - AST 1974 Apr 28 2:00 - -4:00 Bahamas A%sT 1976 + -4:00 Canada A%sT 1976 -4:00 US A%sT # 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:00 - EST +# See America/Panama. # Costa Rica @@ -2870,9 +2845,7 @@ Zone America/Havana -5:29:28 - LMT 1890 -5:00 Cuba C%sT # Dominica -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Dominica -4:05:36 - LMT 1911 Jul 1 0:01 # Roseau - -4:00 - AST +# See America/Puerto_Rico. # Dominican Republic @@ -2921,15 +2894,10 @@ Zone America/El_Salvador -5:56:48 - LMT 1921 # San Salvador -6:00 Salv C%sT # Grenada -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Grenada -4:07:00 - LMT 1911 Jul # St George's - -4:00 - AST +# See America/Puerto_Rico. # Guadeloupe -# 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). +# See America/Puerto_Rico. # Guatemala # @@ -3099,9 +3067,7 @@ 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. -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Montserrat -4:08:52 - LMT 1911 Jul 1 0:01 # Cork Hill - -4:00 - AST +# See America/Puerto_Rico. # Nicaragua # @@ -3182,16 +3148,17 @@ 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 -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/St_Kitts -4:10:52 - LMT 1912 Mar 2 # Basseterre - -4:00 - AST +# See America/Puerto_Rico. # St Lucia -# 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 +# See America/Puerto_Rico. + +# St Martin (French part) +# See America/Puerto_Rico. # St Pierre and Miquelon # There are too many St Pierres elsewhere, so we'll use `Miquelon'. @@ -3202,10 +3169,7 @@ Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre -3:00 Canada PM%sT # St Vincent and the Grenadines -# 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 +# See America/Puerto_Rico. # Turks and Caicos # @@ -3239,11 +3203,7 @@ Zone America/Grand_Turk -4:44:32 - LMT 1890 -5:00 TC E%sT # British Virgin Is -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town - -4:00 - AST +# See America/Puerto_Rico. # Virgin Is -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/St_Thomas -4:19:44 - LMT 1911 Jul # Charlotte Amalie - -4:00 - AST +# See America/Puerto_Rico. diff --git a/southamerica b/southamerica index 17150a8..59f5fe7 100644 --- a/southamerica +++ b/southamerica @@ -631,10 +631,7 @@ Zone America/Argentina/Ushuaia -4:33:12 - LMT 1894 Oct 31 -3:00 - ART # Aruba -# 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 +# See America/Puerto_Rico. # Bolivia # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1328,7 +1325,7 @@ Zone America/Bogota -4:56:16 - LMT 1884 Mar 13 # Curacao -# Milne gives 4:35:46.9 for Curacao mean time; round to nearest. +# Milne gives 4:35:46.9 for Curacao mean time. # # From Paul Eggert (2006-03-22): # Shanks & Pottenger say that The Bottom and Philipsburg have been at @@ -1344,14 +1341,7 @@ 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. # -# 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 -# Bonaire, Sint Estatius and Saba -# Use America/Curacao. +# For all these regions, see America/Puerto_Rico. # Ecuador # @@ -1625,9 +1615,7 @@ Zone America/Paramaribo -3:40:40 - LMT 1911 -3:00 - SRT # Trinidad and Tobago -# Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone America/Port_of_Spain -4:06:04 - LMT 1912 Mar 2 - -4:00 - AST +# See America/Puerto_Rico. # Uruguay # From Paul Eggert (1993-11-18): -- 1.8.1.2
This is like the previous change, except it entails a change to zone.tab. The America/Montreal entry was created only because we mistakenly thought that Montreal's and Toronto's post-1970 time stamps differed. * backward, northamerica (America/Montreal): Now a 'backward' link to America/Toronto. * northamerica (Mont): Remove rules; no longer needed. (America/Thunder_Bay): Refer to Toronto rules, not Mont. This doesn't change any time stamps. * zone.tab (America/Montreal): Remove. (America/Toronto): Say that it also covers most of Quebec. --- backward | 1 + northamerica | 46 +++------------------------------------------- zone.tab | 3 +-- 3 files changed, 5 insertions(+), 45 deletions(-) diff --git a/backward b/backward index 2ee440d..efb5353 100644 --- a/backward +++ b/backward @@ -34,6 +34,7 @@ Link America/Kentucky/Louisville America/Louisville Link America/Puerto_Rico America/Lower_Princes Link America/Puerto_Rico 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 diff --git a/northamerica b/northamerica index 5d8ad63..6210318 100644 --- a/northamerica +++ b/northamerica @@ -1342,8 +1342,8 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # Quebec # From Paul Eggert (2013-08-26): -# Shanks & Pottenger write that since 1970 most of Quebec has been -# like Montreal. +# Since 1970 most of Quebec has been like Toronto. +# See America/Toronto. # Matthews and Vincent (1998) also write that Quebec east of the -63 # meridian is supposed to observe AST, but residents as far east as @@ -1359,46 +1359,6 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # Shanks & Pottenger who have this region observing AST/ADT. # See 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/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 # From Paul Eggert (2006-07-09): @@ -1619,7 +1579,7 @@ Zone America/Thunder_Bay -5:57:00 - LMT 1895 -6:00 - CST 1910 -5:00 - EST 1942 -5:00 Canada E%sT 1970 - -5:00 Mont E%sT 1973 + -5:00 Toronto E%sT 1973 -5:00 - EST 1974 -5:00 Canada E%sT Zone America/Nipigon -5:53:04 - LMT 1895 diff --git a/zone.tab b/zone.tab index b4407f1..769432b 100644 --- a/zone.tab +++ b/zone.tab @@ -122,8 +122,7 @@ CA +4612-05957 America/Glace_Bay Atlantic Time - Nova Scotia - places that did n CA +4606-06447 America/Moncton Atlantic Time - New Brunswick CA +5320-06025 America/Goose_Bay Atlantic Time - Labrador - most locations CA +5125-05707 America/Blanc-Sablon Atlantic Standard Time - Quebec - Lower North Shore -CA +4531-07334 America/Montreal Eastern Time - Quebec - most locations -CA +4339-07923 America/Toronto Eastern Time - Ontario - most locations +CA +4339-07923 America/Toronto Eastern Time - Ontario & Quebec - most locations CA +4901-08816 America/Nipigon Eastern Time - Ontario & Quebec - places that did not observe DST 1967-1973 CA +4823-08915 America/Thunder_Bay Eastern Time - Thunder Bay, Ontario CA +6344-06828 America/Iqaluit Eastern Time - east Nunavut - most locations -- 1.8.1.2
This appears to be a more common name in English for this newish political region; for example, see <http://en.wikipedia.org/wiki/Caribbean_Netherlands>. --- iso3166.tab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/iso3166.tab b/iso3166.tab index d9dcf6a..a1e4b42 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -53,7 +53,7 @@ BL St Barthelemy BM Bermuda BN Brunei BO Bolivia -BQ Bonaire, St Eustatius & Saba +BQ Caribbean Netherlands BR Brazil BS Bahamas BT Bhutan -- 1.8.1.2
Paul Eggert <eggert@cs.ucla.edu> wrote:
This continues in the series of moving entries to 'backward' if they exist only because of obsolete tz rules about country codes. In this case, Zone entries are changed to Links; this doesn't affect any post-1970 time stamps, and the pre-1970 time stamps are out of scope and are often of dubious reliability. This (and the next patch) however also removes quite a bit of data and most definitely changes tinestamps for pre 1970. Again, in my opinion without any benefits. I've said before that I have always admired the stability of this database and I see thus as very important because it allows data comsumers to trust this data.
Are you leaving this longstanding policy of data stability behind now? Cheers, Derick -- http://derickrethans.nl | http://xdebug.org twitter: @derickr and @xdebug
On 08/27/13 01:18, Derick Rethans wrote:
Are you leaving this longstanding policy of data stability behind now?
Systematic support for pre-1970 timestamps has always been outside the scope of the tz database, and as I recall it's been removed before without problems. The intent is that clock transitions before 1970 are recorded only to fill in the blank areas (on platforms with negative time_t) for locations that differ since 1970. So no, the policy hasn't changed here. For details, please see "Scope of the tz database" in the Theory file <http://www.ietf.org/timezones/code/Theory>.
The issue is whether all these changes are worth it. What are you seeking to gain? There is real value in this database of stability and backwards compatibility. Changing something because it is "neater" or general "tidying up" are bad goals here. For example, changes to LMT definitions (which is what the above looks like) will have a visible impact on users where LMT is exposed - soon to be seen by 9 million Java developers. Also, times before 1970 do matter. Whether you are certain or uncertain of the data is less important than not changing the data. In essence the TZDB has become the definition of what time was, irrespective of whether it is accurate or not. As such, history should only be changed if it is demonstratable that the original data was wrong. As such I'm skeptical of all recent changes to the TZDB. Stephen co-spec lead JSR-310 (to be used by 9 million Java developers) On 27 August 2013 19:00, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 08/27/13 01:18, Derick Rethans wrote:
Are you leaving this longstanding policy of data stability behind now?
Systematic support for pre-1970 timestamps has always been outside the scope of the tz database, and as I recall it's been removed before without problems. The intent is that clock transitions before 1970 are recorded only to fill in the blank areas (on platforms with negative time_t) for locations that differ since 1970. So no, the policy hasn't changed here.
For details, please see "Scope of the tz database" in the Theory file <http://www.ietf.org/timezones/code/Theory>.
Stephen Colebourne wrote:
Also, times before 1970 do matter. Whether you are certain or uncertain of the data is less important than not changing the data. In essence the TZDB has become the definition of what time was, irrespective of whether it is accurate or not. As such, history should only be changed if it is demonstratable that the original data was wrong.
Seconded! One of my main problems has been getting a reliable base for historic material. Many systems simply ignore dates prior to 1970, but a large number of us are using genealogical databases and need to know that we are working with the same numbers. -- 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
Lester Caine wrote
Stephen Colebourne wrote:
Also, times before 1970 do matter. Whether you are certain or uncertain of the data is less important than not changing the data. In essence the TZDB has become the definition of what time was, irrespective of whether it is accurate or not. As such, history should only be changed if it is demonstratable that the original data was wrong.
Seconded! One of my main problems has been getting a reliable base for historic material. Many systems simply ignore dates prior to 1970, but a large number of us are using genealogical databases and need to know that we are working with the same numbers.
I also value the pre-1970 data; although I can't claim an impressive user-base for my particular programs, there may well be a fair few projects out there that are quietly making good use of that data. Regards, Stephen Goudge Senior Software Engineer 390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful. Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100 Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK. ___________________________________________________________________________________________ This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
I also think its a shame that the proposed redefinition of 'tz region' will cause the loss of so much historical data, which is being used by many. I am also concerned with merging Atikokan region (north of Lake Superior) into the Panama region, 5000 km, and a half dozen countries away. I still don't see the proposed redefinition as valuable. If this change is implemented, then a separate database of pre-1970 tz data will be required my many users, as had been suggested (and started) by Tobias Conradi (currently banned) and others. I guess there could be two tz databases. Paul, are you saying that other historical data has been removed from tz in the past, as we might like to capture that old data as well into any new pre-1970 database. On 2013-08-28 7:34, Goudge, Stephen wrote:
Lester Caine wrote
Stephen Colebourne wrote:
Also, times before 1970 do matter. Whether you are certain or uncertain of the data is less important than not changing the data. In essence the TZDB has become the definition of what time was, irrespective of whether it is accurate or not. As such, history should only be changed if it is demonstratable that the original data was wrong. Seconded! One of my main problems has been getting a reliable base for historic material. Many systems simply ignore dates prior to 1970, but a large number of us are using genealogical databases and need to know that we are working with the same numbers. I also value the pre-1970 data; although I can't claim an impressive user-base for my particular programs, there may well be a fair few projects out there that are quietly making good use of that data.
Regards,
Stephen Goudge Senior Software Engineer
390 Princesway Team Valley Gateshead Tyne & Wear NE11 0TU
T +44 (0) 191 420 3015 F +44 (0) 191 420 3030 W www.petards.com This email has been sent from Petards Group plc or a member of the Petards group of companies. The information in this email is confidential and/or privileged. It is intended solely for the use of the addressee. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any review, dissemination, disclosure, alteration, printing, circulation or transmission of this e-mail and/or any file or attachment transmitted with it, is prohibited and may be unlawful.
Petards Group plc is registered in England & Wales. Company No. 2990100 Petards Limited is registered in England & Wales. Company No. 2301063 Petards Joyce-Loebl Limited is registered in England & Wales. Company No. 2170100
Registered Offices: 390 Princesway, Team Valley, Gateshead, Tyne & Wear NE11 0TU, UK.
___________________________________________________________________________________________
This email has been scanned by Petards. The service is powered by Symantec MessageLabs Email AntiVirus.cloud ___________________________________________________________________________________________
--
Lester Caine wrote:
a large number of us are using genealogical databases
Sure, but that's always been outside the scope of the tz project. As the Theory file notes: the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping. That being said, it might be helpful to have a new file, "attic" say, that records discarded Zone data that may be useful to genealogists. If a genealogy-oriented extension to the tz database ever becomes a reality, it could take over the attic. If there's interest in this, I'll propose a new change along these lines.
and need to know that we are working with the same numbers
If you have the same version of the tz database, you'll know that; conversely, if you have differing versions of the tz database, you cannot rely on that. This has always been true, and the proposed changes don't alter this property. Stephen Colebourne wrote:
Changing something because it is "neater" or general "tidying up" are bad goals
I too was reluctant to make the change. But the motivation is not "neatness" or "tidying up": it is to avoid future political brouhahas like the ones we've had recently, brouhahas that consume far too much of our time. Avoiding these disputes requires fairness (what you're calling "tidying up"), and fairness is not an easily-omittable triviality.
On Wed, Aug 28, 2013, at 11:25, Paul Eggert wrote:
But the motivation is not "neatness" or "tidying up": it is to avoid future political brouhahas like the ones we've had recently, brouhahas that consume far too much of our time.
I don't understand why it consumed any time at all. The change being requested was literally a one-word change to zone.tab that would have impacted nothing. My theory (and the basis for my perhaps overly strongly worded earlier post calling that original change a blunder) is that it was your pride, since you had made the change that it would have reversed in the first place, but even that is only guesswork.
Paul Eggert wrote:
a large number of us are using genealogical databases Sure, but that's always been outside the scope of the tz project. As the Theory file notes:
the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping.
That being said, it might be helpful to have a new file, "attic" say, that records discarded Zone data that may be useful to genealogists. If a genealogy-oriented extension to the tz database ever becomes a reality, it could take over the attic. If there's interest in this, I'll propose a new change along these lines.
I see two areas here ... pre 1970 we need a reliable archive which your 'attic' could provide, but post-1970 the database should produce the correct historic information, so making changes that do not correctly reflect prior history that is within the cover is the major objection? If we look at 1975 will we get the correct historic situation returned? I'm not seeing any timestamp details against these changes which is where the reliability of data is then lost. Having to look at an 'attic' to find post 1970 data just seems wrong? -- 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
On Aug 28, 2013, at 11:49 AM, random832@fastmail.us wrote:
On Wed, Aug 28, 2013, at 11:25, Paul Eggert wrote:
But the motivation is not "neatness" or "tidying up": it is to avoid future political brouhahas like the ones we've had recently, brouhahas that consume far too much of our time.
I don't understand why it consumed any time at all. The change being requested was literally a one-word change to zone.tab that would have impacted nothing. My theory (and the basis for my perhaps overly strongly worded earlier post calling that original change a blunder) is that it was your pride, since you had made the change that it would have reversed in the first place, but even that is only guesswork.
Another point is that none of the recent political nonsense is in any way related to old data -- quite the contrary, it is entirely about the current information. paul
On 08/28/13 09:04, Lester Caine wrote:
Having to look at an 'attic' to find post 1970 data just seems wrong?
It shouldn't be a problem, as the attic will be limited to zones that differ from non-attic zones only in pre-1970 timestamps. If you're interested only in post-1970 timestamps, you will be able to safely ignore the attic. If you're interested in pre-1970 timestamps, the attic will be only a small part of the data you'll need, but it's not our goal to fix that problem; it's just that we won't discard the attic data. If we find errors in the post-1970 data, these errors will necessarily be in the non-attic files, and we'll continue to correct them as before.
On Wed, Aug 28, 2013 at 08:25:35AM -0700, Paul Eggert <eggert@cs.ucla.edu> wrote:
Sure, but that's always been outside the scope of the tz project. As the Theory file notes:
the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping.
The interpretation I always gave this, and that was consistent with the "old style maintainance regime", is that pre-1970s data is not guaranteed to be correct, useful, or complete, but it is occasionally maintained at best effort base. This can be witnessed by the many pre-1970 changes to the data over the years. I think the part you quoted contradicts your recent actions - the fact that the data isn't provided everywhere implies that data is provided somewhere, and overall, this part of the Theory file gives no reason to actively remove pre-1970 data. The pre-1970 cut-off, IMHO, was always meant as the date from where the tz database really cares and really tries to get right, while earlier tz data might be completely wrong, and definitely much less certain. What makes the tz database so great is its stability. It should be quite obvious from the reactions on this list that people feel that stability is threatened, and I thank you for taking it into account by resurrecting the data. And, as always, thank you for your good work, even if it is occasionally criticised :) -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
On 26 Aug 2013, at 18:18, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
This appears to be a more common name in English for this newish political region; for example, see <http://en.wikipedia.org/wiki/Caribbean_Netherlands>. --- iso3166.tab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/iso3166.tab b/iso3166.tab index d9dcf6a..a1e4b42 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -53,7 +53,7 @@ BL St Barthelemy BM Bermuda BN Brunei BO Bolivia -BQ Bonaire, St Eustatius & Saba +BQ Caribbean Netherlands BR Brazil BS Bahamas BT Bhutan -- 1.8.1.2
I was lucky enough to be on a cruise around the Caribbean late last year. One of the places I called at was Bonaire, pronounced, roughly "bonn-ahree which means "flat island". We had a trip to the other side of the island, away from Kralendijk (sp?) and our guide told us a little of the history of the island including the fact that comparatively recently it had become independent from the Netherlands. That would seem to counter the proposed name on both counts :) jch
On 09/04/13 13:27, John Haxby wrote:
our guide told us a little of the history of the island including the fact that comparatively recently it had become independent from the Netherlands.
Wheee-eww! Your guide got it totally backwards. Bonaire is a special municipality of the Netherlands. That is, unlike (say) Aruba, it is part of the Netherlands, not one of the constituents of the Kingdom of the Netherlands. BQ is a collection of three such special municipalities, Bonaire being the most populous.
That would seem to counter the proposed name on both counts :)
As far as I can tell, "Bonaire" typically refers just to the island of Bonaire, not to the entire territory. I couldn't find an example of someone calling the entire territory "Bonaire" (much as people often call the United Kingdom "Great Britain"). So I don't think just "Bonaire" would work. The names I found in common use for the territory were "Caribbean Netherlands", "Bonaire, St. Eustatius, and Saba", and "the BES Islands". "Caribbean Netherlands" seemed the most common. It's not a big deal either way, of course.**
Paul Eggert wrote:
our guide told us a little of the history of the island
including the fact that comparatively recently it had become independent from the Netherlands. Wheee-eww! Your guide got it totally backwards. Bonaire is a special municipality of the Netherlands.
And there is already a standard to follow ;) https://www.iso.org/obp/ui/#iso:code:3166:BQ -- 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
On 4 Sep 2013, at 22:27, Paul Eggert <eggert@cs.ucla.edu> wrote:
our guide told us a little of the history of the island including the fact that comparatively recently it had become independent from the Netherlands.
Wheee-eww! Your guide got it totally backwards. Bonaire is a special municipality of the Netherlands. That is, unlike (say) Aruba, it is part of the Netherlands, not one of the constituents of the Kingdom of the Netherlands.
It's more likely that I was confusing it with Aruba :( Went there as well. Sorry about that. jch
participants (10)
-
David Patte ₯ -
Derick Rethans -
Goudge, Stephen -
John Haxby -
Lester Caine -
Marc Lehmann -
Paul Eggert -
Paul_Koning＠Dell.com -
random832＠fastmail.us -
Stephen Colebourne