[tz] Adding a "test" region?
philip at trouble.is
Wed Jan 24 22:30:45 UTC 2018
On 2018-01-24 23:22:19 (+0100), Philip Paeps wrote:
>On 2018-01-24 16:36:45 (-0500), Paul G 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
>>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)
>I think this is an excellent idea. But it should be a very obviously
>fictional region -- obvious enough even to end consumers that it can
>be distributed default enabled and not hidden behind a build-time knob
>nobody will ever touch. So it should not look like a test to the
>casual lazy distributor who doesn't want to distribute test code.
>It can be Utopia too. It can be anything other than "Test". People
>will just disable "Test" and not distribute it.
>>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).
>If it's going to be surrounded by "test" fences, nobody is every going
>to actually test it. If we make it obviously fictional, it can be on
>by default an distributed with the rest of the data.
Come to think of it - it may be wiser to make it a subregion rather than
a new region. Possibly under Arctic since there's only one zone there
with a population of well under 10,000 humans.
Rationale: systems may get confused if the top-level regions increase
but are likely already more or less accustomed to changes at the second
Senior Reality Engineer
Ministry of Information
More information about the tz