Y2038 Readiness Update - What's Ready and What Isn't in 2025

Y2038 Readiness Update – What’s Ready and What Isn’t in 2025

Abstract

Y2038 is a time-related rollover that will occur in ~12 years. Current regulations do not yet mandate Y2038 compliance, but auditors will eventually require proof of compliance for certification. Operating systems for 64-bit computers have been Y2038-compliant for years, but support in real-time operating systems (RTOS) is varied. Regardless, operating system compliance is not enough. The entire technology stack must be assessed and potentially mitigated. The recommended best practice is to start Y2038 assessment and mitigation NOW in existing products, and incorporate Y2038 risk analysis in all new designs.

What is Y2038 and Why It Matters in 2025

Many modern products contain microprocessors that use time in one way or another. Time is commonly represented as seconds and stored in an integer with a limited number of bits. An inevitable consequence is that time rollovers eventually occur. An abridged list of rollover events in the next century are shown in the table below.

Table 1 Key date/time rollovers in the next century [1]

The most impactful rollover in the near term will occur in 2038 and is known as Y2038 [2]. Briefly, Y2038 arises from the “time_t” data type in Unix and the C programming language, which represents the number of seconds since January 1, 1970. On January 19, 2038, 32-bit signed implementations of time_t will wrap from 0x7FFFFFFF (03:14:07 UTC) to 0x80000000, which some code may misinterpret as December 13, 1901, leading to errors and unexpected behavior.

Operating systems for 64-bit systems (e.g., Linux, Windows, OSX, iOS, and Android) inherently use 64-bit signed time_t, which is free of systemic Y2038 issues. However, Linux on 32-bit systems did not fully support 64-bit time_t until 2022 [3]. Some Linux variants still have the issue on 32-bit targets [4]. Starting with Linux kernel v5.6 and accompanying glibc updates, 32-bit builds can be made Y2038-safe, and many Linux distributions are in the process of adopting this. For example, Debian is switching its 32-bit distributions to 64-bit time_t in an upcoming release.

The Y2038 issue is most pressing in embedded systems with 32-bit microprocessors, also called Microcontroller Units (MCU). Due to their low cost and high suitability for embedded systems, billions of 32-bit embedded devices still ship each year with 32-bit kernels, libraries, and other components that are at risk to Y2038-related issues. In fact, sales of 32-bit MCUs are increasing, not declining [5].

Y2038 is a concern now because the field life of embedded systems is often 15 years or more. Many products already deployed or currently in development will still be in service in 2038. If they are not Y2038-safe, the consequences could be severe. Given the imminent risks, it is critical to begin addressing Y2038 now. Unfortunately, the current regulatory landscape remains inadequate, as shown in the next section.

Regulatory Certification and Gaps

All critical infrastructure sectors are susceptible to Y2038. The table below lists infrastructure sectors, the US agencies that regulate them, the primary software standards, and the status of Y2038 coverage by the regulations [1].

Table 2 Critical infrastructure sectors and standards

While there are some sectors with indirect standards and general advisories, it is very concerning that there are no known Y2038 regulations as of September 2025. Given the enormity of the issue and the risk of catastrophe, Y2038 awareness will inevitably increase, and auditors will eventually demand proof of Y2038 compliance.

Technology Layers

Y2038 risk is pervasive across all aspects of digital systems and spans all technology “layers”. Table 2 lists the main technology layers for a typical embedded system.

Table 3 Technology layers to consider for Y2038 assessment and mitigation

RTOS Scoreboard

There are many current and historical Real-Time Operating Systems (RTOS) used for embedded systems. The table below lists some of the most common RTOS, whether they are open source, the default type of time_t, and current status.

Table 4 Selected RTOS time representations

* Year shown is earliest OS/library release date with 64-bit signed or 32-bit unsigned time_t support in all default builds. “Safe” means internal APIs, kernel, and default libc all use 64-bit signed or 32-bit unsigned time_t; legacy versions may differ. Other layers may not be “safe”.

There may be build-specific options that modify the data type used for time_t. An easy way to check for time_t size and whether it is signed or unsigned is to print the details with code such as the following (in “C”):

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

int main(void) {
printf(“sizeof(time_t) = %zu bytes\n”, sizeof(time_t));

   if ((time_t)-1 < (time_t)0) {
       printf(“time_t is signed\n”);
   } else {
       printf(“time_t is unsigned\n”);
   }

return 0;
}

Real-Time Clock (RTC) Snapshot

Real-Time Clock (RTC) chips are a common source of time on many embedded systems. Most RTC chips store the year as two BCD digits (00‑99) plus an optional century flag; these have no issue in 2038 but wrap at midnight on Jan 1, 2100. The table below shows some popular RTCs and their maximum time representations.

Table 5 Real-Time Clock (RTCs)s and time limitations

* The “Century Bits” column has the following meaning:

Century Bits = 0 → firmware must hold a separate century byte (often in battery-backed RAM) or accept a 2100 wrap.
Century Bits = 1 → device toggles 19xx/20xx; still needs service on 31 Dec 2099.
Century Bits = 2 → covers four centuries (2000-2399) automatically.
N/A → the part uses a Unix-style counter, so the real limit is the 32-bit unsigned rollover, i.e. February 27, 2106, not BCD storage.

While all RTCs in the table provide support to at least 2099, the software that interfaces to a given RTC (i.e., the device driver) must be implemented properly. Best practice is to thoroughly test RTC device drivers for Y2038 issues.

File Systems

Most modern file systems support timestamps well beyond 2038, but some legacy file systems have rollover limits. For example, ext2 and ext3 use 32-bit signed seconds from 1970 that rollover in 2038. Also, FAT and exFAT use a 7-bit year offset from 1980, so they rollover in 2107. The table below shows some of the most popular file systems and if/when they overflow.

Table 6 File systems and overflow dates

* Dates are from default on-disk timestamp encodings without vendor extensions.

Some file systems support extended timestamp formats that push rollover further. Best practice is to verify Y2038 compliance with the vendor. File systems can also be tested by advancing the system date beyond 2038, creating a folder and file, and verifying that the new folder and file have correct timestamps.

Databases

Most modern databases store integers as 64‑bit signed values as shown in the table below, so timestamps are safe unless an application forces a 32-bit cast before storage or after retrieval. One notable Y2038 risk is BSON timestamps in MongoDB. These contain a 32-bit time_t field, although it is unclear from MongoDB documentation whether this field is signed or unsigned. BSON timestamps are for internal use, but can be misused in application code. Hence, there is a lingering concern that a Y2038 sensitive time field is being used [61].

Another potential Y2038 risk is the TIMESTAMP type in old versions of MariaDB, MySQL, and PostgreSQL, which also overflows in 2038. Best practice is to use DATETIME instead of TIMESTAMP, and carefully review existing code that performs database storage and retrieval of time fields.

Table 7 Databases and time representations

* Years shown reflect built-in timestamp type limits in default builds; application-level casts can reintroduce Y2038 risk. “Safe” means no intrinsic 32-bit time storage in default schema; application logic must still avoid truncation.

Protocols and Interfaces

Applications of all sizes often interface with other computer systems, sensors, or components using public protocols or privately defined data structures that often contain time fields. When such time fields represent 32-bit signed seconds, there is a high risk of Y2038 issues. Finding and correcting these types of issues can be very tedious and time consuming since the protocols may not be well documented, and even once issues are found, mitigation is complicated by the need to correct not just the definition, but also all systems that use it.

One protocol with a rollover issue is NTP. Its 32-bit seconds field wraps in February 2036, about two years before the Y2038 rollover [48]. NTPv4 addresses this by introducing an “era” concept, where each 136-year cycle of 32-bit seconds is treated as a distinct era. With proper implementations, NTP can continue operating correctly by tracking which era a timestamp belongs to. However, systems or applications that fail to account for NTP era transitions may misinterpret times after 2036, leading to synchronization errors [65].

MQTT is another widely used protocol for data exchange with embedded systems [66]. While the protocol itself does not define time fields, MQTT payloads often include timestamps. If these are stored or accessed as 32-bit signed integers, they are at risk to Y2038. When stored as 32-bit unsigned integers, they are valid until 2106, but risks remain if the field values are improperly cast to signed 32-bit types.

Test Scripts and Analytics

Testing is an integral part of embedded system development. Analytic packages are commonly used to determine to verify data or behavior of embedded systems. Most modern scripting languages and analytics packages use 64-bit signed time fields for seconds, but this should not be assumed. For example, scripts may interface with sensors that produce 32-bit signed time fields, or scripts may contain assumptions or casts to 32-bit signed time fields that may break due to Y2038. Therefore, scripts and data analysis packages should be checked for Y2038 issues.

Other Uses of Time

While the areas above highlight many common Y2038 risks, the list is not comprehensive. Any component that uses time can be vulnerable to Y2038. For example, an older computer’s BIOS might fail to boot after the rollover, or a seemingly minor subsystem such as a mobile SIM card, complete with its own MCU and firmware, could encounter unexpected failures.

High-Level Mitigation Playbook

There is unfortunately no universal solution to Y2038 since the potential issues exist deep within each layer. To fully address Y2038, each layer must be assessed, including systems with 64-bit microprocessors.

There are essentially three high-level Y2038 mitigation strategies for 32-bit targets (in order from easiest to most difficult):

Migrate to a 32-bit unsigned time_t – This option moves the time_t rollover to 2106. It is perhaps the “easiest” option if a toolchain and libraries that use 32-bit unsigned time_t are readily available. In some cases, this may require an RTOS, a difficult but not impossible task. Regardless, there is still a risk of bad assumptions or stray casts to 32-bit signed time.
Migrate to a 64-bit signed time_t – In cases where a 64-bit signed time_t toolchain and libraries are available, this may be the best option since 64-bit signed time is inherently safe. However, there may be many touchpoints where 32-bit assumptions and casts cause issues.
Upgrade hardware to 64-bit microprocessor/MCU – This option is the most drastic, expensive, time-consuming, and environmentally detrimental, but it is nevertheless warranted in some cases. Along with the hardware upgrade itself, software must be ported to the new platform. Note that Y2038 issues cannot be circumvented by running 32-bit software on 64-bit hardware.

Conclusion

The Y2038 problem remains a significant, often ignored, and underestimated risk for embedded systems, critical infrastructure, and legacy software. While many modern platforms and protocols have adopted 64-bit signed or 32-bit unsigned time representations of time_t to extend operational lifespans well beyond 2038, a vast number of deployed systems, including those still being manufactured and in development, retain time formats that will fail in less than 13 years. These risks are compounded by inconsistent industry guidance, uneven adoption of mitigations, and the long service life typical of critical systems.

The data presented above illustrates the wide variation in readiness across all technology layers, such as operating systems, file formats, databases, and hardware components. Addressing these issues proactively through early assessment, informed design choices, rigorous testing, and lifecycle planning is essential to ensuring system reliability and avoiding costly failures when the Y2038 epoch rollover arrives.

From a business perspective, an unexpected Y2038 failure in a deployed critical product could trigger urgent recalls and replacements costing millions, while also irreparably damaging customer trust. Proactively addressing these risks protects both organizations and the people who rely on their technology.

For further discussion, collaboration, corrections, or inquiries related to Y2038 readiness, please visit https://y2038.com or connect with me on LinkedIn (https://www.linkedin.com/in/john-lange/). Both channels provide opportunities to share feedback, ask questions, and explore potential partnerships.

References

Time formatting and storage bugs — Year 2106 section. https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2106
Wikipedia. Year 2038 problem. https://en.wikipedia.org/wiki/Year_2038_problem
The GNU C Library manual. “Manual time64,” documenting _TIME_BITS=64. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103886
The Register. Debian Linux still vulnerable to Y2038 bug on 32-bit systems. July 25, 2025. https://www.theregister.com/2025/07/25/y2k38_bug_debian/
Verified Market Reports. Global 32-Bit Micro Controller Unit Market: Size, SWOT, Growth & Forecast 2033. Verified Market Reports, circa March 2025. https://www.verifiedmarketreports.com/product/32-bit-micro-controller-unit-market/
Critical Infrastructure Sectors. https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/critical-infrastructure-sectors
ISO 26262:2018, Road vehicles – Functional safety. https://www.iso.org/standard/68383.html
IEC 61508 series, Functional safety overview. https://www.iec.ch/functional-safety
IEC 61511-1:2016, Process industry SIS – Requirements. https://webstore.iec.ch/en/publication/24241
ISA/IEC 62443 series, Industrial automation and control systems security. https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
RTCA DO-178C, Software considerations in airborne systems. https://my.rtca.org/productdetails?id=a1B36000001IcmqEAC
RTCA DO-278A, Software integrity for CNS/ATM. https://my.rtca.org/NC__Product?id=a1B36000001IciGEAS
IEEE 1483, Verification of vital functions in rail systems. https://standards.ieee.org/ieee/1483/2203/
49 CFR Part 236 Subpart I, Positive Train Control systems. https://www.ecfr.gov/current/title-49/subtitle-B/chapter-II/part-236/subpart-I
NERC Critical Infrastructure Protection standards. https://www.nerc.com/pa/Stand/Pages/ReliabilityStandards.aspx
NIST Cybersecurity Framework 2.0. https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
NIST SP 800-82 Rev. 3, OT security guide. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
TL 9000 overview. https://tl9000.org/about/tl9000/overview.html
NENA i3 Standard for NG9-1-1. https://cdn.ymaws.com/www.nena.org/resource/resmgr/standards/nena-sta-010.3b-2021_i3_stan.pdf
NFPA 1225, Emergency services communications. https://www.nfpa.org/codes-and-standards/nfpa-1225-standard-development/1225
FFIEC IT Examination Handbook InfoBase. https://ithandbook.ffiec.gov/
ISO/IEC 27001:2022, ISMS requirements. https://www.iso.org/standard/27001
ISO 13485:2016, Medical devices QMS. https://www.iso.org/standard/59752.html
ISO 14971:2019, Risk management for medical devices. https://www.iso.org/standard/72704.html
IEC 62304:2006+A1:2015, Medical device software life cycle. https://webstore.iec.ch/en/publication/22794
FDA 2023, Content of Premarket Submissions for Device Software Functions. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions
ISO 13849-1, Safety of machinery – Safety related parts of control systems. https://www.iso.org/standard/73481.html
ISA-95, Enterprise-control system integration. https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
NASA-STD-8739.8B, Software Assurance and Software Safety. https://standards.nasa.gov/sites/default/files/standards/NASA/B/0/NASA-STD-87398-Revision-B.pdf
ECSS-E-ST-40C Rev. 1, Space engineering – Software. https://ecss.nl/standard/ecss-e-st-40c-rev-1-software-30-april-2025/
MIL-STD-882E Change 1, System Safety. https://safety.army.mil/Portals/0/Documents/ON-DUTY/SYSTEMSAFETY/Standard/MIL-STD-882E-change-1.pdf
AWWA G430, Security practices for operation and management. https://store.awwa.org/AWWA-G430-24-Security-Practices-for-Operation-and-Management
Zephyr Project docs. Time Utilities. https://docs.zephyrproject.org/latest/kernel/timeutil.html
AdaCore note on VxWorks 7 SR0660 — 64-bit time_t support. https://docs.adacore.com/gnat_ugx-docs/html/gnat_ugx/gnat_ugx/vxworks_topics.html
FreeRTOS-Plus-POSIX docs. time.h implementation and reliance on platform C library. https://freertos.org/Documentation/03-Libraries/05-FreeRTOS-labs/03-FreeRTOS-plus-POSIX/01-API-Reference/09-time
AB18x5 Real-Time Clock with Power Management Family. Application manual, May 8, 2014. https://abracon.com/Support/AppsManuals/Precisiontiming/AB18XX-Application-Manual.pdf
Artasie AM18X5 RTC Datasheet. Datasheet, rev. current. https://ambiq.com/wp-content/uploads/2020/10/Artasie-AM18X5-RTC-Datasheet.pdf
Texas Instruments. BQ32002 Real-Time Clock (RTC) datasheet. Rev. current. https://www.ti.com/lit/ds/symlink/bq32002.pdf?ts=1754498971345
Analog Devices | Maxim Integrated. DS1307 Serial Real-Time Clock. Datasheet. https://www.analog.com/media/en/technical-documentation/data-sheets/ds1307.pdf
Analog Devices | Maxim Integrated. DS1337/DS1337C I2C Serial Real-Time Clock. Datasheet. https://www.analog.com/media/en/technical-documentation/data-sheets/ds1337-ds1337c.pdf
Analog Devices | Maxim Integrated. DS3231 Extremely Accurate I2C-Integrated RTC/TCXO. Datasheet. https://www.analog.com/media/en/technical-documentation/data-sheets/ds3231.pdf
NXP (Freescale). AN3874: i.MX25 Real Time Clock (RTC). Application note. https://www.nxp.com/docs/en/application-note/AN3874.pdf
PCA21125 SPI-bus Real-Time Clock and calendar. Datasheet, November 23, 2014. https://www.nxp.com/docs/en/data-sheet/PCA21125.pdf
PCF2123 SPI Real-time clock/calendar. Datasheet. https://www.nxp.com/docs/en/data-sheet/PCF2123.pdf
PCF8523 Real-Time Clock (RTC) and calendar. Datasheet. https://www.nxp.com/docs/en/data-sheet/PCF8523.pdf
PCF8563 Real-time clock/calendar. Datasheet. https://www.nxp.com/docs/en/data-sheet/PCF8563.pdf
Micro Crystal. RV-3028-C7 Application Manual. Rev. current. https://www.microcrystal.com/fileadmin/Media/Products/RTC/App.Manual/RV-3028-C7_App-Manual.pdf
Micro Crystal. RV-8263-C7 Datasheet. Rev. current. https://www.microcrystal.com/fileadmin/Media/Products/RTC/Datasheet/RV-8263-C7.pdf
Micro Crystal. RV-8803-C7 Datasheet. Rev. current. https://www.microcrystal.com/fileadmin/Media/Products/RTC/Datasheet/RV-8803-C7.pdf
RX8130CE Real-Time Clock. Product brief, rev. current. https://download.epsondevice.com/td/pdf/brief/RX8130CE_en.pdf
AN3371: Using the hardware real-time clock (RTC) in STM32. Application note. https://www.st.com/resource/en/application_note/an3371-using-the-hardware-realtime-clock-rtc-in-stm32-f0-f2-f3-f4-and-l1-series-of-mcus-stmicroelectronics.pdf
Apple File System Reference (APFS). https://developer.apple.com/support/downloads/Apple-File-System-Reference.pdf
Btrfs. Accessed September 11, 2025. https://en.wikipedia.org/wiki/Btrfs
exFAT File System Specification. Date range 1980 to 2107. https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification
Linux kernel docs. “ext4 inodes” — extra epoch bits push overflow to May 2446. https://www.kernel.org/doc/html/latest/filesystems/ext4/inodes.html
FAT32 File System Specification, v1.03. Directory date encoding 1980 to 2099. https://www.cs.fsu.edu/~cop4610t/assignments/project3/spec/fatspec.pdf
Apple TN1150. “HFS Plus Volume Format” — 32-bit seconds since 1904; max 2040-02-06. https://developer.apple.com/library/archive/technotes/tn/tn1150.html
Microsoft Docs. “File Times” (NTFS 64-bit 100-ns intervals since 1601). https://learn.microsoft.com/windows/win32/sysinfo/file-times
Oracle Linux docs. “XFS bigtime option” — timestamps extended to year 2486. https://man7.org/linux/man-pages/man8/xfs_admin.8.html
MariaDB 11.5 Release Notes — TIMESTAMP widened to 64-bit. https://mariadb.com/docs/release-notes/community-server/old-releases/release-notes-mariadb-11-5-rolling-releases/what-is-mariadb-115
MongoDB, Inc. BSON Types. MongoDB Manual; accessed August 27, 2025. https://www.mongodb.com/docs/manual/reference/bson-types/
MySQL Manual. “TIMESTAMP and DATETIME Types” — 32-bit TIMESTAMP range to 2038. https://dev.mysql.com/doc/refman/8.4/en/datetime.html
PostgreSQL Global Development Group. “PostgreSQL 8.4 Release Notes – integer-datetimes now the default.” 16 July 2009. https://www.postgresql.org/docs/8.4/release-8-4.html
“Datatypes In SQLite” — INTEGER stored as 64-bit signed. https://www.sqlite.org/datatype3.html
Network Time Protocol; accessed September 11, 2025. https://en.wikipedia.org/wiki/Network_Time_Protocol
OASIS. MQTT Version 5.0 Specification, Committee Specification 01, March 7, 2019; accessed September 10, 2025. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html