zone.tab corrections
There seem to be a few minor errors in zone.tab (2007f and earlier): America/Cambridge_Bay: zone.tab latitude/longitude is incorrect, according to http://www.meds-sdmm.dfo-mpo.gc.ca/meds/Prog_Nat/benchmark/single_station2_e..., which gives +6907-10504, and my own experiments with Google Earth. Also zone.tab comments should be 'Mountain Time - west Nunavut' rather than 'Central Time - west Nunavut' Antarctica/DumontDUrville: The comment should very probably read 'Dumont d'Urville Station', rather than 'Dumont d'Urville Base', which seems to be a mis-translation of the French 'Base Dumont d'Urville'. See for example http://pdf.comnap.aq/comnap/comnap.nsf/P/StationsByName/FRdumo Pacific/Johnston: latitude/longitude is incorrect. The CIA seems to have it much closer with +1645-16931 (https://www.cia.gov/library/publications/the-world-factbook/geos/um.html) America/Aruba: latitude/longitude is incorrect. The CIA seems to have it much closer with +1230-06958 (https://www.cia.gov/library/publications/the-world-factbook/geos/aa.html) - looks like the current +1230-06858 is a typo. Europe/London: (!) latitude/longitude is incorrect - the current value is somewhere in the neighbourhood of Syon House in South-west London (http://en.wikipedia.org/wiki/Syon_House). Suggestions for a better value welcome. Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names. Similarly, the comment for Europe/Zaporozhye should perhaps be 'Zaporizhia, E Luhansk', rather than 'Zaporozh'ye, E Lugansk'. See for example http://www.uazone.net/Kiev_Kyiv.html and http://abcnews.go.com/Travel/wireStory?id=2588280. I'm sure I could rustle up references for the other names if pressed. Andy http://www.stemhaus.com/firefox/foxclocks/
Andy McDonald said:
Europe/London: (!) latitude/longitude is incorrect - the current value is somewhere in the neighbourhood of Syon House in South-west London (http://en.wikipedia.org/wiki/Syon_House). Suggestions for a better value welcome.
The official centre of London - where distances are measured from - is variously either Charing Cross (51d30'30"N 0d07'31"W) or the Post Office (51d30'57"N 0d05'52"W). -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | |
Clive D.W. Feather wrote:
Andy McDonald said:
Europe/London: (!) latitude/longitude is incorrect - the current value is somewhere in the neighbourhood of Syon House in South-west London (http://en.wikipedia.org/wiki/Syon_House). Suggestions for a better value welcome.
The official centre of London - where distances are measured from - is variously either Charing Cross (51d30'30"N 0d07'31"W) or the Post Office (51d30'57"N 0d05'52"W).
It looks as though the zone.tab coordinates came from the mail I sent back in July 1994 about a piece in the Independent newspaper (which is in the europe file commentary). They aren't for Sion House, they are for the stone obelisk marking a pre-Greenwich meridian just across the Thames to the south. If you follow the "Aerial photo and map" link on the Wikipedia page and move the OS map overlay to the bottom centre of the photo you will see the obelisk marked. Clive is right: either Charing Cross or the GPO are the proper locations to use for London. I would vote for Charing Cross, but that's just personal preference. Peter Ilieve peter@aldie.co.uk
On Thu, 24 May 2007, Peter Ilieve wrote:
Clive is right: either Charing Cross or the GPO are the proper locations to use for London. I would vote for Charing Cross, but that's just personal preference.
Note that you want the original location of Charing Cross. It was rebuilt in the 19th C. in a new location. The closest landmark now is the statue of Charles I at 51d30'26"N, 0d7'40"W (or 51.5073,-0.1277 in decimal). Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ SOUTH BISCAY: VARIABLE 3 OR 4. SLIGHT OR MODERATE. FOG PATCHES, THEN SHOWERS. POOR OR VERY POOR, BECOMING MAINLY GOOD.
Tony Finch said:
Clive is right: either Charing Cross or the GPO are the proper locations to use for London. I would vote for Charing Cross, but that's just personal preference.
Note that you want the original location of Charing Cross. It was rebuilt in the 19th C. in a new location. The closest landmark now is the statue of Charles I at 51d30'26"N, 0d7'40"W (or 51.5073,-0.1277 in decimal).
Note that the GPO is where road distances used to be measured from, while Charing Cross (the present, not the original) is what most locals would say if you asked them. While I agree the cross itself has moved, I'm not sure the old location was ever thought of as "the centre of London". -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | |
On Fri, 25 May 2007, Clive D.W. Feather wrote:
Note that the GPO is where road distances used to be measured from, while Charing Cross (the present, not the original) is what most locals would say if you asked them. While I agree the cross itself has moved, I'm not sure the old location was ever thought of as "the centre of London".
http://www.bbc.co.uk/london/content/articles/2005/08/15/charingcross_feature... Tony. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ VIKING: WEST OR SOUTHWEST 4 OR 5, OCCASIONALLY 6. MODERATE OR ROUGH. SHOWERS. GOOD.
I agree with Andy: the zone.tab description for Cambridge Bay is wrong. It should read "Mountain Time" instead of "Central Time". As for the Cambridge Bay coordinates... The existing coordinates are indeed sitting in the water. The coordinates provided by Andy are from a monitoring station which is about 5km from Cambridge Bay. Official coordinates for Cambridge Bay from http://gnss.nrcan.gc.ca/gnss-srt are: 69.1138999,-105.0528000 I verified that this point "is" inside Cambridge Bay, it is a central spot right on the water front. -chris -----Original Message----- From: Andy McDonald [mailto:andy_tz@stemhaus.com] Sent: May 24, 2007 12:33 AM To: tz@lecserver.nci.nih.gov Subject: zone.tab corrections There seem to be a few minor errors in zone.tab (2007f and earlier): America/Cambridge_Bay: zone.tab latitude/longitude is incorrect, according to http://www.meds-sdmm.dfo-mpo.gc.ca/meds/Prog_Nat/benchmark/single_station2_e..., which gives +6907-10504, and my own experiments with Google Earth. Also zone.tab comments should be 'Mountain Time - west Nunavut' rather than 'Central Time - west Nunavut' Antarctica/DumontDUrville: The comment should very probably read 'Dumont d'Urville Station', rather than 'Dumont d'Urville Base', which seems to be a mis-translation of the French 'Base Dumont d'Urville'. See for example http://pdf.comnap.aq/comnap/comnap.nsf/P/StationsByName/FRdumo Pacific/Johnston: latitude/longitude is incorrect. The CIA seems to have it much closer with +1645-16931 (https://www.cia.gov/library/publications/the-world-factbook/geos/um.html) America/Aruba: latitude/longitude is incorrect. The CIA seems to have it much closer with +1230-06958 (https://www.cia.gov/library/publications/the-world-factbook/geos/aa.html) - looks like the current +1230-06858 is a typo. Europe/London: (!) latitude/longitude is incorrect - the current value is somewhere in the neighbourhood of Syon House in South-west London (http://en.wikipedia.org/wiki/Syon_House). Suggestions for a better value welcome. Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names. Similarly, the comment for Europe/Zaporozhye should perhaps be 'Zaporizhia, E Luhansk', rather than 'Zaporozh'ye, E Lugansk'. See for example http://www.uazone.net/Kiev_Kyiv.html and http://abcnews.go.com/Travel/wireStory?id=2588280. I'm sure I could rustle up references for the other names if pressed. Andy http://www.stemhaus.com/firefox/foxclocks/
From: Andy McDonald Date: Thu, 24 May 2007 00:33:13 -0400 Subject: zone.tab corrections
Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names. Similarly, the comment for Europe/Zaporozhye should perhaps be 'Zaporizhia, E Luhansk', rather than 'Zaporozh'ye, E Lugansk'.
Yeah, but where does it end? In the former USSR a lot of local languages are spoken, only one of which is Ukrainian. To be consistent, one has to find out what other local languages are spoken in the other Russian timezones. And invent a transliteration scheme for those languages that don't have one yet. Better idea: the current practice, namely using the Russian names. In most former Russian republics people have learned the Russian language and still understand it. Hence: a transliteration from Russian names seems to be more practical. My proposition: don't change no nothing.....
From: Andy McDonald Date: Thu, 24 May 2007 00:33:13 -0400 Subject: zone.tab corrections
Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names. Similarly, the comment for Europe/Zaporozhye should perhaps be 'Zaporizhia, E Luhansk', rather than 'Zaporozh'ye, E Lugansk'.
Yeah, but where does it end? In the former USSR a lot of local languages are spoken, only one of which is Ukrainian. To be consistent, one has to find out what other local languages are spoken in the other Russian timezones. And invent a transliteration scheme for those languages that don't have one yet. Better idea: the current practice, namely using the Russian names. In most former Russian republics people have learned the Russian language and still understand it. Hence: a transliteration from Russian names seems to be more practical. My proposition: don't change no nothing.....
I have no strong personal feelings about this issue. However, looking at the 2007f 'backward' file, precedents include Link Asia/Ashgabat Asia/Ashkhabad Link Asia/Ulaanbaatar Asia/Ulan_Bator In both cases the zone name change was due to a change in transliteration from Russian to the national language. 'Russian timezones' are time zones under the administration of Russia (Asia/Yekaterinburg, Europe/Moscow, etc), not the former USSR. These zones are named based on transliteration from Russian, or on the standard English name for the city, as one would expect. Other nations of the former USSR tend to be ethnically and linguistically distinct from Russia (though Russian is often one of the two official languages); where there is only one official (non-Russian) language one would expect the name of the time zone to reflect this. It's not hard to find out what other local languages are spoken: Ukraine's official language is Ukrainian, Moldova's is Moldovan, etc. In the case that Russian is one of the official languages, I would agree that no change is required. However this is distinct from the status of Russian as being widely understood; certainly many people in the former USSR understand Russian, but I would imagine that the average Ukrainian, Moldovan, Tajik or Georgian would take issue with a transliteration from Russian.
From: Andy McDonald Date: Sat, 26 May 2007 14:16:59 -0400 Subject: Re: zone.tab corrections
In the case that Russian is one of the official languages, I would agree that no change is required. However this is distinct from the status of Russian as being widely understood; certainly many people in the former USSR understand Russian, but I would imagine that the average Ukrainian, Moldovan, Tajik or Georgian would take issue with a transliteration from Russian.
Note that I am a bit lazy (I did most of the Russian names for TZ). Lists with time zones in Russia and the former Soviet Republics can be found in Russian. Finding the local names means a lot more work. The GeoNames server is a great help though. But the transliteration of names is not always correct. Best would be: find the name in the original spelling with Cyrillic, Arabic, whatever characters, find the official or a reliable transliteration scheme and produce a posix 1 conformant transliteration. There you see: too much work for me!
Oscar van Vlijmen wrote:
From: Andy McDonald Date: Sat, 26 May 2007 14:16:59 -0400 Subject: Re: zone.tab corrections
In the case that Russian is one of the official languages, I would agree that no change is required. However this is distinct from the status of Russian as being widely understood; certainly many people in the former USSR understand Russian, but I would imagine that the average Ukrainian, Moldovan, Tajik or Georgian would take issue with a transliteration from Russian.
Note that I am a bit lazy (I did most of the Russian names for TZ). Lists with time zones in Russia and the former Soviet Republics can be found in Russian. Finding the local names means a lot more work. The GeoNames server is a great help though. But the transliteration of names is not always correct. Best would be: find the name in the original spelling with Cyrillic, Arabic, whatever characters, find the official or a reliable transliteration scheme and produce a posix 1 conformant transliteration. There you see: too much work for me!
The time zones of the former USSR, plus Mongolia (heavily influenced by its neighbour) are: AM +4011+04430 Asia/Yerevan AZ +4023+04951 Asia/Baku BY +5354+02734 Europe/Minsk EE +5925+02445 Europe/Tallinn GE +4143+04449 Asia/Tbilisi KZ +4315+07657 Asia/Almaty most locations KZ +4448+06528 Asia/Qyzylorda Qyzylorda (Kyzylorda, Kzyl-Orda) KZ +5017+05710 Asia/Aqtobe Aqtobe (Aktobe) KZ +4431+05016 Asia/Aqtau Atyrau (Atirau, Gur'yev), Mangghystau (Mankistau) KZ +5113+05121 Asia/Oral West Kazakhstan KG +4254+07436 Asia/Bishkek LV +5657+02406 Europe/Riga LT +5441+02519 Europe/Vilnius MD +4700+02850 Europe/Chisinau MN +4755+10653 Asia/Ulaanbaatar most locations MN +4801+09139 Asia/Hovd Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan MN +4804+11430 Asia/Choibalsan Dornod, Sukhbaatar RU +5443+02030 Europe/Kaliningrad Moscow-01 - Kaliningrad RU +5545+03735 Europe/Moscow Moscow+00 - west Russia RU +4844+04425 Europe/Volgograd Moscow+00 - Caspian Sea RU +5312+05009 Europe/Samara Moscow+01 - Samara, Udmurtia RU +5651+06036 Asia/Yekaterinburg Moscow+02 - Urals RU +5500+07324 Asia/Omsk Moscow+03 - west Siberia RU +5502+08255 Asia/Novosibirsk Moscow+03 - Novosibirsk RU +5601+09250 Asia/Krasnoyarsk Moscow+04 - Yenisei River RU +5216+10420 Asia/Irkutsk Moscow+05 - Lake Baikal RU +6200+12940 Asia/Yakutsk Moscow+06 - Lena River RU +4310+13156 Asia/Vladivostok Moscow+07 - Amur River RU +4658+14242 Asia/Sakhalin Moscow+07 - Sakhalin Island RU +5934+15048 Asia/Magadan Moscow+08 - Magadan RU +5301+15839 Asia/Kamchatka Moscow+09 - Kamchatka RU +6445+17729 Asia/Anadyr Moscow+10 - Bering Sea TJ +3835+06848 Asia/Dushanbe TM +3757+05823 Asia/Ashgabat UA +5026+03031 Europe/Kiev most locations UA +4837+02218 Europe/Uzhgorod Ruthenia UA +4750+03510 Europe/Zaporozhye Zaporozh'ye, E Lugansk UA +4457+03406 Europe/Simferopol central Crimea UZ +3940+06648 Asia/Samarkand west Uzbekistan UZ +4120+06918 Asia/Tashkent east Uzbekistan Most of these time zones are named from the accepted English spelling, or - for Russia - accepted transliteration from Russian, so there are few transliteration issues. In addition to the issue of Ukrainian names, the only difficulty arises - to the best of my knowledge - with Hovd (often transliterated from Ховд as Khovd (but as Paul Eggert says in the 'asia' file, 'Naming and spelling is tricky in Mongolia'). I was not confident in the Kazakh names, but the CIA seems to agree: https://www.cia.gov/library/publications/the-world-factbook/geos/kz.html . In short, I think that the time zones of the former USSR are appropriately named, with the exception (I claim!) of those in Ukraine.
Andy McDonald <andy_tz@stemhaus.com> writes:
There seem to be a few minor errors in zone.tab (2007f and earlier):
America/Cambridge_Bay: zone.tab latitude/longitude is incorrect, according to http://www.meds-sdmm.dfo-mpo.gc.ca/meds/Prog_Nat/benchmark/single_station2_e..., which gives +6907-10504, and my own experiments with Google Earth. Also zone.tab comments should be 'Mountain Time - west Nunavut' rather than 'Central Time - west Nunavut'
Thanks, I'll change it to: CA +690650-1050310 America/Cambridge_Bay Mountain Time - west Nunavut as per the followup discussion.
Antarctica/DumontDUrville: The comment should very probably read 'Dumont d'Urville Station', rather than 'Dumont d'Urville Base',
Pacific/Johnston: latitude/longitude is incorrect. The CIA seems to have it much closer with +1645-16931
America/Aruba: latitude/longitude is incorrect. The CIA seems to have it much closer with +1230-06958
Thanks, I'll propagate these fixes too.
Europe/London: (!) latitude/longitude is incorrect - the current value is somewhere in the neighbourhood of Syon House in South-west London (http://en.wikipedia.org/wiki/Syon_House). Suggestions for a better value welcome.
If the BBC says the centre of London is the modern Charing Cross, that's good enough for me. I assume the following will do? GB +513030-0000731 Europe/London The following line in "Europe" shouldn't change, though: Zone Europe/London -0:01:15 - LMT 1847 Dec 1 0:00s since that "-0:01:15" applies to the obelisk in question.
Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names.
The tz database prefers the most common English spelling for the place names in question; this is why we use "Moscow" rather than "Moskva", for example. "Kiev" is more popular than "Kyiv" in English. The other two names are similar. If the English spellings change (which is what happened with Mongolian and Kazakh names) we can revisit this. In the meantime, I can add some comments about this, and change the zone.tab entry to look like the following (a similar solution is already in place for Greenland locations): UA +4750+03510 Europe/Zaporozhye Zaporozh'ye, E Lugansk / Zaporizhia, E Luhansk
Paul Eggert wrote:
Ukrainian time zones Europe/Kiev, Europe/Uzhgorod and Europe/Zaporozhye: These might better be named Europe/Kyiv, Europe/Uzhhorod and Europe/Zaporizhia, being transliterations of the Ukrainian - rather than Russian - place-names.
The tz database prefers the most common English spelling for the place names in question; this is why we use "Moscow" rather than "Moskva", for example. "Kiev" is more popular than "Kyiv" in English. The other two names are similar. If the English spellings change (which is what happened with Mongolian and Kazakh names) we can revisit this. In the meantime, I can add some comments about this, and change the zone.tab entry to look like the following (a similar solution is already in place for Greenland locations):
UA +4750+03510 Europe/Zaporozhye Zaporozh'ye, E Lugansk / Zaporizhia, E Luhansk
Makes sense to me. For want of a better metric, Google shows more (English-only, modified in the last year) results for Uzhgorod than Uzhhorod and more results for Zaporozhye than Zaporizhia. For sufficiently obscure places, though, a most common English spelling must be very hard to establish. I guess the interesting thing about Kiev/Kyiv is that Ukraine wishes the English spelling to be 'Kyiv', although 'Kiev' is of course much more widely used.
Andy McDonald <andy_tz@stemhaus.com> writes:
I guess the interesting thing about Kiev/Kyiv is that Ukraine wishes the English spelling to be 'Kyiv', although 'Kiev' is of course much more widely used.
A much bigger example is Asia/Calcutta. "Calcutta" is still somewhat more popular than "Kolkata" in English, according to Google, but the margin is much closer. There's no hurry, but I have been thinking of changing it to Asia/Delhi. These days Delhi is a bit larger than Calcutta/Kolkata anyway. And nobody is messing with Delhi's spelling. Yet.
On 5/30/07, Paul Eggert <eggert@cs.ucla.edu> wrote:
A much bigger example is Asia/Calcutta. "Calcutta" is still somewhat more popular than "Kolkata" in English, according to Google, but the margin is much closer.
There's no hurry, but I have been thinking of changing it to Asia/Delhi. These days Delhi is a bit larger than Calcutta/Kolkata anyway. And nobody is messing with Delhi's spelling. Yet.
I am an ex-Delhi resident, and one who still has family there. There are calls to rename the city "Dilli", which is how it is pronounced phonetically locally, and written in Hindi. I have not seen any official moves on this, yet, but I am afraid it may not be long. The pressure to prove that we Dilli-walas are as anti-colonial as our neighbours is hard to resist. I would have suggested Asia/Allahabad, being the official standard (I believe) of IST, but there are issues here, too. Some locals wish it renamed "*Ilāhābād*", being the phonetic spelling, and others want it to be Prayag, which is the older (Hindu) name of the spot. I am new on this list, just wanted to muddy the waters with too much info :-) -- Sanjeev "ghane" Gupta
Rather than spend lots of energy exploring the spelling politics of various towns in various countries, it might be easier to look for a common pattern. There are two possible approaches: 1. Spell city names by the "local language rule" 2. Spell city names by the "English language convention". In other words, as the name is most likely to appear in an English language newspaper or magazine article. zone.tab right now does the latter. In fact, you don't really have much choice; it needs to be #2. #1 works if there is a single official (or widely accepted) spelling, and that spelling can reasonably be rendered in the character set used in zone.tab. (I think that's plain ASCII, as in ISO 646.) If there's more than one official language, there's a definite problem. For example, zone.tab says "Europe/Brussels" which is the English language form of the name of Belgium's capital. If you wanted to use approach #1 (local language rule) you would *have* to have two entries (Europe/Brussel and Europe/Bruxelles) because local language politics there can get quite heated and listing only one of the two is very much unacceptable. Switzerland has four official languages. I don't know how to render Europe/Zurich in all of them. If you use the local language of the town, you have to put an umlaut on that u. So to get back to Calcutta, or Delhi: you can't very well put the local spelling of the name in zone.tab unless you're using the local script. (Which one would that be -- India has at least six.) Or you could use the official translateration into the latin alphabet, if there's a plausible transliteration. But that wouldn't work for European languages that use diacritical marks and have no standard way of doing without them (German does, but I don't think Rumanian does, so how would you render the local version of Rumania's capital?). Conclusion: stick with #2, which means stick with "Calcutta" (or "Delhi") unless and until a different spelling becomes generally accepted for English language documents. paul
Paul Koning said:
But that wouldn't work for European languages that use diacritical marks and have no standard way of doing without them (German does, but I don't think Rumanian does, so how would you render the local version of Rumania's capital?).
Especially since it's Romania, not Rumania. The UK Passport Agency uses "Bucuresti" or "Bucharest" (on two documents issued on the same day based on the same paperwork). -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | |
________________________________ From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Wednesday, May 30, 2007 6:34 AM To: tz@lecserver.nci.nih.gov Subject: RE: zone.tab corrections <snip> So to get back to Calcutta, or Delhi: you can't very well put the local spelling of the name in zone.tab unless you're using the local script. (Which one would that be -- India has at least six.) Or you could use the official translateration into the latin alphabet, if there's a plausible transliteration. But that wouldn't work for European languages that use diacritical marks and have no standard way of doing without them (German does, but I don't think Rumanian does, so how would you render the local version of Rumania's capital?). Conclusion: stick with #2, which means stick with "Calcutta" (or "Delhi") unless and until a different spelling becomes generally accepted for English language documents. Paul You could bite the bullet (US idion) and redefine the zone tables to be UTF-8. I'm half kidding (I have Unicode very much on the brain right now). But I'm sure that will happen sooner or later. ++PLS
"Paul" == Paul Schauble <Paul.Schauble@ticketmaster.com> writes:
Paul> You could bite the bullet (US idion) and redefine the zone Paul> tables to be UTF-8. Paul> I'm half kidding (I have Unicode very much on the brain right Paul> now). But I'm sure that will happen sooner or later. Yes, that would be good in some ways. Not so good in other ways. It would be a hassle for travelers who are not sufficiently fluent in the local language to read the local place names in their specific script. It also doesn't help the multiple official languages case, though you could cure that by putting multiple entries, one per language. paul
<<On Wed, 30 May 2007 17:55:09 -0400, Paul Koning <pkoning@equallogic.com> said:
"Paul" == Paul Schauble <Paul.Schauble@ticketmaster.com> writes: Paul> You could bite the bullet (US idion) and redefine the zone Paul> tables to be UTF-8.
Yes, that would be good in some ways. Not so good in other ways. It would be a hassle for travelers who are not sufficiently fluent in the local language to read the local place names in their specific script.
Ultimately, that is the problem that zone.tab is intended to solve: provide an appropriately localized description of each timezone so that a user doesn't have to know which city name was chosen by the tz database maintainers, or which spelling was used. -GAWollman
-----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Wednesday, May 30, 2007 2:55 PM To: tz@lecserver.nci.nih.gov Cc: tz@lecserver.nci.nih.gov Subject: RE: zone.tab corrections
"Paul" == Paul Schauble <Paul.Schauble@ticketmaster.com> writes:
Paul> You could bite the bullet (US idion) and redefine the zone Paul> tables to be UTF-8. Paul> I'm half kidding (I have Unicode very much on the brain right Paul> now). But I'm sure that will happen sooner or later. Yes, that would be good in some ways. Not so good in other ways. It would be a hassle for travelers who are not sufficiently fluent in the local language to read the local place names in their specific script. It also doesn't help the multiple official languages case, though you could cure that by putting multiple entries, one per language. Paul ---------------------------------- Yes, exactly. Have one synonym for each local name. Just require that the English choice always exists. ++PLS
Date: Wed, 30 May 2007 15:45:53 -0700 From: "Paul Schauble" <Paul.Schauble@ticketmaster.com> Message-ID: <0165EECEBB4CF745ACF095E1176B03EA1143BDD5@SUNCA-EXB-AV1.ticketmaster.corp> | Yes, exactly. Have one synonym for each local name. Just require that | the English choice always exists. And the original problem remains ... what is "the English choice" ?? Handling zone.tab in other languages is best done by the users of those languages who know what they need, rather than by us ... we'd mostly be just guessing. As long as the zone.tab names remain reasonably stable (which we really want for other reasons in any case) making a script to translate what's there into anything else that works on your local system should be just plain trivial. kre
These are zone IDs, so I'd rather want to keep them unchanged. I think there are some applications which store the zone IDs in persistent data. In these applications, any changes in zond IDs will require mapping table for backward compatibility support. Anyway, I'd like to address that these zone IDs are captured in the Common Locale Data Repository ( http://www.unicode.org/cldr/ ) and these region names are localized (timezones - exemplarCity... of course these localized names are represented by Unicode!). The latest version of CLDR includes local names, for example, "Montreal" in French locale is "Montréal". At this moment, the coverage of localization is not great, but it is improving in every CLDR releases. In my opinion, zone IDs should be stable and based on common English spelling and supporting native/localized city names via separated bundles such as CLDR timezones data. - Yoshito Umaoka (ICU project) "Paul Schauble" <Paul.Schauble@ticketmaster.com> wrote on 05/30/2007 06:45:53 PM:
-----Original Message----- From: Paul Koning [mailto:pkoning@equallogic.com] Sent: Wednesday, May 30, 2007 2:55 PM To: tz@lecserver.nci.nih.gov Cc: tz@lecserver.nci.nih.gov Subject: RE: zone.tab corrections
"Paul" == Paul Schauble <Paul.Schauble@ticketmaster.com> writes:
Paul> You could bite the bullet (US idion) and redefine the zone Paul> tables to be UTF-8.
Paul> I'm half kidding (I have Unicode very much on the brain right Paul> now). But I'm sure that will happen sooner or later.
Yes, that would be good in some ways. Not so good in other ways. It would be a hassle for travelers who are not sufficiently fluent in the local language to read the local place names in their specific script.
It also doesn't help the multiple official languages case, though you could cure that by putting multiple entries, one per language.
Paul
----------------------------------
Yes, exactly. Have one synonym for each local name. Just require that the English choice always exists.
++PLS
2007-05-30T22:10:28 yoshito_umaoka:
These are zone IDs, so I'd rather want to keep them unchanged. I think there are some applications which store the zone IDs in persistent data. In these applications, any changes in zond IDs will require mapping table for backward compatibility support.
Leaving aside the question of unicode, as I understand things (I'm a lurker, not a policy-maker) zone IDs are not expected to remain "stable" in the sense of the primary name not changing; when another city in the covered region grows to have substantially more population than the current primary, we shift that primary, and we'll rename the primary if a city's name in common english usage changes. But we build legacy compatibility links for every zone, any time there's a change; once a zone ID becomes valid it should remain valid forever more, and aside from bugfixes and addition of historical rules over time, the ID will continue to refer to the same timezone forever. -Bennett
<<On Thu, 31 May 2007 14:31:00 -0400, Bennett Todd <bet@rahul.net> said:
changes. But we build legacy compatibility links for every zone, any time there's a change; once a zone ID becomes valid it should remain valid forever more, and aside from bugfixes and addition of historical rules over time, the ID will continue to refer to the same timezone forever.
Depends on the operating system. We do not, by default, include the "backward" file in FreeBSD, so zones which are renamed will, over time, no longer be available. (Users generally will not notice this unless they are in the habit of setting their TZ environment variable explicitly, as the system time zone is copied into place by tzsetup(8).) -GAWollman
participants (14)
-
Andy McDonald -
Bennett Todd -
Chris Walton -
Clive D.W. Feather -
Garrett Wollman -
Oscar van Vlijmen -
Paul Eggert -
Paul Koning -
Paul Schauble -
Peter Ilieve -
Robert Elz -
Sanjeev Gupta -
Tony Finch -
yoshito_umaoka＠us.ibm.com