Multi-timezone clock

Fri Jun 10 06:53:42 UTC 2005

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
____________________________________________________________________