Jon Skeet wrote:
I quite like Tim's padding idea overall, although I'd stlil argue for colons in offsets (RFC5322 uses a horrible format in general; I see no reason to copy mistakes of the past)
Tim argued for that as well, so let's do that.
and "d" instead of "a positive integer" to indicate daylight. (My goal is for this to capture all the relevant information from the original data text files, but the implementation details of is_dst fall outside that scope IMO. That's not part of the source data.)
The decimal integer does both, no? That is, it captures all the relevant information from the original data text files, and it also captures the POSIX-specified implementation details. Since zdump is supposed to be portable to other implementations where the value of the flag may matter, I'm still inclined to have the -i format output that information, as the -v format already does.
I'm still fine with the idea of transforming some non-ideal-to-me format from zdump into a more canonical format in a simple way though.
I plan to tweak the -i format to add colons to UT offsets, and do a couple of other things to make it easier to view and process (notably, use tabs rather than spaces to separate fields, so that people who want columns to line up can easily do that). Also, I would like to distribute a new file that contains the zdump -i output, so that changes to the tzdata source can easily be tracked by diffing the zdump -i output. This should help with regression testing. With luck, I'll get out a new patch shortly to do all this.