[tz] Adding a "test" region?

[Clive D.W. Feather]

Paul.Koning at dell.com said:
>>> 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,

(1) This is covered by the other Paul's comment about "erroneously display
them to users".

(2) Do you currently display the TAI zones, the GMT+n non-geographical zones,
the backwards zones, etc.? I would have thought that was more confusing
that test zones (particularly if someone confuses Europe/London with
Etc/GMT).

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