Home / Blogs

The Year 2038 Computer Problem – a Repeat of Y2K?

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 be unable to restart when the time is changed to that date.

It is like the Y2K problem caused by the 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 undoubtedly 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 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.

By Paul Budde, Managing Director of Paul Budde Communication

Paul is also a contributor of the Paul Budde Communication blog located here.

Visit Page

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

VINTON CERF
Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Related

Topics

Domain Names

Sponsored byVerisign

DNS

Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

New TLDs

Sponsored byRadix

Cybersecurity

Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API