On Thu, 05 Jun 2003 07:06, you wrote: > So, just what are those "various optimizations in doing time zone > > calculations" ? OK, building indexes is fine, but can't you access > I'm not sure what you're referring to.
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$ One question, is the olson database the same as the one delivered by glibc (in theory or otherwise)? > > 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. This would give distribution vendors an easy path for shipping a binary package that has minimal duplication of data, and accesses the same database that all other applications on the system do. In this scenario, the packager can be relatively sure of the characteristics of the binary files, as you are building against a known binary libc package. Surely the glibc sources have a struct definition somewhere that can be used to build a Perl `unpack' string ? > > 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. -- Sam Vilain, [EMAIL PROTECTED] A closed mouth says nothing wrong; a closed mind does nothing right. - anon.
