[tz] time keeps on slipping into the future
Paul Eggert
eggert at cs.ucla.edu
Sat Oct 15 08:23:10 UTC 2022
On 2022-10-14 14:05, Bradley White wrote:
> And the non-visibility of "the tests" means that we "downstream users" are
> never going to be as effective in catching problems as you might be
> expecting. We also can't contribute to the tests.
All the tests I use are in the standard distribution; they are neither
invisible nor secret, and you can contribute to them the same way you
can contribute to any other part of the distribution. Unfortunately,
writing patches to improve the tests is a boring and thankless task and
I expect few will want to do it.
> to handle old readers I need fat TZif files, and to handle new readers
> I need to avoid fat TZif files. That places folks who want to handle all
> readers in an untenable position.
This topic is discussed at some length in Internet RFC 8536 Appendix A.
You're correct that no single format will cater to every buggy TZif
reader for every possible timestamp. However, these problems are
inherent to the situation and has been true ever since TZif files were
introduced: the problems occurred with TZif files before slim files were
introduced, and I expect they'll occur with TZif files long after fat
files die out (assuming that ever happens).
By design, these compatibility problems and bugs have been rare in
practice. That being said, I do expect quite a few more bugs to shake
out around the year 2038, due to the large number of currently-produced
systems that continue to mishandle timestamps after 2038. So it'd be
helpful if we had a testing strategy that would help people discover and
report these bugs in other systems sooner than 15 years and 3 months
from now, when it'll be too late.
More information about the tz
mailing list