[tz] Adding a "test" region?

Paul G paul at ganssle.io
Wed Jan 24 22:37:04 UTC 2018

I really disagree with making it a sub-region of an arbitrary geographical region. That will just cause confusion as to whether it's real or not. If it's under "TestZones" it will be obvious enoguh. Plus, "number of regions never increases" is an unwarranted assumption, so that alone argues for adding it as a separate region.

Of course this is going to break some software (or really, make it obvious that software is already broken) - the point is to break the software *now* when the maintainers of said broken software can just filter out the `TestZone` region while they are working on removing the unwarranted assumptions, rather than break it when Iceland decides (or rather, recognizes) that leap seconds are a bad idea and changes their official timekeeping to a TAI-based zone.

On 01/24/2018 05:30 PM, Philip Paeps wrote:
> 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 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)
>> 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.
>> Suggestions:
>> Dystopia/Isle_of_Negative_Save
>> Dystopia/Half_Hour_Bay
>> Dystopia/Fifteen_Minutes_Late_Land
>> Dystopia/Fifteen_Minutes_Early_Town
>> Dystopia/Twice_Yearly_DST_Ville
>> Dystopia/...
>> 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.
>  Arctic/Dystopia/...
> Rationale: systems may get confused if the top-level regions increase but are likely already more or less accustomed to changes at the second level.
> Philip

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20180124/1de2f424/signature-0001.asc>

More information about the tz mailing list