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