In the "Fractional seconds in zic input" thread, Howard Hinnant wrote:
> Ah, I see our disconnect here.  I have no concern about the zic compiler.
> The zic compiler is not in my workflow.  The *input* to the zic compiler
> is the *only* thing that concerns me.  I (and several others) have our
> own "zic compilers" which take this input, process it, and deliver it
> to our customers.

This strikes me as a very significant statement.  If this is
already a well-settled issue, pardon me for reraising it, but:
is it agreed that the zic *input* files are as much of a product
of this project as are the compiled output files, and the
reference code that reads and interprets them?

In the beginning I would have thought that the project's product
was the database *and* the reference code, such that the project
could change the database format as much as it wanted to as long
as it released updated code to match.

Soon enough, of course, there were other consumers of the
database files (one in fact written by the project's current
maintainer), such that more caution was needed when making
changes to the zonefile format, changes which now necessitate
corresponding changes by the authors of all other consumers.

But I would have thought that, working our way upstream, the
project could still change the zic input format as much as it
wanted to as long as it updated zic to match.  But now Howard is
saying:

> For us, the product of the IANA repository is only the tz database,
> and not the tz code.

And he is using the words "the tz database" to refer, not to the
zic output files, to the *input* files!

I'm not trying to blame Howard, and he's certainly not alone.
There was of course that a big long thread last month about
the issues with OpenJDK/CLDR/ICU/Joda and the Ireland change,
and just today we heard about Kerry Shetline's new compiler.

My point is simply that it's pretty hugely significant whether
the zic input files are an officially-supported product or not.
If they are, the project has to be much more conservative about
making these kinds of changes, probably more conservative than it
otherwise wants to be.  But if they're not an officially-supported
product, then people have to be discouraged from writing their
own compilers, or if for whatever reason they truly need their
own compilers and their own compiled data formats different from
zic's, it seems to me we're going to inexorably wind up feeling
the need to fork the project, a possibility which Stephen
Colebourne has already raised.

But, again, apologies if I'm being overly melodramatic, or
raising and issue that's already well understood.

(But in any case, we may need some clearer terminology.  In
particular: do those words "the tz database" properly refer to
the zic output files, or the input files, or both?)