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

[Jon Skeet]

(To the list this time instead of just to Paul - sorry for the duplicate,
Paul.)

Thanks for your work on this, Paul. I'm about to go on vacation so I don't
know how popular I'd be with my spouse if I investigated this much further
this week, but I'm somewhat nervous about the readability for the sake of
compactness. I'd like to try a bunch of different formats, with examples
and sizes - using Noda Time to generate them just for the sake of making
this experimentation easier. I'd personally be willing to sacrifice a
certain amount of compactness for the sake of readability, but obviously if
we can get the size down a bit *without* losing readability, that would be
good. I'll try to come back with a document of options, at least within the
next couple of weeks.

I think it's fine for zdump not to bother with version information etc - it
should be easy enough to write code to add that later, so that zdump can
focus just on the time part of things.

I'm *personally* not bothered about the lack of leap second information -
my bias here is that Noda Time completely ignores leap seconds. (I view
them as rather separate from actual time zones anyway - I think if we were
thinking about systems from scratch I'd separate the two entirely, but
that's a different matter.)

Great to see progress on this though!

Jon

On 29 May 2016 at 19:49, Paul Eggert <eggert at cs.ucla.edu> wrote:

> Jon Skeet wrote:
>
>> I'd be perfectly happy with zdump gaining more display options, but I
>> think
>> there's still huge benefit in deciding on one *canonical* format for
>> validation.
>>
>
> I looked into the format you suggested, along with the other comments
> noted and formats I've seen elsewhere (e.g., Shanks), and came up with the
> attached proposal for a "canonical" -i format for zdump, with the design
> goals being a format that is unambiguous, easy to review, and compact.
> Although this format's columns don't always line up, in general aligning
> columns appears to be impractical (in the extreme case, year numbers might
> exceed 9999!), and I found that unaligned columns make it easier to see
> glitches anyway. The proposed -i format does not contain versioning
> information as that would complicate regression testing.
>
> For what it's worth, the -i format is about 10% the size of -v format, and
> is about 53% the size of the format you proposed.
>
> This proposal is incomplete, for several reasons. First, it doesn't
> address leap seconds. Second, it doesn't abbreviate predicted futures into
> POSIX TZ strings; fixing this would make the output significantly shorter.
> Third, there is no infrastructure for verifying a distribution by
> checksumming its zdump -i output. So the proposal is documented as being
> experimental in the attached patch, and I haven't installed it on github
> yet. Of course zdump -v has all these problems as well, so the proposal
> format wouldn't make these problems worse.
>
> The first attachment consists of the revised man-page output; the second
> attachment is the change to tzcode.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160530/0e451391/attachment.html>