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?)