[tz] Adding a "test" region?

[Paul.Koning at dell.com]

> On Jan 24, 2018, at 5:24 PM, Paul G <paul at ganssle.io> wrote:
> 
> 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.

Sure.  The storage products I work on (Dell EqualLogic storage arrays) allow the customer to set the array time zone, for friendly timestamps.  The GUI offers the timezones named in the tzdata database.  In the development organization, we have a script that downloads the current tzdata and updates the product source files to reflect the current information.

Since it is unacceptable for geek internals like a test timezone to show up in a customer GUI, we would have to change our tools to ignore those entries, if tzdata started to include them.  For that to happen there would have to be adequate announcement, and a commitment that there is a well defined name pattern that will always be used.  Since there is no "Test" continent, naming them Test/<something> would clearly work.  But even so, that is a change from the current tzdata content, which as defined today contains only meaningful real world data.

	paul