[tz] Adding a "test" region?

[Paul G]

To be clear, this is mostly about testing tzdata compilers, not consumers of the compiled files (though it would also be useful for that). I think that this would come with a change to `zic` to add either a --test or a --no-test flag which would compile or not compile the test zones as appropriate.

I'm weakly in favor of making the test region opt out (so by default running `zic` would generate them). No one further downstream than whoever distributes your zoneinfo binaries should bother with filtering out these zones, and for the zoneinfo distributors it would be a matter of adding a flag to the zic command.

On January 24, 2018 10:52:58 PM UTC, Paul.Koning at dell.com wrote:
>
>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180124/cbdc009f/attachment.html>