<html><head></head><body>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.<br>
<br>
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.<br><br><div class="gmail_quote">On January 24, 2018 10:52:58 PM UTC, Paul.Koning@dell.com wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> On Jan 24, 2018, at 5:24 PM, Paul G <paul@ganssle.io> wrote:<br> <br> On 01/24/2018 04:55 PM, Paul.Koning@dell.com wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> 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.<br></blockquote> <br> 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.<br></blockquote><br>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.<br><br>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.<br><br> paul<br><br></pre></blockquote></div></body></html>