This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Year 2038 problem
- From: Clemens Ladisch <clemens at ladisch dot de>
- To: newlib at sourceware dot org
- Date: Fri, 20 Nov 2015 11:53:30 +0100
- Subject: Re: Year 2038 problem
- Authentication-results: sourceware.org; auth=none
- References: <298571211 dot 10499346 dot 1447832835018 dot JavaMail dot yahoo dot ref at mail dot yahoo dot com> <298571211 dot 10499346 dot 1447832835018 dot JavaMail dot yahoo at mail dot yahoo dot com> <20151118094331 dot GQ6402 at calimero dot vinschen dot de> <564C569B dot 4080308 at ladisch dot de> <20151118205314 dot GZ6402 at calimero dot vinschen dot de> <564D8537 dot 20103 at ladisch dot de> <20151119102037 dot GC6402 at calimero dot vinschen dot de> <564EEEE3 dot 7010501 at gmx dot de>
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