|Is it news?|
|The Latest News|
In an era where computer memory was measured by the byte or "word" and came in the form of things like drums[wp] and ferrite cores[wp], 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. The problem arose in the two-digit year format — any period longer than 99 years, 12 months, and 31 days was not representable, which would presumably lead to unpredictable results at the date rollover.
This problem had been anticipated as early as the mid 1980s, but at the time, when increases in computing power were inevitable and software maintenance was expected to be routine, software implementers and technicians didn't consider this to be a significant issue, believing, when they considered it at all, that the programs in question would be replaced before the millennium rollover. 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 '90s that there could be a problem.
 Rational reactions
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. Banks were certainly alarmed at the notion, as a failure in their interest calculation systems could cause them to lose money. 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[wp] programmers of the world, hitherto hiding their identities out of shame, were raking in substantial amounts of money while trying to fix the problem; similar efforts were being made with embedded systems, which by their nature are much harder to repair.
 Irrational reactions
Inevitably, the media and the public took an interest in the potential harm that this issue could cause to industries, national security, and the world economy. 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 Reconstructionist writer Gary North spearheading a movement towards large-scale survivalism. This spawned a cottage industry of low-tech appliances (many bought from companies that had once made most of their business supplying the Amish and groups like them) and survival-themed books and campaigns, the intent being that either the Second Coming would follow or the fundies of the world would be the only people with the resources to reconstruct, paving the way for a theocracy. (After Y2K came and went, many of the same people would recycle themselves after 9/11 as "counterterrorism experts". Different bottle, same snake oil.) Y2K became the subject of much fictional literature, mostly of a pulpy nature, often science fiction or religious but sometimes other genres (including pr0n), and one particularly bad NBC TV movie. Y2K temporarily became a byword for any major but avoidable technical failure.
 What actually happened
While the Y2K scare can be credited for many companies doing significant data infrastructure upgrades and generally cleaning house on a lot of legacy software and data, the final work was nowhere near complete as New Year's Eve 1999-2000 approached, with many party plans but quite a few anxieties (and a lot of techies getting considerable overtime for working New Year's Eve). 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 and minor crashes here and there, the scariest involving alarm systems in Japanese nuclear reactors, and a spy satellite went on the fritz, but for the most part the rollover went smoothly, even in areas and industries where there had been little to no preparation. The cascading supply-chain failures and embedded control system disasters that were predicted never materialized, and some systems (most notably Unix-like and Mac OS systems, but also many embedded systems that didn't really care about the date to begin with) didn't have any problems at all. The main actual victims were ill-maintained vertical market apps for PCs, the sort of obscure but essential business software that has one writer and very few users.
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 over-hyped fizzle. A few expired credit cards and the odd broken satellite do not make a disaster, and Y2K passed rapidly out of pop culture. The economy remained more or less healthy until April 2000, when the money train ran out for the dotcom boom.
As sort of a lead-up to Y2K, there were some minor concerns around what would happen on 9 September 1999, mostly centered around shitty programming that turned out to be negligible. In one instance, sales callers over the previous decades were instructed to enter "9/9/99" into a "next call" date field for any clients they were not going to contact again (as opposed to having an "inactive client" field) ...thus scheduling them to call back former customers on 9 September 1999. Total anarchy!
Was it all for naught? 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.
But just when you thought it was safe to go back in the water... In 2038, 32-bit Unix systems will experience a similar problem with "date rollover"; this has been dubbed, unimaginatively enough, the Year 2038 problem[wp]. Note that "Unix" today includes BSD and its derivatives (which in turn includes Mac OS X) as well as "Unix-likes" such as Linux. The PC industry has been shifting gradually to 64-bit hardware and software, but there will probably still be a lot of legacy stuff sitting around, and most embedded systems (not only tablets and smartphones, but automobiles, industrial equipment, etc.) are not 64-bit. This of course means the world will end and we're all DOOMED! But in reality, just as with Y2K, it will entail a lot of boring work upgrading and replacing stuff.
 A case study of a Y2K book
The Millennium Bug: How to Survive the Coming Chaos by Michael S. Hyatt was a fairly typical layman's guide to the bug. Hyatt's writing leaned heavily on fear-mongering and argument from authority, while advocating survival solutions apparently calculated to appeal to right-wing libertarian and survivalist values, including moving to a small town and stocking up on guns and food. Hyatt offered three possible scenarios: brownout (major inconvenience), blackout (life-threatening economic failure), and meltdown (complete societal collapse), considering some combination of the second two most likely. The scenario of "not much of anything" was never even mentioned.
After the Y2K bug proved to be mostly a bust, Hyatt would go on to write books on protecting yourself from terrorism.
- ↑ 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 — the UNIX Epoch — 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 (as almost all new computer systems save embedded products and netbooks have done over the last couple of years — anything with 4 or more gigabytes of memory needs a 64-bit system). 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.
- ↑ New York Times archive of the Year 2000 Problem
- ↑ IMDb: Y2K (1999)]
- ↑ The first hint of trouble in the Y2K movie was when an airliner crossed the International Date Line on December 31st, and promptly fell from the sky. In a case of truth being stranger than fiction, years after Y2K this actually almost happened, except with the F-22 fighter jet, because the authors of the avionics software screwed up. Guess $66 billion isn't enough to get good programmers.
- ↑ Y2K bug fails to bite, BBC News
- ↑ US satellites safe after Y2K glitch, BBC News
- ↑ A few software packages, mostly programming libraries written in the 1990s and still actively maintained, still carry Y2K compliance statements, most likely because no one could be bothered to excise something like that from the documentation.
- ↑ Yes, these happened after the millennium...
- ↑ So, in a sense, Y2K did wreck the computer industry after all.
- ↑ Sept. 9, 1999: 9/9/99 No Big Deal for Computers, Wired
- ↑ Hyatt, Michael S. The Millennium Bug: How to Survive the Coming Chaos. Washington DC: Regnery Publishing, 1998.
- ↑ At one point, he included fluency in Pascal and "three different dialects of BASIC" as part of his qualifications, some very trivial resume items likely to result in gales of laughter from more sober-minded geeks.