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.