[tz] LST

[Zefram]

Robert Elz wrote:
>some code that parses the output from the date command (and perhaps a few
>other similar things) and which expect that the abbreviation will be all
>alphabetic.

FWIW, the POSIX standard for $TZ allows ASCII letters (of either case),
digits, "+", and "-" in the abbreviation, and requires the abbreviation
to be at least three characters long.  So "LT" is not a good idea,
nor is "___", but "-04:00" and "UT-4h" are valid abbreviations that
timezone-handling code ought to be prepared for.  However, if you
use digits or punctuation in the abbreviation then the $TZ format
requires quoting the abbreviation in angle brackets.  So it looks like
the historical practice (in the System V world), from which the POSIX
standard is derived, only portably allowed letters.  It's sane for us to
(mostly) stick to alphabetic-only abbreviations.

I say "mostly" because we already have a handful of exceptions.  Firstly,
the Etc/GMT+n and Etc/GMT-n zones, for which the abbreviation matches the
zone name.  For example, Etc/GMT+5 has the very clear and descriptive
abbreviation "GMT+5".  Unfortunately the abbreviation is totally
misleading, because Etc/GMT+5 is actually a fixed 5 hours *behind* GMT.
I understand that this is historically related to the POSIX $TZ format's
inversion of offsets, but that actually makes it an even worse mistake:
"GMT+5" as a POSIX $TZ means a fixed offset of -5h *with abbreviation
"GMT"*.  (We can deride Hugo Chavez for advising his people to put their
clock forward half an hour to go from UT-4 to UT-4:30, but it seems to
be a rule that everyone involved with timezones gets the direction of
offsets mixed up sometime.)

The other class of exception is the "Factory" zone, which has spaces
in its abbreviation.  That's liable to break timezone-handling software
that can otherwise handle a wide range of characters in abbreviations:
splitting date(1) output on spaces, for example, is otherwise a very sane
behaviour.  As I noted about a year ago (with discussion not reaching
any conclusion), it also means that the POSIX-TZ field of that tzfile
doesn't actually conform to POSIX.  I think it would be better to change
those spaces to dashes, which would be totally POSIX-acceptable.

-zefram