[tz] Extended data format
zefram at fysh.org
Fri Sep 6 10:26:51 UTC 2013
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.
More information about the tz