97 systems, products, formats and practices, with the ones that will break listed first. Confirmed means there is a vendor advisory, a CVE, a documented limit or a demonstrated failure. Likely is a judgement about a whole class of device (typical software and lifetimes) where no specific product has failed in public yet. Each entry links to the page that carries its sources.
Fails at or before its deadline unless something is changed. Ordered by impact, with confirmed items first.
Why: CISA ICSA-25-261-07. Changing the system time past the limit causes authentication errors and denial of service.
What to do: Update to 4.20.3 or 5.20.3.
Details & sources →Why: CISA ICSA-25-296-03. At 2038-01-19 the clock "resets to December 13, 1901", disrupting login, history and leak-detection functions. The failure can be triggered early by time manipulation.
What to do: Apply the vendor fix when released (pending at publication, 2025-10-23), and restrict network access to time settings.
Details & sources →Why: CERT@VDE advisory VDE-2025-007. A low-privileged user can set the date past the 32-bit limit, and functions may misbehave or stop.
What to do: Update to firmware 4.10.0 (FW32).
Details & sources →Why: These have 15–20+ year lifetimes. IEC 61850 Edition 1 timestamps are signed 32-bit, and GPS/PTP timing chains add separate rollover risks.
What to do: Check IEC 61850 edition support and firmware, and include GPS-disciplined clocks in the inventory.
Details & sources →Why: Typical service life is 15–30 years, and many run 32-bit RTOS or Linux firmware. Researchers have triggered 2038 failures early in real ICS devices by manipulating NTP or GPS time.
What to do: Inventory firmware and OS versions, ask vendors for a written 2038 statement, and plan replacement where no fix exists.
Details & sources →Why: These have 10–15+ year lives, and firmware changes need re-certification. No FDA 2038-specific guidance was found.
What to do: Add 2038 to procurement and lifecycle reviews, and ask manufacturers for statements early because fixes take years.
Details & sources →Why: These have 10–20 year lifetimes, legacy embedded stacks and NTP/PTP/GNSS timing chains. A wrong date on one timing card spread across Telstra's network in 2026.
What to do: Assign an owner to the timing chain, monitor time sources around the clock, and get vendor statements.
Details & sources →Why: These are 32-bit MIPS/ARM systems with C libraries that have a 32-bit time_t.
What to do: Move to OpenWrt 22.03 or later, or vendor firmware built on musl 1.2+ or another time64 C library. Otherwise replace.
Details & sources →Why: Bitsight found that about 60% of public NTP servers revealing their OS ran old 32-bit systems. A wrong time from a server spreads to every client.
What to do: Use maintained time sources on 64-bit systems, and configure several independent servers.
Details & sources →Why: CERT@VDE advisory VDE-2025-020. Setting the date to 2038-01-19 resets system time to 1970 and corrupts log timestamps. The advisory states no fix.
What to do: Restrict who can set the time, and follow the vendor advisory for updates.
Details & sources →Why: These typically use 32-bit SoCs with BusyBox and old embedded web servers such as Boa, and rarely get updates.
What to do: Check for firmware updates, or plan replacement.
Details & sources →Why: These have long-lived embedded firmware with certificate checks, and Kaspersky names them as an at-risk class.
What to do: Ask vendors for 2038 statements, and test certificate handling with post-2038 dates.
Details & sources →Why: Vehicles have 150–300 ECUs from multi-tier suppliers and 15–20 year lifetimes. 32-bit Android head units have a 32-bit time_t, and ISO 15118 charging depends on certificate time checks. No public 2038 recall has been found.
What to do: Fleet operators should ask OEMs and charger vendors for 2038 statements.
Details & sources →Why: This already failed in March 2022. A cookie set about 500 million seconds ahead pushed dates past 2038, and some searches threw exceptions. This is reported by a secondary source only.
What to do: Apply Oracle patch 33983548.
Details & sources →Why: These run 32-bit Android or vendor Linux, where bionic's 32-bit time_t will not be changed.
What to do: Use devices with 64-bit userspace, or plan replacement.
Details & sources →Why: Bionic's time_t is 32-bit on 32-bit ABIs, and Google has no plan to adopt the kernel's time64 interfaces. The whole system is affected.
What to do: Specify 64-bit userspace in procurement, and plan replacement of 32-bit devices.
Details & sources →Why: Even glibc 2.34+ keeps a 32-bit time_t by default on 32-bit platforms. 64-bit time is opt-in.
What to do: Rebuild with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 (glibc 2.34+, kernel 5.1+). Rebuild all libraries that exchange time structures together.
Details & sources →Why: Kernels before 5.1 have no 64-bit time system calls for 32-bit programs, and 5.1–5.5 are incomplete.
What to do: Move to Linux 5.6 or later (or a vendor backport), then rebuild userland with 64-bit time.
Details & sources →Why: No time64 support. uClibc-ng is common in older embedded and router SDKs.
What to do: Upgrade to 1.0.46+ with TIME64 enabled, on kernel 5.1+.
Details & sources →Why: These have a 32-bit time_t. VxWorks 7 supports 64-bit time_t only in a VSB configured for it.
What to do: Move to VxWorks 7 with a 64-bit time_t VSB.
Details & sources →Why: Native code in a 32-bit app uses the 32-bit ABI, even on a 64-bit phone.
What to do: Ship 64-bit (arm64-v8a) native libraries.
Details & sources →Why: 64-bit applications are safe, but 32-bit ones keep a 32-bit time_t. On illumos about 90% of utilities are still 32-bit, and HP-UX is past standard support.
What to do: Rebuild as 64-bit or migrate, and check JFS1 timestamps on AIX.
Details & sources →Why: A 2024 demonstration showed core functions breaking when the clock was set to 2038.
What to do: Move to 64-bit Windows.
Details & sources →Why: armhf and armel used a 32-bit time_t until the 2024 transition.
What to do: Upgrade to Debian 13 or Ubuntu 24.04 LTS, and rebuild third-party armhf software.
Details & sources →Why: Deliberately left on a 32-bit time_t so legacy binaries keep working.
What to do: Move workloads to amd64, and treat i386 only as a legacy-compatibility layer.
Details & sources →Why: These have a 32-bit time_t. ESP-IDF 5.0 moved to 64-bit.
What to do: Rebuild firmware with ESP-IDF 5.0 or later.
Details & sources →Why: FreeBSD i386 never moved to 64-bit time. The platform was retired in 15.0.
What to do: Move to amd64.
Details & sources →Why: These versions have a 32-bit time_t on 32-bit platforms. Older Alpine, OpenWrt and embedded images inherit it.
What to do: Upgrade to musl 1.2.0 or later and rebuild.
Details & sources →Why: On 32-bit microcontrollers, long-based time_t is 32-bit.
What to do: Use a toolchain built without _USE_LONG_TIME_T.
Details & sources →Why: These use the old 32-bit time_t. Microsoft warns such programs "may fail after January 18, 2038".
What to do: Rebuild with a current compiler and remove _USE_32BIT_TIME_T.
Details & sources →Why: These are capped at iOS 10 with a 32-bit time_t. The same devices needed emergency updates for the 2019 GPS rollover.
What to do: Retire these devices.
Details & sources →Why: 32-bit Darwin uses a 32-bit time_t. On 32-bit kernels, the kernel itself is affected too.
What to do: Retire or isolate these systems.
Details & sources →Why: These use a 32-bit seconds field even on x86-64. glibc 2.40 made it unsigned, which moves the limit to 2106.
What to do: Upgrade glibc and migrate tools off utmp/wtmp (for example to systemd-logind/wtmpdb).
Details & sources →Why: Application-level truncation to Int32 overflows in 2038.
What to do: Use long or DateTimeOffset end to end.
Details & sources →Why: This is the most common pattern in every language. A 64-bit OS doesn't help if the program truncates time to 32 bits, and it wraps silently.
What to do: Search code for 32-bit casts and fields around time values, and widen them to 64-bit or native time types.
Details & sources →Why: The JVM's own time types are safe, but application int fields wrap silently.
What to do: Use long or java.time.Instant.
Details & sources →Why: When PHP_INT_SIZE is 4, timestamps are limited to 1901–2038.
What to do: Use a 64-bit PHP 7+ build.
Details & sources →Why: These write 32-bit fields regardless of the language's internal range.
What to do: Use 64-bit pack codes and version the file format.
Details & sources →Why: time and datetime C conversions raise OverflowError after 2038-01-19. Pure-Python arithmetic is fine.
What to do: Use a 64-bit or time64 build of Python.
Details & sources →Why: Timespec and Timeval are 32-bit on linux/386, arm and mips. The fix (Go issue
What to do: Avoid raw syscalls on 32-bit targets, and use the time package.
Details & sources →Why: These coerce values to signed 32-bit, so epoch seconds wrap in 2038.
What to do: Use Math.floor or Math.trunc, and Float64Array, BigInt64Array or readBigInt64LE for stored times.
Details & sources →Why: DATEADD takes an int argument, so epoch seconds past 2038 overflow. SQL Server 2025 and Azure accept bigint.
What to do: Upgrade to SQL Server 2025 or Azure SQL (bigint argument), or convert epoch values in application code.
Details & sources →Why: Each returns or stores a 32-bit time value.
What to do: Use TIME8(), default 64-bit Lua integers, or time64 builds.
Details & sources →Why: A signed 32-bit column overflows at the same moment as time_t, in any database.
What to do: Migrate to BIGINT or a native timestamp type.
Details & sources →Why: These use 4-byte signed epoch seconds.
What to do: Upgrade to 11.8 LTS or later on 64-bit, allowing time for system-versioned tables to be rewritten.
Details & sources →Why: TIMESTAMP is stored as 4-byte epoch seconds and ends at 2038-01-19 03:14:07 UTC, regardless of platform. MySQL has not extended it.
What to do: Migrate to DATETIME, storing UTC explicitly because DATETIME has no implicit time-zone conversion.
Details & sources →Why: These functions were 32-bit until 8.0.28, which made them 64-bit on 64-bit platforms.
What to do: Upgrade to 8.0.28 or later on a 64-bit platform.
Details & sources →Why: These use a fixed 128-byte inode with 32-bit signed seconds.
What to do: Reformat as ext4 with 256-byte inodes.
Details & sources →Why: There is no room for the extra epoch bits. This is common in small and embedded images and older mke2fs profiles.
What to do: Check with tune2fs -l. Back up, recreate with mkfs.ext4 -I 256, and restore.
Details & sources →Why: The classic on-disk format ends in January 2038. Volumes made with older xfsprogs lack bigtime.
What to do: Upgrade offline with xfs_admin -O bigtime=1 (kernel 5.10+).
Details & sources →Why: SecondSinceEpoch is a signed 32-bit INT32 in Edition 1.
What to do: Move to Edition 2, which uses unsigned INT32U and reaches 2106.
Details & sources →Why: Certificates already carry expiry dates past 2038. Validators on 32-bit time_t misread them, and failures have been seen in OpenSSL, GnuTLS and Tor.
What to do: Use 64-bit time_t builds and current libraries, and test with certificates expiring after 2038 and after 2050.
Details & sources →Why: This format uses a 32-bit mtime, ending in 2038 or 2106 depending on signedness.
What to do: Use newc, odc or pax formats.
Details & sources →Why: This field uses 4-byte signed Unix times.
What to do: Write the NTFS extra field (0x000a), which has 64-bit times.
Details & sources →Why: NTP's 32-bit seconds field wraps on 2036-02-07, two years before 2038. Devices that boot without a real-time clock can't tell which era they are in, and may jump to 1900 or the wrong era.
What to do: Use era-aware NTP software, add an RTC or a firmware time floor, and test boot behaviour after 2036.
Details & sources →Why: The 10-bit week number rolls over on 2038-11-20/21. Receivers with stale pivot dates can fail earlier, on any weekend.
What to do: Record each receiver's firmware date, test with a GPS simulator, and prefer CNAV or multi-GNSS receivers.
Details & sources →Why: A wrong date at the source spreads to every client, as in the Telstra outage in July 2026.
What to do: Cross-check against independent time sources, and alarm on large jumps around the clock.
Details & sources →Safe only with a particular version, build or setting. Check yours.
Why: These run certified software with 25–40 year lives that is hard to change. Counter overflows have already grounded aircraft, such as the Boeing 787 248-day bug, though that was not a 2038 issue.
What to do: Raise 2038 with OEMs and include it in airworthiness and ground-system reviews.
Details & sources →Why: These run vendor network operating systems or embedded RTOS/Linux, and exposure is vendor-specific.
What to do: Get a vendor statement, and check SNMP, syslog and certificate handling.
Details & sources →Why: These usually run Linux. They are exposed through old ext3, 128-byte-inode ext4 or non-bigtime XFS volumes, and NFSv3 to 2106.
What to do: Check kernel and C library versions and file-system settings, and reformat or convert old volumes.
Details & sources →Why: Yocto 4.3+ builds 32-bit targets with 64-bit time_t and ships a 32bit-time QA check. Buildroot glibc toolchains need BR2_TIME_BITS_64. musl toolchains need nothing.
What to do: Use Yocto 4.3+, or enable BR2_TIME_BITS_64, and run the QA checks.
Details & sources →Why: The FreeRTOS kernel itself is not affected, but coreSNTP and libc-based application code may be. Zephyr 3.5+ with picolibc is 64-bit, and other libc configurations need checking.
What to do: Check the C library configuration and any SNTP and time-conversion code.
Details & sources →Why: time_t is unsigned 32-bit, which reaches about 2106, but code that casts it to a signed type breaks in 2038. QNX SDP 8.0 uses signed 64-bit.
What to do: Audit signed casts, or move to SDP 8.0.
Details & sources →Why: Native calls use the platform's time_t, and JDK-8279444 is still open.
What to do: Run 64-bit JVMs where possible, and test on the target platform.
Details & sources →Why: COBOL rarely uses Unix time internally, but PIC S9(9) COMP fields fed by other systems are 32-bit.
What to do: Check interface fields that carry epoch seconds.
Details & sources →Why: libc 0.2.178 and earlier use a 32-bit time_t on 32-bit glibc and musl. 0.2.179+ has an unstable 64-bit opt-in.
What to do: Track the libc crate's time64 support, and test on target.
Details & sources →Why: These are 32-bit fields. They are fine to 2106 when read as unsigned, but break in 2038 if code treats them as signed.
What to do: Check readers treat the field as unsigned. For krb5, cast with (time_t)(uint32_t) as MIT documents.
Details & sources →Why: DNSSEC uses uint32 with serial arithmetic (a ±68-year window), and JWT numbers are bounded only by the parser.
What to do: Use RFC 1982 comparisons and 64-bit parsing.
Details & sources →Why: The protocol uses 48-bit TAI seconds, but 32-bit implementations must handle all 48 bits.
What to do: Check embedded PTP stacks.
Details & sources →Not hit in 2038, but has another date limit. These are worth knowing about when you plan ahead.
Why: These use an unsigned 32-bit range. They are safe for 2038 but end on 2106-02-07.
What to do: Prefer BIGINT or native types for new schemas.
Details & sources →Why: These are 32-bit fields read as unsigned. Drivers that read the ObjectId as signed show 1901 dates after 2038.
What to do: Check that drivers treat the field as unsigned.
Details & sources →Why: These use unsigned 32-bit seconds since 1904, ending 2040-02-06 06:28:15 GMT.
What to do: Migrate to APFS.
Details & sources →Why: The protocol carries unsigned 32-bit seconds.
What to do: Use NFSv4, which has 64-bit seconds.
Details & sources →Why: These store a 7-bit year offset from 1980.
What to do: Use the ZIP NTFS extra field, or a modern file system.
Details & sources →Why: These are unsigned 32-bit seconds. They are informational, and they wrap in 2106.
What to do: Treat them as opaque or unsigned.
Details & sources →Why: A 32-bit count of hundredths of a second, which wraps about every 497 days. This is a recurring uptime wrap, not a calendar limit.
What to do: Handle the wrap in monitoring tools.
Details & sources →Why: The 13-bit week number lasts about 157 years, so the first CNAV rollover is in 2137.
Details & sources →Not affected by the 2038 overflow. The reason is given. "Not affected" applies to the platform or type itself. Application code built on it can still store time in 32 bits.
Why it's not affected: The 64-bit bionic ABI has a 64-bit time_t.
Details & sources →Why it's not affected: 64-bit Linux has used a 64-bit time_t since those ports began. The kernel, glibc and musl all agree.
What to do: Still check file systems, login records and application data formats.
Details & sources →Why it's not affected: Rebuilt in 2024–2025 with a 64-bit time_t, using the t64 library transition.
What to do: Rebuild any third-party armhf binaries. Debian warns of possible silent data loss otherwise.
Details & sources →Why it's not affected: 64-bit only since iOS 11. 32-bit apps no longer launch.
Details & sources →Why it's not affected: Catalina and later run only 64-bit apps, so time_t is 64-bit throughout.
Details & sources →Why it's not affected: The BSDs moved to 64-bit time_t on these platforms between 2012 and 2014, or used it from the start. Some fields are unsigned 32-bit and last to 2106.
Details & sources →Why it's not affected: In the modern CRT, time_t is 64-bit by default and valid to 3000-12-31.
Details & sources →Why it's not affected: Windows stores time as a 64-bit count of 100-nanosecond intervals since 1601, which lasts to about the year 30,828.
Details & sources →Why it's not affected: These use 64-bit 100-ns ticks from year 1 to 9999. Unix-time helpers return Int64.
Details & sources →Why it's not affected: Time.Unix() returns int64, valid for billions of years. UnixNano() alone is limited to 1678–2262.
Details & sources →Why it's not affected: These are 64-bit millisecond or second counts, good for hundreds of millions of years.
Details & sources →Why it's not affected: Date uses double-precision milliseconds, valid to the year 275760.
Details & sources →Why it's not affected: Perl 5.12 and Ruby 1.9.2 (both 2010) moved to 64-bit or arbitrary-precision internal time, even on 32-bit machines. Erlang integers grow as needed.
What to do: Still check pack('l'), XS modules and fixed-width binary matches.
Details & sources →Why it's not affected: PHP_INT_SIZE is 8, so timestamps are effectively unlimited.
What to do: Still check database columns and pack() formats.
Details & sources →Why it's not affected: time and datetime conversions use a 64-bit time_t on these builds.
Details & sources →Why it's not affected: A Double count of seconds since 2001.
What to do: Watch integer conversions such as Int32(timeIntervalSince1970).
Details & sources →Why it's not affected: Native date types are 7–8 bytes or text. PostgreSQL reaches 294276 AD, and the others 9999 or beyond.
What to do: The engines are safe, but check application columns and client conversions.
Details & sources →Why it's not affected: Each has 64-bit or extended timestamps. ext4 lasts to 2446 and XFS bigtime to 2486. Btrfs, ZFS, NTFS and APFS last centuries or more.
Details & sources →Why it's not affected: These use text or wide fields. pax is unbounded, ustar lasts to 2242, X.509 and Kerberos use GeneralizedTime to 9999, and DNP3 counts milliseconds since 1970 far into the future.
Details & sources →Why it's not affected: They resolve the era from the system clock or build date, and ntp.org has tested the 2036 transition.
What to do: On 32-bit systems they still depend on a 64-bit time_t for 2038.
Details & sources →No entries match. Try a broader filter, or browse the topics.
Missing something, or have evidence that changes a status? Email info@epoch2038.com. Register last reviewed 2026-10-21.