[tz] Idea for internationalized time point unique time zone abbreviations

[Brian Inglis]

On 2012-06-06 09:35, Boruch Baum wrote:

> CRITICISM: As Andy Lipscomb, Brian Inglis and Peter Machata all
> recently posted, localizations for all timezone names and
> abbreviations can (and should) be expected to be in the local language
> and character set.
>
> Who is/are responsible for maintaining each locality's localization
> lists, in order, for example, to guarantee uniqueness?
>
> The GLIBC library of GNU/Linux currently has a function nl_langinfo,
> which gives programmers an easy way to localize pretty much all time
> and date related data elements... but not timezone names or
> abbreviations. The GNU/Linux coreutil commandline 'date +%Z' command
> will return a timezone abbreviation, but seemingly never localized. I
> see no option in the GNU/Linux coreutil commandline 'date' command to
> return a timezone name.
>
> So how do locales represent timezone strings in their own localization?
>
> I recently started testing my libhdate collection under a variety of
> locales, so I had a small script all ready for this test:
>
> =====================================================================
> #!/bin/bash
> # locale_test.sh
> # execute an arbitrary command from a list of locales
> # note: the locales must first be defined using localedef(1). This
> usually requires administrator privileges
>
> locales=( \
> he_IL Hebrew Israel \
> de_DE German Germany \
> pt_BR Portuguese Brazil \
> ru_RU Russian Russia \
> ar_MA Arabic Morocco \
> es_AR Spanish Argentina \
> es_MX Spanish Mexico \
> fr_FR French France \
> fr_CA French Canada \
> hi_IN Hindi India \
> fa_IR Farsi Iran \
> ja_JP Japanese Japan \
> ko_KR Korean Korea     \
> hy_AM Armenian Armenia \
> ka_GE Georgian Georgia \
> am_ET Amharic Ethiopia \
> zz
> )
>
> i=0
> while [[ "${locales[$i]}" != "zz" ]]; do
>     echo -e "\e[48;5;234mcommand: $*, locale: ${locales[$i]}
> ${locales[$i+1]} ${locales[$i+2]}\e[01;00m"
>     env LC_ALL=${locales[$i]}.UTF-8 $*
>     i=$i+3
>     done
>
> =====================================================================
> $ ./locale_test.sh TZ='Asia/Tehran' date +"%A_%B_%Z"
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: he_IL Hebrew Israel
> רביעי_יוני_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: de_DE German Germany
> Mittwoch_Juni_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: pt_BR Portugese Brazil
> quarta_junho_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ru_RU Russian Russia
> Среда_Июнь_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ar_MA Arabic Morocco
> الأربعاء_يونيو_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: es_AR Spanish Argentina
> miércoles_junio_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: es_MX Spanish Mexico
> miércoles_junio_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fr_FR French France
> mercredi_juin_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fr_CA French Canada
> mercredi_juin_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: hi_IN Hindi India
> बुधवार _जून_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: fa_IR Farsi Iran
> چهارشنبه_ژوئن_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ja_JP Japanese Japan
> 水曜日_6月_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ko_KR Korean Korea
> 수요일_6월_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: hy_AM Armenian Armenia
> Չորեքշաբթի_Հունիսի_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: ka_GE Georgian Georgia
> ოთხშაბათი_ივნისი_IRDT
> command: TZ=Asia/Tehran date +%A_%B_%Z, locale: am_ET Amharic Ethiopia
> ረቡዕ_ጁን_IRDT
> =====================================================================
>
> - From my perspective, it would be best if nl_langinfo would be extended
> to include timezone names and abbreviations. That would make it
> trivial to write code that would portable across all locales, and
> would be able to auto-magically accept timezone names and
> abbreviations in the user's selected locale.
>
> Of course, nl_langinfo just picks up data from locale definition
> files, so this still would mean each locale having a complete set of
> entries for each timezone name and abbreviation (just as each dos now
> month names, days of week).

CLDR would need to collect timezone names and abbreviations for each 
combo of Olson/IANA timezone (which specifies an associated territory/ 
country code in the zone.tab file), standard/daylight state, and 
languages used in that territory.
So for any timezone and territory, localization is likely to be possible 
only for those languages used (or the subset provided in the CLDR, which 
may be only the officially supported languages) in that territory for 
that timezone and state.

For Canada, English and French names and abbreviations are provided, but 
do how those are rendered into say Chinese, Arabic, and Hebrew depend on 
whether the populations using those languages are in North American 
English, French, or their native locales?

So limited localization may be supported by CLDR, but it is likely to be 
a large effort and a long time before internationalization of timezone 
names and abbreviations could be supported, as the locales required 
could be a large subset of the product of all languages and territories.