Difference between revisions of "607: 2038"
LuigiBrick (talk | contribs) (→Explanation) |
(→Explanation) |
||
| Line 8: | Line 8: | ||
==Explanation== | ==Explanation== | ||
| − | The {{w|2038 problem}} is a well-known problem with 32-bit Unix-based operating systems. {{w|Unix time}} is stored as a 32-bit signed integer on these systems, counting the number of seconds since 1970. In 2038, we overflow the highest number we can store in 32-bit integers, leading to unexpected behavior. The switch to 64-bit operating systems will most likely be complete by the year 2038, which is why [[Randall]] is relieved. The reference to {{w|Y2K}} is a throwback to the year 2000 problem, in which people were concerned that computers storing digits as two numbers (e.g.: 99 to represent 1999) would cause problems when the year 2000 began because 00 could have been interpreted as 1900 by error. That Y2K issue was covered widely — with only some small mishaps — but calculating dates beyond 2038 is still not solved on many 32-bit UNIX based systems today. The "even WORSE" is | + | The {{w|2038 problem}} is a well-known problem with 32-bit Unix-based operating systems. {{w|Unix time}} is stored as a 32-bit signed integer on these systems, counting the number of seconds since 1970. In 2038, we overflow the highest number we can store in 32-bit integers, leading to unexpected behavior. The switch to 64-bit operating systems will most likely be complete by the year 2038, which is why [[Randall]] is relieved. The reference to {{w|Y2K}} is a throwback to the year 2000 problem, in which people were concerned that computers storing digits as two numbers (e.g.: 99 to represent 1999) would cause problems when the year 2000 began because 00 could have been interpreted as 1900 by error. That Y2K issue was covered widely — with only some small mishaps — but calculating dates beyond 2038 is still not solved on many 32-bit UNIX based systems today. The "even WORSE" is possibly referring to how our increased reliance on computers means the bug could affect many more vital systems, but with Y2K passing by relatively uneventfully especially in light of the hype that preceded it caused people to take this sort of problem less seriously. |
The title text is a reference to the film "2012" which is about the world ending in December of 2012, at the end of the {{w|Mayan calendar}}. If the designers of the UNIX operating system had used 1944 as their epoch instead of 1970, then the UNIX crash due to a variable overflow would coincide with the end of the Mayan calendar. Thus, the implication is that there could have been a boring scene in the movie where the UNIX time rolls over and nothing happens and no one cares — because the world doesn't exist any more. | The title text is a reference to the film "2012" which is about the world ending in December of 2012, at the end of the {{w|Mayan calendar}}. If the designers of the UNIX operating system had used 1944 as their epoch instead of 1970, then the UNIX crash due to a variable overflow would coincide with the end of the Mayan calendar. Thus, the implication is that there could have been a boring scene in the movie where the UNIX time rolls over and nothing happens and no one cares — because the world doesn't exist any more. | ||
Revision as of 14:54, 19 April 2018
| 2038 |
 Title text: If only we'd chosen 1944-12-02 08:45:52 as the Unix epoch, we could've combined two doomsday scenarios into one and added a really boring scene to that Roland Emmerich movie. |
Explanation
The 2038 problem is a well-known problem with 32-bit Unix-based operating systems. Unix time is stored as a 32-bit signed integer on these systems, counting the number of seconds since 1970. In 2038, we overflow the highest number we can store in 32-bit integers, leading to unexpected behavior. The switch to 64-bit operating systems will most likely be complete by the year 2038, which is why Randall is relieved. The reference to Y2K is a throwback to the year 2000 problem, in which people were concerned that computers storing digits as two numbers (e.g.: 99 to represent 1999) would cause problems when the year 2000 began because 00 could have been interpreted as 1900 by error. That Y2K issue was covered widely — with only some small mishaps — but calculating dates beyond 2038 is still not solved on many 32-bit UNIX based systems today. The "even WORSE" is possibly referring to how our increased reliance on computers means the bug could affect many more vital systems, but with Y2K passing by relatively uneventfully especially in light of the hype that preceded it caused people to take this sort of problem less seriously.
The title text is a reference to the film "2012" which is about the world ending in December of 2012, at the end of the Mayan calendar. If the designers of the UNIX operating system had used 1944 as their epoch instead of 1970, then the UNIX crash due to a variable overflow would coincide with the end of the Mayan calendar. Thus, the implication is that there could have been a boring scene in the movie where the UNIX time rolls over and nothing happens and no one cares — because the world doesn't exist any more.
Transcript
- I'm glad we're switching to 64-bit, because I wasn't looking forward to convincing people to care about the Unix 2038 problem.
- Friend: What's that?
- Cueball (arms raised high): Remember Y2K? This could be even worse!
add a comment! ⋅ add a topic (use sparingly)! ⋅ 
refresh comments!Discussion
- Can anyone explain the mouse-over text? Saibot84 (talk) 23:02, 7 May 2013 (UTC)
- Good thing it's explained now, because I was relating 1944 and apocalypse with WW2. 108.162.212.196 21:57, 3 January 2014 (UTC)
"calculating dates beyond 2032 is still not solved on many 32-bit UNIX based systems today". Is the year 2032 a typo, should be 2038? If not, what is the relevance of 2032, should be explained. --Pudder (talk) 07:30, 12 September 2014 (UTC)
Woah, I learned about the 2038 problem yesterday, and I clicked "Random page" today and got this comic! Anyone remember what that phenomenon is called? LuigiBrick (talk) 13:57, 6 January 2017 (UTC)
- The phenomenon might be called apopheny. 172.68.213.181 07:59, 13 July 2024 (UTC)
It's the Baader-Meinhoff Phenomenon 162.158.78.22 14:39, 28 August 2018 (UTC)
The phenomenon is called "coincidence." -- Davidh (talk) (please sign your comments with ~~~~)
This wiki will have it's own 2038 problem, as when we get the 2038th comic (assuming both explain xkcd and the comic itself are still ongoing), http://www.explainxkcd.com/wiki/index.php/2038 will have to be shared by two pages (currently, this link redirects to this comic, as does this one) 172.68.54.10 17:03, 1 September 2017 (UTC)
- Writing to you from the day of comic no. 2038, I can reassure you that our admins solved the problem. --172.68.150.64 19:55, 27 August 2018 (UTC)
Maybe the "even WORSE" part was a pun because things will roll over 136 years instead of 100 as Y2K did. I don't want to add it without discussion first 162.158.75.136 16:32, 25 March 2019 (UTC)
- it's possible, but I think it's mostly in reference to how much more we use computers now than we did then.--Twisted Code (talk) 15:59, 24 November 2022 (UTC)
I never really understood why people were worried about the Y2K bug. At worst, surely it would just interpret it as 1900 instead of 2000? Beanie (talk) 13:58, 19 April 2021 (UTC)
- despite its simplicity, don't think you want to have a bill that the computer system thinks is overdue by 100 years. Same problem here.--Twisted Code (talk) 15:59, 24 November 2022 (UTC)
