Pondering 2038

Posted Aug 15, 2013 5:08 UTC (Thu) by dlang (guest, #313)
Parent article: Pondering 2038

One thing that people need to think about for this is what they mean by the statement that the software will "break"

There is no dispute that the system's idea of the date will be wrong, but will that actually cause a problem that the user will be able to detect?

If the user can detect the problem, is there a simple work-around? (if the system just displays time-of-day, it's trivial, if it shows day of week or month, it's a bit more complex, but still just a matter of setting the date to the right 'incorrect' value)

to post comments

Pondering 2038

Posted Aug 15, 2013 9:24 UTC (Thu) by keeperofdakeys (guest, #82635) [Link] (3 responses)

32bit time is usually stored as a signed int, so when it rolls over, it will become negative. I don't know what this will do to most of the time code out there.

Pondering 2038

Posted Aug 15, 2013 9:49 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

That's defined in the spec, negative times are seconds before Jan 1 1970

time will go from
Tue, 19 Jan 2038 03:14:08 GMT
to
Fri, 13 Dec 1901 20:45:51 GMT

Pondering 2038

Posted Aug 15, 2013 12:15 UTC (Thu) by jengelh (subscriber, #33263) [Link]

But is is conceivable that some code may be (ab)using (time_t)-1 or time values < 0 to mean "unset" or something.

Pondering 2038

Posted Aug 23, 2013 14:02 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]

Which spec? The current SUS doesn't require any mapping for pre-1970 times or any meaning for negative time values (see section 4.15). Further, (time_t)(-1) is reserved as an error value, leading to ambiguity for 1970 - 1 second.

This is not a problem unless you want to accurately represent timestamps on files from systems older than Unix, or you try to use time_t outside of its original scope.