[tz] Getting current tzdb version in use

[Robert Elz]

    Date:        Fri, 20 Jul 2018 11:33:28 -0400
    From:        Paul G <paul at ganssle.io>
    Message-ID:  <f81b3a20-7f57-a214-c254-e8c1b190c38c at ganssle.io>

I think a lot of the disconnect here is summer up by this ...

  | but I think that once tzdata.zi is widely deployed, in 90%+ of cases
  | you won't go wrong by trusting the system version.

To me, that's entirely backwards, and completely wrong.   That is,
if it gets to 90% it will be bad, if it makes it to 95% it wil be worse,
and if it makes it to 99% it would be a disaster.

Not that there's anything wrong with the tzdata.zi file itself (and Paul,
the other Paul, I know what its purpose was - but saving a few bytes of
download time in an environment when half the world are streaming
movies (or porn) and the rest are trying to download kde or openoffice
just isn't an objective that matters.)

The issue is that unless you can guarantee 100% (and no-one is foolish
enough to claim that) relying on something that "almost always works"
or "works almost everywhere" (and then passing the buck when it
doesn't work ... "*they* should have fixed that!" )  is what leads to hard
to find and/or fix problems, things that fail so rarely that no-one cares
enough to actually fix them.   If it was just 30%, everyone would know
that this was a likely cause of problems, and what to do to to deal with
the issues.

To go back to the (one real) specific example ...


In a different message paul at ganssle.io said:
  | 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".

The problem is that this kind of thing works, sometimes...   In the example
in question, if you're in Europe, or the Americas, and barely have any idea
where Kiribati is, and don't much care what happens there (and quite
likely have no idea how to pronounce it) there is a fair chance this
strategy would work.    But if you're actually in Kiribati (or nearby) and care
about communication, and coordination, then you might find that quite a
lot of tzdata users knew about the problem, and had been patching it
locally to make the data be correct - in version after version of tzdata,
until it was eventually fixed in the tzdata distribution (recently).   If you
make the distinction just by looking at versions, your test will fail.   If you
do it properly (and tests are really a place where things should always be
done properly, a few seconds of performance really is irrelevant, but
bad results matter) then you will always get the right result.

Similarly ...

in the other message paul at ganssle.io also said:
  | 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.

Again, that's attempting to do it on the cheap, rather than do it properly.

The first issue is to discover whether the software supports a zone with
a time shift that goes backwards, rather than forwards (one that temporarily
sets the clocks backwards from the local notion of standard time.)

The (or a) way to do that is to configure a small "fake" timezone in exactly that
way  (write a very small zic input file) - run zic on it (and make sure that doesn't
fail first) and then use the result to test the software.    That way you find  out
for sure whether or not the software works, not depending upon being able to
guess which random piece of (possibly) installed standard data might happen
to be a good test.   

If the software doesn't support it, then there is no real point attempting to
perform further tests in this area, you have already detected a primary 
probllem.   If the software does all work correctly, then you can check zones
where this should be able to be observed, and see if it is or not.

But even if the "not" happens, you still don't know that the tzdata version is
old - you may have run into one of the cases where the local tzdata packager
is one of the people who believes that the "variant" period of the UTC offset
for a zone must always be a step forward from the "standard" version, and
has been patching the Dublin zone back to the old way "because everyone
knows that is how it really should be" - and distributing that to their users.

Lastly, for now anyway....

again iin the other message paul at ganssle.io said:
  | I want to write software and libraries independent of package managers. 

That's fine - mention of package managers was just because those are
one thing that does care about version numbers - but note it is their own
version numbers.   Those might be derived from, or even identical to, those
used by the source of the package, but to the package manager, it is its
own version number, that it maintains, and updates as needed.   The exact
same version number in a different distribution could mean something
totally different.

I totally agree that a test suite is not that (or should not be) nor will most
software or libraries be (the mythical long running airline system, that updates
itself, might be an exception).    The point is that for yor purpose you should
not be relying on (or even knowing about) version info.  It is the warong way.
The quick and easy simple way perhaps - but not the way that really works.

Just put in the work to do things correctly, long term, you will be happy that
you did.   Always test for what you need to know - exactly - never simply
assume that if X is detected, then (an unrelated) Y will also exist, just 
because that is what usually happens.

kre