Ian Abbott wrote:
Rather than extending the current zic format, would it make more sense to have a preprocessor that produces files that can be fed to zic or to third-party "zic file" parsers?
That'd be "as well as". The input to the preprocessor would be an extended version of the zic format. I think we should indeed have something that can turn extended-zic source into old-zic source, for the benefit of third parties that have their own zic equivalent. But edge cases around transition times being specified in different ways mean that it's not straightforward to resolve "=" items to the underlying zone behaviour. You have to decide whether "02:00u" comes before "01:00" (local), for example. Doing it correctly requires quite a lot of zic's understanding of the data. So the preprocessor to generate old-style zic source would actually be our zic with an option telling it to act as the preprocessor.
even do the winnowing of data that has been talked about.
That wouldn't work so well. Resolving the winnowing requires computing all the observances and transitions, which is zic's job, so you'd have to incorporate zic into the "preprocessor", at which point it isn't "pre" any more. Even more so than "=" resolution, this requires full zic. As it is, we can reasonably easily implement source winnowing around the tzwinnow program, which operates from the tzfiles. For completeness, we can also implement a program that turns a tzfile into zic source. Of course, its synthetic DST rules wouldn't bear much resemblance to the original zic source, so Stephen wouldn't be happy with it. It wouldn't be an adequate solution to turning "="-enabled extended-zic source into old-zic source. But it may be useful in some strange set of circumstances. -zefram