Y2K
| Line 1: | Line 1: | ||
| − | The [[wp:Year 2000 problem|Year 2000 problem]] (also known as '''Y2K''', the Millennium Bug, and a number of other names) was the name given to the repercussions of a design flaw in much mainframe computer software that threatened to cause havoc in data centers around the world at the changeover from 1999 to 2000. In an era where computer memory was represented by technologies such as ferrite cores and other low-density designs, programmers of bygone days (the 50s through the 70s, mostly) generally tended to represent dates in 6-byte text strings (usually in a format such as ''yyddmm'' or ''ddmmyy'', depending on the local standards) to save memory.<ref>The "right" way to do this is to represent the date as a numerical offset from a specified zero date (the ''epoch'', in techspeak). Unix's ''time_t'' does this, using seconds as its standard increment. The 32-bit ''time_t'' runs out in the year 2038, when most Unix-like systems are expected to long since have converted to 64-bit or larger integers. We'll see about that, but it still won't be anything like what people feared for Y2K.</ref> The problem arose in the two-digit years -- any period longer than 99 years, 12 months, and 31 days was not representable in that format, presumably leading to unpredictable results at date rollover. At the time, when increases in computing power were inevitable and software maintenance was expected to be routine, software implementors didn't consider this to be a significant issue; however, as these old programs continued in daily use with few or no updates, a certain sense began to gather around a group of computer consultants in the mid-1990s that there could be a problem (which had been anticipated as early as the mid-80s). | + | The [[wp:Year 2000 problem|Year 2000 problem]] (also known as '''Y2K''', the Millennium Bug, and a number of other names) was the name given to the repercussions of a design flaw in much mainframe computer software that threatened to cause havoc in data centers around the world at the changeover from 1999 to 2000. In an era where computer memory was represented by technologies such as ferrite cores and other low-density designs, programmers of bygone days (the 50s through the 70s, mostly) generally tended to represent dates in 6-byte text strings (usually in a format such as ''yyddmm'' or ''ddmmyy'', depending on the local standards) to save memory.<ref>The "right" way to do this is to represent the date as a numerical offset from a specified zero date (the ''epoch'', in techspeak). Unix's ''time_t'' does this, using seconds from 1970-01-01 0000h UTC as its standard increment. The signed 32-bit ''time_t'' runs out in the year 2038, when most Unix-like systems are expected to long since have converted to 64-bit or larger integers. We'll see about that, but it still won't be anything like what people feared for Y2K. In any case, date strings are old and busted.</ref> The problem arose in the two-digit years -- any period longer than 99 years, 12 months, and 31 days was not representable in that format, presumably leading to unpredictable results at date rollover. At the time, when increases in computing power were inevitable and software maintenance was expected to be routine, software implementors didn't consider this to be a significant issue; however, as these old programs continued in daily use with few or no updates, a certain sense began to gather around a group of computer consultants in the mid-1990s that there could be a problem (which had been anticipated as early as the mid-80s). |
There was considerable controversy over the magnitude of the potential problem. Within the computer industry, though few people advocated outright ignoring the problem, most seemed to feel that it would be mostly an annoyance, and that the real concern was not so much in data centers as date-sensitive embedded control devices such as industrial monitoring and control devices, ATMs, and security systems. Within the IT world, however, there were numerous minor issues -- many operating systems, Microsoft Windows in particular, used 2-digit years internally, and though the problem itself was conceptually simple, it required many man-hours of picking through code and archived data -- an issue more of tedium than ingenuity. | There was considerable controversy over the magnitude of the potential problem. Within the computer industry, though few people advocated outright ignoring the problem, most seemed to feel that it would be mostly an annoyance, and that the real concern was not so much in data centers as date-sensitive embedded control devices such as industrial monitoring and control devices, ATMs, and security systems. Within the IT world, however, there were numerous minor issues -- many operating systems, Microsoft Windows in particular, used 2-digit years internally, and though the problem itself was conceptually simple, it required many man-hours of picking through code and archived data -- an issue more of tedium than ingenuity. | ||
Revision as of 06:18, 7 January 2008
The Year 2000 problem (also known as Y2K, the Millennium Bug, and a number of other names) was the name given to the repercussions of a design flaw in much mainframe computer software that threatened to cause havoc in data centers around the world at the changeover from 1999 to 2000. In an era where computer memory was represented by technologies such as ferrite cores and other low-density designs, programmers of bygone days (the 50s through the 70s, mostly) generally tended to represent dates in 6-byte text strings (usually in a format such as yyddmm or ddmmyy, depending on the local standards) to save memory.[1] The problem arose in the two-digit years -- any period longer than 99 years, 12 months, and 31 days was not representable in that format, presumably leading to unpredictable results at date rollover. At the time, when increases in computing power were inevitable and software maintenance was expected to be routine, software implementors didn't consider this to be a significant issue; however, as these old programs continued in daily use with few or no updates, a certain sense began to gather around a group of computer consultants in the mid-1990s that there could be a problem (which had been anticipated as early as the mid-80s).
There was considerable controversy over the magnitude of the potential problem. Within the computer industry, though few people advocated outright ignoring the problem, most seemed to feel that it would be mostly an annoyance, and that the real concern was not so much in data centers as date-sensitive embedded control devices such as industrial monitoring and control devices, ATMs, and security systems. Within the IT world, however, there were numerous minor issues -- many operating systems, Microsoft Windows in particular, used 2-digit years internally, and though the problem itself was conceptually simple, it required many man-hours of picking through code and archived data -- an issue more of tedium than ingenuity.
By 1997-8, the COBOL programmers of the world, hitherto hiding their identities out of shame, were raking in substantial amounts of money[2] while trying to fix the problem; similar efforts were being made with embedded systems, which however by their nature are much harder to repair, especially as most of them have not traditionally been flash-based for easy upgrade. Christian fundamentalists, seeing an opportunity for evangelism, blew the expected results wildly out of proportion trying to shoehorn Y2K into their end times theology, with Christian Reconstructionist writer Gary North spearheading a movement towards large-scale survivalism and spawning a cottage industry of low-tech appliances (many bought from companies supplying the Amish and groups like them) and survival-themed evangelism, the intent being that either the Second Coming would follow or the Christian fundamentalists of the world would be the only people with the resources to reconstruct, paving the way for a fundamentalist theocracy. [3] Y2K became the subject of much fictional literature (mostly of a pulp (and often religious) nature, often science fiction but sometimes other genres, including pr0n), and temporarily became a byword for any major but avoidable technical failure.
New Year's 1999-2000 approached with many party plans but quite a few anxieties. Midnight approached at the International Date Line, with New Zealand being among the first to be affected by the changeover... and not much happened. There were a few glitches, the scariest involving alarm systems in Japanese nuclear reactors, but for the most part the rollover went smoothly, even in areas and industries where there had been little to no preparation. Y2K, expected by some to have the kind of lasting impact that natural disasters such as Hurricane Katrina or the Boxing Day Tsunami have had, went into the history books as an overhyped fizzle. A few expired credit cards and the odd broken satellite do not a disaster make, and Y2K passed rapidly out of pop culture.
Was it all for nought? No one really knows how much of the painlessness of the transition could be attributed to preparation and how much was a factor of the problem being not as big as expected. And in fact Y2K preparations had a considerable effect in terms of overall disaster readiness, allowing many companies and governments substantially greater operational flexibility and recoverability in the wake of events such as 9/11 and the 2003 Northeast US Blackout. What is generally agreed is that the demagogues who tried to turn it into a mass settling of accounts with God and humanity were out of their minds, and that everyone got a little hot under the collar about a problem that wasn't quite as big a deal as they expected.
References and notes
- ↑ The "right" way to do this is to represent the date as a numerical offset from a specified zero date (the epoch, in techspeak). Unix's time_t does this, using seconds from 1970-01-01 0000h UTC as its standard increment. The signed 32-bit time_t runs out in the year 2038, when most Unix-like systems are expected to long since have converted to 64-bit or larger integers. We'll see about that, but it still won't be anything like what people feared for Y2K. In any case, date strings are old and busted.
- ↑ and hitting on waitresses that weren't really working at TGI Friday's, mmmkay?
- ↑ After Y2K came and went, many of the same people would recycle themselves after 9/11 as counterterrorism "experts". Different bottle, same snake oil.