Skip to main content

Software, apps, websites, networks and AI automation

Technology Insights

The Year 2038 Problem in 2026: Why a 32-Bit Clock Counter Runs Out in Twelve Years, What Embedded Devices and Databases Will Actually Break, and How to Find Y2038 Bugs Before the Rollover

The Year 2038 Problem in 2026: Why a 32-Bit Clock Counter Runs Out in Twelve Years, What Embedded Devices and Databases Will Actually Break, and How to Find Y2038 Bugs Before the Rollover

  • Internet Pros Team
  • October 24, 2026
  • Software Development

At 03:14:07 UTC on Tuesday, January 19, 2038, a counter inside millions of computers will reach the largest number it can hold. One second later, systems that still store time as a signed 32-bit integer will believe it is December 13, 1901. That date is twelve years away, but the devices that will be running on that day are being bought, installed and buried inside walls and machines right now.

Where the 2038 Deadline Comes From

Unix and its descendants, including Linux, macOS, Android and most embedded firmware, measure time as the number of seconds since midnight UTC on January 1, 1970. That count is called Unix time or the epoch. For decades the C language type that holds it, time_t, was a signed 32-bit integer on most systems.

A signed 32-bit integer tops out at 2,147,483,647. Add that many seconds to 1970 and you land on January 19, 2038. Add one more and the number wraps around to its most negative value, which the software reads as a date in 1901. Nothing crashes on its own. The program simply starts doing arithmetic with a clock that has jumped back 136 years.

Y2K was a formatting problem: two digits for the year. Y2038 is a storage problem: the number itself no longer fits. That makes it harder to spot by reading screens or reports.

Why This Is a 2026 Problem, Not a 2037 One

The bug does not wait for 2038 to show up. Any software that calculates a date in the future crosses the line early. A 15-year loan, a long-term certificate, a warranty end date, a cache that expires “never” by setting a date far ahead, or a license that runs 20 years will overflow today. These failures already happen. They tend to be logged as odd one-off bugs instead of being recognized as Y2038.

The bigger issue is equipment lifespan. A desktop PC is replaced every four or five years. A building access controller, an HVAC controller, a medical device, a point-of-sale terminal, a network camera or a programmable logic controller on a factory line can easily run for 15 to 25 years. A cheap 32-bit device installed in 2026 is very likely to still be working in 2038, and many of them will never receive another firmware update.

What Is Already Fixed, and What Is Not

The good news is that the mainstream software world has done most of the hard work. The bad news is that “mainstream” leaves out a lot of devices.

Layer Status What to watch for
64-bit operating systems Safe 64-bit Windows, macOS, Linux, iOS and Android use a 64-bit time_t, good for billions of years
32-bit Linux Fixable Kernel 5.6 (2020) and glibc 2.34 added 64-bit time, but each program must be rebuilt with it. Debian and Ubuntu rebuilt their 32-bit ARM packages in 2024 and 2025; older images were not
Embedded firmware and RTOS Often unknown Old toolchains, frozen vendor SDKs and devices that no longer get updates
Databases Mixed MySQL and MariaDB TIMESTAMP columns historically stop at 2038-01-19; DATETIME runs to the year 9999
File systems Mixed ext4 with small 128-byte inodes and older XFS volumes store 32-bit timestamps; XFS “bigtime” and 256-byte ext4 inodes fix it
File and network formats Mixed Any binary format, log record or protocol field that saves time in 4 bytes has the same limit, even on a 64-bit machine

That last row matters most. A modern 64-bit server can still write a 32-bit timestamp into a database column, a binary log or a packet it sends to an older device. Upgrading the operating system does not fix data formats.

The Neighbouring Rollovers

2038 has company. The classic network time protocol (NTP) counts seconds from 1900 in an unsigned 32-bit field that wraps on February 7, 2036. Modern NTP clients handle that era change, but old ones may not. The GPS week number, a 10-bit counter, rolls over again in November 2038, as it did in 1999 and 2019, when some older receivers and clocks jumped back two decades. Software that uses an unsigned 32-bit Unix time lasts until 2106, which buys time but is not a real fix.

Where Y2038 Bugs Hide in a Typical Business

  • Building systems: door access controllers, alarm panels, HVAC and lighting controllers, elevator monitors.
  • Network gear: older routers, managed switches, NAS boxes, IP cameras and video recorders running 32-bit Linux.
  • Industrial and medical equipment: PLCs, data loggers, lab instruments and devices tied to a regulatory approval that makes updates slow.
  • Line-of-business software: in-house apps written years ago, especially ones that store dates as integers or use TIMESTAMP columns.
  • Vehicles and fleet hardware: telematics units and in-vehicle computers that stay in service for a decade or more.

How to Find and Fix It Now

A practical Y2038 checklist

  1. Inventory long-life devices. List anything expected to run past 2037 and note whether it has a 32-bit processor or 32-bit firmware.
  2. Ask vendors in writing. Add “Is this product Y2038 compliant?” to every purchase of equipment meant to last ten years or more, and keep the answer.
  3. Check database columns. Search schemas for TIMESTAMP columns that hold future dates, such as expiry or due dates, and move them to DATETIME or a 64-bit integer.
  4. Search your own code. Look for timestamps cast to 32-bit integers, 4-byte time fields in file or network formats, and “never expires” values set to the maximum 32-bit number.
  5. Test with a moved clock. On an isolated test system, set the clock to January 2038 or use a time-faking tool, then let the software run past the rollover and watch the logs.
  6. Check file systems. Confirm that ext4 volumes use 256-byte inodes and that XFS volumes have bigtime enabled before data on them needs to outlive 2038.

Test on isolated systems only. Pushing a production clock forward can expire certificates, licenses and passwords instantly and lock users out.

The Bottom Line

The Year 2038 problem is predictable down to the second, which makes it one of the easiest technology risks to plan for. Most PCs and servers are already safe. The risk sits in the long-lived, rarely updated devices and in old data formats that nobody has looked at in years. If you buy equipment this year that is meant to last a decade or more, ask the Y2038 question now, while switching vendors is still cheap.

Not sure which of your systems, databases or custom applications still keep time in 32 bits? Contact Internet Pros for a review of your software and devices, and a plan to fix what will not make it past 2038.

Share:
Tags: Software Development Business

Related Articles