Attached is a patch that revises timezone name parsing in DT::TZ.
The changes:

Anything that looks like a System V timezone string is treated as such,
via DT::TZ::SystemV.  This interpretation overrides some of the zones
and links in the Olson database, and a couple that were in DT::TZ only.
In each case, of course, the overridden names existed for ad hoc backwards
compatibility with System V.

A filename (beginning with "/") is accepted as a timezone name, and
the file is parsed by DT::TZ::Tzfile.  (To consider: how should this
facility behave on non-Unix systems?  It would be nice to keep leading
"/" as the signal to the parser that a filename is coming up.  So the
main options are (a) parse a Unix-like filename and translate to local
form and (b) accept "/" followed by a local-form filename.)

A leading ":" is accepted and ignored in any timezone name except for
the meta-name "local".  This provides compatibility of $TZ parsing with
the various libcs.

If a timezone name can't be parsed at all, the error comes from DT::TZ
rather than DT::TZ::OffsetOnly.  This makes the message less confusing,
and is a cleaner arrangement.

Embedded "::"s are not allowed in place of "/" in Olson zone names.
That was an undocumented capability that didn't apply to link names.

In $TZ, *any* name other than "local" is accepted, as the documentation
already stated.  Previously a character set limitation was applied which
prevented the use of the numerical offset syntax.

The handful of non-SysV single-part zone (not link) names in the
Olson database are implemented differently.  Formerly the EU ones were
filtered out and the rest (the US ones) were accepted as first-class
zones.  Now the US ones, which are all fixed offsets, are implemented
as aliases to System V strings, and the rest (the EU ones) are thrown
away.  Little difference in behaviour, but internally cleaner.  Now no
single-part Olson zone names are used as such.

The documentation about name parsing is now more accurate.

-zefram

Reply via email to