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