On Thu, 17 Dec 2009, Zefram wrote:
Almost. In principle, the DT:TZ way of working handles far future dates
slightly better.
I'd actually say this doesn't matter. Look at how often time zone
definitions change. Looking at America/Chicago, I see changes in 1974,
1975, 1976, 1987, and 2007. That tells me that I should not count on
_anything_ being the same 30+ years from now.
And the US is stable compared to some places.
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.
I don't think you need auto-downloads. People download a new DT::TZ when I
release one, or they don't. No one's complained about that.
The real question for me is whether the generated binary data will be
cross-platform compatible. Are there any 32/64 bit issues? Endianness?
As long as they are cross-platform and the files can be distributed via
CPAN, I think switching to this approach would be fine.
No one (that I recall) has asked for Posix or binary file support,
so making them dependencies seems like overkill.
Regarding asking for binary file support, I meant no one seemed to care
about using their existing binary files.
If DT::TZ depended on DT::TZ::OlsonData that would be fine.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
