Re: Year 2038 problem

[Stefan Heinzmann <stefan_heinzmann at gmx dot de>]

On 19.11.2015 at 11:20 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.

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?

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).

If it does indeed work with either signed or unsigned time_t, 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.

And some time after 2038, when everybody (hopefully) has long gotten 
used to an unsigned time_t, one could switch back to signed, while at 
the same time shift the epoch forward by 2^32 seconds. And so on, 
towards infinity.

Or, to put it another way, use the 32-bit time_t in modulus arithmetic, 
which comes natural to 2's complement numbers anyway.

Why would I need to spend 32 bits in a time value to distinguish bewteen 
dates that are way beyond both my own lifetime and the lifetime of the 
products I design? Granted, spending those extra bits makes it 
unabiguous once and for all, but is that important enough in practice?

Cheers
Stefan