Michael G Schwern wrote:
>That looks like a great place to start. If it matches the DT::TZ
>interface, and shipped a default time zone database, could DT::TZ simply
>be replaced with it?
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
DT:TZ:Tzfile can only work from what's in the compiled tzfile.
When the explicitly-listed observances run out (typically at 2038),
the tzfile can only express future rules by means of a SystemV-style
$TZ string. For most zones this is perfectly adequate: for example, my
Debian-supplied copy of Europe/London says "GMT0BST,M3.5.0/1,M10.5.0",
which accurately expresses the rule laid down by the Summer Time Order
2002. DT:TZ:Tzfile passes this string on to DT:TZ:SystemV, which does
the work, and it's really DT:TZ:SystemV which is responsible for there
being no silly delay for linear calculation.
A handful of zones' rules cannot be adequately described in the System
V style. For example, America/Santiago starts DST on whichever Sunday
falls between October 9 and October 15, and has a similar rule for
ending DST. This is properly described in the Olson tzdata source file,
but because it can't be expressed in System V style it can't be described
by a compiled tzfile.
DT:TZ isn't limited by the tzfile format, because it works from the
tzdata source. In the case of America/Santiago, it can therefore
give correct answers for future years where the tzfile says nothing
and so DT:TZ:Tzfile is forced to give up. (My copy of the compiled
America/Santiago has explicitly-listed observances out to 2409, instead
of the usual 2038, presumably to compensate for this limitation.)
There are also some rules that DT:TZ won't handle correctly. For example,
Asia/Jerusalem uses a DST-ending rule that is based on the Jewish
calendar. Not only can this not be expressed in System V style, it
can't be expressed in tzdata source either. Whoever wrote the tzdata
source has included an explicit list of ending dates, up to 2037, and
both DT:TZ and DT:TZ:Tzfile are limited to that list. (However, while
DT:TZ:Tzfile recognises that its knowledge has run out, DT:TZ incorrectly
extends the last indicated observance into the infinite future.)
These issues affect about ten zones in the current Olson database
(depending on how you count them). In principle you'd get better results
by using the DT:TZ approach and just implementing it in a less dippy way.
But the difference in results is not very much, and it's probably easier
to get a working implementation from DT:TZ:Tzfile. It'd also avoid the
need for those enormous DateTime/TimeZone/$a/$b.pm files.
To get a full DT:TZ-like service from DT:TZ:Tzfile, you need a layer or
two over it. I don't want to bundle the Olson files with DT:TZ:Tzfile
itself: the module is for the single job of interpreting existing tzfiles.
But it'd be easy to produce a module that encapsulates a full set of
compiled tzfiles from Olson. Slightly harder to produce a cleverer module
that automatically downloads the latest tzdata. A module layered over
that could then use the tzfiles together with DT:TZ:Tzfile to provide
the full Olson timezone service. And DT:TZ can then be reimplemented
to use *that* as the basis for the geographic timezones.
Dave Rolsky has previously objected to the idea of the default-installed
DT:TZ depend on DT:TZ:Tzfile or DT:TZ:SystemV. He said in
<mid:pine.lnx.4.64.0702180928510.1...@urth.org>:
No one (that I recall) has asked for Posix or binary file support,
so making them dependencies seems like overkill.
I'm happy to implement more timezone logic on top of DT:TZ:Tzfile, up
to a complete drop-in DT:TZ replacement, but you'll have to argue with
Dave about actually replacing the existing DT:TZ.
-zefram
