The Y2K bug may seem a long way off, but it perfectly illustrates an ever-present danger: invisible dependence on aging systems that are only called into question when they fail. In 1999, some were saying that for large companies, it was already too late to correct their systems. The only solution left was to draw up a contingency plan and hope to limit the damage. For small businesses and private individuals, there was still a bit of leeway. But they had to act quickly (very quickly). As a result, this type of guide was essentially aimed at those who had neither a dedicated IT team nor a huge budget, but who still depended on their computers, software or electronic equipment on a daily basis.
In many countries, the warning came late, followed by a flood of information that was sometimes useful, sometimes confusing, sometimes alarmist. The result: uneven preparation, often carried out in a state of urgency or doubt. Of course, this blog does not seek to dramatize or rewrite the past. It draws its inspiration from this period to offer a clear and useful reading of what a real technological risk represents: invisible, silent, but potentially very real. Even if not everything can be anticipated, choosing to do nothing is often the worst option.
It’s not about being a soothsayer and trying to predict exactly what’s going to happen at this millennial tipping point. What’s important is to reflect on what happened during this period, to take a step back and prepare for future computer bugs.
What is the y2k problem?
Although it has become perhaps the most discussed issue in the history of computing, defining the Y2K problem is not as straightforward a task as it may seem. Millions of newspaper articles and casual observers have been happy with explanations along the lines of ‘problems caused when computers fail to recognise the year 2000 in dates, assuming instead that it is 1900’; but in itself that definition does nothing to explain why such a problem should have had such a widespread impact. The Y2K problem originates from a very simple decision made by programmers back when computers first began to be used widely in (large) businesses in the late 1950s and early 1960s. Storage was extremely expensive, and processing power had to be used carefully.
To keep information stored to a minimum, numerous new approaches were used to compact data. Names were often stored with only surnames and initials; states were not included, since these could be deduced from postcodes; professions were coded as numbers rather than descriptions. One of the many decisions made to compact storage at this time concerned the storage of dates. Dates are essential to all kinds of business computing tasks; think of bank statements which must show when transactions were conducted, payroll programs which must operate at a particular time, or interest calculations which are based on the time elapsed from when a loan has commenced.
To keep dates compact, programmers almost invariably chose to store them as a six-digit string, including the day, the month and the year, but not the century. For example, January 23, 1963 might be stored as 230163, or 630123, or 012363, or 23/01/63; the order and the format doesn’t matter as long as the program knows which part of the number corresponds to day, month and year.
It’s important to note, however, that the Y2K danger itself is not caused by storing dates in this format, but rather due to the way in which that stored information is used to make comparisons and perform calculations. Imagine, for instance, a program which needs to check if a given date is in the future or the past. Say the program wants to check the date February 4, 1999, which it records as 990204, and it knows that today’s date is March 7, 1999, recorded as 990307. To determine if the date is in the past, the program can merely subtract 990204 (the query date) from 990307 (the current date). This would give an answer of 103. Since this is a positive number, the date is in the past. If the system performed the same task with the date June 18, 1999 (990618), it would return a negative number (-311), indicating a future date.
The Y2K Problem originates a very simple decision made by Programmers
So far, so good. But what happens when the year 2000 arrived? On January 1, 2000, if the computer performs the same calculation for February 4, 1999, it will subtract 990204 from 000101, and return a negative answer (-990103). The program will deduce from the negative number that the date is in the future, when in fact it is in the past. This is a somewhat simplified and trivial example used for demonstration purposes. The methods by which dates are stored and compared vary widely, but they will almost always cause problems if there is no century included. (For a more detailed discussion of how calculations can go wrong and the consequences of those errors, see ‘The mathematics of Y2K’).
In some cases, as soon as these programs were created, it was recognised that this compact date format would cause problems in both the short and long term. However, the attitude taken was that the computer systems in use in 1960 (or 1970 or 1980 or 1990) were unlikely to be still in use by the turn of the century. Obviously, this turned out to be a false assumption. Companies continued to expand their use of computers, but more often than not they built on existing, older systems with new features, rather than starting from scratch. The more data that was stored in these systems, and the more they were used, the less inclined anyone was to go through the very inconvenient process of removing and replacing them.
And so the systems stayed in place. At the time, it was highly probable that many banks were still running core software that was, at its foundation, more than 40 years old, even if the customer interface had shifted to newer technologies such as EFTPOS or internet-based services.
Millennium bug or Y2K problem?
When problems relating to turn-of-the-century dates first became widely discussed, the usual term used was the ‘millennium bug’. More recently, the term ‘Y2K problem’ has gained currency, and the acronym ‘Y2K’ itself has become a kind of shorthand for the issue. Throughout this website, we will mostly refer to “Y2K’ or the “Y2K problem’.
The Millennium Bug is a widely recognised example of a more general phenomenon: computers which are expecting a certain type of information, and which function incorrectly if they don’t receive that information. The technical category into which Y2K falls is known as ‘bounded storage’, where data is assumed to always be of a certain size or to remain within certain boundaries. This problem in fact occurs with monotonous regularity on computerised systems. Some notable historical examples include: in the late 1990s, the Dow Jones Industrial Average — an aggregate figure which tracks the performance of the US stock market — frequently moved towards 10,000 points, which at the time was considered a historical high. Many computerised systems used by large investment houses had automatic triggers built into them which would give orders to sell, buy or freeze trading when certain conditions were met, such as a large change in the value of the Dow Jones.
However, many of those systems also originally assumed that the Dow Jones would always fall in a four-digit range (between 0 and 9,999). It was widely feared that if the Dow Jones hit 10,000 points, some computer systems would interpret this as 0, deduce a large drop in the value, and sell off huge volumes of stocks, causing fiscal panic and chaos. However, few problems were reported when the Dow finally topped 10,000 in mid-March 1999. This remains a testament to the value of early warnings and careful testing.
Systems which use the Unix operating system generally store dates using a 32-bit digit which represents the number of seconds elapsed since midnight on January 1, 1970. This meant that there were no Y2K-specific problems with these OSes, but they were expected to run into issues at 03:14:07 on January 19, 2038, the moment when the maximum value of a 32-bit signed integer would be reached. Companies that migrated to 64-bit flavours of Unix could generally avoid this problem, though rigorous testing remained necessary. Some Unix vendors had already incorporated tests for this issue into their broader Y2K preparations at the time, recognising that operating system compliance does not automatically ensure application-level safety.
Some boundary storage problems occurred because certain types of data were explicitly rejected. For instance, programs which used Australian postcodes had often rejected special series beginning with 1000, 8000 or 9000 (which were assigned to certain large businesses), and most PABX systems had to be adjusted to handle eight-digit telephone numbers when these were introduced. Because these rules were generally explicit and often user-selectable, fixing them was often — though not always — straightforward.
And if the Y2K bug seems to be behind us, another horizon is looming: the Unix bug of 2038. Less publicized, it is based on a similar logic – that of date formatting limits in older systems. This bug also reminds us that the problem is still real today, even before the 2030s, as banking and administrative systems run on languages like COBOL, dating back to the 60s, illustrating that technical debt is alive and well.
The y2k problem: A history
Early computer programs were generally written inhouse by experts and were designed to solve the problems of one specific business. The programs that were created by one company might occasionally be sold to another, but since effective use of IT systems is often viewed as a competitive advantage, companies were reluctant to share this expertise. Once a company was committed to its own in-house solution, it would not shift from it willingly — even if it was riddled with potential Y2K problems.
While companies such as IBM and Digital began selling some programs for general use in the 1970s, these were still often heavily customised by inhouse IT staff. It was not until the emergence of the PC in the 1980s that mass-market software (designed for use by many different businesses) really took off. Small businesses might have been able to afford a machine for the then cheap price of around $5,000, but they couldn’t pay the same again for software. The emergence of cheap spreadsheets and word processors in particular meant that anyone could use a PC, and even customise it to some extent. Suddenly, it seemed, computers were spreading everywhere — and so was the Y2K problem, although few people realised it at the time.
The number of possible Permutations of the Problem is Incalculable
Throughout this period, the programming practices of an earlier age persisted, including the use of compacted dates. Older software continued to use them, while newer programs also often went down this route. Again, this seemed a sensible decision at the time; if your home computer only offers 64,000 characters of storage (for both programs and files) and you want to keep details of 2,000 customers, do you really want to sacrifice 3% of your total available memory every time you enter a date for all of those customers just by including the century?
The real killer, on both PC and other platforms, was the desire to maintain backward compatibility. A key selling point for DOS as it went through its many upgrades was that software written for older versions would continue functioning; a key selling point for every major release of Windows has been the ability to upgrade your OS while keeping your applications. This ‘keep your old logic’ idea helped PCs become massively popular, but it also meant that fragments of code that dated back 10 or 20 years — to a time when no-one thought
storing century data was a necessity — were included in many modern applications. That assumption, that storing century data wasn’t necessary, was built into the applications that would continue to be used for years to come, the operating systems those applications were built for and even the processors PCs relied on at the time. At the time, this made many systems potentially vulnerable.
Instance of a date-reliant calculation needs to be changed to achieve Y2K Compliance
In the introduction, we noted one simple calculation that could go wrong when using compacted dates. The number of possible permutations of the problem is incalculable; dates can be stored in a variety of different formats, and calculations can be performed on those dates in a number of ways, and the results of those calculations used to make other calculations. The end result is little short of chaos, and exceedingly hard to fix even for the original programmer of a piece of code.
The Mathematics of Y2K
While our earlier example used positive or negative numbers to make a comparison, not all applications are encoded for this distinction. A payroll package, for example, might have ‘92’ stored as the year in which a staff member began working for the company. Long-service leave is calculated on the number of years at work, which can be assessed by subtracting the year the staff member started from the current year. Since someone can’t have worked at a company for a negative number of years, the original programmer may not have bothered storing the sign (positive or negative) of this number, to save space. In 2000, the number of years at the company will jump from 7 (99-92) to 92 (00-92).
This inaccuracy can then impact other processes. For instance, many payroll systems generate an automatic warning when an excessive amount of leave has been generated. The software might also calculate the cost of leave to the company each week, and start issuing dire warnings about the department where the staff member works. Given that the same problem will afflict anyone who didn’t start at the company after 2000, the estimated leave bill may s00n appear to be grounds for bankruptcy.
Compliance in a single application is also not enough. For instance, imagine a backup program which is itself Y2K compliant, and which bases its decision on when to perform backups on when a data file was last altered; if the file has changed since the last backup was performed, a new backup is carried out.
If the backup program is running on an older, non-compliant DOS or Windows PC, then the machine is likely to set its system date to January 4, 1980, when it is switched on in 2000 because of DOS’s own date assumptions. Other non-compliant programs which alter the file will stamp this as the new date, and when the backup program checks, it will see that the file was altered in 1980, and hence assume it was backed up in a previous session.
These kinds of problems can occur many, many times in any program that makes use of a date in calculations. Every single instance of a date-reliant calculation needs to be changed to achieve Y2K compliance (the term used to indicate a system which can correctly handle dates in 2000 and beyond). This nearly always requires the software to be rewritten — a task that is generally beyond the individual user (although custom spreadsheets are one obvious exception). In some cases, the only realistic alternative is to upgrade to new software, or even hardware in some instances. Teaching you how to check for these problems — in hardware, operating systems and software — and how to avoid them is the main purpose of this Pocketbook.
Dates to watch out for
The most commonly cited date for triggering the Y2K problem is, of course, January 1, 2000 (which is, incidentally, a Saturday). As the first date of the new century (for computing purposes), this is when problems will first show up en masse. However, there are a number of other dates in the next two years which will also be affected by the problem.
Some common Y2K myths
As Y2K fever swept the globe in the late 1990s, a number of popular myths about what was compliant, what wasn’t, and what could be done about it spread like wildfire. Here are four statements that people were often wrong about at the time:
“I use a Mac, so I’m OK.”
Apple often claimed that Mac OS was always four-digit date aware, suggesting there were no OS-level issues and that most applications should be safe. But relying on the operating system alone was misleading. Assuming your apps were fine just because the OS handled dates correctly was a shortcut to trouble. In fact, one of the Mac’s internal routines — StringToDate — didn’t interpret dates properly. It assumed all dates belonged to the same century as the Mac’s internal clock, which led to miscalculations in edge cases.
“I only used word processing software, so I was OK.”
It’s true that most word processors didn’t perform date calculations — but that didn’t make them Y2K-proof. Many modern word processing suites at the time included spreadsheet components or automation tools that interacted with system dates. More importantly, every file saved was timestamped with the current date and time. If the operating system didn’t handle dates correctly in the year 2000, those timestamps became unreliable.
And if a backup system relied on those same date stamps to detect changes, it could malfunction or fail to recognize recent edits.
“I had just bought a new PC, so I was OK.”
A PC purchased in 1999 wasn’t likely to have major hardware-level issues, and OS problems were usually minimal. But that didn’t guarantee safety. What applications were you planning to run? Had you imported old spreadsheet data? Were other machines in your network older? These overlooked factors could still trigger Y2K problems.
“My business didn’t use a PC, so we were OK.”
This was one of the biggest myths. Even if your internal systems were paper-based, you still depended on external services. If your business partners, suppliers, or clients had IT issues, it could easily affect your operations. Y2K was not just about what you controlled — it was also about who you relied on.
“Bugs like Y2K can’t happen today.”
False. The Y2K bug story shows that the simplest design flaws can lead to global consequences. In a world increasingly dependent on automation and AI like ChatGPT, DeepSeek or more, invisible bugs can now have immediate, large-scale impact.