[tz] zdump new option -i for easier-to-review output
skeet at pobox.com
Mon Aug 22 15:37:33 UTC 2016
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz