"Mark Davis" <mark.davis@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