<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 22 August 2016 at 18:38, 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">
Is that due to dates past 2038, or something else?<br>
</blockquote>
<br></span>
Also dates before 1901 for 32-bit signed time_t, or before 1970 for unsigned time_t. I want the pre-1901 transitions to be checked, though, so I would rather stick with 64-bit signed time_t when generating the reference file.<br>
<br>
Plus, on some platforms zdump uses CRLF instead of LF to terminate output lines. There may be other niggling things like that.</blockquote><div><br></div><div>Right. My own <a href="https://github.com/nodatime/tzvalidate/blob/master/format.md">format spec</a> explicitly calls out U+000A, so that's consistent with using a Unix 64-bit version of zdump to generate the canonical file.</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">
I'd be testing something where time_t doesn't get involved at all, of<br>
course - an entirely different, non-C-based representation. That's the<br>
point of it, from my perspective.<br>
</blockquote>
<br></span>
Something with bignums, say? (Because 64-bit signed time_t doesn't suffice for simulations of proton decay in degenerate stars. See:<br>
<br>
Adams FC. The future history of the universe. Cosmic Update. 2011-07-23. <a href="http://dx.doi.org/10.1007/978-1-4419-8294-0_3" rel="noreferrer" target="_blank">http://dx.doi.org/10.1007/978-<wbr>1-4419-8294-0_3</a></blockquote><div><br></div><div>If we still have time zones that need this sort of support in even a thousand years time, then... well, heck, <i>I</i> won't be maintaining it :)</div><div><br></div><div>Given the other reactions around file merging, perhaps the data file should just be hosted as a separate file?</div><div><br></div><div>Jon </div></div></div></div>