naveen_reloaded
!! RecuZant By Birth !!
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.
*www.hackosis.com/wp-content/uploads/2007/12/y2k38.png
What happens when Linux is set to January 19, 2038 at 3:14am?
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.
*www.hackosis.com/index.php/2007/12/21/linux-is-not-y2k38-compliant/
*www.hackosis.com/wp-content/uploads/2007/12/y2k38.png
What happens when Linux is set to January 19, 2038 at 3:14am?
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.
*www.hackosis.com/index.php/2007/12/21/linux-is-not-y2k38-compliant/
afaik even microsoft too got this problem!not a programmer but it has to do with some C function time.h.
