TZ environment variable

[Paul Eggert]

"Mark Davis" <mark.davis at jtcsv.com> writes:

> I'm a little fuzzy about what you are talking about.

We're talking about the time zone abbreviation.  For example, on my host:

   $ echo $TZ
   America/Los_Angeles
   $ date -u; date
   Tue May 10 03:58:35 UTC 2005
   Mon May  9 20:58:35 PDT 2005

Here we're talking about the strings "UTC" and "PDT".  We're not
talking about "America/Los_Angeles", or "Pacific Time", or "Pacific
Daylight Time", or anything like that.

POSIX says time zone abbreviations must be at least 3 bytes, and
cannot be more than TZNAME_MAX bytes, and must contain only
"alphanumeric characters from the portable character set in the
current locale, the plus-sign ('+') character, or the minus-sign ('-')
character".  In practice this set is just the ASCII letters, digits,
"-", and "+".  TZNAME_MAX must be at least 6; a value of 255 is common
on BSD hosts.

The common practice of an abbreviation like "CET DST" is not a
portable POSIX time zone abbreviation, for two reasons.  First, it
contains a space.  Second, it's longer than 6 bytes.  POSIX requires
"CEST" or something like that.

Implementations can support abbreviations like "CET DST" as
extensions.  The question is whether to allow such extensions,
including really weird abbreviations such as abbreviations containing
newlines, or empty abbreviations.  These can cause real problems in
practice.

Even "CET DST" can cause problems, and various implementations treat
it differently.  For example:

$ date -u; TZ='CET DST8' date # Solaris 8
Tue May 10 04:09:27 GMT 2005
Tue May 10 04:09:27 CET 2005

Ouch!  That "CET" looks like a bug to me.  Fixed on Solaris 10:

$ date -u; TZ='CET DST8' date # Solaris 10
Tue May 10 04:09:40 GMT 2005
Tue May 10 04:09:40 GMT 2005