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) ============================================================*/