Should I worry about Year 2038 issue now?
Remember the year 2000 issue? To save storage space, many old programs stored the year with just the last two digits and assumed it was always the twentieth century. Therefore, such programs would treat the year 2000 as the year 1900 and malfunction.
A similar issue exists for year 2038. Unix systems count time as seconds since Jan 1, 1970. This is known as POSIX time or Epoch time. This time value is held in a signed 32 bit 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 of European Space Agency (ESA) Ariane rocket that carried four expensive satellites. You might also have noticed recent news that Boeing 787 could have a complete electrical shutdown and potential loss of control of the aircraft if the control unit is powered on continuously without a shut down for 248 days!
To address this critical issue, operating systems begin to come up with new OS patches that support a new system call with a 64 bit time value. At the time of writing, Linux and IBM AIX have come out with the fix; however, Solaris and HP-UX have yet to address the issue. Interestingly, Windows does not have the same year 2038 issue as it represents time differently.
Since 2038 is still quite some time away, you shouldn’t have to worry about it, right? No. It all depends on how far your application is looking into the future. If your application is doing quarter-end or year-end processing of current year; or 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 have already run into the issue today; you may just not know about it!
How does one address Year 2038 issue? Are you done once you upgrade to the OS version that supports 64 bit time value? No. First, any 32 bit application would continue to have the Year 2038 issue even on a 2038 capable OS. A 64 bit application must be re-compiled and rebuilt with the new 64 bit time API (Do you still have the source code)? Any applications linked to the 32 bit time API would still have the issue.
Also keep in mind, time values are often stored and recomputed by programs. If 32 bit time values are stored; then it will pop its ugly head once year 2038 is reached or during calculation even if the programs are calling 64 bit API. That is why even modern language like Java could have the Year 2038 issue, even if the language itself does not deal with 32 bit time.
So to be safe, one must test all time-sensitive applications and programs to ensure it is Year 2038 ready. Depending on how far your application looks into the future, the time bomb might be closer than you think.