Year 2038 Problem

In brief: Many computers count time as the number of seconds since 1 January 1970. On systems that store that count in a signed 32-bit number, the count runs out at 03:14:07 UTC on 19 January 2038. One second later the number "wraps around" and the computer thinks it is December 1901. Most modern desktops, servers and phones are already fixed, but older software, 32-bit embedded devices, file formats and databases that still use 32-bit time can fail. Some of them fail years early, as soon as they handle a date after 2038.

Overview

What time_t is

Unix and Unix-like systems, and the C language they spawned, represent a moment in time as a single integer: the number of seconds since the Unix epoch, 1970-01-01 00:00:00 UTC. The C type that holds the count is time_t. Functions such as time(), gmtime(), mktime() and stat(), together with the timestamps of almost every file on a Unix file system, are built on it. The same "seconds since 1970" convention spread well beyond C and Unix. It turns up in network protocols, database column types, file formats, embedded firmware, and the runtimes of languages such as Java, PHP and Python.

For decades time_t was a signed 32-bit integer on most platforms, because long was 32 bits wide on the 16- and 32-bit machines where Unix grew up. A signed 32-bit integer holds values from −2,147,483,648 to +2,147,483,647, so it can represent:

The exact overflow moment

At 2038-01-19 03:14:07 UTC a signed 32-bit time_t reaches its maximum value. Adding one more second causes an integer overflow. On two's-complement hardware, which is effectively all hardware, the value wraps to −2,147,483,648. Software then reads that value as 1901-12-13 20:45:52 UTC ^[1][2]. Depending on the program, the result can be a date shown in 1901, a negative interval, a timer that never fires or fires at once, an expired certificate, a failed mktime() that returns −1, or a crash.

Why signed 32-bit?

time_t was signed so that dates before 1970 could be stored as negative numbers, and so that subtracting two times gives a negative difference without special handling. The cost is that half the range is spent on 1901–1970, so the forward range ends in 2038 and not in 2106. Some systems took the opposite trade-off: they made the 32-bit count unsigned, which pushes the limit to 2106 but makes pre-1970 dates unrepresentable. OpenBSD ^[3], glibc's utmp/lastlog records ^[4], Linux struct input_event ^[5] and QNX before SDP 8.0 ^[6] all made this choice in some form. See Year-2106-and-Beyond.

Technical details

Worked binary example

The largest signed 32-bit value has a 0 sign bit followed by thirty-one 1s:

2147483647  = 0111 1111 1111 1111 1111 1111 1111 1111   -> 2038-01-19 03:14:07 UTC
        + 1
-----------------------------------------------------------------------------
-2147483648 = 1000 0000 0000 0000 0000 0000 0000 0000   -> 1901-12-13 20:45:52 UTC

The bit pattern 0x80000000 is exactly 2³¹. In a signed two's-complement interpretation the top bit is the sign bit and carries a weight of −2³¹. The same bits that meant "one second after 2038-01-19 03:14:07" therefore now mean "2,147,483,648 seconds before 1970". In C, signed overflow is formally undefined behaviour, so an optimising compiler is free to do something even stranger than wrapping.

You can reproduce the two endpoints with GNU date:

$ date -u -d @2147483647
Tue 19 Jan 2038 03:14:07 UTC
$ date -u -d @-2147483648
Fri 13 Dec 1901 20:45:52 UTC

A minimal C demonstration of how a 32-bit counter misbehaves:

#include <stdint.h>
#include <stdio.h>
#include <time.h>

int main(void) {
    int32_t t32 = INT32_MAX;              /* 2038-01-19 03:14:07 UTC */
    t32 = (int32_t)((uint32_t)t32 + 1u);  /* wrap explicitly (defined behaviour) */
    time_t t = t32;                       /* widen to the platform's time_t */
    printf("%s", asctime(gmtime(&t)));    /* Fri Dec 13 20:45:52 1901 */
    printf("sizeof(time_t) = %zu\n", sizeof(time_t));
    return 0;
}

The fix: 64-bit time_t

A signed 64-bit time_t gives a range of about ±292 billion years, which in practice removes the problem. The underlying change is simple. Deploying it is not, because time_t is embedded in ABIs (struct stat, struct timespec, struct timeval, struct utmp, ioctl structures, library interfaces), in on-disk formats and in wire protocols. Widening the type changes struct layouts, so binaries and libraries compiled against the old size become incompatible with the new one. This is why the fix took decades on 32-bit platforms:

• 64-bit platforms (LP64: x86-64, AArch64, ppc64, RISC-V 64 and others) have used a 64-bit time_t from their first day on Linux, the BSDs, macOS and Solaris.
• 32-bit platforms needed new kernel system calls, new C-library entry points, and a rebuild of the whole userland. On Linux this took from roughly 2014 to 2024. See OS-Linux.
• Standards: POSIX.1-2024 (Issue 8) now requires that "time_t shall be an integer type with a width … of at least 64 bits" ^[7][8].

Not just time_t

A 64-bit time_t does not help when a timestamp is squeezed back into 32 bits somewhere else. Common hiding places include:

• On-disk timestamps: ext2/ext3 and ext4 with 128-byte inodes, XFS without bigtime, UFS1, HFS+ (2040). See File-Systems.
• Database column types and functions such as TIMESTAMP and UNIX_TIMESTAMP(). See Databases.
• Binary file and network formats with 32-bit seconds fields, such as utmp/wtmp, PE headers, cpio and many proprietary formats. See File-Formats-and-Protocols.
• Application code that casts time_t to int or long, or that stores it in a 32-bit field of a struct.
• Related counters with different rollover dates: NTP era 0 ends in 2036 (NTP-Era-2036) and GPS week numbers roll over every 1024 weeks (GPS-Week-Rollover).

History of awareness

Current state of industry fixes (as of 2026-10-21)

The detailed matrix is on Operating-Systems.

Why it matters now: future dates

The rollover is about 11 years and 3 months away (4,108 days from 2026-10-21), but software meets 2038 long before the clock reaches it. Any calculation that projects into the future can cross the boundary today:

• Long timeouts and expiry dates. AOLserver failed in 2006 because "now + 1 billion seconds" passed 2038 ^[2]. Certificates, licences, tokens and cookies issued with very long lifetimes behave the same way. Oracle Access Manager hit a post-2038 cookie expiry in 2022 (secondary source) ^[2].
• Finance and insurance. A 30-year loan or bond issued in 2008 or later matures after January 2038.
• Scheduling, warranties, retention and compliance dates that are set 10–20 years ahead.
• Clock errors. A misbehaving NTP server or RTC can push a device's clock into 2037 or past 2038 without warning. In a 2024 report a private CA, fed bad time by a faulty NTP source, began issuing certificates "valid" from 2037 to 1910 ^[26].
• Long product lifecycles. Cars, PLCs, medical devices, meters, set-top boxes and routers sold in 2026 may well still be running in 2038. Many will never receive a firmware update. See Devices-and-Embedded-Systems and OS-Embedded-and-RTOS.

Affected versions / products

The per-OS pages carry the detailed tables:

Risk & compliance notes

• What to inventory. Inventory every 32-bit OS image and binary, each C library and its version, every database column and file format that stores epoch seconds, and every device with a multi-decade service life. Use the Risk-Assessment-Checklist.
• Ownership. The OS vendor fixes the kernel and libc. You own application code, data formats, firmware you ship, and the third-party binaries you cannot rebuild.
• Timing. Failures involving future dates are happening already. Failures driven by the clock arrive on 2038-01-19. Devices sold today may still be in the field on that date.
• Lessons from Y2K. Early inventory, testing with clocks set forward, and supplier attestations proved effective in Y2K remediation. See Y2K-Lessons-for-2038 and Y2K-Remediation-and-Cost.

Detection & mitigation

1. Check type widths: sizeof(time_t) on every target, and getconf LONG_BIT on Linux.
2. Rebuild 32-bit Linux userland with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 (glibc ≥ 2.34, kernel ≥ 5.1/5.6), or move to musl ≥ 1.2.
3. Test with clocks set past 2038 (for example faketime, or VMs and containers with a shifted clock) and with future-dated inputs.
4. Audit file systems (ext4 inode size, XFS bigtime), database types and binary formats.
5. Full procedures are in Testing-and-Detection and Remediation-Guide. Real-world failures are collected in Known-2038-Incidents.

See also

• Operating-Systems · OS-Linux · OS-BSD-and-Unix · OS-Windows · OS-macOS-and-iOS · OS-Android · OS-Embedded-and-RTOS
• Programming-Languages · Lang-C-and-CPP · Lang-Java-and-JVM · Lang-DotNet · Lang-Python · Lang-PHP · Lang-JavaScript-and-TypeScript · Lang-Go-Rust-Swift · Lang-Perl-Ruby-and-Others
• Devices-and-Embedded-Systems · Devices-Industrial-and-Infrastructure · Devices-Automotive-Aviation-Medical · Devices-Networking-and-IoT
• Databases · File-Systems · File-Formats-and-Protocols
• Year-2000-Problem · Y2K-Timeline · Y2K-Remediation-and-Cost · Y2K-Incidents · Y2K-Lessons-for-2038
• Related-Date-Bugs · GPS-Week-Rollover · NTP-Era-2036 · Year-2106-and-Beyond
• Testing-and-Detection · Remediation-Guide · Risk-Assessment-Checklist · Known-2038-Incidents · Articles-and-Sources · Glossary

References

1. Pondering 2038 — LWN.net (Jonathan Corbet), 2013-08-14. Linux options, the OpenBSD ABI break, and the embedded lifespan concern.
2. Year 2038 problem — Wikipedia. Secondary overview: the AOLserver 2006 failure, the Oracle Access Manager 2022 cookie issue, and a solutions table.
3. OpenBSD 5.5 release page — OpenBSD, 2014-05-01. "time_t is now 64 bits on all platforms". Unsigned 32-bit fields are "good till the year 2106".
4. glibc NEWS file (mirror of sourceware glibc.git) — GNU C Library. 2.34: _TIME_BITS=64, which requires LFS and kernel ≥ 5.1. 2.40: utmp/lastlog fields made unsigned (to 2106).
5. [GIT PULL] y2038: core, driver and file system changes — Arnd Bergmann, LKML, 2020-01-29. Linux 5.6 readiness, the 5.1 time64 syscalls, input_event moved to unsigned, and remaining file systems.
6. What time is it? (QNX OS 8.0 Programmer's Guide) — BlackBerry QNX. Previous releases used unsigned 32-bit seconds; 8.0 uses signed 64-bit.
7. Austin Group defect 1462: time_t width — Austin Group. Accepted requirement for a 64-bit time_t in Issue 8.
8. <sys/types.h> — POSIX.1-2024 (The Open Group Base Specifications Issue 8). "time_t shall be an integer type with a width … of at least 64 bits."
9. 32-bit 2038 issue — tz mailing list, November 1997. Early discussion of 2038 and LP64 time_t.
10. Re: time_t size: The year 2038 bug? — linux-kernel, 2000-01-05. The 2000 kernel thread on widening time fields.
11. Announcing NetBSD 6.0 — The NetBSD Project, 2012. "time_t is now a 64-bit quantity on all NetBSD ports."
12. Pondering 2038 — LWN.net, 2013-08-14. Reports Philip Guenther's OpenBSD 64-bit time_t commit of 2013-08-12.
13. Making inode time stamps y2038 ready (RFC 00/32) — Arnd Bergmann via LWN, 2014-05-30. The first Linux y2038 series.
14. Solving the Year 2038 problem in the Linux kernel — Deepa Dinamani, opensource.com, 2019-01-21. VFS timestamp conversion merged in June 2018.
15. y2038: add time64 syscalls — Arnd Bergmann via LWN, 2019-01-10. Syscall series for the 5.1 merge window.
16. musl 1.2.0 released — musl mailing list (Openwall), 2020-02-20. "moves all 32-bit archs to 64-bit time_t".
17. Microsoft Exchange year 2022 bug in FIP-FS breaks email delivery — BleepingComputer, 2022-01-01. Value 2,201,010,001 exceeded the signed int32 maximum.
18. ReleaseGoals/64bit-time — Debian Wiki. Transition began 2024-02-27; i386 and hurd-i386 excluded.
19. Ubuntu 24.04 LTS release notes — Canonical. "Ubuntu 24.04 LTS solves the Year 2038 problem that existed on armhf."
20. Debian 13 "trixie" release notes §2.2.6 — Debian. "All architectures other than i386 now use a 64-bit time_t ABI." Released 2025-08-09 per Debian News.
21. FreeBSD 15.0-RELEASE Release Notes — FreeBSD Project. i386, armv6 and 32-bit powerpc retired; armv7 remains.
22. arch(7) — FreeBSD Manual Pages. "time_t is 8 bytes on all supported architectures except i386."
23. time, _time32, _time64 — Microsoft Learn. time_t is 64-bit by default. _USE_32BIT_TIME_T is discouraged and not allowed on 64-bit.
24. FILETIME structure — Microsoft Learn. 64-bit count of 100 ns intervals since 1601-01-01 UTC.
25. 32-bit ABI bugs (bionic docs) — Android Open Source Project. "On 32-bit Android, time_t is 32-bit, which will overflow in 2038."
26. IT incident report: VPN CA certificates dated 2037–1910 — The Register, 2024-02-09. A CA with 2037→1910 validity dates caused by 32-bit time and bad NTP.