[tz] Adding a "test" region?

[Paul G]

On 01/24/2018 04:55 PM, Paul.Koning at dell.com wrote:
> No, please do NOT do that.  Anyone who depends on an automated or semi-automated system to track real changes will get completely messed up by such a tactic.  Let the real database contain real data.  A test database is fine; a test zone in the real data is not.

Do you have examples of this? I'm not really sure what problem it would cause to have well-namespaced fictional zones in the real database. What kind of automated processes would be affected by there being some zones that don't represent real zones? I could imagine there being some applications that don't know about these test zones that erroneously display them to users, but why would users set their time zone to `TestZone/Test_Monthly_DST` or something? Doesn't seem hugely risky to me, but I would not be surprised to find that there are some applications where this could be a deal-breaker.

That said, one of the problems this would be designed to solve is that apparently a lot of people are already *not* testing against the master branch or doing their own tests, since we hear about a lot of problems only *after* new releases come out. Having the default be "you don't get the test zones" would at least partially defeat the purpose of such an initiative.

> Of course it would be possible for the tools that track changes to ignore the test entry, but that's an incompatible change.  And that also only works if the test zone(s) have rigorously defined name patterns fixed for all time.

I assume it's fine to have rigorously defined name patterns. I was thinking of something designed from the beginning to be filtered out (it could, for example, *only* generate zones in TestZones/, and/or there can be a "testzones" file that lists all the fictional zones).

Since it seems like Paul is already leaning towards moving to a 2-track release ("main" release and "compatibility" release that is more stable with respect to some of these features), it would make sense to distribute the test zones *only* as part of the "main" release (and whether the `TestZone/` region/folder is generated at all can be opt-in in `zic`, since this is mostly intended for downstream *compilers*, not for the much more stable compiled binaries). Presumably anyone not ready to handle the test zones can opt-out easily enough by using the compatibility releases.

Best,
Paul

>> On Jan 24, 2018, at 4:40 PM, Clive D.W. Feather <clive at davros.org> wrote:
>>
>> Paul G said:
>>> 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.
>>
>> That sounds a really good idea.
>>
>>> - 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 changes every month, or even every week.
>>
>> -- 
>> Clive D.W. Feather          | If you lie to the compiler,
>> Email: clive at davros.org     | it will get its revenge.
>> Web: http://www.davros.org  |   - Henry Spencer
>> Mobile: +44 7973 377646

-------------- 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/62b4b828/signature.asc>