On Jan 24, 2018, at 4:36 PM, Paul G <paul@ganssle.io> wrote:
All this hubbub about the negative SAVE values in the tzdb source code makes it pretty obvious that downstream consumers are making some assumptions about undocumented features of the tzdb code. I'm wondering if it might be worth it to add a new region that contains fictional time zones that have properties that are perfectly valid but are edge cases that might be improperly handled downstream. It's probably a good idea to have this sort of thing in place *before* some region makes a change that actually violates one of these assumptions.
A few example test cases I can think of (but I assume others will have *many* other ideas):
- Zone with negative DST - Zone with large DST offset and/or large standard offset - Zone with 3, 4 or 5 offsets per year - Zone which goes from STD->DST with no change in offset. - Zone with new rules that don't take place until after 2038 - Zone with arbitrary DST offsets (10m15s, for example) - Zone that corresponds to TAI (e.g. offsets change to compensate for leap seconds)
Downstream consumers could then use this in their test suites and be effectively "on notice" that they should be able to handle these sorts of cases, even though we have no examples of them existing in the wild (though there's actually some case to be made for interpreting TAI as a time zone, in which case that one *does* exist in the wild).
There is some precedent for this sort of thing in the GREASE mechanism for testing TLS extensibility ( https://tools.ietf.org/html/draft-ietf-tls-grease-00 ), which provides some mechanism for testing whether TLS implementations will break if some arbitrary extensions are added.
To be effective it would need to come with something like this: https://nodatime.github.io/tzvalidate/ Howard