Feature Requests: Browse | Submit New | Admin
It would be nice to be able to offer the option of storing the timezone and country data in different formats (e.g. Ruby module files, SQL database, ActiveRecord, binary zoneinfo files on the system). The different data storage facilities could be provided by separate gems that plug in to tzinfo.
Add A Comment:
Date: 2013-06-02 17:30 Sender: Philip Ross TZInfo v1.0.0 has introduced an interface to allow timezone data to be loaded from different sources. Included with v1.0.0 are DataSources that support loading from the existing Ruby data module files as well as from binary zoneinfo files on the system.
Date: 2011-10-26 22:24 Sender: Philip Ross Hi Petr, Yes I'd be happy to discuss and am willing to merge a patch that adds support for using the system zoneinfo files. This has been high up on the list of changes I'd like to make for some time, but I've been busy with some other projects. The maintainers of the Debian ruby-tzinfo package are also interested in the same thing (see bug #503591 - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503591). During the discussion on the Debian bug, I wrote a quick hacky patch that makes TZInfo use zoneinfo files as the data source. I’ve attached the patch here as tzinfo_zoneinfo_hack.diff. This patch only deals with data for the timezones - country information is still read from the built-in Ruby modules. My ideal solution would be to separate the current TZInfo package into an API package (tzinfo-api) and a Ruby data modules package (tzinfo-data). This would allow users to either install both tzinfo-api and tzinfo-data and use the Ruby data modules or just install tzinfo-api and use the zoneinfo files from their system. It would also mean that the two packages could be versioned independently, which would be helpful as most of the releases are solely data updates. Kind regards, Phil
Date: 2011-10-20 10:45 Sender: Petr Machata If someone were to write a patch implementing this mechanism, would you (the maintainer(s) of this gem) be willing to merge it? Or discuss it? Or is this viewed as an unnecessary complication and would be rejected anyway? As a bit of a background, as the tzdata maintainer for Fedora and RHEL, I'm trying to consolidate all the zoneinfo sources. I understand the desire of TZInfo to be independent from the system. However, in a typical Linux distributions, system-wide zoneinfo is updated frequently and kept up to date. The same often cannot be said about other zoneinfo providers, such as TZInfo. The mechanism described in the OP would allow us to keep TZInfo up-to-date automatically, and would make TZInfo a better fit in a typical Linux ecosystem.
