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

[Alan Perry]

I thought that the abbreviations were intended to be the local 
abbreviations used for the display of a time value within particular 
timezones and reflect local practice.  I didn't think that they were 
supposed to be unique.  The Zone name is unique.  Why does a timezone 
need two unique identifiers?

If this proposal is adopted, is the intent to promote the use of the new 
unique abbreviations as the new local practice?

alan


On 6/6/12 8:35 AM, Boruch Baum wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> For what it's worth, I'll second David Patte's post that Tobias's idea
> is a good one (that would face the usual hurdles of adoption of a new
> international standard). I do have a criticism regarding localizations
> of the abbreviations (see below), but that doesn't detract in any way
> from the merit I see in having a unique international standard for the
> abbreviations.
>
> - From my perspective as an app developer, Tobias's proposal would
> (obviously) make it easier to work with users' identification of
> timezones.
>
> Here's a tweak to Tobias's idea that, while linguistically inelegant,
> might be a functional improvement: Have the DST code be the final
> character of the abbreviation string. This would allow computer
> programs to easily truncate and ignore the the DST code, associate the
> remainder with a timezone name, and get the relevant and correct time
> data either directly from the tzif file or from a library function.
> Thus (as in John Haxby's recent example in his post), a self-described
> infallible user could refer to her zone using the 'winter'
> abbreviation for a 'summer' date, without any negative repercussions
> to her self-esteem or to the scheduling of an international conference
> call between PST and GMT.
>
> 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).
>
>