new centurial digit ---> Year 2000 Problem

Walter Nissen (dk058@cleveland.Freenet.Edu)
Thu, 2 Jan 1997 18:21:04 -0500 (EST)

For some time now, the Year 2000 Problem has been growing ever more 
horrific in the minds of those in the know, but largely ignored by the 
populace at large.  By issuing an estimate of US$600,000,000,000.00 as the 
cost of fixing the Year 2000 Problem worldwide, the Gardner Group seems to 
have caught some peoples' attention. 
 
According to the 19970101 (last night's) Nightline (ABC News), NASA 
received a "D" on a recent report card which rated various US agencies for 
readiness for 2000.  DOE (the nuke boys) received an "F".  And this on a 
scale on which some agencies received "A"s (I would guess little-deserved, 
even if relatively accurate). 
 
Until the last few years, very little software was programmed, or tested, 
to work in, or past, the year 2000.  By contrast, much software was 
expected to work in leap years.  Critical pieces of software nevertheless 
failed in leap years.  What could possibly justify any hint of optimism 
about this software when the centurial digit changes? 
 
I had the special advantage of working, as early as 1975, for a securities 
firm with a speciality in fixed income securities, and was forced to 
assure that the information systems under my purview could at least mature 
(if not necessarily issue) bonds correctly past the year 2000. 
 
I've done a very little checking into tracking software, and, so far, found 
only QuickSat which seems to be ready for the new century. 
 
I did a very simple-minded test.  I cobbled up an elset, based on Solrad 
6B r, which would be high in my sky at the very end of 2000 (not 1999): 
 
YY, MA adjusted 
1 01245U 65 16 J  00352.21904405  .00000027  00000-0  20100-4 0  550x 
2 01245  70.0731  32.3872 0023671 196.2652 143.7693 13.9533128561653x 
 
Actually I made 4 elsets, setting the year in this elset to 92, 96, 00, 
and 04, on the assumption that the sky and the Earth change very little 
after a 4 year interval (roughly analogous to the Julian calendar 
assumption).  I then ran each into Quicksat asking for output for 921231, 
961231, 001231 and 041231.  The results appeared entirely sensible, with 
only the most minor changes in the last digit for a few of the output 
values (this is to be expected because the Gregorian calendar, and the 
real solar system, differ slightly from the Julian; and also because QS 
correctly changed the year).  I'm still trying to figure out how to sky 
test this.  8-> 
 
I would like to suggest that I think it more or less unreasonable, and 
unimportant, to expect a program to work through the actual change of 
digit on the night (hi, Tony) of 19991231/20000101.  Hopefully, US 
SPACECOM uses a clock based on microseconds after some convenient t=0, and 
will be able to provide air defense services without glitch.  Hopefully, 
GPS and Glonass have been thoroughly checked out (anyone know about this? 
I'm suddenly immensely curious).  For everyday tracking needs, in 
contrast, I'd gladly trade that night's observing for a program that works 
on all the other nights of my life. 
 
The two big problems seem to be "input and validation of the year", and 
"What century is it?".  QuickSat allows (requires, I guess) a 4-digit 
year, so the first of these, input from the control file, is not a 
problem.  Also, it seems to know that 00, as a year in an elset, is the 
year after 99.  I suppose it has a dividing point (after which it, too, 
will fail).  Maybe 1957 to 2056 is its operating interval?  This would 
make sense. 
 
Another problem is "output of the year".  This is more than a convenience, 
but might be worked around ("You know what you asked for, don't you?"). 
Regular QS users are accustomed to dealing with ephemerides (this is the 
plural of ephemeris, meaning a tabular output for various times) from QS 
for December 32nd, September 31st, etc., because it doesn't even try to 
increment the month, let alone the year or century.  (At least this is 
true for the old-ish version of QS I use).  Non-programmers may think such 
crude compromises unseemly, but it is estimated that 10% of all lines of 
code deal with the clock and the calendar, making it attractive to call a 
halt to perfectionism before the effort involved in testing seems 
completely disproportionate to the value-added.  The additional advantages 
of shorter programs and files (faster loading, faster execution, faster 
transmission) accrue incrementally as the program is used again and again. 
 
Cheers. 
 
Walter Nissen                   dk058@cleveland.freenet.edu 
 
--- 
 
I generally don't predict the future, but I do anticipate that the 21st 
Century will be dominated by those companies, nations, agencies and 
organizations which: 
a) make the smoothest transition to the new centurial digit  -and- 
b) make the most effective use of multimedia in education and training. 
 
Most likely, the Year 2000 Problem will cause the failure of at least one 
company in the S&P 500.  I would not think it prudent to enter the year 
2000 without a large supply of bottled water and canned goods and a 
non-power-grid-dependent can opener.  Nor prudent to fly in the first week 
of 2000.  Indeed, if a two-year sabbatical on a South Sea island appeals, 
1999 July might be an ideal time to begin.  With any luck, most of the 
aircraft maintenance skipped during the first half of 2000 (in part 
because a constant flood of undeserved delinquency notices obscured the 
real delinquencies) will have been caught up by mid-2001. 
 
Note to software implementors:  while you are at it, please change your 
programs to use UTC, to place the year first, and to output the century, 
as in 1999/12/31 and 2000/01/01.  Such consistency and universal 
understanding will be much valued in contrast to a plethora of (mostly 
meaningless and/or confusing) dates like 03/01/02 and 01/02/03.  (I
welcome commercial inquiries on this subject).