[tz] Version identification (was Re: Downstream use of 2021c)
paul.tz at ml.ganssle.io
Thu Oct 7 17:25:49 UTC 2021
I also think a better story for versioning in the binaries would be very
nice to have, though the fact that TZif is designed such that you can
have arbitrary TZif files generated from something other than TZDB and
the fact that people deploy forks makes things a lot more complicated.
For some context, previous discussions on this that I know about:
From 2015: https://mm.icann.org/pipermail/tz/2015-October/022807.html
(That thread gets fragmented, so looking at the "October 2015" view
might be best to see the whole thread)
From 2018: https://mm.icann.org/pipermail/tz/2018-July/026645.html
I'll note that IIRC the tzdata.zi file with version comment and the
`make version` file resulted from or at least came after that 2015
thread, and I've seen a lot wider adoption of shipping tzdata.zi, so
it's much easier to get the data version on most platforms today than it
has been in the past.
On 10/7/21 13:00, Tom Lane via tz wrote:
> Philip Paeps via tz <tz at iana.org> writes:
>> This is looking terribly fragmented. Spare a thought for a hypothetical
>> engineer tasked with debugging a Java application on Debian with some
>> Python scripts on Fedora talking to a PostgreSQL database running on
> BTW, that brings a thought to mind: why isn't there an easy way to
> identify the release version of an installed tzdata tree?
> I'm envisioning that there could be a text file at the top level,
> say /usr/share/zoneinfo/version in typical layouts, containing
> "2021a" or the appropriate string. This'd make it a lot easier
> to diagnose what you've got in a particular installation.
> Some vendors (Red Hat at least) include the tzdata.zi file in
> /usr/share/zoneinfo. I persuaded Paul awhile back to put a
> version comment at the top of that, so that provides a way to
> determine the version if your vendor did that. But it seems
> like a mighty redundant approach.
> regards, tom lane
More information about the tz