Computer systems that use time for critical computations may encounter fatal errors if the Y2038 problem is not addressed, writes Paul Budde.
THE YEAR 2038 PROBLEM relates to representing time in many digital systems as the number of seconds passed since 00:00:00 UTC on 1 January 1970 and storing it as a signed 32-bit integer. Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038. At that time, systems might crash and will be unable to restart when the time is changed to that date.
It is like the Y2K problem, which was caused by widespread use of two decimal digits to store the year. While that problem was overhyped, at the same time a frantic effort to fix that problem has certainly assisted in preventing widespread computer disruption.
The Year 2038 problem is caused by an insufficient number of bits (digits) chosen to represent time. This has been known as early as 2006, when companies started to implement software with code embedded to handle a database request that should “never” time out.
One of the problems with the Y2K issue was that many organisations left it to the last minute to fix their systems to prevent the disruption. One could argue that lessons have been learned and that this Y2038 problem will be fixed well before the deadline.
The Y2038 issue affects all computer code that uses 32 bits for time values. Systems that do not require access to dates are not affected by this problem.
In the 32-bit computer systems, the representation for time is a signed 32-bit integer containing the number of seconds since 1 January 1970. This value will overflow on 19 January 2038. The solution is to transition to 64-bit time support. With 64 bits, there is more than enough room to store time values far past the foreseeable future, even if high-resolution (nanosecond-based) time values are used.
The problem, however, will be that such changes will have a range of ripple effects that will need to be mapped first and then thoroughly researched to find the appropriate solutions that prevent unwanted side effects. And in turn, these solutions could create their own side effects so it not something that computer engineers would want to leave to the last minute, as happened with the Y2K issue.
With this knowledge of the Y2038 issue, all current computer systems will have been upgraded well before that time. However, there are potential problems lurking in other corners. Most of these problems are going to be in old programs that no one ever remembers to update and test.
But there are also other areas that require attention. Lots of devices, such as the current mobile handsets, are based on 32-bit computers. These devices will have long since failed for any of several other reasons by then, so there is little point in ensuring that they can survive 2038.
But people keep cars going for a long time. There may still be routers, wireless access points and IP cameras in use by then, and there is highly likely to be a lot of deeply embedded systems such as building infrastructure. Some of these systems are going to fail in 2038. That is why it is important to get the problem fixed as soon as possible.
In many of such cases, it might no longer be possible to upgrade these devices, or it doesn’t make economic sense to do so. In those cases, equipment and devices will simply need to be replaced.
For this article, I also had a look at what the various computer organisations are doing here, especially Linux. While what they are doing is way beyond my technical knowledge, it is good to see that they already have been working on this issue for more than a decade.
However, there are many other software systems based on 32 bits and some of these systems are no longer supported but still exist, so it is important for any organisation to investigate the Y2038 issue to prevent a sudden costly rush to fix the problem or to find out too late that they are in trouble on 19 January 2038.
Paul Budde is an Independent Australia columnist and managing director of Paul Budde Consulting, an independent telecommunications research and consultancy organisation. You can follow Paul on Twitter @PaulBudde.
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Australia License
Support independent journalism Subscribe to IA.
