Bug 729763
| Summary: | rubygem-tzinfo should use system-wide zoneinfo data | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Petr Machata <pmachata> |
| Component: | rubygem-tzinfo | Assignee: | Josef Stribny <jstribny> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | hhorak, jstribny, mnewsome, sghosh, vondruch |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-04-17 11:21:30 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Hello, Unfortunately this is how the tzinfo is designed. The data are taken from tz database and converted int Ruby classes. They are not working with system-wide zone informations. If you which this feature, it would be good to open upstream ticket. Actually there are already two similar tickets opened [1, 2], but they seems to be stalled for 5 years already. But it might be good idea for some student's project? [1] http://rubyforge.org/tracker/index.php?func=detail&aid=4148&group_id=894&atid=3528 [2] http://rubyforge.org/tracker/index.php?func=detail&aid=6522&group_id=894&atid=3528 Once I sent the response, I realized, that it will never work, since it is expected that the upstream is releasing the new versions as soon as the tz database is updated. So it would look like we are providing obsolete version of gem, although the data are always up-to-date. It would need to be replaced by some other project. I know this is how it is designed, and I'm claiming that for Fedora, the design is not a good fit. We already have one source of zoneinfo information, updated in a timely manner, and that is the tzdata package. Duplicating that effort is a waste, and of course that effort never really is expended to begin with, and the package ends up out of date. Everything else should be built either together with tzdata (like tzdata-java is, for example), or should consume system-wide zoneinfo files (like python-dateutil and pytz do). Replacing the gem won't do, unless the prospective replacement has the same API. The easiest way of achieving that is patching TZInfo. FWIW, the classes for individual zones are not meant to be user-visible (per http://tzinfo.rubyforge.org/doc/), they are merely data containers. Couldn't we simply generate them on the fly? > Replacing the gem won't do, unless the prospective replacement has the same > API. Keep the same API should not be problem I guess. Other possible way is to keep everything as it is just split the data into separate gem and provide some other plugable data sources, as is suggested by [1] > The easiest way of achieving that is patching TZInfo. This would be huge difference from upstream, so unless we are able to push this change into the upstream, it does not work for me. I'll keep it open and let's try to find somebody who will hack it together and push upstream :) [1] http://rubyforge.org/tracker/index.php?func=detail&aid=4148&group_id=894&atid=3528 (In reply to comment #4) > > Replacing the gem won't do, unless the prospective replacement has the same > > API. > > Keep the same API should not be problem I guess. Other possible way is to keep > everything as it is just split the data into separate gem and provide some > other plugable data sources, as is suggested by [1] Splitting the data won't help, because you would still have two packages to worry about. I like [2] from your previous post better. Upstream might be even willing to merge this. Then again, I don't know. Their raison d'etre is system-independent tzdata. Making it source-independent might be accepted, but it might also be viewed as an unnecessary complication. I commented on the upstream bug that you listed as [2]. Let's see where this gets us. > > The easiest way of achieving that is patching TZInfo. > > This would be huge difference from upstream, so unless we are able to push > this change into the upstream, it does not work for me. Yeah, but upstream is unreasonable from the viewpoint of Fedora (or RHEL, for that matter). It might turn out that they are just not interested in this kind of work. I'm all for merging things upstream, but if this somehow doesn't go through, then we will have to consider patching this ourselves. Frankly, I don't suppose it would be that big of a deal. Anyway, let's see if they respond to my post. Has anyone looked at tzfile instead of tzinfo ? http://www.a-k-r.org/ruby-tzfile/ It's supposed to look at the system tzdata as noted on http://tzinfo.rubyforge.org/ tzfile cannot replace tzinfo, since * tzinfo is dependency of ActiveSupport * which in turn is part of RubyOnRails * and they are platform independent * whereas tzfile is not. tzfile might be used as a source for tzinfo but somebody has to implement it. If you read this issue carefully, you could see that there is already open tzinfo upstream ticket [1] and upstream is open to patches which will use the tzdata if available. Now it is just a question who will get this done. [1] http://rubyforge.org/tracker/index.php?func=detail&aid=6522&group_id=894&atid=3528 I opened a new ticket at RubyForge to discuss it with Philip Ross: http://rubyforge.org/tracker/index.php?func=detail&aid=29620&group_id=894&atid=3525 Petr Machata: If you have time, please have a look on https://github.com/strzibny/tzinfo, which contains last version that prefers zoneinfo db and uses Ruby modules only when zoneinfo is not present. You can try it and help me to test it. This seems to work, thank you. I didn't realize that a zoneinfo reader was already present in the project, I guess that could have simplified some of our initial conversation. Note I only tried the reported use case, I didn't try to dig inside much. I'm not myself user of this gem. Thanks Petr, I am working on a separate gem for Ruby timezone data now (those in /definitions and /indexes) and waiting for comments from Phillip Ross on the code (he replied by email that he doesn't have time right now, but will look at it as soon as possible). I have finished separating tzinfo into tzinfo [1] and tzinfo-data [2]. More on this at RubyForge [3]. Comments and tests are welcome. [1] https://github.com/strzibny/tzinfo [2] https://github.com/strzibny/tzinfo-data [3] http://rubyforge.org/tracker/index.php?func=detail&aid=29620&group_id=894&atid=3525 This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19 This is finally resolved with the latest update of tzinfo[1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=917630 |
Description of problem: Inlining the zoneinfo data into ruby files, and distributing them, is rather unfortunate. We distribute separate, canonical copy of zoneinfo data, in the package tzdata. This package is updated about 20 times a year. Unless you go through hoops of re-packaging rubygem-tzinfo every time there's a tzdata update, rubygem-tzinfo will be out of date. If you do go through these hoops, rubygem-tzinfo will merely waste space and needlessly duplicate effort. I know very little ruby, so I won't be of much help myself, but I would like to propose that some sort of mechanism is implemented whereby rubygem-tzinfo uses system-installed zoneinfo data files. This could be reasonably easy if TZInfo::Timezone.get is the sole interface to the system. If the classes themselves are part of the interface, then this is presumably a bigger problem. Version-Release number of selected component (if applicable): 0.3.26 How reproducible: Always. Steps to Reproduce: > su - # cp /usr/share/zoneinfo/Europe/Prague /usr/share/zoneinfo/Europe/Myzone # TZ="Europe/Myzone" date +%Z CEST # ruby require 'rubygems' require 'tzinfo' tz = TZInfo::Timezone.get('Europe/Myzone') /usr/lib/ruby/gems/1.8/gems/tzinfo-0.3.26/lib/tzinfo/timezone.rb:105:in `get': no such file to load -- tzinfo/definitions/Europe/Myzone (TZInfo::InvalidTimezoneIdentifier) from -:3 Actual results: rubygem-tzinfo fails to see the new zone. Expected results: rubygem-tzinfo is able to work with the zone that was introduced after it was compiled. Additional info: I recognize that rubygem-tzinfo claims its independence of system-wide zoneinfo for an advantage. I understand that for some installations, this is indeed the desired behavior. But it should be possible to use system-wide zoneinfo data in preference to own data.