Zefram wrote:
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.
It sounds like what might be simplest is to:
A) Have DT::TZ be a wrapper around DT::TZ::Tzfile
B) Have DT::TZ ship with (or download) v2 Olson data
C) Write special case .pm files for the special cases
How big is the compiled Olson data?
Do all those individual time zone .pm files have to be preserved for backwards
compat? ie. Does "use DateTime::TimeZone::Africa::Addis_Ababa" have to work?
It would be nice if they could be totally removed. Their existence doesn't
appear to be documented in DT::TZ.
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.
That sounds like the objection was when it would be in addition to DT::TZ and
just to get support to read the Olsen files. If this is replacing the guts of
DT::TZ that seems a different matter. Dave?
--
emacs -- THAT'S NO EDITOR... IT'S AN OPERATING SYSTEM!
