I've spent the past week reinventing a wheel.
http://www.fysh.org/~zefram/tmp/DateTime-TimeZone-1.900.tar.gz
size: 29025
MD5: 812934a0174783eb8bdd37f6c99175d6
SHA1: 7d4e73b10574534667a48f2f148b09bef1d0a541
This is a total rewrite of DateTime::TimeZone. The main purpose of the
change is that, as we've discussed for the past couple of years, it uses
DT:TZ:Olson (and thus the standard tzfiles) for Olson zones. It ought
to be a drop-in replacement for the existing DT:TZ. Please try it out,
to see if it actually succeeds as a replacement. I'd particularly like
to know whether the new DT:TZ:Local code behaves itself on Windows, VMS,
HP-UX, and AIX.
When (if) everyone's happy with the rewritten version, I'd like to have
module ownerships transferred from Dave Rolsky (six modules) and from
Joshua Hoblitt (DT:TZ:Alias), and then make a 2.000 release to CPAN.
Compatibility notes attached.
-zefram
compatibility between DROLSKY DT:TZ and ZEFRAM DT:TZ
====================================================
DT:TZ
-----
DT:TZ is no longer a base class for timezone objects. Its class methods
therefore can't be called on timezone objects, only on the DT:TZ class.
Timezone object methods are now documented in DT:TZ:API.
All the class methods can now be called as normal subroutines.
Previously ->new and ->is_valid_name couldn't, but all the others could.
When calling ->new, the "name =>" argument is now optional.
The ->new method no longer uppercases the input name when looking for
links. This bizarre bit of logic made inputs such as "akst9akdt" work,
but not the similar "pst8pdt".
If the ->new method is given a syntactically unrecognised timezone name,
it will generate an error message of its own. Previously it would hand
such a name to DT:TZ:OffsetOnly, which generated an "Invalid offset"
message, which was likely to be confusing.
If the ->new method is given a timezone name that syntactically looks
like an Olson name but isn't actually in the Olson database, an error
message will be generated by DT:TZ:Olson, referring to a specific version
of the database. Previously an error message would be generated by DT:TZ,
with no explicit reference to Olson.
The "Factory" zone from the Olson database is now supported by the
->new method. This is because everything not specially overridden is
now passed to DT:TZ:Olson, which provides a complete Olson database.
The ->all_names and ->links methods now operate only on Olson data.
Previously they included a couple of exceptions, such as treating
AKST9AKDT as a link.
The ->categories method now returns all Olson categories. Previously
"Etc" was omitted.
The ->names_in_category and ->names_in_country methods now return []
if given invalid input, where previously they would return undef.
The ->names_in_category method was documented to return the names in
a useful order, but actually didn't. Behaviour has not changed there,
but the documentation now doesn't make a false claim.
DT:TZ:Alias
-----------
The aliases managed by this module are now separate from the Olson
database's internal links. It is therefore impossible to read or delete
Olson links through this module.
Offset strings, as alias targets, are no longer canonicalised.
In several respects the documentation was inaccurate. Behaviour has
mostly not changed, and the new documentation is accurate.
Two bugs whereby the ->add method could be induced to override aliases
or timezone names, contrary to its documentation, are now fixed.
The ->is_timezone method, and therefore also ->is_defined, now recognise
offset strings, "local", and other specials. Previously it only
recognised Olson names and a couple of specials, and the other specials
were recognised only by the ->add/->set logic.
The ->timezones method now explicitly operates only on Olson data.
Previously it was documented as "all known timezones", but it never
included things like offset strings. It's not possible to make it match
up with ->is_timezone.
DT:TZ:Catalog
-------------
Does not exist in the new distro. It wasn't meant to be used directly,
so this should be OK. It was meant to be used via the functions in DT:TZ,
which still exist. If anything is using it directly, it would be a bit
awkward to provide compatibility, but something could be arranged using
tied variables.
DT:TZ:Europe::London et al
--------------------------
These are no longer separate classes. Olson timezones are now implemented
as instances of DT:TZ:Tzfile, constructed via DT:TZ:Olson. Nothing should
be referring directly to the specific zone classes. If anything is,
it would be easy to put together a backcompat distro that provides
constructors DT:TZ:Europe::London->new et al that just wrap DT:TZ:Olson.
DT:TZ:Floating
--------------
The constructor used to accept and ignore any arguments. Now it croaks
if any are supplied.
The ->short_name_for_datetime method was documented to return undef,
but actually returned "floating". Behaviour has not changed, but the
documentation now correctly describes it.
DT:TZ:Local
-----------
Can no longer be extended for a particular OS by installing a new
DT:TZ:Local::* module. It's now all in one module, and hence behaviour
doesn't vary depending on other modules installed.
Default Unix behaviour now makes a serious attempt to interpret
$TZ in the way the OS does, rather than just passing $TZ to
DateTime::TimeZone::new(). It will accept a SystemV-style timezone
specification, handling it through DT:TZ:SystemV, and will accept
an absolute pathname to a tzfile, handling it through DT:TZ:Tzfile.
(Both of those modules are already indirect dependencies via DT:TZ:Olson.)
Olson names in $TZ are still handled by DT:TZ's own Olson facility,
rather than by looking for the OS's copy of it. Leading ":" in $TZ
is uniformly accepted, to match OS behaviour. Where $TZ is not set,
a system default tzfile in /etc/localtime will be used if available,
before (as previously) falling back to looking up a default $TZ value
in various places.
HP-UX now consistently has special handling. There's a static translation
table, descended from the old DT:TZ:HPUX distro, to convert HP-UX
timezone names to Olson names. Apart from that, SystemV-style timezone
specifications are now accepted in $TZ.
AIX now has special handling, based on documentation found on the web. It
can accept Olson names (new AIX) or SystemV-style timezone specifications
in $TZ, and there's a static translation table to interpret ruleless
SystemV-style strings that AIX specifically knows about (old AIX).
VMS looks in the same environment variables ass before, but will now
interpret them more according to Unix behaviour, as described above.
Windows does essentially the same job as before, translating native
Windows timezone names to Olson through a static table, but the logic
is now simpler. Previously DT:TZ:Local::Win32 would also accept an
Olson name in $ENV{TZ}, but that can't be authentic Windows behaviour,
so it's been dropped.
DT:TZ:Local::{hpux,Win32,VMS,Unix}
----------------------------------
These are no longer separate modules. Their functionality has been
rolled into DT:TZ:Local.
DT:TZ:OffsetOnly
----------------
The documentation now correctly describes the special behaviour for
zero offset.
DT:TZ:OlsonDB
-------------
Doesn't appear in the new distro. The facility to parse Olson source
is potentially still useful, so maybe this could be spun off into a
separate distro if anyone wants to play with it.
DT:TZ:UTC
---------
The constructor used to accept and ignore any arguments. Now it croaks
if any are supplied.
The documentation used to say that this timezone is not in the Olson
database, which is not true. The new documentation doesn't make this
false claim.
