Year 2038 problem

Richard Earnshaw
Fri Nov 20 11:45:00 GMT 2015

On 20/11/15 10:53, Clemens Ladisch wrote:
> Stefan Heinzmann wrote:
>> I don't quite understand yet why the Y2038 problem means that we have
>> to go to a 64-bit time_t.
>> How important is it to be able to deal with times back to almost the
>> year 1900, particularly in an embedded system?
> I estimate that there are more than zero devices that need to handle
> dates both before 1970 and after 2038.
>> When reading POSIX I don't seem to find anywhere stated that time_t
>> needs to be signed, and indeed there are various platforms that have
>> it unsigned, even though the Unix world seems to tacitly assume it is
>> signed. For a portable C library like newlib, I would have assumed that
>> it works correctly with either. Does it? (I've not checked this yet).
> In C, for many arithmetic operations, signed types are the default.
> So unless this has actually been tested, I doubt that it would work
> reliably.
> We know that newlib works with a (signed) 64-bit time_t on 64-bit
> architectures.  So it makes sense to use the same on all architectures.
>> one can push out the problem another 70 years with no speed or size
>> penalty, at the small cost of not being able to represent dates before
>> 1970.
> That cost probably is not so small.
> And do you really want to _create_ a year 2106 problem?
> Regards,
> Clemens

time_t is a signed type, so with a 32-bit time_t we only have a positive
range of 68 years when counting in seconds.  1970 + 68 years = 2038.  I
don't know where you get the 1900 from.


More information about the Newlib mailing list