Everybody has read about the problems we are going to face in the year 2000. The problem need
not be as bad as all the news stories state, unless you run your programs on a mainframe.
First, some factoids. We all know that the winter solstice comes about December 21, and that the
solstice is the day when the days are shortest in the Northern hemisphere. So, what is so magical
about January 1, such that Pope Gregory XIII had to change the world's calenders and blow
away nearly two whole weeks of the late 16th century? It happens that January 1 is the date of the
Earth's closest approach to the sun. And the Julian calendar had built up that much inaccuracy
over the 1600 years since Big Juli named the months after all his friends and family.
Dealing with dates is one of the most mind boggling exercises that a programmer confronts.
90% of the numbers that a programmer work with are decimal or hexidecimal or octal or binary
numbers, all very easy to understand and manipulate. 9% of the numbers are floating point,
which in their printed representation are easy to understand (eg 99.44) but when you have to
hand fiddle with them though a core dump, it gets a little more complicated.
But this date thing, come on. 12 months. Variable numbers of days per month. 24 hours. 60
minutes. Decimal fractions for seconds. Get real. What is most amazing is that we have been
able to get through date manipulations as well as we have, for a long as we have. How do you
add one week to June 27th? How do you figure out the date 90 days from September 18th?
Forget about going back in history to the point where you have to deal with the Pope's vaporized
two weeks. (Try to figure out the then-known day of the week of June 1, 1492, which was before
the Gregorian calendar.)
For one thing, you use a lot of tables. Tables of days in months, tables of days in years, formulas
for leap years. That part is real interesting. 20 years ago, everybody understood that a leap year
came every 4th year, except for every 100th year. The pope laid down one more piece of the
algorithm that most people forgot, which was you Do get a leap year every 400 years. So, under
the first two rules, year 2000 is not a leap year, but with the third rule, it is. I recently reviewed
some old software that went to great lengths to make sure they would skip the year 2000 as a
leap year, when in fact the simple (mod 4) rule would have done the job till the year 2100.
So, consider that you are writing a credit card verification program. You know how everybody
always asks you for your credit card expiration date, especially when you are ordering things
over the phone? Somewhere, that month/date value gets punched into a computer during the
validation process. The computer looks at the date today (month and year), subtracts the current
year from expiration year, current month from expiration month, maybe carries the 12, and
comes up with a positive or negative (or zero) number. A guy I work with just got his card
renewed. They are doing it for 3 years now. He has already got his card rejected at some places,
because his expiration date is 02/00, and the credit card validation programs have not figured
things out yet.
At World Wide Widgets, we write software for both internal use, and sell that software to other
companies in the Widget business. We have already received a 10 page questionnaire from one
customer, asking us in excruciating detail to testify that our software will survive the Year 2000
boundary. It will probably take us a few months before we can so verify.
There are a lot of people who do not have much to worry about. Companies who have all their
mission critical data on modern databases, like Ingress to my certain knowledge, and probably
the Oracles and Informixes, maybe even the DB2es, are protected because these databases store
dates in an internal format that is not MM/DD/YY nonsense, but some internal continuous
number sequence. And many operating systems do the same thing. As long as these people
don't screw up their data entry forms, the rest of the system should work just fine.
We use Unix a lot. And Unix stores dates as the number of seconds since January 1, 1970. DOS
is similar, except being a newer OS, it started its epoch in 1980. They use a 32 bit word to store
the values, which gives you something on the order of two billion seconds, and that will give you
valid dates until 2033 for Unix, and 2043 for DOS. By then, I will be long retired and somebody
else can worry about the "Year 2033 Virus".
While DOS can handle Year 2000 dates easily, the computer's knowledge of its current date is
done with a chip external to the CPU since the PC/AT came out, plus the computer's BIOS
somehow gets involved. Depending on what BIOS, and what kind of a date chip you have, your
personal workstation may or may not deal with the year 2000 gracefully. I have not had to guts
to try this on my own computer yet.
The Dec Vax is even more elegant. It starts its epoch at November 17, 1858 (say what??),
measures time in 100 nano second increments, and uses a 128 bit counter. The sun will be stone
cold cinders before that counter turns over.
So, in Unix, for a programmer to go and do date manipulations, such as what is the date 90 days
from September 18th, you only need convert September 18th to Unix internal format, add 90 times
86400 seconds to that value, and use the 'localtime' subroutine provided by Unix to tell you what
that date is. All times are carried as Greenwitch Mean Time, and the 'localtime' routine converts
that value to the present time zone and daylight savings time offset.
Databases make it even easier. The Ingres database allows you to take 'date(18-sep-1977)' and
add '1 week' to it, and then print the answer out. I presume the other major database have
similar functions.
People working in C++ are supposed to have it easy, my C++ afficionados tell me, because you
can just use an existing "class library" for date manipulation, and it will take care of all the
fiddling for you. The neat thing about C++ is that once you have created a class library and its
member functions, objects (in this case, a date) can be manipulated using commonly understood
terms. I would presume a C++ class library would allow me to declare some variable as a date,
another variable as some number of weeks, and it would deal with adding or subtracting the
weeks variable to the date variable, using standard programming mathematical symbology.
But, all that is beyond a lot of existing programs, and especially programs that might have been
written ten or fifteen years ago. There was no C++, little in the way of databases, and only a
very few Operating Systems held the date in a useful format. And a lot of programs that are in
constant use today, were written back then. And they will break.
We actually wrote a thank you letter to our customer that sent us the huge questionnaire on our
software. It has started our group to actually working on and testing our software against the
benchmarks spelled out in their questionnaire. I am already in the process of rewriting the
particular subsystem that is most likely to be affected by this problem, and over time, we will
advance the clocks and make sure that we can ride through the millennium gracefully.
For companies that are starting to worry about this issue, the usual suspects of consultants and
trade shows are starting to crawl out of the woodwork. I get a blurb for some trade show dealing
with the "Y2K" problem every couple of weeks now. There are a dozen consulting companies
that have started up specializing in just this problem. (I wonder if their employees need a
pension plan, since their companies will, one way or another, be out of business in four years.)
All of a sudden the politicians have got on this bandwagon, but unless they are carrying Cobol
handbooks, I don't know how much good they will do.
It will be interesting to see just how this all turns out. In the first few weeks of Y2K, it is quite
possible that a lot of paychecks will be calculated wrong, or not at all the first couple of weeks.
Pension checks might be held up for a couple of months. But these problems can be handled by
hand, even in a big company, until things get fixed. I think that the years leading up to Y2K will
be more traumatic than the actual event, because the problems will be more widespread even if
less intense. The credit card instance I already mentioned is an example. Over the next two
years, everybody with a credit card will be getting a new one, and most of them will have
expiration dates past 2000, and many of them will break some company's computers. But it will
happen a few instances at a time, giving grief to the poor soul that got rejected, but giving that
company time to get its act together.
Read Next Article --> Return to Home Page ^