You may remember the Y2K problem, also known as the millennium bug. It was a big deal towards the end of the last century, generating hundreds of apocalyptic headlines across the globe with scare stories about aeroplanes falling out of the sky, major computer systems failing and basically bringing about the end of the world as we know it. In the end, it turned out to be a bit of a non-event, thanks in the main to IT professionals planning for and updating applications in the run up to, the date.

But if you thought we had seen the last of date-related bugs then you would be mistaken, there’s now a new date looming large; 19^th January 2038. On that date, some applications will break, and as we’ll see, some applications may have problems much sooner than that.

The 2038 problem explained

You may know one of the measures of the power of a computer is the number of “bits” it has. Modern systems are invariably 64-bit; older systems typically have 32-bits or less. There are all kinds of advantages of 64-bit over 32-bit, but for purposes of this discussion 64-bit systems make it much easier to store large numbers without having to write special code. On 32-bit systems the biggest whole number we can simply work with is 2,147,483,647. Enough to count most things but not all. In 2014, the music video for Gangham Style surpassed the 32-bit number limited of 2,147,483,647 video views on YouTube, prompting the website to upgrade its counter to a 64-bit integer.

Internally, most computers store the current time as the number of seconds since midnight 1^st January 1970; 2,147,483,647 seconds after that date is 03:14:07 on 19^th January 2038. Any attempt to process times after that may give us trouble on 32-bit systems. Some may crash, some may produce obviously wrong dates and values (i.e. some systems may think it’s 1904). In some scenarios subtle errors may creep into calculations with potentially disastrous results.

Times stored as 64-bits run out much, much later; beyond the lifetime of the universe.

Some developers were aware of the problem on 32-bit systems and used varying techniques to handle it, but it’s hard to know if the technique was consistently applied across an application or if testing was good enough. Applications also rely on other services to function (the “stack”) – do we know for sure that our databases and other services handle times correctly?

Why Consider this now?

2038 is a long way off, surely we have plenty of time to address this and it’s likely many of our current applications won’t be in use. True, but if your systems perform any kind of projection (i.e. work with dates in the future) then you may have problems much sooner than that:

• Systems using +20 years as equivalent to “never”
• Systems performing projections for events in 20-years time, e.g. in finance, government and healthcare. At worst you’ll have unnoticed errors in your projections with potentially serious impact.
• Architectural applications projecting lifespans of building and infrastructure projects.

So it’s not just a 2038 problem, it could be a 2018 problem.

Didn’t we fix this when we fixed the Y2K bug?

It depends.

• In some circumstances a rewrite of date handling was done, but in most cases fixing Y2K bugs one-at-a-time was the approach; further issues simply weren’t considered. In 1998 we simply didn’t worry about events 50-years ahead.
• Many Y2K fixes affected the display and input of dates, the internal processing wasn’t touched.
• Servers – some legacy operating systems and hardware may not be 2038 compliant.
• Clients – some browsers and desktop operating systems may not be 2038 compliant.
• File formats, RPC and API definitions may not be 2038 compliant.

2038 problem action plan

Dismissing the 2038 problem as something for a future generation to solve is the wrong course of action, steps should be considered today to see what impact, if any, the 2038 problem will have on your organisation’s systems. Here’s what you can do to kick start your 2038 problem solution:

• Judge the “2018” risk: Does your system make projections against future events? What is the impact of a projection producing invalid results or failing altogether? Do you use +20 years as a shortcut for “never”?
  • If you do not have a “2018” risk, then you may defer 2038 investigation and fixes to a future date.
• Having a 64-bit platform is not enough, 32-bit applications may be running on 64-bit platforms or in some circumstances 32-bit dates have been used in 64-bit applications.
• Testing – with modern systems we can easily “mock” system dates for testing, but for older applications we must actually set the system time before testing.
• Consider the stack – we may have old/unsupported versions of databases and other services. When testing ensure the entire production stack is replicated.
• Code – All modern programming languages have support for “date objects” that “hide away” complexities of date and times, including the 2038 problem. However, developers often bypass these, so risks may still be present. A detailed review of all date processing is required.
• File formats, RPC and API definitions that use 32-bit dates may require workarounds or redevelopment.
• Check hardware and operating systems for 2038 compatibility.

Summary

We need to avoid another Y2K. We have plenty of time before we hit 2038, but it’s possible that we’ll hit problems much sooner than that if we do any kind of date projection in our software. Here we’ve outlined some of the risks and an action plan to start addressing the issue.