<div dir="ltr"><div class="gmail_default"><font face="times new roman, serif">I agree that the data is key, and by that I mean the distributed 'zic input data' (eg "southamerica"). However, I disagree strongly about:</font></div><div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif">>  no-one should really be overly concerned with the format in which we write it</font></div><div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif">When a data file format is in very widespread use, changes to it are extremely painful for downstream clients. I've had plenty of experience with this with Unicode, BCP47, CLDR, and similar levels of internal changes at the companies I've worked at. Seemingly trivial changes have a way of screwing up lots of programs and millions of people.</font></div><div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif"><i>If the TZDB were not important, <span style="color:rgb(34,34,34);font-size:small;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">arbitrary changes would not matter. </span></i><span style="color:rgb(34,34,34);font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">But it is a crucial part of the world's software stack; its very importance cries out for stability.<span> </span></span>(As a trivial counterexample for "no-one should really be overly concerned with the format", try changing the character set of the files to EBCDIC and see how many squawks you get from users). </font></div><div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif">Now, there are ways to both expand the format and retain stability. Here are a couple of ways to do that.</font></div><div class="gmail_default"><font face="times new roman, serif"><br></font></div><div class="gmail_default"><font face="times new roman, serif">A. Bifurcate the data</font></div><div class="gmail_default"><ol><li><font face="times new roman, serif"><b>Core. </b>Always make available a set of data files in the current format. No changes to support "advanced" features like SAVE<0, fractional digits, etc. No splitting IDs because of advanced features either.</font></li><li><font face="times new roman, serif"><b>Advanced. </b>The format of data files can change "with no concern", in order to support "advanced" features.</font></li></ol><div><font face="times new roman, serif">One way to make this practical is to always have a program that generates the core data by filtering the advanced. It is important, however, such a program strictly minimize the textual changes to the core, so that diffing produces changes on the order of what it done now, for updates to country rules. </font></div><div><font face="times new roman, serif"><br></font></div><div><font face="times new roman, serif">B. Add conditionals</font></div><div><font face="times new roman, serif"><br></font></div><div><font face="times new roman, serif">Another way is to have just one set of files, but have well-defined "conditionals" to enable new features. Here is an example, just for illustration:</font></div><div><br></div><div><font face="times new roman, serif"><div># @ IF FRACTIONAL</div><div><div># @ Rule<span style="white-space:pre">      </span>Arg<span style="white-space:pre">  </span>2007<span style="white-space:pre"> </span>only<span style="white-space:pre"> </span>-<span style="white-space:pre">    </span>Dec<span style="white-space:pre">  </span>30<span style="white-space:pre">   </span>0:00.0000001<span style="white-space:pre"> </span>1:00<span style="white-space:pre"> </span>S</div></div><div># @ ELSE</div><div><div style="color:rgb(34,34,34);font-family:"times new roman",serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial"><div>Rule<span style="white-space:pre">      </span>Arg<span style="white-space:pre">  </span>2007<span style="white-space:pre"> </span>only<span style="white-space:pre"> </span>-<span style="white-space:pre">    </span>Dec<span style="white-space:pre">  </span>30<span style="white-space:pre">   </span>0:00<span style="white-space:pre"> </span>1:00<span style="white-space:pre"> </span>S</div></div></div><div># @ END</div><div><br></div><div>The key to having that work is that older implementations will just ignore the # @... lines, and newer implementations that want to support the features can use them.</div></font></div></div><div class="gmail_extra"><font face="times new roman, serif"><br clear="all"></font><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><font face="'times new roman', serif"><div style="background-color:transparent;margin:0px"><div></div></div><div style="background-color:transparent;margin:0px">Mark</div></font><div><div><font face="'times new roman', serif"><i><span style="font-style:normal"><i></i></span><i></i></i></font></div></div></div></div></div></div></div></div></div></div></div></div></div>
<font face="times new roman, serif"><br></font><div class="gmail_quote"><font face="times new roman, serif">On Tue, Feb 6, 2018 at 12:14 PM, Robert Elz <span dir="ltr"><<a href="mailto:kre@munnari.oz.au" target="_blank">kre@munnari.oz.au</a>></span> wrote:<br></font><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="times new roman, serif">    Date:        Mon, 05 Feb 2018 23:57:59 -0500<br>
    From:        <a href="mailto:scs@eskimo.com">scs@eskimo.com</a> (Steve Summit)<br>
    Message-ID:  <2018Feb05.2357.scs.0001@<wbr>quinine.home><br>
<span class="gmail-"><br>
  | In the beginning I would have thought that the project's product<br>
  | was the database *and* the reference code,<br>
<br>
</span>The reference code is a side issue, useful to show how to use the<br>
data, and to assist in verifying its correctness, but it is the data that<br>
matters.  Note: the data, not the format in which it is expressed, that's<br>
an even smaller side issue.<br>
<br>
The part of all of this that is difficult (aside from attempting to make<br>
the code work on a zillion different systems in a sane way) is actually<br>
collecting and, as best as is possible, verifying the data.<br>
<br>
That is all that really matters.   All the rest is just frills, and as anyone<br>
is free to take the collected data and write it down in whatever format<br>
they like, no-one should really be overly concerned with the format in<br>
which we write it, nor how often that changes.<br>
<br>
Getting as much data as possible, as accurately as we can determine<br>
it (down to tiny fractions of a second, when it matters) is all that is really<br>
important.  When the format cannot represent the data, we change the<br>
format, never compromise the data.  The format can also change just<br>
because something new happens to be more convenient.<br>
<br>
kre<br>
<br>
</font></blockquote></div><br></div></div>