On 22 August 2016 at 16:30, Paul Eggert <eggert@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