[tz] question about mktime_tzname()

[Kees Dekker]

FYI: on Windows 32-bit builds CAN use 64-bit timestamps (by using USE_32BIT_TIME_T macro, see https://msdn.microsoft.com/en-us/library/1f4c8f33.aspx). As far as I know, this is not possible on *NIX (my knowledge is limited to Solaris/AIX/HPUX/Linux). I don’t understand how 32-bit time_t systems can survive 2038 and beyond. I’m not sure what this will mean for embedded systems (with e.g. Linux), where 32-bit is still very common. That systems then also should have a 64-bit representation for time_t?

From: Arthur David Olson [mailto:arthurdavidolson at gmail.com]
Sent: Wednesday, January 11, 2017 23:06
To: Paul Eggert <eggert at cs.ucla.edu>
Cc: Kees Dekker <Kees.Dekker at infor.com>; Time Zone Mailing List <tz at iana.org>
Subject: Re: [tz] question about mktime_tzname()

> 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<mailto: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/20170112/d6a40ac0/attachment-0001.html>