Re: Year 2038 problem

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

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