Year 2038 problem

[Joel Sherrill]

On 11/19/2015 4:20 AM, Corinna Vinschen wrote:
> On Nov 19 09:15, Clemens Ladisch wrote:
>> Corinna Vinschen wrote:
>>> On Nov 18 11:44, Clemens Ladisch wrote:
>>>> changing _TIME_T_ to long long
>>>> [...]
>>>> Would such a simple configuration option be accepted into newlib?  (Most
>>>> embedded systems do not care about backwards compatibility, but newlib
>>>> as a whole probably does.)
>>>
>>> ACK.  And yes, a configuration option is welcome.  It should still
>>> default to long for backward compat, yes.  32 bit Cygwin is still
>>> suffering 32 bit time_t as well, but changing that in a backward
>>> compatible way is quite a big task.
>>
>> glibc is currently talking about this:
>> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
>> (summary: User code defines _TIME_BITS=64 to ask that 64-bit time be the
>> default.)
>
> For embedded targets we don't have a backward compat problem,
> typically so I'd prefer a simple solution. which just changes
> time_t to the prefered type for the target.  But as I just wrote
> in my reply to Joel, nobody can avoid the year 2038 and at one
> point everybody will need a 64 bit time_t anyway.

My only technical concern is performance on 8 and 16 bit targets.
But there are a couple of realities to consider there.

(1) As you said, we can't push 2038 back. Suck it up.
(2) Is an 8/16 bit target really going to use time_t for much?
     Many RTEMS systems don't even know the calendar time.
     They are more focused on periodic and interval times.


I am all for pushing time_t to 64 bits for us. We are tidying up
a release branch and can move the development master to 64-bit.
We already use a native internal time format that is better than
a 32-bit time_t so it is just a matter of double checking any
conversion math.

But RTEMS is not a dictatorship. We have a good cooperative
leadership team and I would like to get feedback from others.
This is an important issue.

>
> Corinna
>

--joel