On Sun, 11 Feb 2007, Zefram wrote:
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.
I took a look at the patch, and I have a couple things I'd like to see
changed.
First, I don't want to make these new modules requirements. What I'd
prefer to do is just load them if they exist and use them. No one (that I
recall) has asked for Posix or binary file support, so making them
dependencies seems like overkill.
Given that, I don't want to change the handling of these names. This would
be a backwards-incompatible change as it is, since in the Olson database a
name like EST5EDT uses the US rules, meaning it includes many historical
changes.
Your SystemV module's interpretation of this zone name would be very
different. I think the Olson interpretation is probably better, since it's
more correct in terms of current rules. An application that _really_
wanted the SysV interpretation could always explicitly construct a SystemV
object and pass it to DateTime.
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.)
This should probably use File::Spec->file_name_is_absolute() to figure
this out. None of the currently valid names are absolute file names on any
system (I think).
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 I do "man tzset" on my system (Ubuntu edgy) it tells me this about
a leading colon:
:[filespec]
If the file specification filespec is omitted, the time zone
information is read from the file localtime in the system timezone
directory, which nowadays usually is /usr/share/zoneinfo. This file is
in tzfile(5) format. If filespec is given, it specifies another
tzfile(5)-format file to read the time zone information from. If
filespec does not begin with a '/', the file specification is
relative to the system timezone directory.
It seems like a leading colon for other things (like "EST5EDT") would be
an error. Of course, removing it isn't a big deal.
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.
That seems like a good thing.
Embedded "::"s are not allowed in place of "/" in Olson zone names.
That was an undocumented capability that didn't apply to link names.
That was probably accidental on my part.
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.
Doh, also a good catch.
I'm about to upload DT::TZ 0.61, which includes some new bits for handling
of local names, and a bunch of small doc changes. I'd love to see a new
version of your patch against 0.61, with the following changes:
1. Make SystemV & Tzfile entirely optional.
2. Use the Olson versions of existing SystemV names (follows from 1)
3. Use File::Spec->file_name_is_absolute to determine if a name could be a
path to a tz file.
Thanks,
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
