<div dir="ltr"><div>One odd possibility on standardizing access to version information: a zic'd line such as...</div><div>    Zone Version 0 - 2021c</div><div>...would allow use of the command...<br></div><div>   TZ=Version date</div><div>...to discover the version.-)<br></div><div><br></div><div>    @dashdashado<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 7, 2021 at 1:01 PM Tom Lane via tz <<a href="mailto:tz@iana.org">tz@iana.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Philip Paeps via tz <<a href="mailto:tz@iana.org" target="_blank">tz@iana.org</a>> writes:<br>
> This is looking terribly fragmented.  Spare a thought for a hypothetical <br>
> engineer tasked with debugging a Java application on Debian with some <br>
> Python scripts on Fedora talking to a PostgreSQL database running on <br>
> FreeBSD...<br>
<br>
BTW, that brings a thought to mind: why isn't there an easy way to<br>
identify the release version of an installed tzdata tree?<br>
<br>
I'm envisioning that there could be a text file at the top level,<br>
say /usr/share/zoneinfo/version in typical layouts, containing<br>
"2021a" or the appropriate string.  This'd make it a lot easier<br>
to diagnose what you've got in a particular installation.<br>
<br>
Some vendors (Red Hat at least) include the tzdata.zi file in<br>
/usr/share/zoneinfo.  I persuaded Paul awhile back to put a<br>
version comment at the top of that, so that provides a way to<br>
determine the version if your vendor did that.  But it seems<br>
like a mighty redundant approach.<br>
<br>
                        regards, tom lane<br>
</blockquote></div>