[tz] Adding a "test" region?

[Paul.Koning at dell.com]

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.

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.
 
	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