Past Issues of Government Technology

The Year 2000 Is Coming!

If you haven't started preparing for its arrival, it's about time you did.

by / October 31, 1998 0
Warning: This year might bite! Armed and considered extremely dangerous to automated systems!" Perhaps we should put up wanted posters in all public places or place a label on every calendar. Some call it the year-2000 problem, others the Millennium Bug, and still others the Y2K problem; but whatever you call it, call it a serious problem. Of course, there are many people who, for whatever reason, don't believe it, are still hoping for a "silver bullet," or are just plain mad at the whole thing.

What is the year-2000 computer glitch? Simply stated, programmers in the past used two digits, instead of four, to describe the year. Thus 1997 became 97, and 2001 would become 01. If someone says to you "I was born in 45," you would quickly assume they were born in 1945. Your mind makes a logical conclusion that the person could not still be alive if they were born in 1845 and obviously could not have been born in 2045, so they must have been born in 1945. Your mind used deductive reasoning -- one of the many affable traits of human beings.

Unless a programmer has instructed a computer, through a program, to make the same sort of deduction, the computer will not make any assumption at all. For instance, assume for a moment the year is 2000 and a computer program is to calculate a person's age but is given only the last two digits of a person's birth year (say 45). The computer will perform as it has been instructed, i.e. it will subtract the birth year from the current year to calculate the age. In this case it will calculate current year - birth year = computer age, e.g. 00 - 45 = -45. Of course, the correct answer is really 55. But in this simple, but realistic, example the computer did not "blow up" or stop working, or anything obvious -- it just gave the wrong answer.

Problem Occurs at Three Levels

This problem can occur at three levels. The first is the most obvious: in traditional "mainframe" computers. These systems are dominated by older computer languages such as COBOL, which encouraged significant independent programming. While these programs served their entities extremely well and have paid for themselves many times over, they generally were not written for years beyond 1999.

The second place to look for this problem is in embedded process controllers. "What's that?" you ask. It is any automated process controlled by a computer chip, such as personal computers, security elevators and doors, telephone switches, traffic lights and electric utility sub-stations. This problem is truly a "Year 2000 Bug." When the microchip was invented, the BIOS (Basic Input Output System) of these chips was designed only to have a two-digit year. A personal computer containing a faulty chip might change its internal date to Jan. 1, 1980, when restarted after Dec. 31, 1999. By the way, Jan. 1, 2000, is a Saturday but Jan. 1, 1980, was a Tuesday, a situation that may cause business doors to be unlocked when they should be automatically closed.

The third place to find the year-2000 problem is, unfortunately, largely overlooked. The third problem is hidden in data. For instance, how will spreadsheets be interpreted after Jan. 1, 2000, when staff has entered only the last two digits of the year for the last several years? The answer depends on the spreadsheet being used. If Excel or Lotus 1-2-3 is being used, it also depends on programmers in Utah (where Lotus 1-2-3 is manufactured) or Washington (where Excel is manufactured). These two popular spreadsheets provide different answers and very little documentation. As long as customers of these systems enter data in its abbreviated two-digit year form, there will be a year-2000 problem when those dates are compared to other dates after the year 2000.

How is the problem fixed? Technically the year-2000 problem is not very challenging. Even novice COBOL programmers can find and correct the use of two-digit year identifiers. Several techniques are available to help embedded process controllers. What makes the problem difficult is two related issues. One, many different areas must be examined and fixed. A medium-size local government may have millions of lines of code -- nearly any of which could contain tests that use dates. Invalid date comparisons can occur in computer programs, training, embedded processors, and in existing data. This becomes a massive inventory, remediation and testing campaign. In short, it requires an extensive management effort to prioritize and execute a plan that will avert problems in time.

And time (or lack thereof) is the second complicating issue. Very little time remains before the year 2000. This is one deadline that will not slip or be delayed. There is no reprieve -- no extension. Worse, even now the problem is manifesting itself in systems that project a result into the future.

To make wise use of the little time that remains, a local government must do a comprehensive inventory of all its automated applications -- mainframe, enterprise servers, telephone switches, etc. Governments must determine which applications will be compliant and which ones will not be using thorough testing techniques. Governments must prioritize the results and find out what remediation steps are required, so plans can be constructed to fix the problem. Finally, local governments must determine which applications can be fixed on time. Contingency plans will be very important for those applications that can't be fixed in time.

Only a few ways exist to fix the year-2000 problem. There appear to be only five recognized ways to fix programs and data affected by the use of two digits to represent year. The International Standard (ISO 8601), adopted by ANSI (American National Standards Institute) requires that all dates be expressed in yyyymmdd format (sometimes dashes are included separating the year-month-day fields) using leading zeroes where appropriate. Thus Jan. 1, 2000, would be 20000101 and Dec. 31, 1999, would 19991231. The ISO 8601 standard is the most intuitive and easiest way to express dates. But it has its drawbacks.

The second and third techniques are called windowing -- fixed and sliding. The idea behind both techniques is to choose, based upon the application, a 100-year segment of time. In a fixed window system, all two-digit years are compared to the selected 100-year segment. For instance, assume a file contained the date 12/25/45 and the 100-year segment is 1940 to 2040. The year would be compared to 40. Since 45 is greater than 40 a 19 is applied for the century. If the two-digit year were less than 40, a 20 would be applied for the century. In the terminology of "windowing" the years selected become "pivot" years -- meaning the century is pivoted based upon the "pivot" years comparison.

Obviously, over time, the fixed window technique becomes obsolete. Thus the concept of a "sliding window" was developed. It is similar to the "fixed" concept, except the pivot years are based upon the current date. So instead of a fixed 100-year period, as in the "fixed window" technique, a "sliding" 100-year period is selected. For example, instead of selecting 1940 and 2040, the sliding technique might use 48 years previous and 52 years from now as pivot points. The same logic is applied as in the fixed window technique, e.g. if the two-digit year is greater than the first pivot point (current year minus first pivot point) the century 19 is applied but if it is less than the second pivot point (current year plus second pivot point) then the century 20 would be assumed. One of the advantages of using a sliding window approach is different pivot points can be selected for different applications, but, as in the fixed window technique, the pivot points indicate a specific 100-year period.

The fourth technique relies on computer math and often is called "encryption." Without trying to describe why, it is well-understood the American date, 12/31/99, can be stored in six numeric computer bytes and with a little bit of rearranging can be used for comparing two dates, i.e. rearrange to 991231. But after extending the date (to include a four-digit year), a programmer can store 19991231 in five computer bytes simply by making the field binary. Thus a programmer can store the complete date, using one byte less, through the use of a computer mathematical "trick."

The final technique relies on the fact that the Georgian calendar repeats itself every 28 years. Twenty-eight years ago it will be the same day of the week and the same day of the same month. It is called the encapsulation method. This technique is hotly debated but is probably a very useful concept for some embedded process controllers where the actual year is not important. But it is not a recommended technique for systems with complex programming.

The Good, the Bad and the Ugly

No, we are not talking about another spaghetti western. What techniques make the most sense? ISO 8601 makes the most sense, because it is the most intuitive. It is also the most expensive technique available. Converting to ISO 8601 means three things. One, all significant date fields in any existing databases (active, archived and security files) must be converted. Two, every program in an application must be checked for significant date usage and converted. And three, the entire application has to be converted from its previous form to the new form all at once. However, most standard setting bodies have looked to the ISO 8601 technique as the best technique.

Fixed windowing has the obvious drawback that soon it would become obsolete. As the years advance, the future-year pivot point draws nearer, and the bottom pivot point draws farther away, therefore less useful to the application. Fixed windowing has a very limited use, if at all. The advantage in using the sliding window technique is that data need not be converted and, for most applications, production programs can be gradually converted. The decision to use this technique probably rests on the amount of time remaining to make year-2000 fixes and the amount of money available. However, if the 100-year period is well selected, this technique may be permanent and cheaper than ISO 8601.

Like the ISO 8601 format, above, the encryption method will require changes to the data and programs and might require an "all-at-once" conversion. It does avoid having to buy additional permanent memory and it is easily explained to the IT professional. The encapsulation method is, perhaps, useful only in embedded process controllers in which the actual year is not important, but the day of the week is very important. For such specialized applications its use might save considerable time and effort.

What if we don't finish? After a thorough inventory, and before remediation is in full swing, it is crucial, though difficult, to determine if the government's efforts will result in compliant systems. And if not, what will your city or county do? If your city's unable to bill for water and sewer services until June 2000, what contingency plan will you have in place?

"There will not be enough time and/or money to fix everything. As triage principles are applied, some low-priority systems will not be fixed at all. Similarly, some medium-priority systems may not be thoroughly tested. Finally, some mission-critical systems may still have errors, even after thorough testing, just due to complexities and oversights" (see for a very technical presentation of Y2K Contingency Planning Requirements by MITRE Corp.). Both time and available resources have diminished. If a local government is not well into its remediation efforts the time this article [is published], then action steps must include development of a contingency plan.

After a thorough and complete inventory of potentially affected systems, rigorous prioritization of those systems must be accomplished. This must, of necessity, involve an evaluation of essential services provided by the local government. It is essential that top management performs or at least directs this effort.

After all potentially affected systems have been prioritized and remediation efforts are under way, estimates to fix crucial applications may exceed the available time. In those cases, contingency plans must be developed and the prioritized list reordered.

How bad will it really be? Many predict doom-and-gloom scenarios. They argue that financial institutions won't function, electric utility companies will lose their electric grids, and governments will fail. We know that many local governments have made corrective actions and that many more are on schedule to complete remediation. Large numbers of financial institutions have pulled millions of dollars into this problem. But a question remains, how many entities have done nothing? Unfortunately, those entities that have done the most work in addressing this problem are the most concerned. In this world of interconnected automated processes, some critical mass of compliant entities is necessary to avoid a large-scale problem.

Be a good scout! "Be prepared" is the official Scout motto. There is no better credo for local government anywhere. The most effective advice we can offer local governments is to start today, if you have not already, and urge your local businesses to do the same.

Copyright 1998, Public Technology Inc.

|
November Table of Contents


By Michael Humphrey
Director of telecommunications and information, Public Technology Inc.

Reprinted by permission of Public Technology Inc., the nonprofit technology organization for local governments. PTI is the technology arm of the National League of Cities, the International City/County Management Association, and the National Association of Counties.