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. Best, Paul On 10/7/21 13:00, Tom Lane via tz wrote:
Philip Paeps via tz <tz@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 FreeBSD... 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