[tz] question about mktime_tzname()

Arthur David Olson arthurdavidolson at gmail.com
Wed Jan 11 22:06:12 UTC 2017


> 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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20170111/240783ad/attachment.html>


More information about the tz mailing list