Bug 1124415 - RFE: expose tzdata version in filesystem
Summary: RFE: expose tzdata version in filesystem
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: tzdata
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Patsy Franklin
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 12:48 UTC by Joe Orton
Modified: 2016-05-06 16:03 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-06 16:03:06 UTC


Attachments (Terms of Use)

Description Joe Orton 2014-07-29 12:48:21 UTC
Description of problem:
First some background:  PHP upstream ships a copy of the Olson database in binary format internally.  It also allows users to install a new PHP extension which overrides that (and hence update to a newer version of the database).

We modify PHP to use the database provided by tzdata by default, but we still allow extensions to override it.

A problem is that users cannot easily identify which *version* of the timezone database is present, with our patch, so some users naively still think they need to install the extension to get the latest timezone database.

What we'd like is a file provided somewhere by tzdata which contains simply the version string e.g. 

echo %{version} > /usr/share/zoneinfo/.version

then we can parse that file and expose the version at run-time.  We don't care about the location or format of the file. 

Version-Release number of selected component (if applicable):
tzdata-2014e.1

Comment 1 Joe Orton 2014-07-29 12:49:25 UTC
A special comment in zone.tab would be fine too, since we parse that anyway.

Comment 2 Joe Orton 2014-07-29 14:13:11 UTC
It's also been suggested this might be useful to push upstream so other users can benefit.

Comment 3 Petr Machata 2014-07-30 12:20:34 UTC
(In reply to Joe Orton from comment #0)
> What we'd like is a file provided somewhere by tzdata which contains simply
> the version string e.g. 
> 
> echo %{version} > /usr/share/zoneinfo/.version
> then we can parse that file and expose the version at run-time.  We don't
> care about the location or format of the file. 

So, I'm kinda hazy on how a typical use case would look like.  Would the PHP modules in question actually care about this?  Or would they have to learn about this?  Couldn't they similarly learn to just rely on Red Hat to provide latest greatest in a timely fashion?  Or is the ultimate consumer of this interface a human?

Besides, we fairly often ship "impure" versions.  E.g. our 2013b-2 actually packaged relevant changes from tzdata 2013c.  The last time this happened was with 2014b.  It could conceivably happen that a -1 release actually does so as well, simply because we would rebase to the latest version, which wasn't released before, and would add a patch on top of that from a nascent new version.  Which is to say that there's more to NVR than meets the eye, not to speak of V by itself.  I'm somewhat reluctant to formalize this all in any sort of API.

Also, there's rpm -q tzdata, or rpm -q --changelog tzdata if a prose telling you what's actually inside is what you are after.

Comment 4 Petr Machata 2014-07-30 12:21:36 UTC
Eh, I talk about Red Hat in the above, but the same bunch of people (really, Patsy, as of late) takes care of Fedora releases.

Comment 5 Joe Orton 2014-07-30 12:45:29 UTC
PHP exposes the timezone db version via the "phpinfo" page which tells a human consumer the version of all the components used by PHP.   At the moment, people get our placeholder string of "0.system" for the version, which we use instead of the "real" tzdata version.

So e.g. exchanges like this result:

http://stackoverflow.com/questions/5776392/incomplete-list-of-timezones-generated-by-php

where people are encouraged to install the PHP extension rather than update their tzdata package.

The idea is that we can expose the "real" version of the underlying Olson db here instead, and that will both: a) reduce confusion, and b) ensure users do actually get the latest bits.

e.g. in the case where a user installs the PHP extension providing 2013a, and the system has 2013b, then 2013a will get used because we don't know any better.

The "impurity" issue is not a concern for us though I appreciate what you are saying there; having the baseline Olson db version is just fine.

Comment 6 Petr Machata 2014-07-30 13:52:18 UTC
Sad.  And all that because someone tries to list all zoneinfo identifiers, which shouldn't be necessary in the first place.  Browsing stackoverflow, there's a fair amount of misconception around tzdata.  Ho hum.

Could we maybe export a URL with explanation on that info page?  Or maybe ${year}.system?

Comment 7 Joe Orton 2014-07-31 07:28:12 UTC
It's not necessarily *just* about listing all the ids, though that does seem to be strangely common, maybe for those timezone selection drop-down boxes...

Yes, we should definitely still decorate the version (and/or the phpinfo output), to make show it obvious that is coming from the system tzdata at least to informed users.  ${year}.system is a good idea.

There are also people on SO giving correct advice that for the special "0.system" version, the right solution is "yum update tzdata", which is actually really nice to see.

Sticking a URL in there is also an interesting idea, though Debian et al use our patch as-is so I wouldn't want to stick a Fedora-specific URL in there.


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