On Wed, Sep 11, 2013, at 8:50, Zefram wrote:
random832@fastmail.us wrote:
We're getting stuck on ways to compatibly extend the current format.
Appending new fields to the existing format is a serviceable mechanism. The problem with glibc, and other tzfile parsers that are sensitive to such changes, is best addressed by giving advance notice of the new format before releasing the new zic.
My thinking is, If it's not going to actually be compatible with current implementations, what's the point of being compatible at all?
What about adding another file in a new location,
I don't think there's any pressing need to do this, but it has its attractions. If we do work on an incompatibly different file format, it should be a long-term project to produce a format to serve for the next 30 years, not a hasty process that we'd need to redo. You've listed a couple of issues we could tackle this way, and I've got my own laundry list of desiderata.
I had been thinking about a PNG-like "chunk" structure which would allow implementations to ignore anything they don't understand. I thought about proposing this back when we were talking about tz-to-metazone mapping (something which I still think should belong to this project rather than CLDR). That would take care of future extensibility.