In the situation above, there is at least one person standing by who can intervene when the problem occurs: the card owner or issuer. More disturbing, perhaps, are the "silent killer" versions of the Y2K problem, which can occur with any of the millions of embedded processors used in computers, toasters, cars, power plants and many other devices.
Next, consider a system that is required to run an internal safety test once a year. The system regularly checks whether the difference between the current date and the last test date is greater than days. When a last test date in this century is subtracted from a date in the next century, though, the answer is a negative number less than , so the system will not believe it is time to perform the test. And in fact, left as is, the system will not perform another safety check for another years.
Why do these systems make such bad assumptions? In most cases, designers just never thought the programs they were writing would be in use for so long--namely into the 21st century. And there were real practical advantages to using shorter, two-digit years in dates at the time they were put in place. There are many different ways to fix the problem. Ideally we could just rewrite all the offending programs and modify all the existing stored data.
But in many cases the program is so old that the original "source code" the form written by the programmer before it is converted into a digital form understood by the computer is lost and it is impractical or impossible to modify the digital form.
When the source code does exist, there may be no "compilers" the programs that convert source code to its digital form compatible with that version of the code's language anymore.
And even if the program could be successfully modified, changing all the stored data would be impractical. Many non-date-dependent programs would also need to be changed because the placement of data in the file would change when space for the additional date digits was added.
If the window has simply been pushed back again, we can expect to see the same error crop up. Another date storage problem also faces us in the year Read more: How tech bugs could be killing thousands in our hospitals. Trending Latest Video Free. COP26 news: US-China climate pact is important but largely symbolic A fragment of our moon may be orbiting the sun with Earth Our Human Story newsletter: The patterns of domestication Sterile neutrinos could explain dark matter — if we can find them COP New alliance commits to ending oil and gas extraction.
The flaw, faced by computer programmers and users all over the world on January 1, , is also known as the "millennium bug. So, Y2K stands for Year Many skeptics believe it was barely a problem at all. When complicated computer programs were being written during the s through the s, computer engineer s used a two-digit code for the year.
The "19" was left out. Instead of a date reading , it read Engineers shortened the date because data storage in computers was costly and took up a lot of space.
As the year approached, computer programmers realized that computers might not interpret 00 as , but as Activities that were programmed on a daily or yearly basis would be damaged or flawed. As December 31, , turned into January 1, , computers might interpret December 31, , turning into January 1, Banks, which calculate interest rate s on a daily basis, faced real problems. Interest rates are the amount of money a lender, such as a bank, charges a customer, such as an individual or business, for a loan.
Instead of the rate of interest for one day, the computer would calculate a rate of interest for minus almost years! Centers of technology, such as power plant s, were also threatened by the Y2K bug. Power plants depend on routine computer maintenance for safety checks, such as water pressure or radiation levels. Not having the correct date would throw off these calculations and possibly put nearby residents at risk.
Billions of dollars were spent addressing the Y2K bug. Government, military, and corporate systems were all at risk, yet we made it through, more or less, unscathed. So, was the threat even real? One reason for this was to save space. The earliest computers had small storage capacities, and only a fraction of the RAM of modern machines. Programs had to be as compact and efficient as possible.
Programs were read from punched cards, which had an obvious finite width typically, 80 columns. Wherever space could be saved, it was. An easy—and, therefore, common—trick was to store year values as two digits. For example, someone would punch in 66 instead of Because the software treated all dates as occurring in the 20th century, it was understood that 66 meant Eventually, hardware capabilities improved. There were faster processors, more RAM, and computer terminals replaced punched cards and tapes.
Magnetic media, such as tapes and hard drives, were used to store data and programs. However, by this time there was a large body of existing data.
Computer technology was moving on, but the functions of the departments that used these systems remained the same. Even when software was renewed or replaced, the data format remained unchanged.
Software continued to use and expect two-digit years. As more data accumulated, the problem was compounded. The body of data was huge in some cases. Making the data format into a sacred cow was another reason. All new software had to pander to the data, which was never converted to use four-digit years.
Storage and memory limitations arise in contemporary systems, too. For example, embedded systems , such as firmware in routers and firewalls, are obviously constrained by space limitations.
Programmable l ogic c ontrollers PLCs , automated machinery, robotic production lines, and industrial control systems were all programmed to use a data representation that was as compact possible. Plus, the more dates you have to deal with, the bigger the benefit. The software was written to treat all dates as though they were in the 20th century.
This gives false results when you hit the next century. The year would be stored as Therefore, the program would interpret it as , would be treated as , and so on. At the stroke of midnight on Dec. Perhaps the software would accept the wrong date and carry on, producing garbage output. Or, perhaps it would throw an error and carry on—or, completely choke and crash.
Microprocessors were running in aircraft, factories, power stations, missile control systems, and communication satellites. Practically everything that was automated, electronic, or configurable had some code in it.
The scale of the issue was monumental. Typically, some quarters predicted the end of days and the fall of society. In scenes that will resonate with many in the current pandemic, some took to stockpiling essential supplies. Others called the whole thing a hoax, but, undeniably, it was big news. There were other, secondary, concerns. As a result, how it would perform on Feb. Long before , governments and companies worldwide had been working hard to find fixes and implement work-arounds for Y2K.
0コメント