[tz] time keeps on slipping into the future

[Paul Eggert]

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.