Year 2038 problem facts for kids

An animated visual of the bug in action. This problem will happen at 03:14:08 UTC on 19 January 2038.

The year 2038 problem (also called Y2038 or Epochalypse) is a computer bug. It means some computer systems will not be able to tell the correct time after 03:14:07 UTC on 19 January 2038. This happens because of how these computers store time.

Many computers count time as the number of seconds that have passed since 00:00:00 UTC on 1 January 1970. This starting point is called the "Unix epoch". These systems store this number in a special way called a signed 32-bit integer. Think of it like a digital counter that can only count up to a certain number. For a 32-bit integer, the biggest number it can hold is 2,147,483,647.

When the number of seconds reaches this limit (which happens on January 19, 2038), the computer tries to add one more second. But because it can't hold a bigger number, it "overflows." This means the number suddenly flips to a very large negative number. The computer then thinks the date is actually in 1901! This problem is similar to the year 2000 problem (Y2K), but it's about how computers count in binary (base-2) numbers, not base-10.

Computers that use time for important tasks could have serious errors if this problem is not fixed. Some programs that use future dates have already run into this bug. The systems most at risk are older ones that are rarely updated. These include old and embedded systems. Newer systems and updates for older ones fix this by using a bigger number type called a 64-bit integer. This new counter would take about 292 billion years to overflow, which is much longer than the estimated age of the universe.

How the Problem Happens
Systems That Could Be Affected
- Embedded Systems
Early Problems Seen
Solutions to the Problem
- Solutions That Have Been Put in Place
See also

How the Problem Happens

Many computer systems use Unix time to keep track of dates and times. Unix time is a way to measure time as the number of seconds that have passed since 00:00:00 UTC on January 1, 1970. This specific moment is known as the Unix epoch.

Historically, Unix time has been stored as a signed 32-bit integer. This is a type of number that uses 32 binary digits (bits). The word 'signed' means it can store both positive and negative numbers. A signed 32-bit integer can only hold numbers from about -2.1 billion to +2.1 billion.

Because of this limit, the latest time a signed 32-bit integer can store is 2,147,483,647 seconds after the Unix epoch. This exact moment is 03:14:07 UTC on 19 January 2038. If a system tries to add one more second, the number becomes too big for its storage space. This causes an integer overflow. The number then flips to a negative value, making the computer think it's a date in the past, specifically 20:45:52 UTC on 13 December 1901. Since many computer systems rely on correct time for important tasks, this bug could cause serious issues.

Systems That Could Be Affected

Any computer system that uses 32-bit numbers to store time could be at risk. It's hard to list every single system, but some common ones include:

File systems like ext2 and ext3 that use 32 bits for time stamps on files.
Databases that have time fields stored as 32-bit numbers.
Database languages like SQL that use commands similar to UNIX_TIMESTAMP().

Embedded Systems

Embedded systems are small computers built into other machines. They are often found in cars, planes, and other devices. These systems are very likely to be affected by the Y2038 problem if they use dates for calculations or logging. Embedded systems are designed to last a long time, sometimes for the entire life of the machine they are in. It's possible that many of these systems will still be in use in 2038. It might be difficult or even impossible to update the software on these systems. If they can't be updated, they might need to be replaced entirely to fix the 32-bit time limit.

Many transportation systems, like cars and airplanes, use embedded systems. In cars, these can control things like anti-lock braking systems (ABS) or electronic stability control (ESC). Airplanes use them for navigation and GPS. Cell phones and internet devices like routers also use embedded systems. These devices need to keep accurate time and date. For example, some older cell phones running 32-bit Android from around 2010 would crash if their time was manually set to a date in 2038.

However, not all embedded systems will have this problem. Many don't need to know the exact date. Also, systems that only track the difference between two times, rather than an absolute date, might not be affected.

Early Problems Seen

Even though the main problem is set for 2038, some systems have already shown signs of the bug. In May 2006, the AOLserver software had an early issue. This software was designed to handle database requests that should "never" time out. Instead of a special code for this, it used a very far-off date in the future. The default setting was for requests to time out after one billion seconds.

However, one billion seconds before the 2038 cutoff date was May 13, 2006. So, any requests sent after this date would try to set a time-out date that was beyond the 2038 limit. This caused the time-out calculations to overflow, making the software think the time-out date was in the past. This caused the software to crash. When this was found, AOLServer operators had to change the settings to a lower time-out value.

Solutions to the Problem

There isn't one single fix for the Year 2038 problem that works for every system. For example, in the C programming language, changing how the time t data type works would break older programs. If time_t was changed to an "unsigned" 32-bit integer, it would extend the date range to 2106. But then, programs that deal with dates before 1970 (which are stored as negative numbers) would have problems. Making time_t a 64-bit number would also change how programs work and might make them incompatible with older versions.

Most modern operating systems that run on 64-bit hardware already use signed 64-bit time_t numbers. Using a 64-bit value means the next time it could overflow would be in about 292 billion years. This is much, much longer than the age of the universe!

Other ideas have been suggested, and some are already in use. These include storing time as milliseconds or microseconds since 1970 in a signed 64-bit integer. This would give a range of at least 292,000 years. For example, Java and JavaScript use 64-bit numbers for timestamps, which will work correctly for the next 292 million years. Other new ways to store time offer different levels of precision and range, and can also solve other issues like handling leap seconds.

Solutions That Have Been Put in Place

Since Ruby version 1.9.2 (released in 2010), the year 2038 bug is fixed. It stores time in a signed 64-bit integer, even on systems that use 32-bit time_t.
NetBSD operating system, starting with version 6.0 (released in 2012), uses a 64-bit time_t for both 32-bit and 64-bit computers. Older programs still use the 32-bit system and might have the Y2038 problem.
OpenBSD version 5.5 (released in 2014) also uses a 64-bit time_t for all systems. However, older programs might not work correctly with this change.
Linux originally used a 64-bit time_t only for 64-bit computers. But starting with version 5.6 in 2020, 64-bit time_t is also supported on 32-bit systems. This was mainly done for embedded Linux devices.
The GNU C Library (since version 2.34 in 2021) now supports using 64-bit time_t on 32-bit systems with the right Linux versions.
FreeBSD uses 64-bit time_t for most systems, except for 32-bit i386, which still uses signed 32-bit time_t.
The x32 ABI for Linux, a new environment for programs, uses a 64-bit time_t.
Network File System version 4 (since 2000) uses 64-bit numbers for time.
The ext4 filesystem, when using larger inode sizes, has extra bits to extend the timestamp range to the year 2446.
The XFS filesystem, starting with Linux 5.10, has an optional "big timestamps" feature that extends the timestamp range to the year 2486.
OpenVMS C runtime library was updated in 1998 to use unsigned 32-bit integers for time, extending its range to 7 February 2106.
As of MySQL 8.0.28 (released in 2022), functions like FROM_UNIXTIME() and UNIX_TIMESTAMP() can handle 64-bit values on systems that support them. This includes 64-bit versions of Linux, macOS, and Windows.
As of MariaDB 11.5.1 (released in 2024), the TIMESTAMP data type and related functions handle unsigned 32-bit values on 64-bit systems. This extends the range to 2106-02-07 06:28:15.
Since Visual C++ 2005, the C runtime library uses a 64-bit time_t. The Windows API itself is not affected by the 2038 bug. Windows tracks time using 64-bit numbers, which will not overflow until the year 30,828.