[tz] Getting current tzdb version in use

Paul G paul at ganssle.io
Fri Jul 20 15:25:21 UTC 2018

> I just did a random check on mesages in my copies, and they all
> look to have been sent to tz at iana.org - what makes you think
> otherwise?  And what other list is there they could have been sent to?

Sorry, that was my mail client - it was only showing me the first 3 or 4 recipients. Sometimes people end up replying to specific people and not the list. Probably it's implausible that this would grab 5 people and not the list as one of them though. My fault.

>   | 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.
> The right way to test that is to check the translation of 1994-12-31
> in the Kiribati timezone, and see what UTC value you get.   That way,
> regardless of who fixed what, or when, or in what random patch to
> what version, you'll always find out what you should use.   To be even more
> flexible you could work through some times, in case some other random
> version had the transition listed at yet another point in time.

Yes, I heuristically do this, but in a test suite I prefer to minimize the amount of logic that relies on the thing I am testing. If I know that there was a change to a test case in a specific version, I can say, "Use the old test case if you see a version older than this, and use the new test case if you see a version newer than this", or "skip this test if the version is older than X".

Another case is the Europe/Dublin negative DST. I want to write a test that says, "Europe/Dublin should return negative DST in the winter", but that test only works with versions >= 2018e. There's no really good heuristic for that - if it doesn't return negative DST it's either that my version is too old or my implementation is wrong. Having a version number really helps distinguish between these two.

>   | 2. It is useful to check the version to see if the system version is outdated
> This is a package manager issue - and yes, software installers need to
> keep track of which versions are installed, or everything...

I want to write software and libraries independent of package managers. It's very common practice for software to have a method for querying the version using the conventions of the software itself for that very reason. System deployment details shouldn't be baked into my library, but "When I'm looking for time zone data, which of the many versions of the time zone data that is distributed do I have" is a very reasonable question to ask.

>   | 3. It can be useful when you have the choice of more than one source for
>   | time zone data
> Same thing.
>   | 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.
> We have that now, and ave for some time (and on NetBSD, before the
> version file appeared in txdata, we had a TZDATA_VERSION which
> served the same purpose ... we still do...)
>   | 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.
> Which we don't in NetBSD, that file adds no value for us.

If there were *any* standard way to query the version of the data independent of platform (as there is for accessing *all* other data about the zone info mind you - I don't see why metadata should be different), I would be happy. Given that those of us providing libraries accessing this data want the information, and the people consuming our libraries want the information, I would say that it doesn't add *no value* for NetBSD - using the standard scheme for marking the version means it's easier to write cross-platform software that includes NetBSD.

-------------- 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/cbff95af/signature.asc>

More information about the tz mailing list