Date: Thu, 2 May 2013 18:44:55 -0700 From: Guy Harris <guy@alum.mit.edu> Message-ID: <8EF0A340-6E4C-4D70-ACA4-FEFC25B50D83@alum.mit.edu> | We should also make our current specification of the format a | little easier to find, so that people developing consumers other than | zic don't write parsers for what they *think* the format is rather | than for what we *say* it is. Actually, I suggest that we should really be discouraging people from creating alternate parsers for the zone input files than zic - those two should remain closely tied together. From time to time we discover the need to add some new feature to the input language, doing that is really hard if all kinds of other implementations will suddenly break. Further, the input file format is rather quirky, and hard to explain completely in a way that makes a lot of sense (though it is perfectly fine for zic). Rather we should be encouraging people to use the binary output files from zic for almost all purposes when they need something more than standard libc functions provide. And if that means documenting that format, more than is already done, then let's do it. It is already difficult to the point of almost impossibility to make much in the way of changes to that file format, as it is understood by system's libc functions, that we cannot alter - and even where libc is normally shared (and so can be updated if needed) nothing compels users to use the shared version - static program linking works on every system I'm aware of. If the binary format changes in some incompatible way, all old static linked programs would stop working, which is an unaceptable result (which is why we never do that, at most we have, very rarely, added to that format in a way that doesn't break existing parers). This does mean that people may need to use a new zic to handle new tzdata distributions, but that should be easy (if it isn't, we should be fixing whatever the problem is to make it easy.) Anyone who does insist on parsing the input files themselves should be made to understand the risks involved - we have in the past, and I am sure will again in the future, make changes to that format, with zero advance notice (beyond normal code review here). Of course, that we can change it does not mean that we must, or even should, and there's been nothing in this recent discussion that even suggests to me any need to make any kind of change. kre