Should you worry about the Year 2038?

Do you remember the year 2000?  Back then, to save storage space, many old programs stored their years with just the last two digits of the year. Perhaps the assumption was it would always be the twentieth century.   Unfortunately, that was not the case and such programs ended up treating the year 2000 as the year 1900.  This caused massive malfunctions.

A similar issue exists for the year 2038.  Unix systems have counted time as seconds since January 1, 1970.   This time value is held in a signed 32bit value; so it will overflow, or become a negative value, on 03:14:07 UTC Jan 19, 2038.

Integer Overflow issues are infamous for major software blunders.  Notable instances include the $370 Million lost with the European Space Agency (ESA) Ariane rocket that carried four expensive satellites.  You might also recall recent news that a Boeing 787 could have a complete electrical shutdown, causing a loss of control of the aircraft if the control unit is powered on without being shut down for 248 days!

To address this critical issue, operating systems began to come up with new OS patches to support a new time system with a 64bit value.  Within the last two years, Linux and AIX have both come out with a fix, however Solaris and Hp-UX have not yet addressed this issue.  Interestingly, Windows does not have the 2038 issue, as it is much newer than Unix.

Since this 2038 issue is still relatively far off, you might wonder: should I worry about it now?  Well, that all depends on how far your application is looking into the future.  If your application is doing quarter-end processing, year-end processing, or even a five year forecast, then it is fine for now.  On the other hand, if your application is doing a 30 year loan calculation or forecast, it could already be running into this issue today!

Now you face a few questions.  Firstly, how should you address your 2038 issue?  Secondly, are you done once you upgrade to the OS version that supports a 64bit time value?  In short, the 32bit application will continue to have the 2038 issue even on a 2038 capable OS.  As a result, the 64 bit application must be re-compiled and rebuilt with the new 64bit time API (Do you still have the source code)?  On top of that, the old version of 64bit program linked to the 32bit time API will still have the issue.

Also keep in mind, time values are stored and calculated at all times by programs.  If 32bit time values are stored, then it will rear its ugly head once 2038 is reached.  This will also happen during calculation, even if the programs are calling 64bit API.  That is why even modern language like Java could have a 2038 issue, even if the language itself doesn’t deal with 32bit time.

So to be safe, one must test all time-sensitive applications and programs to ensure it is ready for 2038.  Depending on how far your application is looking into the future, 2038 might be closer than you think!