- 21
- Dec
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?
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.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
Related Posts
Tags: Bug, Linux, Y2K38
December 22nd, 2007 at 3:03 am
“By the way, unlike Y2K, this is acually real.”
Y2K was real. However, in almost all cases it was fixed in time.
Actually a patch would be non-trivial. See http://en.wikipedia.org/wiki/Year_2038_problem for more info.
December 22nd, 2007 at 11:15 am
thanks for the enlightenment — I guess I was too naive during that time to realize. ;)
December 23rd, 2007 at 12:55 am
Um, 2038 is a long time from now. Imagine, it’s the literal equivalent of comparing OSs from 1976 to today’s. It’ll get worked out.
December 23rd, 2007 at 1:05 am
The web’s most interesting stories on Sun 23rd Dec 2007…
These are the web’s most talked about URLs on Sun 23rd Dec 2007. The current winner is …..
December 23rd, 2007 at 1:36 am
I just can’t feel sorry for anyone still using a 32-bit processor by 2038
December 23rd, 2007 at 1:48 am
we have a few years i think.
December 23rd, 2007 at 1:51 am
Yea, My 64bit notebook gives time correctly. But thanks for the article.
December 23rd, 2007 at 2:05 am
This is only a problem for 32-bit Linux, which follows the other Unixes by having a time_t defined as uint32. Since the ABI changed for x86_64 anyway, they changed time_t to 64 bits. That means anything that you successfully compile (without warnings or stupid casts) in 64-bit mode will work fine.
So even today, it’s not a problem for almost half of us. In 2038, I bet using a 32-bit machine will be akin to using a 4004 today.
December 23rd, 2007 at 2:27 am
Mac OS X Leopard can’t get any farther than December 31st, 2037.
December 23rd, 2007 at 2:36 am
“Why was the *nix time stamp developed like this?”
It makes dealing with time easier. Everything becames basic addition and subtraction.
December 23rd, 2007 at 3:52 am
A thirty-two bit processor means that it works with four bytes at a time. It seems logical that this is the amount of data that a programmer would use to store the time. Any other type of data storage would be extra effort not worth the programmer’s time, especially if the consequences are 60 years in the future, after the programmer is likely dead.
December 23rd, 2007 at 3:53 am
[...] value of a four byte integer is 2,146,483,547 which is equivalent of January 19, 2038 at 3:14:07read more | digg [...]
December 23rd, 2007 at 3:59 am
theli@desktop ~ $ sudo date -s “01/19/2038 03:14:00″
Tue Jan 19 03:14:00 EET 2038
and working normal
December 23rd, 2007 at 4:38 am
On amd64 architecture (in 64bit mode) it seems to be fixed at first glance.. But there’s a lot of time :)
December 23rd, 2007 at 5:18 am
Before any ‘Woah Linux sucks hahaha’ commentsd I’d like to mention that Windows XP is also affected. DOS is not affected since it’s year 87 for it today…
December 23rd, 2007 at 5:23 am
I’m splitting hairs a little, but the maximum total unique values that can be represented with a 32 bit number is 4,294,967,296. What you choose to represent is entirely up to you. So the maximum number that can be represented with a 32bit number is in fact infinite.
December 23rd, 2007 at 5:33 am
You silly rabbit, in 30 years you’ll either be dead by old age or wiped out by a giant meteor what do you care ?
December 23rd, 2007 at 5:48 am
How is this in any way or form a problem? Who will be sitting on a non-updated Linux distro in 31 years?
Anyway, it works on my Gutsy 64 bit.
December 23rd, 2007 at 6:03 am
What do you mean “why was it developed like this”? Do you have a better way to do it?
32bits is the native size of the system, 32bits as a timestamp is nice and it scaled reasonably well (70 years). Whats so bad about it?
December 23rd, 2007 at 6:34 am
[...] El efecto 2000 (+38) en GNU/Linux Curiosa noticia que he visto en Hackosis siguiendo los enlaces de Digg: Linux Is Not Y2K(38) Compliant!? [...]
December 23rd, 2007 at 7:01 am
Come on people. STOP BEING STUPID. I guess from the general human race the typical person is borderline retarded. Think about it for a second. IF this operating system were to last until 2038 then WOW they did good. 30+ years out of an operating system is unheard of. Think about it are we using the same OS that came out in the late 70’s? I didn’t think so. Even windows 98 less than 10 years old or close to it is OLD!! and WAY OUTDATED. If you are worried about 2038 I suggest you worry more about other things first
December 23rd, 2007 at 7:16 am
Well if I’m running a 32 bit OS in 2037, I’m old and out of touch and deserve to have my computer die on me.
December 23rd, 2007 at 7:17 am
the maximum value of a *signed* four byte integer is 2,146,483,547
December 23rd, 2007 at 7:35 am
Congrats, your page has been dugg
http://digg.com/linux_unix/Linux_Is_Not_Y2K_38_Compliant
Unix programmers will be releasing patches soon
December 23rd, 2007 at 7:57 am
> The latest time that the Linux date command will accept is around 01/18/2038 22:00:00.
Pay attention to your timezone setting…
December 23rd, 2007 at 8:53 am
It’s not so terrible. Do you think it’s real: 32-bit system in 2038 year?…
December 23rd, 2007 at 9:56 am
*Makes a note that if he plans to send a computer in a time capsule to make sure it is 64-bit*
December 23rd, 2007 at 10:27 am
everybody panic!! …. oh wait… what are the odds that any computer currently running is gonna be anywhere but a museum in 30 years?? I believe there is ample time to come up with a solution
December 23rd, 2007 at 10:42 am
Thanks for the feedback everyone, and obviously this is a great topic for discussion as you can see this article has brought in the most comments on the site so far.
December 23rd, 2007 at 10:58 am
>Think about it are we using the same OS that came out in the late 70’s? I didn’t think so.
Yes, we are.
http://en.wikipedia.org/wiki/Unix
That’s the point entirely. Lurk the f$%king more.
December 23rd, 2007 at 11:10 am
[...] Linux Is Not Y2K(38) Compliant!? is on the top stories for Unix/Linux on Digg.com. It is currently at 639 diggs and counting. If you like this article, please digg it. Merry Christmas everyone. Tags: Digg, Hackosis News Like this post? Subscibe to the Hackosis RSS feed. [...]
December 23rd, 2007 at 11:20 am
Here’s a hint “DATE FORMAT INVALID”
$ date –help | grep YY
or: date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
$ date
Sun Dec 23 11:15:43 EST 2007
$ sudo date “010903142038.00″
Sat Jan 9 03:14:00 EST 2038
$ date
Sat Jan 9 03:14:24 EST 2038
December 23rd, 2007 at 12:51 pm
This is a real problem as there might be some servers in a back room somewhere still running the same 32bit linux as today because it just works.
This was the problem in 2000. There were legacy 1970s systems running old COBOL business and control applications which controlled systems affecting millions of people.
Do you take down the power grid every 5 years to upgrade your control software from “Windows 98″ to “Windows XP”? No! (By the way, the user of Windows there is just a metaphor.)
Systems are set up and expected to run pretty much forever. Oversights like the Y2K bug and the 2038 bug are critical flaws in high-risk systems.
It’s extremely irresponsible for people to build critical systems built on 32bit timestamps, etc.
That said, it still happens so this is why it’s a REAL PROBLEM. We need to find out which systems are still using this stuff and make sure that they are patched by 2038.
Hopefully we won’t have any scares like with Y2K where there were systems controlling missle launch which were programmed to detect tampering and fire to pre-determined targets. :P
Anyway, I digress. The world of business is pretty much as stupid and improfessional as your personal desktop PC except that lives are at stake. Mistakes happen all the time and it’s important we call people on them and fix them before lives are actually lost.
^^;
December 23rd, 2007 at 2:26 pm
[...] read more | digg story [...]
December 23rd, 2007 at 3:53 pm
[...] read more | digg story [...]
December 23rd, 2007 at 6:25 pm
Ean hit the nail on the head… And let’s not forget all those embedded systems that are normally deployed and forgotten. While everyone can safely assume they won’t be using the same PC 30 years from now, how can we be sure that the airplane or high-speed train we board on Jan 19, 2038 doesn’t have an embedded controller somewhere that has a 32-bit internal clock just waiting to roll over? As mentioned on http://www.y2k38.info (which interestingly was first written almost 9 years ago), this problem has much more potential to wreak havoc than the Y2K problem since it is more fundamental and can also be reflected in hardware designs as well as software.
December 23rd, 2007 at 6:34 pm
Thank you Webauger, you are the only one who has agreed with the author on why a solution is needed and to not write off the problem. I implore your reasonable approach and supplemental evidence as to previous old software and operating systems still in use during 2000.
December 23rd, 2007 at 7:41 pm
oh noes!!!1 i remember back in 99 everybody was freaking out, how did that turn out? wasn’t there something else that everybody said was the new “year 2000″ problem? nothing will happen with this, i just like typing “oh noes!!!1″
December 23rd, 2007 at 8:45 pm
This is EXACTLY why i never learned linux!
December 23rd, 2007 at 9:03 pm
Teh solution is simple. Dump linux and switch to Vista. Problem solved.
ehh
December 23rd, 2007 at 9:53 pm
I love the idiots that keep stating that Y2K was a ’sky is falling’ routine. You have no idea how much work we put into making sure things went as smoothly as they did.
December 23rd, 2007 at 11:38 pm
Desktop Users don’t have to panic on this since they’ll be using 64-bit Architectures by then.
Like it was said before, the problem lies on Servers and embedded Soft-/Hardware. Since Linux is known for its high uptime an little need for maintenance once it is set up, it is possible for a Linux Machine to run in a basement an be forgotten. Plus, business People have a tendency to use Hard/Software until it is useless or broken (even if its no longer supported) so they stick with it until the very last second.
And lets not forget the Space Drones (if they also have a 4-bit signed integer value as Date/Time) :P
Apologies for my bad english, I’m Portuguese and it’s 5:30 AM :P
December 23rd, 2007 at 11:54 pm
[...] couldn’t end this post without mentioning a Digger’s worried post about U/*nix’s horrible dilemna. I for one am really worried: will they be able to patch it in 30 years? [...]
December 24th, 2007 at 12:11 am
How does the os track the date 1901 any better than 2038? (the time your system reverted to after a successful change to 2038) 1901 is actually further from the base date of 1970 than 2038, so isn’t any time from that year inherently impossible for the system to produce?
Not to sidetrack anyone from their search for a solution, but I think it unlikely that the comments here will uncover any viable option that hasn’t already been considered by someone working on this issue.
December 24th, 2007 at 2:26 am
Chris: Perhaps the Windows-alikes from the seventies didn’t make Y2K (ok, there weren’t windows-alikes, only CP/M and such other CLI OS’s)… however, enterprise & realtime operating systems did!! Enterprise systems included Unix-variants and of course IBM Mainframes, which are to date still 100% backwards compatible! The realtimes are known in small embedded devices till the most noteworthy: nuclear power plants & missile guiding systems. And as mentioned by other readers, y2k38 WILL affect those that were (most likely) not affected by y2k itself.
December 24th, 2007 at 2:56 am
the max value for a 32-bit *unsigned* is 4294967295, so i really can’t see the issue here…
December 24th, 2007 at 5:22 am
Running “Linux cosmin-laptop 2.6.23-ARCH #1 SMP PREEMPT Mon Nov 26 21:15:02 UTC 2007 i686 AMD Turion(tm) 64 Mobile Technology MK-36 AuthenticAMD GNU/Linux”.
$ date -s “01/19/2038 05:14:00″
[root@cosmin-laptop cosmin]# date
Tue Jan 19 05:14:05 EET 2038
[root@cosmin-laptop cosmin]# date
Fri Dec 13 22:30:16 BMT 1901
Still up & running.
December 24th, 2007 at 2:54 pm
So I will be 74 when the end of computing as we know it occurs. I don’t think I will even care…unless my motorized wheelchair/pacemaker runs on linux.
December 24th, 2007 at 6:34 pm
This issue has long been known and discussed and by 2038 will not be an issue. In fact the whole issue is a 32 bit os problem (known to affect even almost all windows versions as well) Chicken little go home this is a non-issue already.
December 24th, 2007 at 7:07 pm
Breaking news! Operating systems are not Y10K compliant:
http://en.wikipedia.org/wiki/Year_10%2C000_problem
With only 7992 (and a bit) years before deadline, what will we do?
December 25th, 2007 at 6:44 pm
Regardless of whether or not this is going to effect computers, it’s still interesting to talk about. I think I must have missed the part where the author said that this was going to be the end of the world as we know it unless we(humanity) kicked it into gear and worked together like that episode of South Park where they defaulted to the fun party to make the immigrants go away.
This is just a cool quirk in 32-bit operating systems that is easily fixable and probably won’t be an issue in 30 years. It’s just something fun to talk about, there’s really no need to get all defensive.
December 25th, 2007 at 11:38 pm
[...] value of a four byte integer is 2,146,483,547 which is equivalent of January 19, 2038 at 3:14:07read more | digg story addthis_url = [...]
December 25th, 2007 at 11:44 pm
[...] read more | digg story Posted by abasits Filed in NEWS [...]
December 27th, 2007 at 2:06 am
[...] more info please check to this y2k38 or hackosis adv_username = “adq890″; advgid = “adq890_defalut”; adtype = “336×280″; Sign Up Advertlets [...]
December 27th, 2007 at 9:34 am
Some of the “big” finanical companies i.e. banks, insurers are still using mainframes from way back when running unix, as there about the most reilable OS out there for critical systems. Who’s to say that they will stop using these beasts in 30 years time. You’d be surprised how many servers from the 80’s are still kicking around.
December 30th, 2007 at 1:05 pm
[...] ¿Es Linux compatible con Y2K(38)?www.hackosis.com/index.php/2007/12/21/linux-is-not-y2k38-com… por bull3tpr00f hace pocos segundos [...]
December 31st, 2007 at 12:06 am
This is false, for this date I receive the same answer and is much before your date (spanish keyboard):
josejoa@josejoa-desktop:~$ date -s “18/1/2017 03:14:00″
date: fecha “18/1/2017 03:14:00” inválida
January 1st, 2008 at 2:29 pm
There’s nothing to worry about at all you know. Even if we are still using 32-bit processors or time_t’s when this happens, we can just set like the 17th or some other close enough date and time as the new epoch. We might still have to find a way to distinguish between old and new timestamps but it’s really very unlikely that this will be more than a non-trivial patch to the kernel (if Linux is still even being used in 2038)
January 3rd, 2008 at 11:16 pm
[...] can’t restart it’s time, which may be the case for many Unix systems, it will crash. Hackosis confirms this problem has the potential to affect Linux boxes too. Unfortunately, machines running [...]
January 9th, 2008 at 10:32 am
[...] системите ще крашнат през 2038-ма [...]
January 16th, 2008 at 11:47 am
Just a quick comment to bring truth to some of the above comments.
First, this is NOT a Linux/Unix only problem. It Affects EVERY 32-bit operating systems. So those saying, “Drop linux, get Windows” are in the same boat (as long as we’re talking about 32-bit Windows).
Second, even though an unsigned integer is something like 4294967295, it doesn’t change the fact that Unix/Windows uses SIGNED integers so that it can represent dates previous to Jan 1st, 1970.
However, using unsigned integers is a proposed fix, it will likely be tossed out because it wouldn’t be able to represent records/logs from before the 1970 date. The popular solution is to start using 64-bit integers to represent time.
In fact, this patch has already been introduced in several Linux distributions. Desktop computers are going to be ok by the time 2038 rolls around. It’s the same argument as the Y2K scare.
As mentioned, this won’t affect most computers. It only affects high-risk systems that are used in a “set and forget” environment. These systems run for years, and in many cases, forgotten about, simply because they work and never need to be touched. Even today, we have systems from the 70’s that run power grids, water, gas, and other utilities. Those systems are usually the foundation of everything else, and replacing it would mean down-time, which for power grids and other utilities is unacceptable.
Just my two cents. Hope that clears up some confusion.
March 20th, 2008 at 9:39 am
I have never use linux however i’m sure windows is much better if now why do most people use it? Thanks
April 24th, 2008 at 11:49 am
I work for a large business where I am responsible for adding users to one particular closed network system there. Since we have a lot of part-time, temporary, and contract employees, the system requires an expiration date for every user account. For many years, the default date has been 12/31/2037. Now I know why. I certainly won’t be around then, but if no one pays attention it might be interesting on 1/1/2038 when no one can log in.
June 28th, 2008 at 5:37 am
[...] to last until 2038 then WOW they did good. ….. Dec 30, 2007: ??Es linux compatible con Y2K38? …http://www.hackosis.com/index.php/2007/12/21/linux-is-not-y2k38-compliant/LynuxWorks Selected as Embedded Operating System Vendor for Army’s …… systems Program: [...]