On 05/02/2013 08:44 PM, Guy Harris wrote:
We should at least indicate what our policy is there, from "we reserve the right to change the format any time we want, deal with it" to something stricter.
Suppose we want to extend the zic input format slightly, to accommodate new rules issued by (say) Palestine, which are of the form "The first Friday after the last Thursday in March". Shouldn't we be able to do this? Or, suppose we want to extend the zic output format slightly, to support the rules that are actually used in Greenland right now, past 2038. Shouldn't we be able to do that too? These aren't entirely hypothetical questions, as both issues have crossed my mind in the past few weeks. Obviously we don't want to change zic's input or (especially) output format without good reason, but whatever advice we put into place should allow for changes where the bottom line is "deal with it". Perhaps something like the following? "The code is written in C, and attempts to be portable to a wide variety of systems. The data accepted and produced is also intended to be widely portable. To encourage interoperability with other systems that produce and consume this data, the data format is intended to be stable and changes to it will be made carefully, with the intent that they be upwards compatible as much as possible." This is just a quick first cut and suggestions for improvement are welcome. PS. I didn't quite follow all the back-and-forth about the "Theory" file versus the RFC, but the idea is that "Theory" predates the RFC and notes down practical aspects of tz maintenance. If they weren't deemed important enough to put into the RFC we didn't put them there. Some issues are so trivial that they aren't written down even in "Theory", and that should be fine too. PPS. I'll try to clarify the tabs-in-zone.tab issue by changing "Columns are separated by a single tab" to "Columns are separated by a single tab, except that the Comments column may be preceded by more than one tab" in zone.tab.