On 6 June 2016 at 00:51, Paul Eggert <eggert@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