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 -----
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
>
____________________________________________________________________
>
>
>