This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Year 2038 problem
- From: Richard Earnshaw <Richard dot Earnshaw at foss dot arm dot com>
- To: Clemens Ladisch <clemens at ladisch dot de>, newlib at sourceware dot org
- Date: Fri, 20 Nov 2015 11:30:56 +0000
- 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> <564EFBAA dot 4080703 at ladisch dot de>
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.
R.