By Joel Froese

First and foremost the Y2K bug is a time-keeping problem; regardless of how complex or simple the computer or embedded chip is, it is generally immune from any Y2K problems if has no time & date clock.

Actually the term "the Y2K bug" is a misnomer, there is no one unified Y2K bug, rather a range of problems that differ in significance, scope, and reparability. The often used term "Millennium bug" is also misleading, this problem would have happened at the end of any century; it just so happened that the first practical computer was invented in the 20^th century (1900's.)

Specifically the Y2K bug is a computer problem that may affect some computers and software that only store and only deal with the last two digits of the year in a date field. If a computer only stores "99" instead of 1999, there could be some problems when it compares it to a date in the year 2000 since the only thing it sees is "00". When we humans see only the last two digits, we generally know to add a "19" in front high numbers and "20" in front of low numbers such as "00" or "05". However if a computer program has not been specifically programmed to recognize this rule, it assumes that all dates are in the same century.

There are actually two distinct problems. First there is the rollover question; namely will the computer (or anything else with a computer-based time/date clock) show the correct date after midnight December 31, 1999? The second problem is the date math problem; will the computer correctly compare or calculate the difference between two dates across the century mark?

The date math problem has already presented itself for several years now. If only 2 digits of the year are stored, expiration dates, maturity dates, etc. that extend into the year 2000 or beyond would be considered to be earlier than the current date (since 00 is less than 99.) Also 00 would be considered to be negative 99 years away instead of only 1 year, which could cause big miscalculations. Notice I did not say the computer will think it is 1900 (this is a misconception); if a computer program stores only two digits, it only knows years 00 through 99. After December 31, 1999, "00" will indeed mean 2000, and the problem computer or program will "think" that "99" means 2099. Therefore if you were to begin using computers and software with this problem in the middle of the 21^st century, you generally wouldn't have any problems until 2099. The problem occurs only when comparing dates across the century mark.

Now that many magazine expiration dates are valid well into the 21^st century it is obvious these companies have dealt with this problem, otherwise you would no longer get your magazine, to the computer your subscription would have been expired over 90 years ago. You can check the expiration date on the mailing label of practically any magazine you now receive; you will notice that even if the entire expiration date is abbreviated to 4 or 5 characters, because of limited space on the label, the magazine continues to come although expiration date show the year as 00 or 01.

The same goes for credit cards; during the end of 1997 there were problems with some credit acceptance terminals, but now those have all been resolved. There are now thousands if not millions of people who use their credit cards that expire in the year 2000 or beyond.

Of course solving one particular problem does not necessarily mean the entire organization is Y2K ready. Furthermore, not all organizations have dealt with this problem yet (some smaller, less technically savvy companies may not even have discovered it yet.) They will have several choices come January 2000, either close out all "historical" data so that all new dates will fall in the 21^st, or when running report, labels, etc. they have to run one batch from whatever beginning date, to December 31, 1999 then run another batch from January 1, 2000 to whatever ending date. This, of course, is not always feasible, so there will no doubt be mad scramble to buy new computers and/or off the shelf software to replace these custom systems. This could translate into temporary increase in staffing that manual and less efficient processes require (which could be a problem due to current record low unemployment.)

We have all heard the horror stories about the effort required to fix Y2K bugs, namely combing through thousands or even millions of lines of code looking for elusive date references. This, however, is only the worst case scenario for poorly developed and poorly document programming. To make a change such as increasing the year field to 4 digits should be a simple task in an well-organized program. Programming magazines are full of ads for tools that assist in or even totally automate this process. When using a modern programming language that has a built in date field, no changes may be necessary in the source code at all, just a recompile (a compiler changes human-readable source code into machine language that the computer uses.) with a new compiler.

We always assume that every organization will be affected by the Y2K problem. This is not necessarily true; by using ordinary personal computers and off-the-shelf software it is very likely that an organization will have no problems at all with computers on January 1, 2000. Even on older PC's that do not rollover correctly, the solution is relatively easy: just correct the date once and you're back in business.

While Y2K-related bugs have been reported in modern software, the patches (a patch is a slightly newer version of any given program) are usually available immediately thanks to the Internet. If the software is not "patched" it still is not necessarily going to be a problem for everyone because a "bug" by definition is a problem with software that causes an incorrect response due to an unusual condition. (Therefore the term "Y2K bug" is actually a misnomer, the year 2000 is not unusual, it is inevitable!)

For example, the well-publicized discrepancies between Microsoft's word processing, spreadsheet, and database programs handling of dates with 2-digit years can easily be avoided by typing all four digits for every date, every time. In many cases programs with real Y2K problems will work fine because the dates stored are insignificant or the program is only used for simple tasks and the problem only crops up when specific features are used.

The rollover problem could affect more computers and microprocessor controlled machines. However, it is not impossible to determine what will be affected. First of all, we must understand that in order for anything to have the Y2K rollover problem it must have the following:

1. It must have a real-time (and date) clock (RTC) that runs all the time regardless of what the rest of the computer or machine does
2. This RTC must have a backup battery that keeps the clock running even when the power is shut off.
3. If it does not have a battery or even if it does and the battery goes dead, there must be some way of setting the date (and time) by the user.
4. Which means it must have some kind of readout to display the date and/or time.
5. And of course, for there to be any problem, it must store only two digits for the year.

This really limits the affected machines; if you think about it, your VCR and a personal computer or electronic organizer (if you have one,) are the only things in your home that you set the time and date on. Programmable coffee makers, alarm clock radios, etc. are totally immune from any Y2K problems since they only keep time.

The rollover problem could present itself in several different ways depending on the original design. When you add one to 99 you get 100, but if there is only room for two digits, you have created an overflow error (just as if you add one to 99,999,999 on an eight-digit calculator.) This could "crash" the computer or machine. The term "crash" simply means the computer stops working. Anyone who has used a computer for more than a few hours is probably familiar with this situation. The next step is to "re-boot" the computer by pressing a reset button or by turning the power off and then back on.

Since the RTC runs on a backup battery, it may necessary to also temporarily remove the backup battery. When the machine is turned back on the date will be January 1, 00 or some other default year such as 70 or 80; after the correct time and date is set, the problem is most likely over. Setting the time and date on any machine is normally easy, in most cases it is done at least twice a year (when the time changes for daylight savings time) anyhow.

This is a worst-case scenario, more likely the date will simple rollover to 00 as it should and if the date is only used for display or logging, there is no problem at all. However, there may still be some date-math problems if the current date is compared to previous ones as discussed previously. But it is important to remember that the rollover problem is generally quick and easy to remedy, therefore the only real problem is the date-math problem.

Personal computers and PC based networks, which have nearly replaced mainframe computers and terminals in many businesses, were developed in the early 1980's. From the very beginning the system date had a 4-digit year. The first real database program for PC's, dBase III, also stored dates with a 4-digit year (although by default it only displayed two digits.)

Since it had no real time clock, every time you started an original IBM personal computer it would first ask you for the date and time, which you could enter with or without the extra two digits in the year (it would automatically add "19" if you didn't.) It soon became apparent that this was a nuisance since, unlike mainframes, personal computers were turned on and off at least once a day.

Then came the real time clock (RTC), first as a third-party add-on and later built-in on new computers. Usually it is built right into the motherboard (the heart of any computer; all other accessories are then connected to the motherboard,) the RTC is a separate circuit that runs continuously regardless of what the computer is doing. Even when the computer is turned off and unplugged, it runs off a small battery that you find in every modern personal computer. When you turn a personal computer on, one of the first thing that happens is the computer retrieves the time and date from the RTC; after that, the operating system (such as DOS or Windows 98) maintains a "running clock" in memory. Therefore, from the system date standpoint, all personal computers will sail over the millennium mark without a hitch if they are up and running on New Year's eve. However, due to inconsistencies by computer parts manufactures, the RTC may be storing the wrong date. This will make itself apparent when the computer is turned on for the first time in the new millennium. Of course, the solution is to simply change the date (which affects both the RTC and operating system's "running clock".) After that the RTC will maintain the correct date and time.

If you have a personal computer you can test this. Set the date to 12-31-1999 and the time to 23:59:45; you will quickly see that the operating system has indeed correctly rolled over to the new millennium. Now turn the computer off for a few seconds, then back on; the date may now be incorrect on some older computers, but if you correct it (set it to 01-01-2000) and cycle the power again the date should be correct.

Apple's Macintosh computers were designed from their inception with a very sophisticated time & date field that includes not only the century (4 digit year) but even the time zone of the location of the computer, which can be useful for comparing creation/modification dates of documents from around the globe. And since only Apple Inc. made the hardware, there are less of the inconsistencies that plague some PC's.

Macintosh computers are like a gold standard when it comes to Y2K compatibility, however it does not prevent programmers who write the user applications from using their own method of storing dates. As a matter of fact, a few Y2K problems have already been reported in Macintosh programs; this is part of the insidious nature of the Y2K problem.

Much has been made of the fact that some machines are programmed to shut down if it has not been serviced in a certain amount of time. Assuming these machines also have a Y2K problem, some people expect all kinds of manufacturing machinery, elevators, power transmission equipment, and etc. to grind to a halt on January 1, 2000.

However, if the machine simply keeps track of the time between service, then there is no reason to keep track of the date and time since this adds a lot of complexity. As we all know computers deal only with number (binary number specifically) and all other data is just a layer of abstraction added to computers for the sake of the operators and programmers (humans.)

For example, if the machine must be serviced at least once a year the computer can be programmed to shut down the machine after it counts 31,536,000 seconds (or some other arbitrary unit of time) since the last time a certain switch was pushed. Even though that seem like a big number to us, since it is a numeric value it take only 25 bits (binary digits) to store and no extra programming (all microprocessor can increment a number with only one instruction.) To do this with a standard date and time field (such as 12/10/99 23:45:01) would take at least 96 bits and lot of extra programming (to increment minutes after 60 seconds, hours after 60 minutes, day after 24 hours, and etc. plus the date math to compare it with the last service date.) Unless there is a screen or printout with a human-readable date, the computer does not deal with dates at all and therefore is immune to any Y2K problems.

Otis (the worlds largest maker of elevators) has refuted a now ubiquitous urban legend of elevators being stuck between floors as a result of a Y2K bug for some time now:

• So what do we mean by Year 2000 compliant? Simply stated, if you own an Otis manufactured product serviced by Otis, the product will continue to operate on January 1, 2000, just as it did on December 31, 1999. This includes Otis’ Remote Elevator Monitoring, or REM III, product.

An article in the January 21, 1999 issue of Travel Weekly (a magazine for travel agents) addressed the concerns of the flying public.

This is not surprising, since aircraft systems are thoroughly tested for every conceivable situation due to the unforgiving nature of a malfunction in flight. Aircraft designers must consider all kinds of unusual condition. For example, an aircraft's altimeter will report a "0" then negative numbers when landing in Amsterdam. This information is passed on to other devices in the cockpit, which could cause a "divide by zero" error if the designers were not as careful as they are. This would only be discovered when the aircraft dips below sea level at one of the few places on earth where that is possible (such as Death Valley, CA or near the Dead Sea in Israel.) Rest assured these designers examine how their equipment deals with all types of scenarios no matter how unusual or unlikely. This also applies to most other critical devices such as medical equipment.

Another article on the same page examined several airlines' Y2K readiness. Since tickets for travel in January 2000 can be sold 11 months in advance, February 4, 1999 was the deadline for having their reservation systems fixed. Although these systems are not as critical as an aircraft's systems, they are very critical to the financial health of the airline; the same goes for practically any other kind of corporation for that matter!

The FAA has antiquated air traffic control computers that have already caused their share of problems over the last few years (including shutdowns of regional radar centers.) Air traffic control is actually not a very automated process. The radarscopes themselves can operate without computers and the majority of air traffic controllers were trained how to track aircraft manually. If these computers have Y2K problems, there will not necessarily be any immediate danger, but air traffic may be delayed which is nothing new to experience air travelers.

There has been some concern that we are still not "home free" if everything still works on January 2000; there still may be a problem at the end of February because it is leap year. We all know that a leap year is any year that is divisible by 4, however there are two exceptions: a) if the year is divisible by 100, it is not a leap year b) unless it is also divisible by 400 (like 1600, 2000 & 2400.) While it is conceivable that some programmers may have simply assumed all years ending in 00 are not leap years (since 1900 was not a leap year,) it is more likely that if shortcuts were taken in some programs, the assumption was made that all years divisible by 4 are leap years, in which case this will work fine until 2100. If there really is a problem discovered on Wednesday, February 29, 2000, the solution could be as simple as closing the business for that day. Then on Thursday correct the date on all computers and resume work.

The Y2K problem is not new; when computers came into widespread use in the 1960's and 70's, there were far more people still alive who had been born in the 19^th century than there are today. No doubt problems arose and were dealt with when calculations were made based on their birth date. Of course most of those systems are no longer being used and replacement systems may have actually re-introduced a Y2K problem that was already corrected on the old system.

A perfect example of this is related in a recent issue of Time magazine:

Although this particular programming language apparently required the "invention" of a picture clause, almost any programmer could have dealt with this on his own because early programming languages did not necessarily have a standardized way to store dates, they only had numeric (for numbers) and character (for letters - text) data types. My point is that this is a known issue and some far-sighted programmers (more than we may think) have been addressing this for decades.

It is important to remember that Y2K is a computer problem and as such the extent of the problem can be precisely determined; it is not a mystery. That is why large corporations are doing in-depth Y2K inventories of all computers, software, and other machines that may be affected. This extends all the way up to large-scale, industry-wide Y2K readiness testing like what the securities investment community has already done.

Nevertheless, we know fixing one problem does not automatically mean everything is fixed. There could still be problems in the very same program not to mention the same computer or even other systems; there is no "magic bullet." To solve this problem requires careful, thorough, and sometimes tedious work, but it is not impossible.

Computer problems are nothing new, they have occurred in the past, and will continue to plague us in the future as software become more and more complex.

The Y2K bug is a known problem and there are precise, analytical steps to deal with it. The following is an informative list of steps a business needs to take to be ready for the year 2000 from the National Association of Securities Dealers, Inc.:

1. Awareness - These are the steps an organization undergoes to understand Year 2000 issues and their potential impact. This includes employee education on Year 2000 issues. (e.g., flyers, workshops, seminars), creation of reporting structures, project responsibilities, the creation of a project to monitor and protect the organization against risk.

2. Assessment - This phase usually involves the organization’s preparation for dealing with and identifying the specific risk to their organization. Typically it starts with creating a physical inventory, measuring risk, and contacting third party vendors. Products of the assessment phase might include timelines with milestones, inventory lists, resource and budget allocation.

3. Remediation - This phase is usually referred to as the "fix it" phase. The organization begins replacing any non-compliant business equipment or software, program code modification, management of vendor solutions and renovation of systems.

4. Testing - This phase is to allow the business to know that its business will operate. It involves the testing all your systems and inventory items. Best practices for this phase includes setting up a separate test environment, allowing adequate time for testing, and documenting results systematically. Types of testing include: individual testing, point-to-point testing, and industry testing.

5. Implementation - Installing new or upgraded systems and performing testing along the way.

Regardless of how Y2K ready any computer is, it must have electricity to run. Many people are worried that there are Y2K bugs in power plants and substation around the country and the world, and that if enough equipment fails the effect would cascade across the power grid and cause a nationwide or worldwide blackout. What we must remember is that when computers are used in critical application such as this, they are usually not given complete control. It is understood that such a complex and fragile machine may crash at anytime. That is one of the reasons why you see a control room with hardwired switches, lights, and mechanical dials at any power plant. A computer could easily monitor all these inputs and take appropriate actions without a single operator, but in an emergency, a living, thinking human has to be in control to handle the myriad possibilities that could arise. A competent operator can develop a work-around for broken equipment or even multiple problems.

Any machine, no matter how sophisticated, can only be programmed to handle a finite number of possibilities. Since this weakness and our dependency on electricity is known and the year 2000 now looms so close, doubtless power companies around the country and the world are reviewing and practicing their manual procedure. Unfortunately for most utility workers, they will probably have to be at work on New Year’s eve. Additionally anyone in a computer trade will probably be awake somewhere baby-sitting a computer regardless of whether it needs it because this problem has been publicized to the point of hype.

We must remember that engineers, programmers, and inventors of this century developed all of our modern technology and many of those people are still around. More importantly, this has developed into an intellectual infrastructure that trains new technology workers with their cumulative knowledge plus the very latest technology that allow them to develop even more efficient and sophisticated machines.

Some people revel in the irony that modern technology could destroy itself and not even our brightest mind can save it. However there is not enough evidence to support this wild speculation. This technology was not dropped from outer space, as some UFO cultist may believe. There really are people who understand it and have been working on this problem for some time now.