<div dir="ltr"><div><div>> Unfortunately now that I think of it, I see that this can't work on<br>
> hosts with 32-bit time_t, as they can't cover the 400-year span.  So the<br>
> code is still broken on 32-bit hosts. Is there a better way to fix the code?<br><br></div>Since 32-bit time_t values can only cover (about) 140 years, not covering a 400-year span's not a bug, it's a given.-)<br><br></div><div>(An aside: in the future, my guess is that there'll either be a new, 64-bit-only time zone binary format or that time zone source will be interpreted at run time with no binary format; at that point, a lot of code simplification happens.)<br></div><div><br></div>    @dashdashado<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 11, 2017 at 4:51 PM, 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="">On 01/11/2017 01:28 PM, Arthur David Olson wrote:<br>
> When a table generated from an environment variable does indeed cover<br>
> 400 years, both goahead and goback should be set.<br>
<br>
</span>The localtime.c code in question tries to do that sort of thing, as it says:<br>
<br>
            yearlim = EPOCH_YEAR + YEARSPERREPEAT;<br>
            for (year = EPOCH_YEAR; year < yearlim; year++) {<br>
<br>
and YEARSPERREPEAT is 400.<br>
<br>
Unfortunately now that I think of it, I see that this can't work on<br>
hosts with 32-bit time_t, as they can't cover the 400-year span.  So the<br>
code is still broken on 32-bit hosts. Is there a better way to fix the code?<br>
<br>
Also, I'm puzzled as to why the first transition in 1970 was being<br>
omitted, as that leads me to worry that the above code will generate one<br>
transition shy of 400 years' worth even on 64-bit hosts.<br>
<br>
</blockquote></div><br></div>