> Unfortunately now that I think of it, I see that this can't work on
> hosts with 32-bit time_t, as they can't cover the 400-year span.  So the
> code is still broken on 32-bit hosts. Is there a better way to fix the code?

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.-)

(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.)

    @dashdashado

On Wed, Jan 11, 2017 at 4:51 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 01/11/2017 01:28 PM, Arthur David Olson wrote:
> When a table generated from an environment variable does indeed cover
> 400 years, both goahead and goback should be set.

The localtime.c code in question tries to do that sort of thing, as it says:

            yearlim = EPOCH_YEAR + YEARSPERREPEAT;
            for (year = EPOCH_YEAR; year < yearlim; year++) {

and YEARSPERREPEAT is 400.

Unfortunately now that I think of it, I see that this can't work on
hosts with 32-bit time_t, as they can't cover the 400-year span.  So the
code is still broken on 32-bit hosts. Is there a better way to fix the code?

Also, I'm puzzled as to why the first transition in 1970 was being
omitted, as that leads me to worry that the above code will generate one
transition shy of 400 years' worth even on 64-bit hosts.