<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">From my perspective as a prospective consumer, the input files to zic are the part that I can use in the system that it might be integrated into.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">There are multiple reasons why the library that uses the zic-based output is not usable by the project (many of the reasons are peculiar to that software).  I'm not entirely happy with the output format from zic, but that's somewhat separate — that could be lived with.  But my project would probably be based on the data files that are the input to zic, and changing the format of those would become an issue.  Adding comments etc isn't a problem; changing the format of the operational textual data that is the source for zic could be a problem.  From my perspective, zic plus the library is a sample consumer of the input data — it is not the sole consumer.  The input format to zic is the crucial data — the output from zic is coincidental (useful for checking, etc, but not the end data that will be used).<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I get the impression from the other emails on the list, that lots of other people consider it similarly — not necessarily for the same reasons, of course.<br><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 5, 2018 at 8:57 PM, Steve Summit <span dir="ltr"><<a href="mailto:scs@eskimo.com" target="_blank">scs@eskimo.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the "Fractional seconds in zic input" thread, Howard Hinnant wrote:<br>
> Ah, I see our disconnect here.  I have no concern about the zic compiler.<br>
> The zic compiler is not in my workflow.  The *input* to the zic compiler<br>
> is the *only* thing that concerns me.  I (and several others) have our<br>
> own "zic compilers" which take this input, process it, and deliver it<br>
> to our customers.<br>
<br>
This strikes me as a very significant statement.  If this is<br>
already a well-settled issue, pardon me for reraising it, but:<br>
is it agreed that the zic *input* files are as much of a product<br>
of this project as are the compiled output files, and the<br>
reference code that reads and interprets them?<br>
<br>
In the beginning I would have thought that the project's product<br>
was the database *and* the reference code, such that the project<br>
could change the database format as much as it wanted to as long<br>
as it released updated code to match.<br>
<br>
Soon enough, of course, there were other consumers of the<br>
database files (one in fact written by the project's current<br>
maintainer), such that more caution was needed when making<br>
changes to the zonefile format, changes which now necessitate<br>
corresponding changes by the authors of all other consumers.<br>
<br>
But I would have thought that, working our way upstream, the<br>
project could still change the zic input format as much as it<br>
wanted to as long as it updated zic to match.  But now Howard is<br>
saying:<br>
<br>
> For us, the product of the IANA repository is only the tz database,<br>
> and not the tz code.<br>
<br>
And he is using the words "the tz database" to refer, not to the<br>
zic output files, to the *input* files!<br>
<br>
I'm not trying to blame Howard, and he's certainly not alone.<br>
There was of course that a big long thread last month about<br>
the issues with OpenJDK/CLDR/ICU/Joda and the Ireland change,<br>
and just today we heard about Kerry Shetline's new compiler.<br>
<br>
My point is simply that it's pretty hugely significant whether<br>
the zic input files are an officially-supported product or not.<br>
If they are, the project has to be much more conservative about<br>
making these kinds of changes, probably more conservative than it<br>
otherwise wants to be.  But if they're not an officially-supported<br>
product, then people have to be discouraged from writing their<br>
own compilers, or if for whatever reason they truly need their<br>
own compilers and their own compiled data formats different from<br>
zic's, it seems to me we're going to inexorably wind up feeling<br>
the need to fork the project, a possibility which Stephen<br>
Colebourne has already raised.<br>
<br>
But, again, apologies if I'm being overly melodramatic, or<br>
raising and issue that's already well understood.<br>
<br>
(But in any case, we may need some clearer terminology.  In<br>
particular: do those words "the tz database" properly refer to<br>
the zic output files, or the input files, or both?)<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Jonathan Leffler <<a href="mailto:jonathan.leffler@gmail.com" target="_blank">jonathan.leffler@gmail.com</a>>  #include <disclaimer.h><br>Guardian of DBD::Informix - v2015.1101 - <a href="http://dbi.perl.org" target="_blank">http://dbi.perl.org</a><br>"Blessed are we who can laugh at ourselves, for we shall never cease to be amused."</div></div></div></div></div></div></div></div>
</div>