(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@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.