[tz] Adding a "test" region?

Paul.Koning at dell.com Paul.Koning at dell.com
Thu Jan 25 16:20:09 UTC 2018

> On Jan 25, 2018, at 10:41 AM, Clive D.W. Feather <clive at davros.org> wrote:
> 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).

No, we don't, because we filter those.  Obviously we can filter this new thing also.  What concerns me is that it seems to have been suggested as something that could just be added without any backward compatibility concerns, and that is not correct.  If people are given adequate notice of this new thing so they can update the tools in advance, and the test mechanism is standardized so that it can be reliably filtered, then it is probably ok.

One remaining concern: the idea that changes to the Test data could be made periodically to exercise the machinery.  That is ok if it coincides with real changes.  But if this periodic thing causes tzdata releases to occur that have no real content change, then I object.


More information about the tz mailing list