At 11.14am on 19 January 2038, some computers will decide it is 1901. The bug has already struck three times

Somewhere inside the device you are reading this on, a number is ticking up by one every second. On Sunday morning Perth time it passed 1.79 billion. It has been counting since midnight on New Year’s Day 1970, and it has never once stopped.

On older computers, that number lives in a space with room for exactly 32 binary digits, one of which is used to say whether the number is positive or negative. The biggest number that fits is 2,147,483,647. Add one more second and the count does not go up. It flips to the most negative number the box can hold, minus 2,147,483,648, and the computer counts that many seconds backwards from 1970.

The result is 8.45pm UTC on Friday 13 December 1901.

Engineers call it the Year 2038 problem, or Y2K38. Unlike Y2K, it is not a guess about how programmers wrote dates. It is arithmetic.

Why does a computer count time from 1970?

Because that is when Unix was being built. Unix, the operating system developed at Bell Labs in the late 1960s and early 1970s, needed a simple way to store time, and its designers chose a single count of seconds from a fixed starting point: 00:00:00 UTC on 1 January 1970, now known as the Unix epoch.

It was elegant and cheap, and it spread everywhere. Linux, Android, Apple’s operating systems, web servers, databases, routers and countless embedded chips inherited the idea. A 32-bit counter gave the designers about 68 years in each direction from 1970, which looked like an eternity at the time.

When exactly does it run out?

These are the milestones of the seconds counter. Screenshot this one.

| Seconds since 1970 | Date and time (UTC) | Perth (AWST) | |—|—|—| | 1,000,000,000 | 9 September 2001, 1.46am | 9.46am, 9 Sep 2001 | | 1,500,000,000 | 14 July 2017, 2.40am | 10.40am, 14 Jul 2017 | | About 1,794,700,000 | 15 November 2026 | Today | | 2,000,000,000 | 18 May 2033, 3.33am | 11.33am, 18 May 2033 | | 2,147,483,647 | 19 January 2038, 3.14.07am | 11.14.07am, 19 Jan 2038 | | One second later | Read as 13 December 1901, 8.45.52pm | The machine is in 1901 |

Hasn’t this already happened?

Yes, three times that are well documented, because software often looks into the future.

In May 2006, the web server AOLserver started failing. It used a default timeout of one billion seconds, about 31.7 years. Added to the date in May 2006, that pushed past January 2038, the count overflowed, and the software broke. Operators had to change the setting by hand.

On New Year’s Day 2022, Microsoft Exchange servers around the world stopped delivering email. Microsoft had numbered a malware-scanning update by its date, 2201010001, for 2022, 1 January, version 001. That number is bigger than 2,147,483,647. The scanning engine choked, and Microsoft took until 5 January to roll out an automated fix. Administrators nicknamed it “Y2K22”.

In March 2022, Oracle Access Management began failing when a cookie set to expire in 500 million seconds, about 15.8 years, crossed the 2038 limit. Oracle released a patch in April.

Each of these was a system calculating a date past 2038 long before the date itself. That is why the problem will not arrive all at once on 19 January 2038. It will keep surfacing in the years before it, whenever a mortgage, a warranty, a certificate or a long-term contract is calculated.

What has been fixed?

A great deal, quietly. The fix is to give the counter 64 bits instead of 32, which pushes the limit out by about 292 billion years, roughly 21 times the age of the universe.

1. OpenBSD switched to 64-bit time on every platform in 2014; NetBSD did it in 2012.
2. Linux 5.6, released in 2020, added 64-bit time to 32-bit systems, the version embedded devices run.
3. The GNU C Library, which most Linux software depends on, added 64-bit time for 32-bit platforms in version 2.34 in August 2021.
4. MySQL 8.0.28 in January 2022 fixed its time functions on 64-bit platforms. Older versions return zero after the deadline.
5. Linux file systems have been extended: ext4 timestamps now run to 2446 and XFS to 2486.

Phones and laptops bought in the past decade are 64-bit and largely safe. Some old devices are not: 32-bit Android 4 tablets and some 32-bit iPhones and older Macs are known to misbehave if their clock is set past the limit.

So who should worry?

Anyone who runs machines that are rarely updated and expected to last a long time. Embedded systems are the biggest risk: the small computers inside cars, lifts, industrial controllers, smart meters, point-of-sale terminals, medical equipment and network gear. Many run 32-bit chips, many will still be working in 2038, and many cannot easily be patched.

The fix in the operating system is only half the job. Every program, database column and file format that stores time as a 32-bit number has to be found and changed too. That is the expensive part, and it is what made Y2K cost governments and companies hundreds of billions of US dollars worldwide in the late 1990s.

Not every system will fail. A device that only measures how long something took, rather than what date it is, is largely unaffected.

Is 2038 the only time bomb?

No. Computer clocks are full of counters waiting to roll over.

• 7 February 2036: older versions of NTP, the protocol many computers use to set their clocks over the internet, reach the end of their own counting era.
• 20 November 2038: GPS satellites’ 10-bit week counter rolls over again, as it did in 1999 and 2019, when some older receivers jumped back in time.
• 7 February 2106: systems that patched 2038 by using an unsigned 32-bit number, giving up dates before 1970, run out then.
• The year 30,828: Windows’ own internal clock format, which counts in 100-nanosecond steps from 1601, finally fills up.

Why does this matter to an ordinary person?

Because the devices most likely to fail are the ones nobody thinks of as computers. If the 2038 problem bites, it will look like a payment terminal rejecting cards, a car infotainment unit showing the wrong date, a building’s access system locking out staff, or a certificate that suddenly appears expired. Y2K passed quietly because of years of unglamorous work. 2038 will go the same way only if that work is done again.