Changing the epoch

Posted May 23, 2014 21:05 UTC (Fri) by ScottMinster (subscriber, #67541)
In reply to: Changing the epoch by corbet
Parent article: 2038 is closer than it seems

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.

to post comments

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.