2038 is closer than it seems

Posted May 23, 2014 19:09 UTC (Fri) by kleptog (subscriber, #1183)
Parent article: 2038 is closer than it seems

Ok, so now it's 2038, what does the 32-bit interface return after that? Or does it return 0x7FFFFFFF forever?

I suppose what you could do is change the definition to reduce the resolution. So after 2030 it starts counting at half speed. In 2034 at quarter speed, 2036 one-eighth speed, etc. If you fix the APIs for strftime, ctime, etc everything will be transparent for most programs except the resolution gets worse.

This of course screws people who do calculations on time_t though. You'll only see even seconds after that time. It might save you on file formats though. A sort floating point time_t...

to post comments

2038 is closer than it seems

Posted May 23, 2014 21:37 UTC (Fri) by Jonno (guest, #49613) [Link] (1 responses)

> Ok, so now it's 2038, what does the 32-bit interface return after that? Or does it return 0x7FFFFFFF forever?

Presumably it will be treated as an unsigned integer, covering 1970-2106 instead of 1901-2038.

2038 is closer than it seems

Posted Dec 5, 2016 14:26 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Changing the type of time_t from 31 bit (plus sign) to 32 bit is an API (not just ABI) break just as (or even worse, for the API) changing it to 63 bit (plus sign) is.

(Yes, I know about complement representation, but that was not the point here.)

2038 is closer than it seems

Posted Dec 5, 2016 17:38 UTC (Mon) by zlynx (guest, #2285) [Link]

Start returning -EINVAL on all 32-bit time calls with the time_t fields set to 0. It's really the only sane thing to do.