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

[Steffen Daode Nurpmeso]

Boruch Baum <boruch_baum at gmx.com> 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.

Hmm.

 |Who is/are responsible for maintaining each locality's localization
 |lists, in order, for example, to guarantee uniqueness?

I would appreciate it if there would be a mapping table from the
zone name to a "real" and "official" english name of the zone,
also to compensate a bit for the abbreviations which are used.

But for localization of that (table and the timezone string)?
This is an immense amount of work, and who is going to maintain
that?

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

This function is part of POSIX ([1] recent standard).
And it's a dust-dry interface, just like many other localization
efforts.  Is localization at all possible in such a simple-minded
way, through variables which represent format strings and things
like "the ante-meridiem affix"?  There are people out there who
don't even use words to communicate, numerical systems which don't
know about '0' and use special symbols for values like '1000' or
'10000', very different calendars ...

 [.]
 |So how do locales represent timezone strings in their own localization?

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

I guess the only really satisfying solution would be something
like the Berkeley packet filter or similar -- i.e., pseudo-ops
that will be executed and which produce some string as output.
That is to say, language/locale specific, port programming
language independent code, which can compute and reorder things as
necessary.

I fail to see how you could gain real internationalization with
the current tools otherwise.
But the TZ database gives you data and tools to compute the
correct time -- isn't that just fantastic.
Thanks,

--steffen

[1] http://pubs.opengroup.org/onlinepubs/9699919799/