Changing the epoch

Posted May 23, 2014 19:34 UTC (Fri) by corbet (editor, #1)
In reply to: 2038 is closer than it seems by ScottMinster
Parent article: 2038 is closer than it seems

Running in a different epoch would work in situations where dates in the past do not need to be represented. But think about things like file time stamps that do indeed need to be in the past.

to post comments

Changing the epoch

Posted May 23, 2014 21:05 UTC (Fri) by ScottMinster (subscriber, #67541) [Link] (2 responses)

time_t is signed, so it can represent 68 years in either direction of the epoch (2^31/86400/365.25). Setting the epoch to 2010 would allow representation from 1942 to 2078.

It's not a good long term solution, but could be a workaround for some applications.

Changing the epoch

Posted May 24, 2014 5:30 UTC (Sat) by jzbiciak (guest, #5246) [Link] (1 responses)

Are negative time_t values really valid times, though? There are APIs (such as time()) that return -1 to indicate an error. The lazy programmer in me imagines that among programs that actually check for an error (which, admittedly, are probably rare), the majority would just check for less-than-zero.

Changing the epoch

Posted May 24, 2014 10:40 UTC (Sat) by ScottMinster (subscriber, #67541) [Link]

True, that would probably preclude setting your epoch date in the future (say to 2050 so you could span between 1982 and 2118). At the very least, there would be a time (December 31, 23:59:59) when time() would have to legitimately return -1, which is the error code.

But if the epoch date is in the recent past, that wouldn't cause any trouble for the time() function. I don't think any code would care if, for example, the time_t values in a stat structure are null. As long as they are relatively consistent and localtime() returns the correct human translation.