Editing 2697: Y2K and 2038
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 10: | Line 10: | ||
==Explanation== | ==Explanation== | ||
+ | {{incomplete|Created by a Y2K-BRICKED BOT (MADE JAN 1, 1970). Do NOT delete this tag too soon.}} | ||
[[File:Year 2038 problem.gif|thumb|An animation of the 2038 bug in action. The {{w|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]] | [[File:Year 2038 problem.gif|thumb|An animation of the 2038 bug in action. The {{w|integer overflow}} error occurs at 03:14:08 UTC on 19 January 2038.]] | ||
− | The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years | + | The Y2K bug, or more formally, the {{w|year 2000 problem}}, was the computer errors caused by two digit software representations of calendar years not correctly handling the year 2000, such as by treating it as 1900 or 19100. The {{w|year 2038 problem}} is a similar issue with timestamps in {{w|Unix time}} format, which will overflow their {{w|Signed number representations|signed}} 32-bit binary representation on January 19, 2038. |
− | While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. | + | While initial estimates were that the Y2K problem would require about half a trillion dollars to address, there was widespread recognition of its potential severity several years in advance. Concerted efforts among organizations including computer and software manufacturers and their corporate and government users reflected unprecedented cooperation, testing, and enhancement of affected systems costing substantially less than the early estimates. A major problem struck IBM mainframes as early as August 16, 1972 (9999 days before Y2K) that made tape files that were supposed to be marked “keep forever” instead be marked “may be recycled now”, but on New Year's Day 2000, few major errors actually occurred. Those that did usually did not disrupt essential processes or cause serious problems, and the few of these that did were usually addressed in days to weeks. The software code reviews involved allowed correcting other errors and providing various enhancements which often made up at least in part for the the cost of correcting the date bug. |
− | It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity | + | It is unclear whether the 2038 problem will be addressed as effectively in time, but documented experience with the Y2K bug and increased software modularity has allowed many otherwise vulnerable systems to already upgrade to wider timestamp and date formats, so there is reason to believe that it may be even less consequential and expensive. The 2038 problem has been previously mentioned in [[607: 2038]] and [[887: Future Timeline]]. |
− | + | The caption in this comic provides a punchline: everyone should have completed their "Y2K recovery" as it has been a full 22 years since the year 2000. It is highly unlikely that there are more than a very few consequential older systems that still suffer from this bug, and any modern systems have already been built to handle the years 2000 and later. | |
− | The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes | + | The title text refers to replacing the 32-bit signed Unix time format with a hypothetical new 33-bit signed {{w|Integer (computer science)|integer}} time and date format, which is very unlikely as almost all contemporary computer data structure formats are allocated no more finely than in 8-bit bytes. Taking 20 years to develop and implement such a format is not entirely counterproductive, as it would add another 68 years of capability, but it is far more counterproductive than upgrading to the widely available and supported 64-bit Unix time replacement format and software compatibility libraries. |
==Transcript== | ==Transcript== | ||
− | + | {{incomplete transcript|Do NOT delete this tag too soon.}} | |
− | [Caption:] Reminder: By now you should have finished your Y2K recovery and be several years into 2038 preparation | + | [A timeline rectangle spanning from 2000 to 2038 divided into two halves, with the half-way point of 2019 labeled. The left half is labeled "Recovering from the Y2K bug" and the right half is labeled "Preparing for the 2038 bug." An arrow labeled "Now" is pointing approximately at the year 2022.] |
+ | |||
+ | [Caption:] Reminder: By now you should have finished your Y2K recovery and be several years into 2038 preparation | ||
{{comic discussion}} | {{comic discussion}} |