Linux Is Not Y2K(38) Compliant!?

naveen_reloaded · 23-12-2007, 12:23 PM

According to www.y2k38.info, all 32 bit Unix and Linux systems, in their current state, will come to a halt on January 19, 2038 at 3:14:07. This is due to the fact that *nix systems keep track of time in a four byte integer corresponding to the number of seconds after January 1, 1970 12:00:00. The maximum value of a four byte integer is 2,146,483,547 which is equivalent of January 19, 2038 at 3:14:07.

What happens when Linux is set to January 19, 2038 at 3:14am?

Quote:

$ date -s “01/19/2038 03:14:00″
date: invalid date `01/19/2038 03:14:00′

Hrm. Linux won’t let that date be set for obvious reasons. I was able to get the command to take once while running the Linux Mint 4.0 live CD. (don’t ask me how; I am unable to reproduce it).

The train of events from January 19, 2038 at 3:14:00 until January 19, 2038 at 3:14:07:
After executing the date command several times, it was taking at least 10 seconds for one real second to pass in the system. Odd. It seemed to grow longer as each second passed.
Finally, the system time reached January 19, 2038 at 3:14:07, when the state of the OS was discombobulated to say the least. I could not start nor stop any applications. I did get a peek at the year — it was set back at 1901.
Restarted the X server with Ctrl+Alt+Backspace. I was lucky to get a task bar with no buttons.
I was in VMware and the Ctrl+Alt+F# keys were being passed to the host; no alternate tty access.
The only thing left was to power off. No rebooting to see if it would come up since this was experienced from a live CD environment.

I tried my best to get a screen cast — this was a failed attempt. The latest time that the Linux date command will accept is around 01/18/2038 22:00:00. The system seconds were equal to 5 real seconds and seemingly got longer and longer. It may have taken a year to reach 01/19/2038 in Y2K38 bug time. Sorry, no screen cast.

By the way, unlike Y2K, this is acually real.

By 2038 I am quite sure we will not have anything to worry about. Everything will be 64bit or more and will not be affected. If there is, by chance, any 32bit *nix systems left by then I am sure a patch is feasible. Why was the *nix time stamp developed like this? If you have any information about why, leave a comment — we would love to hear it as I am sure it has it’s pros and cons.

http://www.hackosis.com/index.php/20...k38-compliant/

Garbage · 23-12-2007, 12:26 PM

thats what we were discussing on IRC....

Any way.... nice finding... Thanks !!

sandeepk · 23-12-2007, 12:44 PM

I am really surprised with this.
And this info came into light after all these years after Y2K bug... Strange!!

Hitboxx · 23-12-2007, 12:53 PM

2038., big deal! People are talking about the end of the world in 5 years and these are bothered about computers 30 years into future.

Seriously, it will be fixed by that time, no need to worry.

**ico** · 23-12-2007, 12:56 PM

I am too amazed. Thanks for the info.

praka123 · 23-12-2007, 01:46 PM

isnt this already posted here looong back?

afaik even microsoft too got this problem!not a programmer but it has to do with some C function time.h.

There are lot of options to fix this.but the fix wont have any use as by 2038,this gen PC's are may not be there even if 64-bit may be older by that time

Hey!this is not a big deal.
OK.it was posted in 2005 itself!the thread was deleted when upgraded to Vbulletine may be:
Year 2038 problem !!

x3060 · 23-12-2007, 06:42 PM

first lets survive for another 5 years , then we will see :-P

naveen_reloaded · 25-12-2007, 10:47 AM

I dont know why everyone is talking about doom's day..here..

**MetalheadGautham** · 25-12-2007, 01:04 PM

linux is !windows. they will fix it much before it has a lasting impact. I suppose ext4 file system may fix some stuff, so that the kernel can be upgraded to a better dating system.