Proposal to change Macquarie Island to be Australian territory
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/
Thanks, here's a proposed patch to implement the fix. Like the other patch I sent out just now, this patch is published in the unofficial github repository.
From a676f5ad3b40fa8dc76f05c452e126167444fba3 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Mon, 15 Apr 2013 00:00:01 -0700 Subject: [PATCH] Macquarie Island is politically part of Australia, not Antarctica.
This doesn't affect time stamps, just zone selection. Problem reported by Tobias Conradi in <http://mm.icann.org/pipermail/tz/2013-April/019023.html>. * antarctica (AusAQ, ATAQ): Remove; no longer needed. * australasia (Antarctica/Macquarie): Move here from the 'antarctica' file. Use Aus and AT rather than AusAQ and ATAQ. * zone.tab (Antarctica/Macquarie): Country code AU, not AQ. --- antarctica | 42 +----------------------------------------- australasia | 12 +++++++++++- zone.tab | 2 +- 3 files changed, 13 insertions(+), 43 deletions(-) diff --git a/antarctica b/antarctica index d55924b..9bf2494 100644 --- a/antarctica +++ b/antarctica @@ -53,34 +53,6 @@ Rule ChileAQ 2011 only - Aug Sun>=16 4:00u 1:00 S Rule ChileAQ 2012 max - Apr Sun>=23 3:00u 0 - 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 - - # Argentina - year-round bases # Belgrano II, Confin Coast, -770227-0343737, since 1972-02-05 # Esperanza, San Martin Land, -6323-05659, since 1952-12-17 @@ -122,10 +94,7 @@ Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 - # </a> # From Steffen Thorsen (2010-03-10): -# We got these changes from the Australian Antarctic Division: -# - Macquarie Island will stay on UTC+11 for winter and therefore not -# switch back from daylight savings time when other parts of Australia do -# on 4 April. +# We got these changes from the Australian Antarctic Division: ... # # - Casey station reverted to its normal time of UTC+8 on 5 March 2010. # The change to UTC+11 is being considered as a regular summer thing but @@ -136,9 +105,6 @@ Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 - # # - Mawson station stays on UTC+5. # -# In addition to the Rule changes for Casey/Davis, it means that Macquarie -# will no longer be like Hobart and will have to have its own Zone created. -# # Background: # <a href="http://www.timeanddate.com/news/time/antartica-time-changes-2010.html"> # http://www.timeanddate.com/news/time/antartica-time-changes-2010.html @@ -165,12 +131,6 @@ Zone Antarctica/Mawson 0 - zzz 1954 Feb 13 6:00 - MAWT 2009 Oct 18 2:00 # Mawson Time 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 - 11:00 - MIST # Macquarie Island Time # References: # <a href="http://www.antdiv.gov.au/aad/exop/sfo/casey/casey_aws.html"> # Casey Weather (1998-02-26) diff --git a/australasia b/australasia index 58df73d..4ba53e8 100644 --- a/australasia +++ b/australasia @@ -220,7 +220,17 @@ Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb # Macquarie # permanent occupation (scientific station) since 1948; # sealing and penguin oil station operated 1888/1917 -# like Australia/Hobart +# From Steffen Thorsen (2010-03-10): +# We got these changes from the Australian Antarctic Division: +# - Macquarie Island will stay on UTC+11 for winter and therefore not +# switch back from daylight savings time when other parts of Australia do +# on 4 April. +Zone Antarctica/Macquarie 0 - zzz 1911 + 10:00 - EST 1916 Oct 1 2:00 + 10:00 1:00 EST 1917 Feb + 10:00 Aus EST 1967 + 10:00 AT EST 2010 Apr 4 3:00 + 11:00 - MIST # Macquarie I Standard Time # Christmas # Zone NAME GMTOFF RULES FORMAT [UNTIL] diff --git a/zone.tab b/zone.tab index c1cd95e..9562da7 100644 --- a/zone.tab +++ b/zone.tab @@ -42,7 +42,7 @@ AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula AQ -7824+10654 Antarctica/Vostok Vostok Station, Lake Vostok AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Station, Terre Adelie AQ -690022+0393524 Antarctica/Syowa Syowa Station, E Ongul I -AQ -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island +AU -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) AR -3124-06411 America/Argentina/Cordoba most locations (CB, CC, CN, ER, FM, MN, SE, SF) AR -2447-06525 America/Argentina/Salta (SA, LP, NQ, RN) -- 1.7.10.4
The proposed change to zone.tab leaves the entry for Antarctica/Macquarie in place with the rest of the AQ entries. For consistency (and since we've seen reports in the past of finicky implementations), it should probably live with the rest of the AU entries instead. We may also want to leave the "like Australia/Hobart" comment in and just add "until 2010", so that the historical connection is kept clear. -- Tim Parenti On 15 April 2013 03:02, Paul Eggert <eggert@cs.ucla.edu> wrote:
Thanks, here's a proposed patch to implement the fix. Like the other patch I sent out just now, this patch is published in the unofficial github repository.
From a676f5ad3b40fa8dc76f05c452e126167444fba3 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Mon, 15 Apr 2013 00:00:01 -0700 Subject: [PATCH] Macquarie Island is politically part of Australia, not Antarctica.
This doesn't affect time stamps, just zone selection. Problem reported by Tobias Conradi in <http://mm.icann.org/pipermail/tz/2013-April/019023.html>. * antarctica (AusAQ, ATAQ): Remove; no longer needed. * australasia (Antarctica/Macquarie): Move here from the 'antarctica' file. Use Aus and AT rather than AusAQ and ATAQ. * zone.tab (Antarctica/Macquarie): Country code AU, not AQ. --- antarctica | 42 +----------------------------------------- australasia | 12 +++++++++++- zone.tab | 2 +- 3 files changed, 13 insertions(+), 43 deletions(-)
diff --git a/antarctica b/antarctica index d55924b..9bf2494 100644 --- a/antarctica +++ b/antarctica @@ -53,34 +53,6 @@ Rule ChileAQ 2011 only - Aug Sun>=16 4:00u 1:00 S Rule ChileAQ 2012 max - Apr Sun>=23 3:00u 0 - 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 - - # Argentina - year-round bases # Belgrano II, Confin Coast, -770227-0343737, since 1972-02-05 # Esperanza, San Martin Land, -6323-05659, since 1952-12-17 @@ -122,10 +94,7 @@ Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 - # </a>
# From Steffen Thorsen (2010-03-10): -# We got these changes from the Australian Antarctic Division: -# - Macquarie Island will stay on UTC+11 for winter and therefore not -# switch back from daylight savings time when other parts of Australia do -# on 4 April. +# We got these changes from the Australian Antarctic Division: ... # # - Casey station reverted to its normal time of UTC+8 on 5 March 2010. # The change to UTC+11 is being considered as a regular summer thing but @@ -136,9 +105,6 @@ Rule ATAQ 2008 max - Apr Sun>=1 2:00s 0 - # # - Mawson station stays on UTC+5. # -# In addition to the Rule changes for Casey/Davis, it means that Macquarie -# will no longer be like Hobart and will have to have its own Zone created. -# # Background: # <a href=" http://www.timeanddate.com/news/time/antartica-time-changes-2010.html"> # http://www.timeanddate.com/news/time/antartica-time-changes-2010.html @@ -165,12 +131,6 @@ Zone Antarctica/Mawson 0 - zzz 1954 Feb 13 6:00 - MAWT 2009 Oct 18 2:00 # Mawson Time 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 - 11:00 - MIST # Macquarie Island Time # References: # <a href="http://www.antdiv.gov.au/aad/exop/sfo/casey/casey_aws.html"> # Casey Weather (1998-02-26) diff --git a/australasia b/australasia index 58df73d..4ba53e8 100644 --- a/australasia +++ b/australasia @@ -220,7 +220,17 @@ Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb # Macquarie # permanent occupation (scientific station) since 1948; # sealing and penguin oil station operated 1888/1917 -# like Australia/Hobart +# From Steffen Thorsen (2010-03-10): +# We got these changes from the Australian Antarctic Division: +# - Macquarie Island will stay on UTC+11 for winter and therefore not +# switch back from daylight savings time when other parts of Australia do +# on 4 April. +Zone Antarctica/Macquarie 0 - zzz 1911 + 10:00 - EST 1916 Oct 1 2:00 + 10:00 1:00 EST 1917 Feb + 10:00 Aus EST 1967 + 10:00 AT EST 2010 Apr 4 3:00 + 11:00 - MIST # Macquarie I Standard Time
# Christmas # Zone NAME GMTOFF RULES FORMAT [UNTIL] diff --git a/zone.tab b/zone.tab index c1cd95e..9562da7 100644 --- a/zone.tab +++ b/zone.tab @@ -42,7 +42,7 @@ AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula AQ -7824+10654 Antarctica/Vostok Vostok Station, Lake Vostok AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Station, Terre Adelie AQ -690022+0393524 Antarctica/Syowa Syowa Station, E Ongul I -AQ -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island +AU -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) AR -3124-06411 America/Argentina/Cordoba most locations (CB, CC, CN, ER, FM, MN, SE, SF) AR -2447-06525 America/Argentina/Salta (SA, LP, NQ, RN) -- 1.7.10.4
On 04/15/2013 08:04 AM, Tim Parenti wrote:
The proposed change to zone.tab leaves the entry for Antarctica/Macquarie in place with the rest of the AQ entries. For consistency (and since we've seen reports in the past of finicky implementations), it should probably live with the rest of the AU entries instead.
We may also want to leave the "like Australia/Hobart" comment in and just add "until 2010", so that the historical connection is kept clear.
Thanks, here's a further proposed patch (also out on github) to try to deal with this. I'd like to generate a new release soon, hope this is the last substantive patch but will give it a day or so to percolate....
From 188b29d9664cfcf0384e515c69f94a2dfc27c673 Mon Sep 17 00:00:00 2001 From: Paul Eggert <eggert@cs.ucla.edu> Date: Wed, 17 Apr 2013 09:23:34 -0700 Subject: [PATCH] Fix times of habitation for Macquarie to agree with Tasmania history.
Also, sort Macquarie more-consistently with other parts of Australia. This doesn't affect time stamps, just zone selection. Problems reported by Tim Parenti in <http://mm.icann.org/pipermail/tz/2013-April/019060.html>. * australasia (Antarctica/Macquarie): Tasmania Parks & Wildlife Service history indicates that permanent habitation was 1899-1918 and 1948 on. * zone.tab (Antarctica/Macquarie): Move next to Lord Howe and Tasmania. --- australasia | 13 ++++++++++--- zone.tab | 2 +- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/australasia b/australasia index 4ba53e8..5fe6d53 100644 --- a/australasia +++ b/australasia @@ -218,16 +218,23 @@ Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb # no times are set # # Macquarie -# permanent occupation (scientific station) since 1948; -# sealing and penguin oil station operated 1888/1917 +# Permanent occupation (scientific station) 1911-1915 and since 25 March 1948; +# sealing and penguin oil station operated Nov 1899 to Apr 1919. See the +# Tasmania Parks & Wildlife Service history of sealing at Macquarie Island +# <http://www.parks.tas.gov.au/index.aspx?base=1828> +# <http://www.parks.tas.gov.au/index.aspx?base=1831>. +# Guess that it was like Australia/Hobart while inhabited before 2010. +# # From Steffen Thorsen (2010-03-10): # We got these changes from the Australian Antarctic Division: # - Macquarie Island will stay on UTC+11 for winter and therefore not # switch back from daylight savings time when other parts of Australia do # on 4 April. -Zone Antarctica/Macquarie 0 - zzz 1911 +Zone Antarctica/Macquarie 0 - zzz 1899 Nov 10:00 - EST 1916 Oct 1 2:00 10:00 1:00 EST 1917 Feb + 10:00 Aus EST 1919 Apr + 0 - zzz 1948 Mar 25 10:00 Aus EST 1967 10:00 AT EST 2010 Apr 4 3:00 11:00 - MIST # Macquarie I Standard Time diff --git a/zone.tab b/zone.tab index 9562da7..6b98520 100644 --- a/zone.tab +++ b/zone.tab @@ -42,7 +42,6 @@ AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula AQ -7824+10654 Antarctica/Vostok Vostok Station, Lake Vostok AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Station, Terre Adelie AQ -690022+0393524 Antarctica/Syowa Syowa Station, E Ongul I -AU -5430+15857 Antarctica/Macquarie Macquarie Island Station, Macquarie Island AR -3436-05827 America/Argentina/Buenos_Aires Buenos Aires (BA, CF) AR -3124-06411 America/Argentina/Cordoba most locations (CB, CC, CN, ER, FM, MN, SE, SF) AR -2447-06525 America/Argentina/Salta (SA, LP, NQ, RN) @@ -58,6 +57,7 @@ AR -5448-06818 America/Argentina/Ushuaia Tierra del Fuego (TF) AS -1416-17042 Pacific/Pago_Pago AT +4813+01620 Europe/Vienna AU -3133+15905 Australia/Lord_Howe Lord Howe Island +AU -5430+15857 Antarctica/Macquarie Macquarie Island AU -4253+14719 Australia/Hobart Tasmania - most locations AU -3956+14352 Australia/Currie Tasmania - King Island AU -3749+14458 Australia/Melbourne Victoria -- 1.7.11.7
On 17/04/2013 17:26, Paul Eggert wrote:
On 04/15/2013 08:04 AM, Tim Parenti wrote:
The proposed change to zone.tab leaves the entry for Antarctica/Macquarie in place with the rest of the AQ entries. For consistency (and since we've seen reports in the past of finicky implementations), it should probably live with the rest of the AU entries instead.
We may also want to leave the "like Australia/Hobart" comment in and just add "until 2010", so that the historical connection is kept clear.
Thanks, here's a further proposed patch (also out on github) to try to deal with this. I'd like to generate a new release soon, hope this is the last substantive patch but will give it a day or so to percolate....
Just wondering... will it eventually end up as Australia/Macquarie with a backwards link to Antarctica/Macquarie? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 04/17/13 13:40, Ian Abbott wrote:
will it eventually end up as Australia/Macquarie
As I understand it the Australian government says Macquarie is in the Southern Ocean, where "Antarctica/" might be more appropriate, whereas the International Hydrographic Organization says Macquarie is in the Pacific, where "Pacific/Macquarie" might be more appropriate, and I suppose "Australia/Macquarie" might also be considered appropriate since Macquarie is on the boundary between the Indo-Australian and the Pacific plates. It is one of those odd boundary cases. I don't think it matters that much. All other things being equal it's better to have just one name, and perhaps we should just stick with the one we've got.
By that logic, it seems New Zealand should be in Antarctica. LOL No one suggested Macquarie Island should be listed in the Indian ocean, since it is east of Australia, not west; and it seems out of place with the other Antarctica listings are on the Antarctica continental shelf. Macquarie Island is not. It is just south of NZ. On 2013-04-17 17:39, Paul Eggert wrote:
On 04/17/13 13:40, Ian Abbott wrote:
will it eventually end up as Australia/Macquarie As I understand it the Australian government says Macquarie is in the Southern Ocean, where "Antarctica/" might be more appropriate, whereas the International Hydrographic Organization says Macquarie is in the Pacific, where "Pacific/Macquarie" might be more appropriate, and I suppose "Australia/Macquarie" might also be considered appropriate since Macquarie is on the boundary between the Indo-Australian and the Pacific plates. It is one of those odd boundary cases. I don't think it matters that much. All other things being equal it's better to have just one name, and perhaps we should just stick with the one we've got.
--
I'm not sure if this is what the issue is but politically, Macquarie Island is part of Tasmania and as such, I would have thought it should be included under Australia. Kind Regards, David Grosz Sydney, Australia There are only 10 types of people in the world. Those who understand binary and those who don't. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of David Patte ? Sent: 18 April 2013 08:10 To: tz@iana.org Subject: Re: [tz] Proposal to change Macquarie Island to be Australian territory By that logic, it seems New Zealand should be in Antarctica. LOL No one suggested Macquarie Island should be listed in the Indian ocean, since it is east of Australia, not west; and it seems out of place with the other Antarctica listings are on the Antarctica continental shelf. Macquarie Island is not. It is just south of NZ. On 2013-04-17 17:39, Paul Eggert wrote:
On 04/17/13 13:40, Ian Abbott wrote:
will it eventually end up as Australia/Macquarie As I understand it the Australian government says Macquarie is in the Southern Ocean, where "Antarctica/" might be more appropriate, whereas the International Hydrographic Organization says Macquarie is in the Pacific, where "Pacific/Macquarie" might be more appropriate, and I suppose "Australia/Macquarie" might also be considered appropriate since Macquarie is on the boundary between the Indo-Australian and the Pacific plates. It is one of those odd boundary cases. I don't think it matters that much. All other things being equal it's better to have just one name, and perhaps we should just stick with the one we've got.
--
"David Grosz" <david@DLG.com.au> writes:
I'm not sure if this is what the issue is but politically, Macquarie Island is part of Tasmania and as such, I would have thought it should be included under Australia.
Organization into the top-level structure is by continent or oceanic region, not by political entity. Otherwise, it would be America/Honolulu, not Pacific/Honolulu. That's why Paul's reply pointed out the ambiguity of geographic classification, rather than focusing on the political classification. Classifying by political entity is a fast way to get us into trouble in more politically contentious places. Consider Atlantic/Stanley, for example. Australia is somewhat confusing in that context since it's both a political entity and a continent. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Regarding in which region an island lies, a good approach is probably to refer to the IHO (International Hydrographic Organisation) publication S-23 on the limits of oceans and seas. Unfortunately the current (1952) edition removed the Antarctic or Southern Ocean as a separate region as it was deemed to be an arbitrary delineation with no clear northern geographical boundary. However work was done on a 4th Edition in 2000 which reinstated the Southern Ocean and set the limits as 60 degrees South. This edition would have been published and in force now, apart from a reservation from Argentina. So I would propose that any TZ data south of 60S, which means that Macquarie Island does not fall in to Antarctica. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Russ Allbery Sent: 18 April 2013 01:18 To: tz@iana.org Subject: Re: [tz] Proposal to change Macquarie Island to be Australian territory "David Grosz" <david@DLG.com.au> writes:
I'm not sure if this is what the issue is but politically, Macquarie Island is part of Tasmania and as such, I would have thought it should be included under Australia.
Organization into the top-level structure is by continent or oceanic region, not by political entity. Otherwise, it would be America/Honolulu, not Pacific/Honolulu. That's why Paul's reply pointed out the ambiguity of geographic classification, rather than focusing on the political classification. Classifying by political entity is a fast way to get us into trouble in more politically contentious places. Consider Atlantic/Stanley, for example. Australia is somewhat confusing in that context since it's both a political entity and a continent. -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
Tim Thornton said:
Regarding in which region an island lies, a good approach is probably to refer to the IHO (International Hydrographic Organisation) publication S-23 on the limits of oceans and seas. [...] So I would propose that any TZ data south of 60S, which means that Macquarie Island does not fall in to Antarctica.
If this was a new zone, I think I'd agree with you. But given that it's an existing zone, what is the benefit of moving the zone rather than leaving it alone? I'd want to see a compelling reason for the move, not just a "we've decided to use a new definition of 'Antarctica'". -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
As far as I know, in tz there is no definition of the extents of Antarctica, and tz locations have just been put into whichever region seems best at the time. If I'm right on this, there is no zone to move as it isn't defined. All I'm suggesting is that where there is debate on which zone a location should be in, or if a new location is required, this is probably as good an approach as any to resolve the issue. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: Clive D.W. Feather [mailto:clive@davros.org] Sent: 18 April 2013 11:35 To: Tim Thornton Cc: rra@stanford.edu; tz@iana.org Subject: Re: [tz] Proposal to change Macquarie Island to be Australian territory Tim Thornton said:
Regarding in which region an island lies, a good approach is probably to refer to the IHO (International Hydrographic Organisation) publication S-23 on the limits of oceans and seas. [...] So I would propose that any TZ data south of 60S, which means that Macquarie Island does not fall in to Antarctica.
If this was a new zone, I think I'd agree with you. But given that it's an existing zone, what is the benefit of moving the zone rather than leaving it alone? I'd want to see a compelling reason for the move, not just a "we've decided to use a new definition of 'Antarctica'". -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
1) It is not in the territory covered by the Antarctic Treaty 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" And it is the only zone center that is not south of 60° South Latitude but is in Antarctica/...... 2) IANA time zone database has some islands in oceans, some in continents Atlantic Ocean: Canary, Iceland Indian Ocean: Madagascar Pacific Ocean: New Zealand, Hawaii Asia: Taiwan, Cyprus, ASEAN island countries, Sri Lanka Australia (continent): Tasmania Europe: Guernsey, Jersey, Isle of Man, Ireland, Great Britain Conclusion: 1) Moving Macquarie out of Antarctica/... fixes a bug. 2) Choosing the surrounding ocean (Pacific) or the nearest continent that is not Treaty-Antarctica (Australia) could be equally good. If distance is the deciding factor and since its distance to the Australian continent is similar to that of Auckland, and Madagascar with less than half the distance from its closest continent (Africa) is put in the surrounding ocean, the choice would be Pacific. Mallacoota - Macquarie 2010 km http://www.wolframalpha.com/input/?i=distance+between+54.5S158.95E+and+37.55... Sydney - Auckland - 2160 km http://www.wolframalpha.com/input/?i=distance+between+Auckland+Sydney -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On 04/18/2013 01:06 AM, Tim Thornton wrote:
This edition would have been published and in force now, apart from a reservation from Argentina.
I've read that Australia objected too. The Australian Hydrographic Office, for what it's worth, says that Macquarie is in the Southern Ocean. See: Darby A. Canberra all at sea over position of Southern Ocean. The Age 2003-12-22. http://www.theage.com.au/articles/2003/12/21/1071941610556.html If I had to do it over again I might put it in the Pacific, but given that it's in a geographically ambiguous area I'm inclined to leave it alone. There is an advantage to not messing with the identifiers.
On Apr 18, 2013, at 6:52 , Paul Eggert wrote:
If I had to do it over again I might put it in the Pacific, but given that it's in a geographically ambiguous area I'm inclined to leave it alone. There is an advantage to not messing with the identifiers.
To put that more strongly: There are big disadvantages to messing with the identifiers. They are used in numerous protocols and APIs these days, and whenever an identifier is changed, it takes a long time (years in some cases) for software to get updated to understand the new identifier, and the updated software to be distributed. In the meantime, software and users encounter various failures as the new identifier is not understood by older software components still in use. Norbert
On Apr 18, 2013, at 10:02 AM, Norbert Lindenberg <ietf@lindenbergsoftware.com> wrote:
To put that more strongly: There are big disadvantages to messing with the identifiers. They are used in numerous protocols and APIs these days, and whenever an identifier is changed, it takes a long time (years in some cases) for software to get updated to understand the new identifier,
Presumably by "understand" you mean "have a file with the appropriate pathname"; I don't think software should "understand" the identifiers except by using them to construct pathnames of Olson-database files to load - it shouldn't "know" the pathname syntax or "know" what particular values of particular components of the pathname "mean".
On Thu, Apr 18, 2013, at 13:58, Guy Harris wrote:
Presumably by "understand" you mean "have a file with the appropriate pathname"; I don't think software should "understand" the identifiers except by using them to construct pathnames of Olson-database files to load - it shouldn't "know" the pathname syntax or "know" what particular values of particular components of the pathname "mean".
The timezone identifier is used as a key in other databases, such as CLDR (whose maintainers have, IIRC, declined to recognize any changes made to the identifiers used for existing timezones)
On Apr 18, 2013, at 11:01 AM, random832@fastmail.us wrote:
On Thu, Apr 18, 2013, at 13:58, Guy Harris wrote:
Presumably by "understand" you mean "have a file with the appropriate pathname"; I don't think software should "understand" the identifiers except by using them to construct pathnames of Olson-database files to load - it shouldn't "know" the pathname syntax or "know" what particular values of particular components of the pathname "mean".
The timezone identifier is used as a key in other databases, such as CLDR (whose maintainers have, IIRC, declined to recognize any changes made to the identifiers used for existing timezones)
Perhaps both databases should be using the same LOCODE-derived identifiers as the "official" identifiers, with all the region/city names used as legacy backwards-compatibility names? Using those as the "official" identifiers has the advantages that: 1) they look like line noise to humans, so UIs for setting the zone will perhaps make an effort to do something better than offer you a choice of zone identifiers or zone identifiers with underscores replaced by spaces; 2) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong City was used; 3) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong Region was used; 4) advantages 2 and 3 mean they won't have to change over time; 5) advantage 4 might mean that the CLDR folks won't have to worry about identifier changes.
On Thu, Apr 18, 2013 at 8:11 PM, Guy Harris <guy@alum.mit.edu> wrote:
Perhaps both databases should be using the same LOCODE-derived identifiers as the "official" identifiers, with all the region/city names used as legacy backwards-compatibility names? Using those as the "official" identifiers has the advantages that:
1) they look like line noise to humans,
UN LOCODEs are structured and not noise to all humans. For US people: USNYC, USPDX, what may these refer to? Germans: DEBER ...? Italians ITROM ?
so UIs for setting the zone will perhaps make an effort to do something better than offer you a choice of zone identifiers or zone identifiers with underscores replaced by spaces;
Programmers that feel like doing so can do so already.
2) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong City was used;
An often mentioned case is Asia/Shanghai where people request Asia/Beijing - with UN LOCODEs that would be CNSHA vs. CNBJS
3) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong Region was used;
The first two letters of UN LOCODEs are the ISO 3166-1 alpha-2 codes, likely not noise to all humans.
4) advantages 2 and 3 mean they won't have to change over time;
ISO codes can change, the current region names are not affected by changes in country names and mergers or splits of countries. But CLDR ads a layer of problems on top if UN LOCODEs Some feedback regarding CLDR zone identifiers has been provided at: http://mm.icann.org/pipermail/tz/2012-May/017974.html Variable length and inconsistent country code usage: USNAVAJO (larger region, not a simple locality) MXSTIS JERUSALEM (This is not in JE JERSEY!) GAZA (This is not in GA GABON) - certainly not "line noise" It would have been easy to have at least fixed length identifiers, based on the UN LOCODEs: http://mm.icann.org/pipermail/tz/2012-May/017980.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 maybe CLDR had limited understanding of UN LOCODEs and that is why they choose to not use five digits for places that they couldn't find a LOCODE for. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Apr 18, 2013, at 12:43 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Thu, Apr 18, 2013 at 8:11 PM, Guy Harris <guy@alum.mit.edu> wrote:
Perhaps both databases should be using the same LOCODE-derived identifiers as the "official" identifiers, with all the region/city names used as legacy backwards-compatibility names? Using those as the "official" identifiers has the advantages that:
1) they look like line noise to humans,
UN LOCODEs are structured and not noise to all humans.
OK, "look like line noise to most humans". The point is that they're a lot more cryptic, which I consider a feature, not a bug, for the reasons listed.
For US people: USNYC, USPDX, what may these refer to?
USNYC might be obvious; USPDX, perhaps not so much if you're not familiar with "PDX" for Portland, Oregon (and if USPDX *isn't* Portland, that might surprise a *number* of USans).
so UIs for setting the zone will perhaps make an effort to do something better than offer you a choice of zone identifiers or zone identifiers with underscores replaced by spaces;
Programmers that feel like doing so can do so already.
Yes, they *can*, but I don't know who other than Apple *have* done so already. Making the identifiers more cryptic might light a bit of a fire under more developers.
2) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong City was used;
An often mentioned case is Asia/Shanghai where people request Asia/Beijing - with UN LOCODEs that would be CNSHA vs. CNBJS
That's one of the cases I was thinking of (the other is Kolkata vs. Mumbai vs. Delhi).
3) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong Region was used;
The first two letters of UN LOCODEs are the ISO 3166-1 alpha-2 codes, likely not noise to all humans.
"CH"? That's China, right? :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) (Yes, I know why "CH" was chosen for Switzerland. It's still probably not intuitively obvious to many that "CH" is Switzerland and "CN" is China.)
Tobias Conradi said:
3) they look like line noise to humans, so perhaps people won't get quite as bent out of shape because The Wrong Region was used;
The first two letters of UN LOCODEs are the ISO 3166-1 alpha-2 codes, likely not noise to all humans.
The use of "GB" for the United Kingdom of Great Britain and Northern Ireland is a politically contentious matter. In the recent past taking the wrong side on that issue could get you killed or seriously injured. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
Variable length and inconsistent country code usage:
This is a misunderstanding. 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. When the codes are not 5 letters, the first two letters have no meaning. 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. Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Thu, Apr 18, 2013 at 9:43 PM, Tobias Conradi <mail.2012@tobiasconradi.com
wrote:
On Thu, Apr 18, 2013 at 8:11 PM, Guy Harris <guy@alum.mit.edu> wrote:
Perhaps both databases should be using the same LOCODE-derived identifiers as the "official" identifiers, with all the region/city names used as legacy backwards-compatibility names? Using those as the "official" identifiers has the advantages that:
1) they look like line noise to humans,
UN LOCODEs are structured and not noise to all humans. For US people: USNYC, USPDX, what may these refer to? Germans: DEBER ...? Italians ITROM ?
so UIs for setting the zone will perhaps make an effort to do something better than offer you a choice of zone identifiers or zone identifiers with underscores replaced by spaces;
Programmers that feel like doing so can do so already.
2) they look like line noise to humans, so perhaps people won't
get quite as bent out of shape because The Wrong City was used;
An often mentioned case is Asia/Shanghai where people request Asia/Beijing - with UN LOCODEs that would be CNSHA vs. CNBJS
3) they look like line noise to humans, so perhaps people won't
get quite as bent out of shape because The Wrong Region was used;
The first two letters of UN LOCODEs are the ISO 3166-1 alpha-2 codes, likely not noise to all humans.
4) advantages 2 and 3 mean they won't have to change over time;
ISO codes can change, the current region names are not affected by changes in country names and mergers or splits of countries.
But CLDR ads a layer of problems on top if UN LOCODEs
Some feedback regarding CLDR zone identifiers has been provided at: http://mm.icann.org/pipermail/tz/2012-May/017974.html
Variable length and inconsistent country code usage: USNAVAJO (larger region, not a simple locality) MXSTIS JERUSALEM (This is not in JE JERSEY!) GAZA (This is not in GA GABON) - certainly not "line noise"
It would have been easy to have at least fixed length identifiers, based on the UN LOCODEs: http://mm.icann.org/pipermail/tz/2012-May/017980.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 maybe CLDR had limited understanding of UN LOCODEs and that is why they choose to not use five digits for places that they couldn't find a LOCODE for.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany
On Fri, Apr 19, 2013 at 11:17 AM, Mark Davis ☕ <mark@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.
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)
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.
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." -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Mark <https://plus.google.com/114199149796022210033> * * *— Il meglio è l’inimico del bene —* ** On Fri, Apr 19, 2013 at 12:35 PM, Tobias Conradi < mail.2012@tobiasconradi.com> wrote:
On Fri, Apr 19, 2013 at 11:17 AM, Mark Davis ☕ <mark@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.
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? If so, can you point us to the URL for that?
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.
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.
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.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany
Mark Davis ␦ <mark@macchiato.com> wrote: |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 You know that Hawaii was „somewhat stolen“ by the americans (their force), and that many natives (some still exist) would love to make that undone (a few such movements are left i think); not at last because so much of the holy nature is destroyed for more concrete (nice english word for German „Beton“, still gray in the end) tourist castles. Thus -- i think they'd „join“ some Polynesia, but otherwise re-queen their own Queen, eventually. Hawaii never was Easter Island in the end… --steffen
On Thu, Apr 18, 2013 at 8:01 PM, <random832@fastmail.us> wrote:
CLDR (whose maintainers have, IIRC, declined to recognize any changes made to the identifiers used for existing timezones)
Multiple IANA time zone identifiers for some zones can be found at: http://unicode.org/repos/cldr/trunk/common/bcp47/timezone.xml -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Apr 18, 2013, at 10:58 , Guy Harris wrote:
On Apr 18, 2013, at 10:02 AM, Norbert Lindenberg <ietf@lindenbergsoftware.com> wrote:
To put that more strongly: There are big disadvantages to messing with the identifiers. They are used in numerous protocols and APIs these days, and whenever an identifier is changed, it takes a long time (years in some cases) for software to get updated to understand the new identifier,
Presumably by "understand" you mean "have a file with the appropriate pathname"; I don't think software should "understand" the identifiers except by using them to construct pathnames of Olson-database files to load - it shouldn't "know" the pathname syntax or "know" what particular values of particular components of the pathname "mean".
No, there are several other ways software may have to "understand" TZ identifiers: - Libraries such as ICU, the Java runtime, or tz.js repackage the entire tz database, so they need to be updated to map the new time zone name to appropriate data. - BCP 47 with the Unicode extension (RFC 6067) allows applications to specify time zones as part of BCP 47 language tags, but because of limitations in BCP 47 have to use a different set of names. This requires both client software and the libraries implementing time zone support to have mapping tables between TZ identifiers and the shorter names used in language tags. These mapping tables have to be updated. - Standards such as the ECMAScript Internationalization API Specification require validation of time zone identifiers to prevent non-standard identifiers that implementations may support internally to be exposed in the standard interface. The validation in implementations of such standards needs to be updated. - Locale data collections such as CLDR provide localized names for TZ identifiers. They need to be updated to either map the new name to existing localized names or possibly add new localized names to match an intended change in meaning. And then you have the distribution problem: Locale data gets bundled into libraries, which get bundled into applications, which get bundled into operating system distributions, which get bundled with hardware. Sometimes there are good mechanism to update all this stuff during the lifetime of the complete system, but sometimes there's not. Many cell phones never receive OS updates. Norbert
On 2013-04-18 18:02, Norbert Lindenberg wrote:
On Apr 18, 2013, at 6:52 , Paul Eggert wrote:
If I had to do it over again I might put it in the Pacific, but given that it's in a geographically ambiguous area I'm inclined to leave it alone. There is an advantage to not messing with the identifiers.
To put that more strongly: There are big disadvantages to messing with the identifiers. They are used in numerous protocols and APIs these days, and whenever an identifier is changed, it takes a long time (years in some cases) for software to get updated to understand the new identifier, and the updated software to be distributed. In the meantime, software and users encounter various failures as the new identifier is not understood by older software components still in use.
That's what the backward file is for, so the old identifiers still work. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On 2013-04-17 22:39, Paul Eggert wrote:
On 04/17/13 13:40, Ian Abbott wrote:
will it eventually end up as Australia/Macquarie
As I understand it the Australian government says Macquarie is in the Southern Ocean, where "Antarctica/" might be more appropriate, whereas the International Hydrographic Organization says Macquarie is in the Pacific, where "Pacific/Macquarie" might be more appropriate, and I suppose "Australia/Macquarie" might also be considered appropriate since Macquarie is on the boundary between the Indo-Australian and the Pacific plates. It is one of those odd boundary cases. I don't think it matters that much. All other things being equal it's better to have just one name, and perhaps we should just stick with the one we've got.
As long as the email list doesn't get repeatedly swamped with threads from angry Macquarie Islanders. :) -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
participants (15)
-
Clive D.W. Feather -
David Grosz -
David Patte ₯ -
Guy Harris -
Ian Abbott -
Mark Davis ☕ -
Norbert Lindenberg -
Paul Eggert -
random832＠fastmail.us -
Russ Allbery -
Steffen Daode Nurpmeso -
Tim Parenti -
Tim Thornton -
Tobias Conradi -
Tobias Conradi