On Sat, 15 Nov 2003, Rick Measham wrote: > 1. Create DateTime::TimeZone::Lite. > - This would return a subset of the Olson data that assumed the current > rules extend infinitely in both directions. > - This would not be a prereq, or be installed by DateTime itself. > - I suggest we might make this assumption on the grounds that we already > make a similar assumption with DateTime: The Gregorian Calendar wasn't > used back at the year 0, but DateTime assumes it does.
I'm really not sure how useful this is. Imagine you start using this now, then next year some time zone changes it's rules, so you install the latest version. Now all the year-old data is using the new rules, meaning that you end up with bogus conversions. If this were a calendaring app, that'd mean that old entries might suddenly become an hour off for nor apparent reason. > 2. Create DateTime::TimeZone::Olson::XS > - The Olson Database is already an open-source, free distributable C > library, would we not save considerable space/memory by creating an XS > interface to the library? No it's not, actually. It's an open-source freely distributable set of a data and a few C programs. The interpretation is up to each system's core library. On Unix boxes, that means libc. Also, this would be limited to using epoch values, which means 32 bit ints. Avoiding this has always ben one of the main goals of the DateTime project! I think an XS implementation of the current API/code would be a much more useful thing. As I said, I'd like to implement it but I'm a bit short on tuits. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
