On Thu, 5 Jun 2003, Sam Vilain wrote: > Your own words; > > themachine:~/src$ head DateTime-TimeZone-0.17/README > OVERVIEW > > The DateTime::TimeZone modules provide a Perl interface to the Olson > time zone database. Rather than using the database directly, we parse > the database files and turn them into a set of modules, one for each > time zone defined. This allows for various optimizations in doing > time zone calculations. This conversion is done with the script in > tools/parse_olson. > > The Olson time zone database is the best available source for world > themachine:~/src$
The optimizations I'm talking about there are that since the code is generated I can do stuff like calculate future offsets and make it a data structur in the generated code, rather than having to calculate them all on demand. > One question, is the olson database the same as the one delivered by > glibc (in theory or otherwise)? Yes, at least on my system. > > > the majority of the data from the installed Olson Database at run > > > time? > > I'm not sure they exist on all systems is the main problem. And they're > > in a binary format that isn't well documented. > > I see where you're coming from. It makes sense to distribute a sane > database, especially for Windows' sake, and probably at `Makefile.PL' > time, auto-sense the sanity of the system installed database, with a > command line option to override and skip the detection process. Patches welcome. But that'll be a big PITA to get it it working on all systems, plus the installed version might be very old, etc. > Surely the glibc sources have a struct definition somewhere that can > be used to build a Perl `unpack' string ? Actually, if anybody really is curious the tzcode tarball at ftp://elsie.nci.nih.gov/pub/ contains the code used to generate the zoneinfo database. > > > against the module. I really would like to remove my dependancy on > > > Date::Manip, but, really - 4.5MB? > > 4.5MB in a time when 80GB disks cost $80! Size is very low on my > > priority list. Correctness comes first, then ease of use, then speed, > > then lots of other stuff, then maybe size on disk. > > New 80GB disks may only cost $80, but cost of the installed physical > platter plays only a small part of the true cost of adding another 350 > inodes at 11k each to the core OS image. I'd rather download a 10k > binary package than a 400k one! > > You are right - it is a relatively small issue in this day and age, > but I still think that it consititutes a bug. It's definitely not a _bug_, since it works correctly and as advertised. It might be a liability, but it's a small one AFAIC. The amount of work that would be required to _not_ include all the generated time zone code would be significant, and just getting the code to this point was not easy. You'll notice that _no_ other Perl module, in the history of Perl modules, provided any sort of access to time zone information beyond saying "use POSIX::tzset". There's a reason for this, and it's not because the POSIX interface is sufficient ;) -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
