The end of 32bit time: a Unix story

The exact time I’ve started to write this blog post is 1359592915. That is the Unix time for 31st January 2013, 02:42:00 am (GMT+2 or CST+8 or EST+6). All the 32 bit systems from MAC or Windows have a counter that uses Unix time to calculate the time in seconds since January 1st 1970.

This counter will reach its limit in 19th January 2038 @ 3:14:07 when it will show 2 147 483 647. That is the upper limit of the Unix time because it was calculating the time in 32 bit format. At that date the counter will start over from December 1901. Strange, huh?

Why is this important? Because if we do not switch all computers to 64 bit systems, then the counter will tumble all the data in the computers and some parts of the industries can be blocked for a short while because of this. Time is very important for each PC. Even if you power off a computer it will have the date and time stored in a chip and on reboot it will take the date form there and, sometimes, it will connect to servers on the web to check the exact time.

An interesting thing to know about time is that if you set your date and time to 1980 and then try to login into a secure website, you will not be able to do this due to time mismatch.
wrong-time

So, anyone still saying time is not important? After we set the time on a 64 bit scale then the time will run out in about 297 billion years. Unix time, you were great, but goodbye!

One Response to “The end of 32bit time: a Unix story”

  1. He’s wrong. time_t is now on 64 bits. But that’s old story already. It is on 64 bits since quite some while now.
    Everyone know the Y2K issue and by that time most of the UNIX systems were up-to-date.
    That guys is wrong with one thing: time_t contains the relative time fr Epoch – January 1st 1870. UNIX time has not been used for historic data (although it can be used in this way). It will affect only some systems which weren’t updated since, let’s say, 2000. Is it a problem?

Leave a Reply