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 email@example.com --- 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).