Bug 729763 - rubygem-tzinfo should use system-wide zoneinfo data
Summary: rubygem-tzinfo should use system-wide zoneinfo data
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rubygem-tzinfo
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Josef Stribny
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-10 18:40 UTC by Petr Machata
Modified: 2016-01-04 05:50 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-04-17 11:21:30 UTC


Attachments (Terms of Use)

Description Petr Machata 2011-08-10 18:40:46 UTC
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.

Comment 1 Vít Ondruch 2011-10-19 14:09:20 UTC
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

Comment 2 Vít Ondruch 2011-10-19 14:13:44 UTC
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.

Comment 3 Petr Machata 2011-10-19 17:36:13 UTC
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?

Comment 4 Vít Ondruch 2011-10-20 08:03:43 UTC
> 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

Comment 5 Petr Machata 2011-10-20 11:20:36 UTC
(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.

Comment 6 Subhendu Ghosh 2011-11-23 14:30:32 UTC
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/

Comment 7 Vít Ondruch 2011-11-23 16:22:01 UTC
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

Comment 8 Josef Stribny 2012-07-27 13:15:42 UTC
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

Comment 9 Josef Stribny 2012-08-08 09:08:53 UTC
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.

Comment 10 Petr Machata 2012-08-08 16:48:30 UTC
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.

Comment 11 Josef Stribny 2012-08-09 09:10:38 UTC
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).

Comment 12 Josef Stribny 2012-08-14 16:25:46 UTC
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

Comment 13 Fedora End Of Life 2013-04-03 17:58:00 UTC
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

Comment 14 Josef Stribny 2014-04-17 11:21:30 UTC
This is finally resolved with the latest update of tzinfo[1].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=917630


Note You need to log in before you can comment on or make changes to this bug.