For reference, the POSIX definition of $TZ syntax is at
<http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html>.
In summary, POSIX defines the meaning of $TZ strings matching $posix_tz
below:
$abbrev = qr#[A-Za-z]{3,}|\<[-+0-9A-Za-z]{3,}\>#;
$offset = qr#[-+]?([01]?\d|2[0-4])(:[0-5]\d(:[0-5]\d)?)?#;
$rule_date = qr#J0*([1-9]|\d\d|[12]\d|3([0-5]\d|6[0-5]))
|0*(\d|\d\d|[12]\d|3([0-5]\d|6[0-5]))
|M0*([1-9]|1[0-2])\.0*[1-5]\.0*[0-6]#x
$rule_time = qr#([01]?\d|2[0-3])(:[0-5]\d(:[0-5]\d)?)?#;
$rule_dt = qr#${rule_date}(/${rule_time})?#o;
$posix_tz = qr#${abbrev}${offset}
(${abbrev}(${offset})?(,${rule_dt},${rule_dt})?)?#xo;
(Some of the syntax isn't stated with full clarity in the standard,
so a bit of interpretation went into the above.) It also states that
any string starting with ":" has implementation-defined meaning.
Interaction with the Olson syntaxes:
* all Olson syntaxes that include a "/" are disjoint from POSIX ($posix_tz
can include a "/", but if so then there must be a digit earlier in
the string, which Olson never does)
* the US ones such as "EST5EDT" are backward compatibility hacks for
the same syntax that POSIX also allows for backward compatibility
(POSIX doesn't actually define when DST is taken to start and end if
the rule is not explicitly given)
* the short names qr#GMT[-+]?0# overlap with POSIX and are interpreted
the same by both
* other short names are disjoint from POSIX
Olson's fixed offsets from UT, with names like "Etc/GMT-5", don't appear
at the top level presumably because they clash with POSIX syntax.
POSIX would interpret "GMT-5" as meaning a timezone 5 hours *ahead*
of UTC, and bearing the name "GMT".
Rick: you suggested allowing a timezone string to give a module name
and constructor argument. Interpreting POSIX timezone strings might be
a good application of this idea.
-zefram
