[Email Reply]

The Year 2000 Problem in Perspective

by J. Orlin Grabbe

The four-hour drive from Denver is spectacular. You drive into the Rockies from the east, turn south just beyond Vail, cross Independence Pass which still shows patches of snow in August, and take the practically one-lane road down into Aspen. I always consider the vista one of the primary pleasures of attending the annual Eris Society conference.

The opening cocktail party had just started when I arrived, so I just took time for a quick shower before joining fellow Erisians. And I had scarcely been served a glass of Chateau Lafite Rothschild 1947 (just kidding--I think it was an Oregon Pinot Noir), when THE QUESTION reared its grisly head out of the muck of the Information Super-Cow Trail.

"What do you think of the Year 2000 problem?" someone asked.

Is there no God? "About 50 percent of it is software-marketing hype," I said, hoping this conversation was going nowhere. "The other half is a real problem, but technically not that difficult."

For those who may not have heard yet, the "Year 2000" or "Y2K" problem is the problem that many computers and software programs will interpret a date like "10/08/04" as October 8, 1904--rather than the intended October 8, 2004. Therefore everything from mortgage calculations to scheduled dividend checks will go haywire if the problem isn't fixed ahead of time.

A man adjacent turned to us: "That's what I said in my article. The market--" It was Harry Browne. Harry Browne has the basic requirement to be President: he's tall. (Can you imagine Louis Freeh as President? The marine at the White House door would have to make up his mind whether to salute him or step on him.) In fact, Harry Browne announced his candidacy for President in 2000 while at Eris. But that's a different Year 2000 problem. Myself, I don't believe in encouraging politicians. Even ones as decent as Harry Browne.

I didn't know what article Browne was referring to. (It subsequently appear in the Nov. 1997 issue of Liberty.) But sometimes I cringe when people bring up "the market" as a solution to a flaw in technology. Maybe it's because I make my living solving problems of a technical nature. The market doesn't solve the problems: I do. The market just determines what I'm paid for doing it. When you are staring at a blank sheet of paper, or a blank computer screen, turning your thoughts to the market doesn't help.

The market is a signaling device. In the case of the Year 2000 problem, it sent out a signal to software companies around the world: BONANZA AT HAND. Problem in need of a fix! "Buy our software solution services, or your company will go to hell." You know, the usual marketing hype. The Year 2000 problem is to software providers what the Russian hacker heist of Citibank funds was to computer security providers. It escalated the chain reaction of naked fear to critical mass, which is defined as that point where funds are actually allocated in the budget to address the problem.

Address the problem, mind you. Not necessarily solve it. Few computer security people could have prevented the Citibank heist, because they simply didn't know what the flaw in the software was. And most of them still don't. In the case of the Year 2000 problem, the flaw is well understood. But it's often also well hidden.

Is there a Year 2000 problem? Yes. Is it technically difficult to solve? No. Will everyone get their software fixed before 2000? No. Will there be problems? Undoubtedly.

One of the virtues of the marketplace is that it is also a great destroyer. Firms that solve their software problems in advance will gain a reputation for reliable service. Firms that ignore the problem will see their systems flop, and their customers get angry. The lawyers are already smelling blood, getting those lawsuits ready, eagerly scanning the horizon in search of fee-paying victims to represent. Unless, of course, the government is responsible. Out here in Nevada they passed a law that says you can't sue the State over Year 2000 problems. But generally companies that don't respond to the Y2K problem will lose market share. Some may go under. The market doesn't care. And neither do I. But there is no assurance that problems will be fixed. On the other hand, if you haven't heard about the problem by now, you are living with your head buried in the sand. The market has done its signaling job with its usual finesse.

Fixing the Year 2000 problem is technically easy. So what's the problem? The main problem is ferreting out all the places it can occur. We are not normally aware of the passage of time until it stops passing at an acceptable rate.

Let me illustrate with an example. In the mid-1980s, shortly after I had gone into the banking software business, I accepted a consulting job with a major New York investment bank to evaluate the foreign currency option prices coming out of their newly created back-office system. Now, there is a naive assumption often made outside the business that all an investment bank has to do to get its number-crunching done properly is to pay enough to hire the right "quant" (short for quantitative person) or "rocket scientist", and their valuation problems are solved.

Life is not that simple. Yes, you have to be able to do the mathematics. But you also have to know the finance to marry the two properly. And by "finance" I mean you have to know something about market practices--not necessarily the BS that often passes for finance in MBA classes--as well as financial arbitrage relationships. (There is nothing more pathetic than watching a quant take a "financial engineering" formula using a continuously compounded interest rate, and attempt to pop into it a market interest rate calculated on a simple 360-day year basis.)

In a banking environment, derivatives systems are typically produced by a programmer, who doesn't understand mathematics, and who is not talking to the trader. The trader doesn't understand computers, and in turn is not talking to the mathematician, who doesn't understand either trading or computers. And the three of them are supervised by a "manager" who doesn't understand any of the above subjects, and who thinks his job is done just as long as each person shows up for meetings on time, and delivers an irrelevant report in a civil tone of voice.

On this project, I met with the manager in New York, who was paying the bill, and then talked to the group who did the work. They were headed up by a fellow who had a mathematics degree from MIT, as I recall, and who basically answered all the questions. I asked about various things that had been done in the implementation of the system, and got back sensible answers. So, happy at the smooth sailing, I took a set of sample output option prices back to Philadelphia to check out at my leisure.

Right away I saw their option prices were different from mine. That shouldn't have been the case, based on our discussions. I hate it when things get messy. But, then, they usually do.

Since I couldn't find any understandable pattern of why their prices differed from mine, I decided to check their option prices for internal consistency. I did a put-to-call conversion, and solved for the forward exchange rate at option expiration. (You may not care. But if you do, the relationship is explained in Chapter 7 of my book International Financial Markets. Essentially, the value of a "European" call minus a put is equal to the discounted value of the forward rate minus the option strike price.)

Well, the forward rate that the option prices solved for was wrong for the date in question. "So," I thought, "it's probably an interest rate problem." For incorrect treatment of interest rates was one of the most common problems I customarily came across. But after trying a number of variations on false interest rate conversions, I still couldn't come up with their prices. Yet clearly the forward rate was wrong. So next I made the assumption the interest rates were handled properly, and back-solved for the number of days to maturity. That is, for time T.

T, as I recall, solved out to be 74 days when their option prices were used. But in fact there were 126 days to maturity. Hmm. So I inserted T=74 days in the option formula, instead of T=126. But . . . No luck. I still couldn't reproduce their pattern of prices.

Then, in a burst of intuition, I reprogrammed the option algorithm so it used 74 days for interest rate calculations, but 126 days for volatility calculations. Bingo. I could now duplicate all their prices. Their pricing algorithms were correct, except when they were calculating interest rates, in which case their calendar function (which calculated the number of days between two dates) was wrong. Their function was giving T=74 days when the correct figure was T=126 days.

So I went back to New York and told them the bad news. Naturally, they were somewhat defensive in the presence of their supervising manager. One person pulled out a printout of their computer code. "See," he said, "the code is correct." This is always amusing. You have a computer function. You have verified the inputs are correct. You have verified the output is wrong. Therefore you know the code is wrong. But the programmer, instead of accepting this, may say, "No, look at my code. It's correct."

So I did a conversion for them. Luckily, they knew what a conversion was, and didn't argue the issue. They had no explanation why their conversion relationships were incorrect. They hadn't thought of checking this before. It was, after all, one of those financial things. I went back to Philadelphia feeling happy I had done my job, but leaving behind a clearly unhappy crowd. But two days later the MIT mathematician called me: "Our calendar function is f***ed up," he said.

Now. If a bright MIT graduate can experience this problem, what do you think could be true of the senile COBOL programmers the IRS is trying to hire to fix thirty-year old computer code?

Back in the antediluvian age of 1993, Jim Seymour wrote in PC Magazine: "It's not that the world's COBOL programmers don't know how to fix the problem or that current mainframe programming languages are incapable of handling dates in the next century. The problem is that mountain of old, fragile mainframe code still in use in businesses around the world--often running processes that lie right at the heart of a company's business. These applications have been around so long, were developed in such tangles of spaghetti code, and have been modified in undocumented ways so many times that no one now employed by the company knows how to fix them. In some cases, no one now alive knows how to fix them."

How to Drive Your Computer Crazy

Let's cover the basics of the Year 2000 problem step-by-step:

1. The crux of the Year 2000 problem was the old programming practice of recording dates on a 2-2-2 basis: YYMMDD. Two slots for year (97, for example), two slots for month (10), and two slots for day (08). YYMMDD=971008.

2. However, when you calculated the number of days between dates--which is done thousands and thousands of times every day in almost any financial context--each date must be transformed. For example, if you want to calculate the number of days between October 8, 1997, and the previous September 30, 1997, you can't just subtract 970930 from 971008, for that calculation gives 971008-970930 = 78, which is clearly wrong.

3. You first convert each date into the number of "Julian days". The Julian day count for October 8, 1997 is 2450730. The Julian day count for September 30, 1997 is 2450722. The difference between these two Julian day counts is 2450730-2450722 = 8. There are 8 days from, say, noon of September 30, 1997, to noon of October 8, 1997.

4. What are Julian days? The Julian day count is just a pure accumulation of days, and hence it ignores all the nonsense about the length of different months, years and leap years, and so on. It is used in astronomical calculations. The "Julian" in Julian day count is Julius Scaliger, who is the father of the man who thought up the Julian day count. (But the father in turn was named after Julius Caesar, so it's a moot point.) The "Julian Calendar", on the other hand, is named after Julius Caesar, who in 45 B.C. established the months and their lengths as we know them now. (Don't believe that fabricated tale of how August got 31 days.) The "Gregorian Calendar", which we use presently, was named after Pope Gregory, who chopped 11 days out of the calendar in October 1582, and decreed that years ending in "00" would no longer be considered leap years, unless they were divisible by 400. (So 1900 wasn't a leap year, but 2000 is.) Gregory had October 15, 1582 be the day immediately following October 4, 1582.

5. The Julian day count starts at 0 on January 1, 4713 B.C., as measured by the Julian calendar, if we imagine extending this calendar backward into the past (a "proleptic" extension). The Julian day count starts at 0 on November 24, 4714 B.C., as measured by the Gregorian calendar. (If you want to know why that date was chosen, it's because the first year of the Julian day count corresponds with the first year of three different important time cycles. These are the 19-year Metonic Cycle, which harmonizes the lunar month with the solar year; the 15-year Indiction Cycle, a Roman tax cycle; and the 28-year Solar Cycle, the length of time needed for the Julian Calendar to repeat exactly.)

6. So, suppose the computer software needs to calculate the number of days between, say, October 8, 1999 and October 8, 2000. The Julian day count for October 8, 2000 is 2451826. The Julian day count for October 8, 1999 is 2451460. The difference is 2451826-2451460 = 366 days. So--what's the big problem with Year 2000 calculations?

7. The big problem is when the computer sees a date like "10/08/00". If the computer interprets the "00" as 2000, then the Julian date count is 2451826. But if the computer interprets the "00" as 1900, then the Julian date count is 2415301. So in that case the difference in days between "10/08/00" and "10/08/99" is 2415301-2451460 = -36,159 days. Instead of adding a year's worth of interest, the bank discounts your balance for a hundred years, and reduces it to practically zero. Or, equally likely, the computer software calculates negative days, and just hangs, and you have to reboot the computer.

What can you do about this? The obvious thing is to record dates as 4-2-2: YYYYMMDD. For example, YYYY=1999 or YYYY=2099.

Another way, if you don't need to deal in century-long time spans, is to use "windowing" with respect to the earlier YYMMDD format. For example, if YY>75, then interpret the century as 19YY. But if YY<=75, then interpret the century as 20YY. This, of course, would create a Year 2075 problem if there were no further updating. But, heh, who cares? I am reminded of the corporate treasurer who issued 30-year zero coupon bonds in 1984. These were pure discount securities issued at a fraction of face value, which would pay off their face value at maturity. He took in $200 million. In 30 years he would have to pay back $1 billion. "What will the company do in 30 years, when the notes are due?" one financial publication asked. "I don't know. It's not my problem. I retire in two years," the treasurer replied.

That, of course, is why we have the Year 2000 Problem. The first generation of programmers retired. It wasn't their problem.

Will Civilization End on Jan. 1, 2000?

Immediately after the year 2000 arrives, I suspect that almost every computer glitch that occurs anywhere in the world will be blamed on the Y2K problem, no matter the source of the problem. It will serve as a handy whipping boy for programmers around the globe.

I find it hard personally to take the Year 2000 problem seriously. It's not that big a deal to fix. But it is also clear that there are lots of people not doing anything about it. They don't read computer publications. They don't think about how their computer uses dates for sorting files. And a "Year 2000 Problem" sounds like some heralded event in apocalyptic religion. So they don't pay much attention to the newspaper either.

What will happen in the Year 2000 if a company suddenly can't pay its payroll because the payroll software doesn't work? If invoices can't be paid because the general accounting system doesn't work? What if suddenly you can't get cash because the ATMs are down "due to temporary difficulties"? Or what if the time locks on bank vaults release on Saturday, Jan. 1, 2000, just because Jan. 1, 1900 was a Monday, and so the control system thinks it's Monday?

And of course there are many other contexts, where you might not think the problem appears, but it does. Such as the Global Positioning System (GPS). The GPS has a field called "week number". Week 0 was midnight Jan. 5, 1980. There are 9 bits allocated to the field, so it allows for Weeks up to 1023. The final week is up on August 22, 1999. Then the counter rolls over to zero, to Jan. 5, 1980. So any older application that uses this "week number" field will be affected, unless the unit is replaced before then.

One litmus test I use to gauge alarm levels is the Bank for International Settlements (BIS), the coordinating institution for many of the world's central banks. Not much gets them excited. But recently they came out with a report entitled The Year 2000: a Challenge for Financial Institutions and Bank Supervisors. It drily asserts:

"The Year 2000 poses a significant challenge for financial institutions because many automated applications will cease to function normally as a result of the way date fields have been handled historically. Failure to address this issue in a timely manner would cause banking institutions to experience operational problems or even bankruptcy and could cause the disruption of financial markets."

Well, if the BIS thinks some financial institutions may go bankrupt over the problem, I suspect they are are right. The report also notes the additional problem of the single European currency: "The scheduled introduction of the Euro is placing significant competing demands on scarce technical resources for institutions in that market."

Finally, the report concludes: "The Year 2000 issue is potentially the biggest challenge ever faced by the financial industry." I guess the BIS thinks the problem is serious. Certainly the Year 2000 will come to all financial institutions, and the Market will sort them out.

The Federal Reserve Board has gotten into the act by making Year 2000 compliance part of the bank examination process. You can view their page of Year 2000 links and associated regulatory information.

And, of course, you will not want to miss the collection at Year 2000 Com. This group of materials is put together by people who hope to (and are) profiting from the Year 2000 problem, so naturally they have no incentive to downplay it. But that doesn't mean much of the material isn't valid. What is perhaps most alarming is the number of law firms putting out information on Year 2000 issues. Another resource is the national bulletin board on the Year 2000.

You can test your own system to see if it handles the changeover to Year 2000 correctly. But a little common sense is required. Don't blame me if you end up like the person who wrote the following three paragraphs. I'll let you figure out who is the true bozo here.

"There is a letter that appeared in the Vancouver Sun (a local daily in Vancouver, BC, Canada), Saturday, January 4, 1997 on p. A20 that is entitled "An Easy Transition". The author of the letter describes an apparently simple test procedure you can follow to determine whether your computer can accommodate the change of the calendar from December 31, 1999 to January 1, 2000.

"The test goes like this ... you re-set your system clock to 11:59:00 p.m. on December 31, 1999. You let the system run until the time clicks over to January 1, 2000. Then you re-boot your system. If your system retains the correct year 2000 date you are OK. If your system does not retain the correct date, you BIOS and/or software must be upgraded.

"It all sounds very innocent. However, depending on your hardware and software configuration, the procedure described in the letter may damage your system setup. I found this out the hard way. My system has an AMI BIOS chip set dated 1991. Every file (all 800 MB) on a 1.2 Gig drive was re-dated to January 8, 1980 and re-time stamped for some time between 12:03 a.m. and 12:16 a.m. Every program I have that uses the file date and time stamps as a reference point is screwed up. This includes endless error messages from Win95 caused by system files being back-dated."

I guess the moral of this example is: Why wait for a Year 2000 problem, when you can create your own today?

December 28, 1997

Appeared in Laissez Faire City Times, Vol. 1, No. 8
Posted here January 22, 1998
Web Page: http://www.aci.net/kalliste/