[tz] Getting current tzdb version in use

Paul G paul at ganssle.io
Fri Jul 20 14:12:22 UTC 2018


You guys know this thread was not sent to the main list? Was that on purpose?

I will say that I agree about the churn - that's a good reason not to include the version in every zone file, but even if the version is interpreted as "this is based on XXXX", it would be very useful - particularly since the common case is that the version is accurate and any inaccurate versions would be a bug in the deployment *not* a bug in tzdb - you can't stop your downstream distributors from introducing bugs, but you can't avoid features just because someone might introduce a bug in them.

I can tell you a few places I've found need for the version:

1. I have some tests in my test suite that check certain edge cases, one of which is the international date line switch in Kiribati in 1994. Old versions have this happening on the wrong day, so when that changed, my test suite broke. Ideally I would write my tests like this (pseudocode):

if tzdata_version >= '2018d':
    transition_date = 1995-01-01
else:
    transition_date = 1994-12-30

I would be comfortable skipping this test on platforms that screw up the version information, since the version check has nothing to do with my real application.

2. It is useful to check the version to see if the system version is outdated when debugging, and in general as part of logging to provide maximum context when trying to find bugs later. If I'm digging through some old logs trying to figure out what happened and the log starts "tzdata version == 2014c; OS: Linux; Distribution: RHEL6" or something, I can see if there were any issues in tzdata version 2014c, and if RHEL has made any weird modifications to the system deployed tzdata.

3. It can be useful when you have the choice of more than one source for time zone data and want to try and ascertain which one is more recent and use that one. For example, my library dateutil ships an up-to-date version of the tz database (with version information), but will always choose the system-installed version if it exists. I would prefer it if instead I could check the system installed tzdata's version and the version of the tzdata I shipped and use whichever one is more recent (or give users the choice). Without shipped version information, this is not possible.

In all of these cases, I believe that *some* version information would be better than none, even if not all the complexity of what it means to be a "new version" is captured.

At this point, of course, I think the battle in the tz project is won - tzdata.zi exists and last I checked `make install` installs it into `/usr/share/zoneinfo`, so now it's time to get system distributors to make sure they include it in their distributions, I guess.

Best,
Paul

On 07/19/2018 07:40 PM, Paul Eggert wrote:
> Robert Elz wrote:
>> I have more than doubts, I am convinced that the entire thing is
>> misguided, and that (with the one exception of curiosity value,
>> the ability of an application to tell people which version data it
>> is using) there is no good use of  this data
> 
> Yes, that's the only good use I can think of as well. That is, the version string is more for diagnosing obsolete or misconfigured systems than for use in ordinary computation. That being said, configuration is of growing importance in software engineering, and I hope that the version comment in tzdata.zi is enough to satisfy needs in this area.
> 
> With TZDIST the version info is best done via ETags, and this should work with TZif files so that clients can easily see whether they're up-to-date and get a new version if not. See Internet RFC 7808 section 4.1.4 along with:
> 
> https://tools.ietf.org/html/draft-murchison-tzdist-tzif-09

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20180720/4ec9abcf/signature.asc>


More information about the tz mailing list