I'm not saying that one should necessarily use all the levels of containment. It depends on other aspects of the UI. The 2nd level of the UN tree is actually reasonably close to the top level TZID arrangement. UN: Africa [002] Eastern Africa [014] Middle Africa [017] Northern Africa [015] Southern Africa [018] Western Africa [011] Americas [019] Caribbean [029] Central America [013] Northern America [021] South America [005] Asia [142] Eastern Asia [030] South-central Asia [062] South-eastern Asia [035] Western Asia [145] Europe [150] Eastern Europe [151] Northern Europe [154] Southern Europe [039] Western Europe [155] Oceania [009] Australia and New Zealand [053] Melanesia [054] Micronesian Region [057] Outlying Oceania [QO] Polynesia [061] Here are the differences I see, after replacing the UN "Americas" by "America", and "Oceania" by "Pacific" (or the territories "Antarctica" or "Australia"). Africa/Ceuta ES Africa Europe Arctic/Longyearbyen SJ Arctic Europe Asia/Anadyr RU Asia Europe Asia/Irkutsk RU Asia Europe Asia/Kamchatka RU Asia Europe Asia/Krasnoyarsk RU Asia Europe Asia/Magadan RU Asia Europe Asia/Novosibirsk RU Asia Europe Asia/Omsk RU Asia Europe Asia/Sakhalin RU Asia Europe Asia/Vladivostok RU Asia Europe Asia/Yakutsk RU Asia Europe Asia/Yekaterinburg RU Asia Europe Atlantic/Azores PT Atlantic Europe Atlantic/Bermuda BM Atlantic America Atlantic/Canary ES Atlantic Europe Atlantic/Cape_Verde CV Atlantic Africa Atlantic/Faeroe FO Atlantic Europe Atlantic/Jan_Mayen SJ Atlantic Europe Atlantic/Madeira PT Atlantic Europe Atlantic/Reykjavik IS Atlantic Europe Atlantic/South_Georgia GS Atlantic Oceania Atlantic/St_Helena SH Atlantic Africa Atlantic/Stanley FK Atlantic America Europe/Istanbul TR Europe Asia Indian/Antananarivo MG Indian Africa Indian/Chagos IO Indian Oceania Indian/Christmas CX Indian Oceania Indian/Cocos CC Indian Oceania Indian/Comoro KM Indian Africa Indian/Kerguelen TF Indian Oceania Indian/Mahe SC Indian Africa Indian/Maldives MV Indian Asia Indian/Mauritius MU Indian Africa Indian/Mayotte YT Indian Africa Indian/Reunion RE Indian Africa Pacific/Easter CL Pacific America Pacific/Galapagos EC Pacific America Pacific/Honolulu US Pacific America Mark ----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Thursday, June 09, 2005 23:53 Subject: Re: Multi-timezone clock
That is already done: the timezones (which have TZIDs <region>/<city>) are organized in a tree in which the first level is the <region> and the second level is the country (which I deduce from the zone.tab and iso3166.tab files in the tzdata).
See this screenshot for an example: http://users.skynet.be/Peter.Verthez/projects/intclock/config.jpg
The M.49 regions don't exactly correspond with the <region> given in the TZID (e.g. the TZID has regions like "Pacific", "Atlantic", ...), so these are currently just strings that have to be explicitly translated.
However, I see that I could indeed use the territoryContainment to get around that. I'm only wondering whether the level of detail that M.49 gives would make the UI clearer, since it would result in a tree with more levels. I'll try something and see what it gives.
Peter.
Mark Davis wrote:
BTW, one other thing you might be interested in for a UI are the regions. We translate the United Nations M.49 regions, and supply a machine-readable structure showing their containment. So rather than giving a very long list of TZIDs, you may want to organize them by region and/or country. For more information, see the supplemental data charts from
http://www.unicode.org/cldr/comparison_charts.html
especially "Territory Containment (UN M.49)" (that chart is just a layout of the XML data found in supplementalData.xml, using an English localization).
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: "Mark Davis" <mark.davis@jtcsv.com> Cc: <tz@lecserver.nci.nih.gov> Sent: Wednesday, June 08, 2005 23:58 Subject: Re: Multi-timezone clock
OK, I see, it makes indeed sense to do it that way.
I'll make an update shortly to remove the city names where they are not needed, and I'll also take in the exemplarCity entries in the case of multiple timezones per country (if given).
Best regards, Peter.
Mark Davis wrote:
If you just look at the cities, you will always find them to be sparse;
that
is the intention. Our goal was to avoid having to translate all the city names used in the tz database, since (a) it's a lot of data, and (b)
their
usage is otherwise very limited, and (c) could be covered by the country names. (This was discussed some time back on the list.) So the primary
goal
is to translate the cities for cases where there are multiple zones in
the
same country.
Thus for Russian, for example, we have cities for: Australia/Adelaide => Аделаида (Австралия) Australia/Brisban => Брисбен (Австралия) ... But for single-zone countries like Austria, etc, we use just the
country,
and don't have a translated city: Europe/Vienna => Австрия Europe/Mariehamn => Аландские острова ... And if there is one 'main' city for the country, then we also just use
the
country for that: Europe/London => Великобритания Europe/Belfast => Белфаст (Великобритания)
Europe/Madrid => Испания Africa/Ceuta => Сеута (Испания) Atlantic/Canary => Канарские о-ва (Испания)
http://www.unicode.org/cldr/data/dropbox/timezones/ru_timezones.html
(The translators have the freedom to use different format strings for
the
city / country string, eg "<city> (<country>)" or "<country>, <city>" or ...)
We also don't translate where the translation doesn't differ from the
last
field of the tzid. So if the name for the city is "New York" you won't
see a
translation; just for cases like: Efrog Newydd (cy), Nova Iorque (pt),
Nowy
Jork (pl), Nueva York (es), Νέα Υόρκη (el), Нью-Йорк (ru), (uk), Ню Йорк (bg), אמריקה/ניו-יורק (he), نيويورك (ar), ኒውዮርክ (am), นิวยอร์ก (th), 뉴욕 (ko), ニューヨーク (ja), 紐約 (zh_Hant), 纽约 (zh)....
That being said, this is still a work in progress. Our focus in the last release was on getting the high-runner languages and zones. For example,
if
you look at Greek (http://www.unicode.org/cldr/data/dropbox/timezones/el_timezones.html), you'll find America/New_York => Νέα Υόρκη (Ηνωμένες Πολιτείες) but Antarctica/Casey => Casey (Ανταρκτική) so for the latter we have the country but not the city (the Greeks
somehow
not being that interested in Antarctic timezones yet). And for a number
of
the draft languages (eg Azeri), we have little or no data yet.
Mark
----- Original Message ----- From: <peter.verthez@alcatel.be> To: <tz@lecserver.nci.nih.gov> Sent: Tuesday, June 07, 2005 22:40 Subject: Multi-timezone clock
Hello all,
I've been making a multi-timezone clock based on the Olson timezone database, which may be interesting to the people on this mailing list. The freshmeat project page can be found here: http://freshmeat.net/projects/intclock
The tz database is used in the configuration window, to select a timezone for each clock.
The program is written in Perl and requires perl-Gtk2 (actually, perl-Gtk will also work, but with a much less polished user interface).
It is currently available in English, Dutch and German. Country names are translated via the CLDR (currently version 1.3) for all languages automatically. Manual translation is only needed for some 30 strings in the user interface.
Note that the translations for timezone names in the CLDR (i.e. the exemplarCity entries) are currently not used, because the available data is too sparse: all city names are shown in English. If the CLDR includes more entries later, this may change.
All suggestions, and translations to other languages, are very welcome (see web page for details).
Best regards, Peter.
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@alcatel.be Systems Engineer Network Mgt. Tel: (+32) 3 240 84 50 | Alcanet: Alcatel Telecom, dept. JN22 Fax: (+32) 3 240 84 59 | (6)2605 ____________________________________________________________________
-- ____________________________________________________________________ Peter Verthez mailto:Peter.Verthez@alcatel.be Systems Engineer Network Mgt. Tel: (+32) 3 240 84 50 | Alcanet: Alcatel Telecom, dept. JN22 Fax: (+32) 3 240 84 59 | (6)2605 ____________________________________________________________________