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

[Jon Skeet]

On 22 August 2016 at 16:30, Paul Eggert <eggert at cs.ucla.edu> wrote:

> Jon Skeet wrote:
>
> it isn't canonical at that point - from the perspective of
>> information in the source text. If two valid implementations can give two
>> different outputs, that's a problem for my use case.
>>
>
> We have that problem anyway. If zdump is run on a platform with 32-bit or
> unsigned time_t, it will generate different output from platforms with
> 64-bit signed time_t. This is true even when using the tzcode localtime.c
> implementation.
>

Is that due to dates past 2038, or something else? (I've deliberately
capped my canonical format at 2035 for that purpose, although that's only a
reasonably short term solution of course. Are there other differences I
should be aware of in terms of zdump -i output?

I plan to generate the reference file on a host with 64-bit signed time_t
> and to use the reference tzcode implementation. So long as you test on a
> similar platform we should be OK.


Well I'd be testing something where time_t doesn't get involved at all, of
course - an entirely different, non-C-based representation. That's the
point of it, from my perspective.


> if the output data in the
>> release will always use 1 and 0, I guess I could canonicalize to that
>>
>
> Yes, it should always be 1 or absent.


Right. I think I'll at least *start* by writing a small script to convert
from one format to the other. We can see whether over time one becomes a
clear winner over the other.

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