Version in zoneinfo files?
My understanding is that while the release version e.g. 2014i, etc, is in the tzdata makefile, the binary output by zoneinfo does not have any sort of metadata included. Is this accurate? Is there any way to tell from the zoneinfo output what version was used to generate it? If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output. Otherwise you end up having to bundle your own metadata file along with the zoneinfo (which means that two applications that both consume zic output may each have to bundle their own binary, which can cause problems as two applications with different release cycles go out of sync from one another).
Paul G wrote:
If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output.
Although there is a version number in those files, it's not what you're looking for: it's the version number of the zic format (a number that changes only very slowly), not the tzdata version number. There's no provision in the current zic format for storing an arbitrary tzdata version number like '2015g'. Perhaps we could add one, but there would be a downside: people might take strings like '2015g' too seriously, and assume that two files from different sources labeled '2015g' would be identical (an assumption that would not be true). This downside has made me reluctant to change the zic format in this area.
Why would there be two files labeled 2015g? You mean in the even that someone modified the IANA tzfile before running it through zic? I think if you make it so the included version number comes from the makefile, people could be made aware that they should modify their versioning if they are worried about this occurrence. In my mind, as long as the default case (pulling IANA tzdata down and running it through zic) produces something reliably versioned, the feature would be more useful than not. That said, as an alternative, maybe the METADATA file could also include a version and a CRC-32 or an MD5 of the tzdata input, as an additional check for people who want to know that the inputs were actually the same. This might be overkill, though, because I don't totally understand the use case where multiple tzdata files are floating around with the same release number. On 10/25/2015 03:13 AM, Paul Eggert wrote:
Paul G wrote:
If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output.
Although there is a version number in those files, it's not what you're looking for: it's the version number of the zic format (a number that changes only very slowly), not the tzdata version number. There's no provision in the current zic format for storing an arbitrary tzdata version number like '2015g'. Perhaps we could add one, but there would be a downside: people might take strings like '2015g' too seriously, and assume that two files from different sources labeled '2015g' would be identical (an assumption that would not be true). This downside has made me reluctant to change the zic format in this area.
On 25 Oct 2015, at 14:10, Paul G <paul@ganssle.io> wrote:
Why would there be two files labeled 2015g? You mean in the even that someone modified the IANA tzfile before running it through zic? I think if you make it so the included version number comes from the makefile, people could be made aware that they should modify their versioning if they are worried about this occurrence. In my mind, as long as the default case (pulling IANA tzdata down and running it through zic) produces something reliably versioned, the feature would be more useful than not.
That said, as an alternative, maybe the METADATA file could also include a version and a CRC-32 or an MD5 of the tzdata input, as an additional check for people who want to know that the inputs were actually the same. This might be overkill, though, because I don't totally understand the use case where multiple tzdata files are floating around with the same release number.
Downstream providers sometimes choose to ship an unofficial patch early. There have been a few RHEL/CentOS/OL updates like this. If there was a version string embedded in some file it would usually be left alone. (For example, “ls --version” shows a particular version and it’s not updated with patches applied downstream, this sometimes confuses people.) I think, as Paul E suggests, keeping the version external is a good choice here. It encourages people to use whatever the platform provides to find out the exact, local version information. If anyone knows how to find out what version of tzdata is installed on this macbook I’d love to know :) jch
On 10/25/2015 03:13 AM, Paul Eggert wrote:
Paul G wrote:
If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output.
Although there is a version number in those files, it's not what you're looking for: it's the version number of the zic format (a number that changes only very slowly), not the tzdata version number. There's no provision in the current zic format for storing an arbitrary tzdata version number like '2015g'. Perhaps we could add one, but there would be a downside: people might take strings like '2015g' too seriously, and assume that two files from different sources labeled '2015g' would be identical (an assumption that would not be true). This downside has made me reluctant to change the zic format in this area.
On 10/25/2015 01:10 PM, John Haxby wrote:
Downstream providers sometimes choose to ship an unofficial patch early. There have been a few RHEL/CentOS/OL updates like this. If there was a version string embedded in some file it would usually be left alone. (For example, “ls --version” shows a particular version and it’s not updated with patches applied downstream, this sometimes confuses people.)
Thank you for this clarification! I suspect that this is a problem with all versioned software, and it's generally solved either by versioning that includes a build number or a "buyer beware" attitude. That said, if it's really worrisome, the first patch of any new release cycle could be to change the version number to something like '2015g-unstable' or '2015g-rc', which is only changed to '2015g' as part of the final release process.
I think, as Paul E suggests, keeping the version external is a good choice here. It encourages people to use whatever the platform provides to find out the exact, local version information. If anyone knows how to find out what version of tzdata is installed on this macbook I’d love to know :)
I think this perfectly illustrates the reason why the versioning should be at the zic level and not downstream. If every downstream provider is implementing the versioning in a different way, unless you ship your own version of the built zoneinfo file with your application, there's no reliable way to get the version information in a cross-platform way. This is a problem for organizations where timezone data is critical but with a large architecture - in those cases, it's often best to have all consumers of zoneinfo files point to the same binaries (this way you don't have to redeploy every zoneinfo consumer on every tzdata update), in which case everyone has to standardize on one way to store the zoneinfo metadata anyway, or you're going to get a proliferation of different types of metadata you have to store along with zoneinfo.
On 10/25/2015 03:13 AM, Paul Eggert wrote:
Paul G wrote:
If not, I would like to suggest that a VERSION or METADATA file be added to the zoneinfo output.
Although there is a version number in those files, it's not what you're looking for: it's the version number of the zic format (a number that changes only very slowly), not the tzdata version number. There's no provision in the current zic format for storing an arbitrary tzdata version number like '2015g'. Perhaps we could add one, but there would be a downside: people might take strings like '2015g' too seriously, and assume that two files from different sources labeled '2015g' would be identical (an assumption that would not be true). This downside has made me reluctant to change the zic format in this area.
On Oct 25, 2015, at 10:26 AM, Paul G <paul@ganssle.io> wrote:
I think this perfectly illustrates the reason why the versioning should be at the zic level and not downstream. If every downstream provider is implementing the versioning in a different way, unless you ship your own version of the built zoneinfo file with your application, there's no reliable way to get the version information in a cross-platform way.
So where would zic get the version information to put into the binary files?
On 25 October 2015 at 13:26, Paul G <paul@ganssle.io> wrote:
I think, as Paul E suggests, keeping the version external is a good choice here. It encourages people to use whatever the platform provides to find out the exact, local version information. If anyone knows how to find out what version of tzdata is installed on this macbook I’d love to know :)
I think this perfectly illustrates the reason why the versioning should be at the zic level and not downstream.
There's also the separate matter that tzcode and tzdata are separate and largely independent. Although there have been a few breaking changes to the data format over the years, in principle, there's little reason someone couldn't use a 2014j zic to compile 2015g data, and I suspect that sort of thing actually happens somewhat often. -- Tim Parenti
participants (5)
-
Guy Harris -
John Haxby -
Paul Eggert -
Paul G -
Tim Parenti