2038 Bug Survival Guide: Lessons From Leap Year Code Issues

The 2038 bug refers to a known issue with how millions of systems store and calculate dates and times. It’s expected that this bug will cause dates and times to be incorrect starting January 19, 2038.

You may be thinking to yourself, “A wrong date? A wrong time? So what!” But what about a wrong date in a banking database that routinely schedules transfers and payments? Or the wrong time on a server that causes an SSL certification for a website to expire, exposing visitors to potential security risks?

The reality is the 2038 bug isn’t the first and won’t be the last time date and time calculation issues have affected the systems we use daily.

In fact, since 2024 is a leap year, we can draw many parallels between issues with accounting for leap years in systems and the upcoming 2038 bug to help us better understand what can cause incorrect date and time calculations and their potential impact.

The 2038 bug is not a hypothetical scenario, but a real threat that could affect a wide range of systems, such as embedded systems/devices, Internet-of-Things (IoT) devices, operating systems, databases, servers, networks, applications, and web services. This post aims to provide a deeper understanding of what the 2038 bug is, including some real-world examples and best practices you can start following today to help prevent significant issues in the not-so-distant future.

First, we’ll provide a brief overview of similar problems that can occur when calculating leap years in systems to help set the stage for understanding the more complex 2038 bug and why it matters for device security.

What leap years can teach us about date and time calculations

In 2024, the world will experience a rare event: a leap year. This means that February will have 29 days instead of 28, adding an extra day to the calendar… and an unaccounted day in some software and hardware systems.

Why is that? Many legacy systems contain oversimplified leap-year logic that can lead to systems incorrectly skipping from February 28 to March 1, which, in turn, can cause malfunctions in date and time calculations.

A standard rule used for determining whether a year is also a leap year is if it is divisible by four. However, there are additional exceptions not commonly factored into this calculation that can cause it to be incorrect: a year must be divisible by four except if the year is also divisible by 100, and unless it is also divisible by 400.

Let’s take the year 2100 as an example. Since 2100 is divisible by four, some systems may mistakenly assume it will be a leap year. Using the remaining leap year calculation logic, we can determine that while 2100 is divisible by 100, it is not divisible by 400. So, 2100 is actually not a leap year.

Skipping a day every four years may seem like a minor detail, but date and time calculation issues like this can have serious consequences for systems and their users.

Another, more ominous examples of date and time calculation issues is the upcoming 2038 bug, which could potentially cause serious problems for computers and devices. Let’s drill deeper into what and why this is this case.

What is the 2038 bug?

The 2038 bug, also known as the Unix Millennium Bug or Y2K38, is a problem that arises from the way some systems store and represent date and time values using a number called a timestamp.

A timestamp is the number of seconds that have passed since January 1, 1070, which is called the Unix epoch. For example, the timestamp for January 1, 2024, at 01:00:00 UTC, is 1704070800, which means 1704070800 seconds have passed since the epoch.

However, some systems use a data type called a signed 32-bit integer to store the timestamp in the Unix operating system and its derivatives. A signed 32-bit integer can only store numbers from -2147483648 to 2147483647. This means the highest timestamp these systems can handle is 2147483647, which corresponds to January 19, 2038, at 03:14:07 UTC. After that, the timestamp will overflow and become a negative number, which will cause the date and time to be wrong.

For example, the timestamp for January 20, 2038, in Unix time is 2147483648. Since this is not a valid timestamp using the Unix format, it will overflow and become -2147483648, which corresponds to December 13, 1901, at 20:45:52 UTC. This is the year 2038 bug.

Types of systems affected by the 2038 bug

Many people anticipate that the bug will cause serious problems for systems that rely on 32-bit signed integers to store the date and time, resulting in incorrect and unpredictable behavior that could affect functionality and security, such as crashes, errors, and data loss.

Let’s explore types of systems known to use Unix-based timestamps to store dates and times that could be affected by the 2038 bug:

• Databases: Several database types, including relational and NoSQL databases
• C programs: C programs and other programs written in languages based on C, such as C++ and PHP
• Embedded systems and devices: Medical devices, industrial control systems for facilities like power stations, transportation systems, cars with onboard computer systems that monitor electronic stability control and traction control, routers, switches, sensors, sensors, and IoT devices like smart appliances
• Operating systems: Windows, Linux, and Linux-based operating systems like Android and iOS for cell phones

Recent examples of the year 2038 bug

Some systems are already showing the impact of the 2038 bug in a number of different ways.

For example, developers may use dates that are far in the future for things like scheduling, expiration, or encryption, such as using the date 9999-12-31 as a placeholder to achieve an indefinite or infinite period. However, this date is roughly equivalent to 253402236000 and greatly exceeds the maximum value for the Unix time format.

Others may use future dates beyond 2038 for testing or simulation purposes or for representing historical or geological events that occurred before the common era. In all these scenarios, the year 2038 problem can cause incorrect outputs, errors, and unreliable outcomes.

Here are some real-world examples of systems that have already experienced similar issues related to the use of Unix timestamps:

• Servers crash: On May 13, 2006, AOLserver, AOL’s open-source web server, crashed due to setting the database request timeout to 1 billion seconds, or about 32 years in the future.
• Unexpected downtime: A large specialty retailer experienced a VPN hardware outage due to certificate authority (CA) failures causing mistakes when calculating two dates: notBefore (the date before the CA isn’t valid) and notAfter (the expiration date). Due to additional Network Time Protocol (NTP) issues, the CA believed it was 2037, and since the CA signs certificates to be valid for ten years, it ran into the 2038 problem when calculating expiration dates.
• Systems break: In 2014, the music video for Gangnam Style broke both records and YouTube when it hit 2,147,483,647 views since this view count is also the maximum value Unix systems can record.

Tips on preventing the 2038 bug

Fixing the 2038 bug requires upgrading, removing, or replacing the 32-bit signed integer data type in systems and any code it interacts with, which can be costly and time-consuming. However, taking the following preventative measures now to update your systems, applications, and devices could make a significant difference come January 19th:

• Utilizing a 64-bit format to store and represent date and time values will extend the range of possible values to billions of years
• Using different date and time formats to store and represent values, such as the ISO 8601 format
• Testing and auditing for potential date and time issues to identify outdated code, libraries, or software that may be vulnerable to the 2038 bug
• Updating and patching code, software, and devices regularly to ensure they are compatible with the latest standards and technology

Many companies are already aware of the year 2038 problem and taking proactive steps to update their systems to use 64-bit data types or alternative representations for timestamps and date values. For example, Apple began to build 64-bit support into macOS starting in 2003, which can help ensure Mac users will not encounter issues with dates after January 2038.

Can the year 2038 problem be solved?

Both the 2038 bug and the 2024 leap year are reminders that date and time calculations are not trivial but complex and critical aspects of code and software development. The good news is the year 2038 problem is not the inevitable apocalypse some articles paint it to be if proactive measures are taken.

By being aware of the potential problems and prioritizing solutions, you can more easily minimize the impact of the 2038 bug and help ensure your systems run smoothly and securely for a long time.

How can you begin addressing the 2038 bug in your environment? One way is by gaining comprehensive visibility into your assets and their software statuses. By monitoring and scanning your endpoint devices regularly, you can more easily identify devices running outdated code or software, replace any devices near the end of their life cycles, or update those using 32-bit systems that may be more prone to the 2038 bug.

Since changing the data type and code that deals with the 2038 bug can introduce errors, compatibility issues, and performance degradation, having real-time visibility into your devices can help you better prevent potential vulnerabilities and endpoint security risks.

Learn how Tanium’s Converged Endpoint Management (XEM) platform is built to simplify endpoint management and offers features to streamline your efforts while also empowering users, such as automating configuration enforcement, responding quickly to threats, and enabling employees to self-remediate common issues all in one solution.

Additionally, our approach to Autonomous Endpoint Management (AEM) will integrate further AI-assisted capabilities into the Tanium XEM platform to provide automation recommendations and associated, highly-tunable smart actions, designed with safety, security, and scalability in mind.