<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 August 2016 at 16:30, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jon Skeet wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
it isn't canonical at that point - from the perspective of<br>
information in the source text. If two valid implementations can give two<br>
different outputs, that's a problem for my use case.<br>
</blockquote>
<br></span>
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.<br></blockquote><div><br></div><div>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?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.</blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
if the output data in the<br>
release will always use 1 and 0, I guess I could canonicalize to that<br>
</blockquote>
<br></span>
Yes, it should always be 1 or absent.</blockquote><div><br></div><div>Right. I think I'll at least <i>start</i> 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. </div><div><br></div><div>Jon</div><div><br></div></div></div></div>