Year 2038 problem

[Clemens Ladisch]

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