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

Written by - 3 comments

Published on - 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".

Old blog design

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.


RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder