Y2K has come and gone with minimal effects. Back to business as usual, right?
With a setup like that, you know the answer. The fact is that the Y2K bug will probably pale in comparison to the Y2038 bug.
"Y2038? Great, another lunatic is prophesying imminent doom."
Yes, in the year 2038, another 'rollover' of sorts will occur. This rollover however, is a bit more technically in-depth than Y2K. Everybody can comprehend that the year 00 could be interpreted as 1900 instead of 2000. However, on Monday January 18, 2038 at 9:14:08 P.M. a new computational anomaly will occur.
It as at this time that the function 'time', the old standby of C and C++ programmers will exceed its own capacity. 'time' is a function that counts the number of seconds since January 1, 1970. 'time' also happens to use a signed integer. This means that the highest number of seconds that 'time' can return is 2,147,483,647. This might seem like great amount of time, but do the math. This number only gives us 68 years, 18 days and 21 hours.
What happens when we exceed 2,147,483,647 seconds? Since the number being used is a signed value (meaning it can store negative or positive numbers), the computer will not reset the number to zero as in the Y2K bug. Instead, the number will be set to -2,147,483,648. This means that if this number were interpreted as a date, that date would be December 12, 1902. However, this is not the worst of the problem.
The companion function to 'time' is called 'localtime' which converts 'time' from a second count into a date and time of day. However, 'localtime' will not accept negative values. If you were to pass a negative number to 'localtime', the function will return nothing (a null pointer). When you pass a null pointer to the companion function 'asctime' (which converts the date and time to a human readable character string), it will cause your software to crash and stop running. In fact your software will not run until every call to 'time' has been replaced.
How prevalent is 'time'? This function is used in operating systems, database applications, spreadsheet software, real-time control systems and just about everywhere else.
"But you are talking about a problem that will not affect us for 38 years, why should we care?"
This is the same thinking we had back in the 60's when software developers were creating the Y2K bug. Nobody back then believed that the software they were creating would be around another 40 years.
"What can be done?"
There are two approaches to fixing this problem. The first is to not use 'time' and its companion functions. Instead, use more modern function calls which will not have this rollover problem for millenniums to come. The second approach is to develop your own version of 'time' which returns a data type with greater capacity. This means that you will also have to rewrite the companion functions. Additionally, you will have to check your code to make sure that it does not assume a certain data type. 'time' is defined such that it returns a data type of 'time_t' . You can redefine 'time_t' to a larger capacity data type.
Hopefully, compilers will address this issue within the next 10-20 years. In that case, you will not need to rewrite the 'time' functions. However, at the very least you will need to recompile all of your old applications. More likely, you will have to examine all of your code to make sure that your developers did not cast the 'time_t' data into a basic (or integral) data type such as an int or long int. You will probably find at least one instance of this in every large project. And one instance of this bug is enough to stop your software in its tracks.
We would not recommend that you spend a great amount of money eliminating this software problem in your existing software. However, you would be advised to at least distance yourself from 'time' and its companion functions in current and future development efforts. Using an object-oriented approach, you can still make use of these functions without risking a Y2K type phenomenon. Better yet, you can begin to use API's that are a bit more far-sighted. At MPC we have already put this into practice in our software development efforts.
If your business is in need of a custom software application, or you need assistance maintaining or upgrading your own software, put MPC to work for you.