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).