-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/06/2012 12:16 PM, Alan Perry wrote:
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?
I can't speak for the OP, but ... The attraction of the proposal to me is that there be unique identifiers that are easy to type, easy to work with, and that will be sufficiently attractive to people and mass media that they actually use the identifiers to the extent that what they input into a computer program / mobile app corresponds to something that can be parsed.
If this proposal is adopted, is the intent to promote the use of the new unique abbreviations as the new local practice?
I don't think that would ever work; the global trend is to accept diversity and multiplicity of locales. People would continue to refer to timezones using abbreviations and names in their own languages and character-sets (refer to recent posts by Andy Lipscomb re French Canadians, and Peter Machata re Czech republic). Rather, the idea would be to start with a baseline international standard of unique abbreviations (and their text descriptions); each locale would have locale-internal-unique localization strings corresponding to the baseline. The result could allow international portability of computer programs for timezone information similar to that which already exists for gregorian month names and days of the weeks (using, in the case of GNU/Linux, the GLIBC nl_langinfo() function ). That I take it for granted the baseline will be in Latin characters and English is just a consequence of that language's stature at this point in history. Two thousand years ago, we would be e-mailing each other in Greek. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPz5BdAAoJEDvrUfDmCx9LQokP/Rawy5VK3DN72l++Dj9CWs5i TmE5PZHhN2x2+Pkhgo7BuUxIkrwyObLshW0ss630+cEOn9HJNqTLbTG4YZckdnD9 ii7lBHWxbgA631mj+Lw8KxZ12fWBVxiKlnRJwYYy/MQSeTRmMw9wTl017oNJ3GWZ 3nuyBr36iD+1zPPaJlECZDJuZCR8mT3YgSgn3YBAH0CO8zQRGcKaSUh9zEKY2J9S xIaHmO9f93Bi3jNOT7avZAPQZICQ2Okx4vA1A215oMwLMG9w+y79zLbXiNHvqiET rWMy2/7Nuuzdc6WMkr0u/oAQb9/G+9DuP9coXMNiKuCvlNrsmFdRu2WXLX0c68lC skHjpnSwe31doMNo4BXu5Pk4ZA/d0SFgB3+LBZ5nrdQ086JPURLadWwPDLvJGkVu 1U/aescOYrph/VX+1Mxjjf85l6pJoSljB2iSEriyHQC6OGq8+smY3JrSEwgrQgMu sn5811gzci1BNQxyrFTR52J1gybkylkvFRdLDo1lYZYJvjJhupNxYRHnXzaIoWrh ktd5CBMT309uuUAWqzv5tMqBRZ5MZVN8LURIGRYoKAP/m8acNRNzg31Sik9lK/wb dY3vodrILc2fqqkGnHlkpcJr8fH1m88/hWnuzG+NSEws6i7uzKlEhokquMpgrtkj tOA45cpvoaYpY+xiDd52 =b3QX -----END PGP SIGNATURE-----