[tz] zdump new option -i for easier-to-review output

Jon Skeet skeet at pobox.com
Mon Jun 6 05:52:38 UTC 2016


On 6 June 2016 at 00:51, Paul Eggert <eggert at cs.ucla.edu> wrote:

<snip>

I hope I've explained the significant technical advantages of zdump -i
> format for my use case (manually looking at zdump -i output, and looking at
> diffs of it). I am not surprised that its style is offputting, which is why
> I'm thinking that we may need a way for people to specify output style more
> flexibly than zdump -i versus zdump -v versus zdump -V.
>

Yes, it does seem that we're unlikely to come up with a format that both of
us are happy with.

One alternative is for me to keep the format I've worked up, but
post-process the output of zdump with a Python script, to convert it into
the tzvalidate format. I suspect that making zdump flexible enough to
output both formats (and others) based on command line arguments would be a
*huge* amount of work - especially with things like variable-width times,
omitting time zone abbreviations if they happen to match the offset etc.
The Python code could also generate the headers and hashes necessary.

zdump -i + a Python script is something that can be done reasonably quickly
(I doubt that it's more than an afternoon's work) and would still be
significantly more portable than my current C#-based solution.

If we were to go ahead with that, how hard (both technically and in terms
of any IANA process required) would it be to start publishing a zip file of
the tzvalidate output alongside the code and data files, and include just a
hash within the main data zip file (e.g. as a new file such as
tzvalidate-sha256.txt)? While I'm happy to keep doing this separately, it
would obviously be better if it were integrated into the main process.

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160606/d26e3e5e/attachment.html>


More information about the tz mailing list