Multi-timezone clock
Mark Davis
mark.davis at jtcsv.com
Fri Jun 10 16:57:40 UTC 2005
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 at alcatel.be>
To: "Mark Davis" <mark.davis at jtcsv.com>
Cc: <tz at 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 at alcatel.be>
> > To: "Mark Davis" <mark.davis at jtcsv.com>
> > Cc: <tz at 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 at alcatel.be>
> >>>To: <tz at 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 at 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 at 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
> ____________________________________________________________________
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20050610/33c5666d/attachment-0001.html
More information about the tz
mailing list