What the countdown 'until Death of Computers' means (the Y2K38 problem)

Written by Claudio Kuenzler - 3 comments

Published on June 17th 2011 - last updated on November 15th 2023 - Listed in Personal Internet Linux Unix

---

For several years I showed a countdown on this website (in the old version before the redesign). It counted down until the "Death of Computers".

What does it mean? Here's the solution/explanation:

Countdown until Death of Computers in 2038

I would like to refer to the day Skynet becomes aware of its capacities and blows us humans away.. but it ain't the case with my countdown.

Update 2023: Well with AI on the rise, maybe it would actually turn out to be true...

Actually the timer is counting down to January 19 2038, 03:14:07 UTC. What basically happens then is that the UNIX timestamp, which counts the seconds since January 1 1970 reaches the maximum, the highest possible number. In 32bit systems this means that the system time will look like this:

11111111 11111111 11111111 11111111

32 single bits having the number 1. As I'm sure you know, computers "speak" binary: 0 and 1.

Once all 32 bit are having the number 1, the maximum number is achieved and it will logically continue like this:

10000000 00000000 00000000 00000000

But this messes the system time completely up!

The human date will show 1901 and the UNIX timestamp will show something like -2147483643. Now try to program something, e.g. with PHP which uses the time() function and therefore the UNIX timestamp -> which is now a negative number!

Applications, Operating Systems and maybe even the hardware (depending on firmwares etc) will fail. This will have a global effect as so many things are connected now.

This problem is also known as Year 2038 problem. I accidentally stumbled over it after a typo of a time variable in a self-made PHP program what made me aware of this.

But of course I'm exaggerating this fact a bit. Since this problem only affects 32bit systems, the problem is of course not known in 64bit systems, as there are 64 bits of 0 and 1. With 64bit this problem will only arrive in about 292 billion years. I don't think that mankind or earth will exist that long to worry about such a problem...

Add a comment

Show form to leave a comment

Comments (newest first)

IGnatius T Foobar from United States wrote on Jun 14th, 2014:

I'm sure that by 2038 the vast majority of mainstream computers will have migrated to 64-bit. Who knows, maybe we'll even be lucky enough that non-unix operating systems will be extinct (really, there's only one major one left).

But there will certainly be some edge cases -- certainly enough to be an annoyance. It'll be an annoyance to tech people though, not enough to knock out the mainstream.

Everyone just needs to make sure they always use the type "time_t" and not "int" or even "long" when they refer to timestamps, so it's just a quick recompile.

---

Carl Friend from Massachusetts/USA wrote on Dec 4th, 2012:

Even in many 64-bit UNIX operating systems there is a problem -- many of them still have time_t defined as a (signed) int which is inexact at best at usually an int is a 32-bit value and one needs to go to a long long. Worse yet, the allocation on the filesystem for timestamps may still only be 32-bits and the conversion to a 64-bit value means a roll in the filesystem version necessitating either a backup/restore or an on-the-fly conversion from old to new(er).

But this isn't the worst case I've seen so far. The size of the year field for OS-8 was only three bits guaranteeing that the thing would go obsolete (or at least be able to keep track of dates) for 8 years. Those were the Bad Old Days.

---

Dan Sichel from O'Neals, Ca. wrote on Nov 9th, 2011:

In 292 billion years and one day, someone with a legacy system will be going damnit damnit, damnit, I knew we should have upgraded this thing.

---