Hide Forgot
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
A special comment in zone.tab would be fine too, since we parse that anyway.
It's also been suggested this might be useful to push upstream so other users can benefit.
(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.
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.
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.
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?
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.