2038 is closer than it seems

Posted May 23, 2014 16:24 UTC (Fri) by ScottMinster (subscriber, #67541)
Parent article: 2038 is closer than it seems

Would it be possible to change the epoch date? For example, setting an environment variable like $EPOCH_YEAR to 2010 would make the 32 bit time_t relative to midnight UTC, January 1, 2010. Methods like localtime() would take this offset into account. Somehow, the kernel would have to be informed that the process is running with an epoch offset, but presumably that could be done during the process startup in glibc.

Obviously this wouldn't solve situations where the time_t value is recorded outside the process (in a file, sent over the network, etc), so this wouldn't work for some subset of applications. But most applications probably do not do that, so this workaround seems like it could be effective in cases where recompiling is not possible or desirable.

to post comments

Changing the epoch

Posted May 23, 2014 19:34 UTC (Fri) by corbet (editor, #1) [Link] (3 responses)

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.

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.

2038 is closer than it seems

Posted Jun 2, 2014 16:00 UTC (Mon) by jch (guest, #51929) [Link]

> setting an environment variable like $EPOCH_YEAR to 2010 would make the 32 bit time_t relative to midnight UTC, January 1, 2010.

Ouch. That would break all of the (perfectly correct) code that does

fprintf(datafile, "%ld\n", (long)timestamp);

and expects the data to be valid in the next session.