[tz] Version in zoneinfo files?

John Haxby john.haxby at oracle.com
Sun Oct 25 17:10:31 UTC 2015


> On 25 Oct 2015, at 14:10, Paul G <paul at 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.
> 



More information about the tz mailing list