The year 2038 problem
A counter that started in 1970 reaches the largest number a 32-bit integer can hold, and anything still using one goes wrong.
Unix systems count time as the number of seconds since the start of 1970. For decades that number was stored in a signed 32-bit integer, whose largest value is 2,147,483,647. The count reaches it at 03:14:07 UTC on 19 January 2038. One second later the integer overflows to −2,147,483,648, which decodes as 20:45:52 on 13 December 1901. A program that has not been updated will, at that moment, believe that a hundred and thirty-six years have passed backwards. The countdown tool will tell you how long that leaves; the Unix time converter shows the overflow value itself if you paste it in.
Why it is not just a date problem
The comparison with the year 2000 is natural, but the mechanics differ. The millennium bug came from storing years as two digits in data; 2038 comes from the width of a single integer type, time_t, used by the operating system itself and by every program that asks it for the time. On a 32-bit build, time_t was 32 bits wide, and the type leaked into file formats, network protocols, database columns and on-disk structures that are far harder to change than source code.
What has already been fixed
Every mainstream 64-bit operating system has used a 64-bit time_t for years, and a 64-bit signed count lasts for roughly 292 billion years in either direction, so a server, laptop or phone bought in the last decade is not at risk from its own clock. The remaining work was on 32-bit platforms: the Linux kernel gained 64-bit time interfaces in version 5.6 in 2020, and the GNU C library followed in 2.34, so that 32-bit programs can be rebuilt with _TIME_BITS=64 to use them. Debian spent its 2024 to 2025 development cycle rebuilding its 32-bit ARM ports for exactly this reason. Those changes fix the operating system; they do not fix a program that stores a 32-bit value somewhere of its own.
Where it still bites
The exposure is in things that were built once and expected to keep running: routers, industrial controllers, set-top boxes, car electronics, older medical and lab equipment, and anything else with a 32-bit processor and firmware nobody plans to update. Some of that hardware will still be in service in 2038 because it will have been installed in the 2020s with a twenty-year life.
Software exposures are quieter. MySQL’s TIMESTAMP column type historically stops at the overflow instant, so a schema using it for anything that might fall after January 2038, such as a long contract or a far-future expiry, needs DATETIME instead. File systems that store 32-bit timestamps (ext2 and ext3, and some older variants of others) cannot record a modification time after it. Compiled binaries that used a 32-bit time_t keep that width forever, however modern the machine they run on.
Failures arrive early
The date is the point at which the current time overflows. Any calculation that adds to the current time overflows sooner. A system that computes an expiry twenty years out hit the limit in 2018; one that works with ten-year certificates reached it in 2028; a thirty-day session cookie is safe until December 2037. Several of the reported incidents so far have been of this kind: a certificate rejected, a date rolled back to 1901 in a report, a scheduled job that never ran because its next run was in the past. A system that handles long-range dates can therefore be broken by 2038 years before the headline date.
The unsigned trap
A tempting fix is to make the 32-bit value unsigned, which moves the limit to 06:28:15 UTC on 7 February 2106. It is tempting because it needs no change in storage size, and it is a trap because it removes the ability to represent any instant before 1970, which breaks dates of birth, historical records and anything else from the twentieth century. A few embedded systems have taken that route; nothing general-purpose should.
Other counters with the same shape
Any count of fixed units in a fixed width eventually ends. GPS reported its week number in ten bits, rolled over in 1999 and again in April 2019, and a surprising number of devices mishandled the second rollover. Some systems count milliseconds in 32 bits and wrap every 49.7 days; Windows 95 famously froze for this reason. NTP’s 32-bit seconds field, counted from 1900, wraps in February 2036, two years before the Unix date. The lesson generalises: any time value stored in a fixed number of bits has a last representable moment, and someone should know when it is.
What to check
For anything you maintain, the questions are concrete. Is every stored time value 64 bits wide, including in the database schema and any binary file formats? Is every library and dependency built against 64-bit time? Do any devices in the field run firmware that will not be updated? And does any calculation add a long duration to the present time? The last one matters most because it decides when, not whether, the problem reaches you. The date calculator is a quick way to see how far ahead a given duration lands.
Sources
Frequently asked questions
When exactly does the 2038 problem happen?
At 03:14:07 UTC on 19 January 2038, the second at which a signed 32-bit count of seconds since 1970 reaches 2,147,483,647 and overflows.
Will my phone or laptop be affected?
Not by its own clock. Every mainstream 64-bit operating system has used 64-bit time for years. The risk is in old 32-bit embedded devices and in software that stores time in a 32-bit field of its own.
Is the Year 2038 problem the same as Y2K?
They are related only in outcome. Y2K came from two-digit years in data; 2038 comes from the width of an integer type used throughout operating systems, which is why it reaches firmware and file formats that are hard to update.
Why do some systems fail before 2038?
Because they add a duration to the current time. A calculation that looks twenty years ahead overflowed in 2018, and a ten-year certificate reached the limit in 2028.