Year 2038 problem
Fri Nov 20 11:31:00 GMT 2015
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
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
That cost probably is not so small.
And do you really want to _create_ a year 2106 problem?
More information about the Newlib