Ken, Thanks for the quick reply.
On Sat, Nov 01, 2008 at 07:48:12PM -0500, Chanoch (Ken) Bloom wrote: > The build process for the tzdata package involves running zic > (included in libc6) on a collection of text source files downloaded > from upstream, and included in the tzdata source package (but not the > binary package). This creates the binary files in /usr/share/zoneinfo > > libtzinfo-ruby has a script in lib/tzinfo/tzdataparser.rb that parses > the same text source files, and regenerates the ruby scripts in > libtzinfo-ruby. Perhaps the easiest way to fix this for lenny is to > convince the tzdata maintainer to install the text source files as > well (either in tzdata or a separate package), and then use those at > install time to generate brand new ruby versions. Then to deal with > updates, set up a dpkg trigger that regenerates the ruby files when > the text sources are updated. > The libtzinfo-ruby was only recently passed through NEW. Since it just entered Sid (and we are months into the freeze), we are not pressured by trying to figure something out in time for a Lenny release. > Alternatively, one could port the /usr/share/zoneinfo parser > from ruby-tzfile and integrate it into libtzinfo-ruby, with a > fallback to the embedded ruby files if /usr/share/zoneinfo doesn't > exist (e.g. a non-Linux system, so that this port could be included > upstream). I spent some time on Friday trying my hand at such a port, > but I have no idea how to integrate it properly, and I have noticed > that some of the information in the ruby scripts (specifically the > difference between "the current timezone rules" and "standard time") > is not derivable at all from the data in /usr/share/zoneinfo > I think that such a fallback would be a good approach. From the perspective of Debian, I can simply write a repack.sh script that strips out those zone data sources from the upstream tarball. This would be OK for the Debian (and its derivative's) package since we can guarantee the presence of /usr/share/zoneinfo. > libtzinfo-ruby and ruby-tzdata have different enough interfaces that I > doubt it will be feasible (or desirable) to port rails to use > ruby-tzfile. > > ruby-tzfile creates its own completely different (incompatible) set of > time objects from Ruby's builtin. Mathematical operations on > ruby-tzdata objects are specified in seconds, while mathematical > operations on Ruby's built-in time objects are specified in days. > > libtzinfo-ruby performs conversion on Ruby's built-in Time objects. > > Also, ruby-tzfile has not been updated in over a year. > I figured that they were different, but that it couldn't hurt to consider it as an option. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
signature.asc
Description: Digital signature
