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@gmail.com] Sent: Wednesday, January 11, 2017 23:06 To: Paul Eggert <eggert@cs.ucla.edu> Cc: Kees Dekker <Kees.Dekker@infor.com>; Time Zone Mailing List <tz@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@cs.ucla.edu<mailto: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.