[tz] LST

[Guy Harris]

On Oct 14, 2011, at 3:29 AM, Zefram wrote:

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

I'm not sure "-04:00" is allowed; ':' is not one of the characters allowed in the "std" or "dst" part of the TZ setting.  ($TZ can *begin* with ':'; that was added as an escape hatch to allow those weird Olson timezone folks to specify ":America/Los_Angeles" etc..  However, neither "std" nor "dst" in a doesn't-begin-with-colon specification can contain a colon.)

"UT-4h", however, is allowed, as is, at least as I read the SUS, an RFC 2822-style "-0400".  (Then again, so is "L+O+L", unless I've missed something; I'm not sure why they didn't have a tighter specification - the Rationale says

	The quoted form of the timezone variable allows timezone names of the form UTC+1 (or any name that contains the character plus ( '+' ), the character minus ( '-' ), or digits), which may be appropriate for countries that do not have an official timezone name. It would be coded as <UTC+1>+1<UTC+2>, which would cause std to have a value of UTC+1 and dst a value of UTC+2, each with a length of 5 characters. This does not appear to conflict with any existing usage. The characters '<' and '>' were chosen for quoting because they are easier to parse visually than a quoting character that does not provide some sense of bracketing (and in a string like this, such bracketing is helpful). They were also chosen because they do not need special treatment when assigning to the TZ variable. Users are often confused by embedding quotes in a string. Because '<' and '>' are meaningful to the shell, the whole string would have to be quoted, but that is easily explained. (Parentheses would have presented the same problems.) Although the '>' symbol could have been permitted in the string by either escaping it or doubling it, it seemed of little value to require that. This could be provided as an extension if there was a need. Timezone names of this new form lead to a requirement that the value of {_POSIX_TZNAME_MAX} change from 3 to 6.)