On Sat, 18 Jan 2003, Jesse wrote: > So. Where I left the Date::ICal::Timezone stuff was that I couldn't get > it to work properly with flavio's then-latest Date::Set stuff. Before > that, I had it basically working, but too slow to be at all usable in > real-world code. Autrijus Tang recently pointed me at:
I don't think it needs to be terribly fast, since we only need to calculate an offset when an object is created or modified. I did have an implementation idea that might be faster, which is to represent the observances as a red-black tree where node keys, instead of single numbers, are ranges (start & end). The right-most node would have a range of [ $start, undef ], and if that node is reached, new nodes could be generated until the given datetime fits in one of them. Same for the left-most node. > http://search.cpan.org/author/SCHOP/Geography-Country-Utils-1.05/ ENODOCS! Yeesh, a CPAN release with literally not a freaking line of POD. Nice. > which seems to contain a much more pragmatic timezone module. IE it > handles all current, but not all historical timezones. And it looks like > it does it without a lot of upsettingly complex math. At this point, I'd > probably be inclined to adopt the code from > Geography::Country::Utils::TZ. I know that it's currently maintained, > due to the untimely death of the author and that Autrijus is one of > several parties who's applied to take over the module proper. FWIW, it _does_ seem to include historical data. In fact, it has the whole damn (or most of) the Olson DB in its __DATA__ section! I'm not too impressed by the code, but it might help in implementing an Olson DB parser. I really think that you were on a better track in terms of organization (catalog, individual zones as modules, etc.), regardless of implementation problems. The implementation can be reworked as needed, but the design you had is much closer to what I want than the G::C::U stuff. If performance is an issue we could have a code generator that used the Olson DB parser and generated custom code for each TZ that could take something like '19020203T12:12:43' (GMT) and simply care it to a bunch of pre-determined dates and times, in a range specified when the time zone module is loaded, with other datetimes handled by applying recurrence rules. Or we could have an XS implementation. Heck, we could have a generated XS implementation! -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
