The 2038 Problem

The "Harmless" Y2K

Remember the "Year 2000" problem (or Y2K) in the late 90s? This referred to the fact that many older computer systems represented years using only two digits. This meant that when the year 2000 arrived, many systems would incorrectly display it as "00" instead of "2000", causing errors with dates and calculations.

While I was a teenager at the time, I was already into computers so it fascinated me and I was glued to the screen reading about it. When the New Year eve hit... nothing happened. Life continued as normal, so all the non-technical people around me said this "threat" was blown out of the proportion to make some news headlines. What I didn't know is that behind the scenes there was a massive efforts to remediate systems to avoid major disruptions when the actual date arrived.

This is a great example of "Preparedness paradox". When a potential disaster is properly prepared for, it won't seem like a big deal after the fact. People will think the precautions were unnecessary. But Y2K could have been a major catastrophe if nothing was done. Some estimates suggested failures in key systems could lead to blackouts, air travel shutdowns, supply chain issues and even nuclear missile system failures.

The End of Time

"The 2038 problem" relates to an issue with how Unix-based systems store dates and timestamps. Most Unix systems use a 32-bit signed integer to represent the number of seconds since January 1st, 1970. This is known as the Unix epoch or Unix time.

The core of the issue is that a 32-bit variable can only store integers up to 2147483647. Once the system clock ticks past this at 03:14:07 UTC on January 19, 2038, it will integer to overflow, setting its value to −(2³¹) , wreaking havoc from there:

When this overflow happens, any application relying on the correct Unix time stamp will fail or behave erratically. Dates will suddenly show as being in December 1901, calculations will be off, comparisons won't work properly, and overall system functionality will break.

The Impact

What systems can be impacted by this issue if we don't act accordingly:

• Legacy Systems and Embedded Devices: many older systems, especially those in critical infrastructure like nuclear power plants, airplanes, healthcare devices, telecommunications equipment, and embedded systems in consumer electronics are using 32-bit time representations. These systems are often not updated or replaced frequently, making them the biggest threat.
• Operating Systems: some older or less maintained operating systems that still rely on 32-bit time representations will face issues. Although many modern operating systems have transitioned to 64-bit time representations, legacy versions and systems might still be in use in certain environments.
• Databases: some databases still operate with 32-bit time fields and apps rely on UNIX_TIMESTAMP() type of queries.
• File systems: older file system versions still use 32 bits to represent times in the inodes.
• Networking Equipment: networking protocols and systems that use 32-bit time stamps for scheduling, logging, timeout management, etc could fail.
• Financial Systems: banking and financial systems that use 32-bit timestamps for transaction processing, logging, or future date calculations may also be impacted.

Essentially any software, service, business or personal function that relies on accurate recording of dates and times is at risk if steps are not taken to address the 2038 problem. And the risks go beyond just computer failures - they extend to legal, financial, scientific and other integrity issues. I don't consider myself a prepper, but proactive remediation is needed to avoid catastrophe.

Let's do a little experiment. Set your system date past January 19, 2038 and see if the software you are working on is still functions properly. Chances are it might break.

The Mitigation

We are only 14 years away. The time is running out fast, but the good news the tech community is already working on mitigation, in order to address the risks before 2038.

Some OSS examples I found of what being done proactively:

• Linux is ready to the end of time
• Debian efforts to address Y2K38
• LWN coverage of 2038 progress
• XFS addresses 2038 problem
• MySQL functions to support 64-bit unix timestamp
• Memcached fixes log timestamps

Implementing the following actions today can significantly reduce your chances of hitting the bugs in your systems:

• Identify the inventory of vulnerable systems by thorough inspections and testing to uncover any sections of code, libraries, or dependencies susceptible to the 2038 issue.
• Transition to a 64-bit system for the storage and management of date and time information, greatly increasing the range of dates that can be accommodated.
• Adopt alternative formats for date and time, such as ISO 8601, to enhance the robustness and compatibility of data handling.
• Perform required software, firmware or hardware upgrades and migrations to ensure your systems are future proof. Easier said than done, as some of this would require significant capital/operating investments and multi-year journey to finish.

Closing Thoughts

The Year 2038 bug is real and will bite us if systems are not properly updated. While it may seem distant, the task of updating legacy infrastructure is monumental and time-consuming. We cannot afford to delay.

And I don't know about you, but I'm definitely not flying or driving anywhere that day 😄