Roy D. Welch, W0SL, firstname.lastname@example.org
As we approach the year 2000, there are some items we need to begin to check out in our computers and the software that is running on them to be sure that the date and time sensitive software will function during and after the transition from December 31, 1999 to January 1, 2000.
Most computer software that uses the current date and time, gets that information from the PC operating system. The operating system, DOS, Windows, etc., is just software that disappears when the PC is turned off. From where then, does the operating system get this information?
At boot time the operating system is loaded and reads the CMOS Real Time Clock (RTC) which remains running on a backup battery when the PC is powered off. This RTC is hardware in the PC. The CMOS RTC maintains a two digit year value, so the PC BIOS appends these two digits to a pair of stored century digits making the four digit year value that the operating system obtains.
The RTC does not have the century digits and therefore cannot increment them when the year changes from 1999 to 2000. The RTC then just turns over from 99 to 00. The earlier PC BIOS systems only stored the century value of 19. No one was worried about the year 2000 back then. It was a long way off. Now when the year rolls over from 1999 to 2000 you would logically expect this to cause the programs run in those PCS to think the date is 1900. If the program takes its date input directly from the BIOS, that is what will happen. However, if the program gets the date from the operating system, it will think the year is 1980. This is because the operating systems that were designed back in 1984 had no need for supplying current dates earlier than the 1980's. So when the PC boots up with the RTC showing the year 00, the operating system tries to make this 1900, but discovers this is an invalid date and defaults to 1980. How many of you remember booting up one of the older PCs that had a dead ROM backup battery, or even no RTC at all? It probably showed the date of April 1, 1980.
Generally, machines that have been manufactured more recently have BIOS systems that have the ability to decide that the century year is either 19 or 20. You might infer that deep in the BIOS there must be some decision tree that says if the year digits are between 80 and 99, for example, the century digits are 19 and if they are between 00 and 79 they are 20. This would mean that all would be OK until 2079. However, this is not the case. In Windows 95 you can set the date to any year from 1980 through 2099. The next time you boot up, the date is remembered, that is if your PC is "Year 2000 (Y2K) compliant."
Your PC will be "Y2K compliant" if:
How can you tell if your PC is Y2K compliant? There are three manual tests you can make which will help you determine this.
First, set your system date and time to December 31, 1999 and the time to about two minutes before midnight. Turn your PC off and wait for three or four minutes. Then reboot and check that the system date and time displayed are a few minutes after midnight on January 1, 2000.
Secondly, set the date to any date after January 1, 2000, except February 29, 2000. Power down the PC and reboot. Check that the date shown is still the same date you set.
Lastly, try to set the system date to February 29, 2000.
If any of these tests fail, your PC is not Y2K compliant. If you want to perform a more thorough test, there are software programs available which can perform these tests for you. Also, in some cases, there are software solutions available that can correct for certain types of non-compliance for Y2K. One Internet site to visit for a more complete discussion of this problem and a free test program is http://www.rightime.com.
OK, so lets assume our PCs are Y2K compliant. We ought to be home free, right? Wrong! Our software must also be Y2K compliant. Back when early software was being written, the ability to conserve memory was paramount. If you could find a way to store data in memory in a compressed way, you did it. It cost more processing time to compress and uncompress the data, but it saved memory. Memory cost more than processing time back then. One of the minor memory savings used was to store year values in two digits rather than four. In other words store 1985 as just 85. After all, everybody knew that the century value was 19 and it would be assumed that way by any software writer.
As a result, in many cases, only two digit year values are contained in the data input to date and time sensitive programs. One example of this is seen in the Keplerian elements data. Remember the Epoch entry? It is in the form YYDDD.xxxxxxxx, where YY is the two digit year value. The satellite tracking programs written beginning in the middle to late 1980s have had to interface with these two digit year values. In many cases, the orbital calculation algorithms in these programs used the two digit year values throughout.
A typical tracking program looks at the Keplerian elements and then calculates forward from the Epoch time in the elements to the current time to determine the current position of the satellite. This means that the year, day and fraction of a day values in the Keplerian elements are the beginning point of the calculations. The current year, day and fraction of a day are the target of the calculations. The program must determine the exact difference in time from the Keplerian element Epoch time and the current time. This involves mathematical operations on the year, days, hours, minutes, seconds, and fraction of seconds involved. Leap year days and Century days have to be accounted for also. This gets rather messy. So the Epoch times involved are converted to Julian days. Julian day one was January 1, 4713 BC. January 1, 2000 will be Julian day 2,451,545. There are mathematical formulas that let you input two different Gregorian calendar dates and times, with four digit year values, convert them to Julian dates and obtain the difference between the two dates in days and fractions of days. These formulas take into consideration all leap year and century days. This really simplifies things. This difference in time is the input to the orbital calculation algorithms that let us determine the current satellite position from the Keplerian elements.
If there are tracking programs still out there which do not use Julian dates in their calculations, they are in deep trouble. However, even those programs that do use Julian date calculations can still have problems. Remember, that the Julian dates are calculated from Gregorian date inputs that contain a four digit year value. NASA has said that the Keplerian Element format will remain the same and that the year value will just roll over from 99 to 00 with the transition to the year 2000. When the tracking program looks at the Keplerian elements for a satellite, how then will it know what century value to use with the two digit year value in the Epoch date? Somewhere along the calculation train, a decision must be made.
One way is to make the assumption, for example, that any Keplerian Epoch year value 78 through 99 has a century value of 19, and any year value 00 through 77 has a century value of 20. Once this has been done, the use of Julian day calculations will safely allow you track a satellite right through midnight December 31, 1999 into January 1, 2000 without a glitch.
However, there is another glitch to look for. In some orbital calculations it is necessary to calculate a value called the Sidereal Time value at January 1, YYYY at 00:00:00.000Z. This value is used throughout that year. Here again, the assumption above must be applied to determine which century should be applied to the two digit year value. In other orbital calculations, the Julian date difference between the Keplerian Epoch year value and the Julian day value for January 1, 2000 is used. Still, it is necessary to convert the two digit Epoch year value to a four digit year value to obtain the Epoch Julian date.
Lastly, a less troublesome problem may arise when the Keplerian Elements are updated. Most tracking programs have a Keplerian update routine which protects against updating the elements for any given satellite with elements that are older than the ones already on file. Imagine what will happen when the first set of new Keplerian elements are issued in 2000. Some Epoch dates will have year values of 00 and some will still have 99. It usually takes one or two issues of Keplerian elements before all the satellites have a year value from the new year. In the case above, those satellites with Epoch year values of 99 will still update OK as long as the complete Epoch date is later than the ones already on file. However, unless some programming has been done to recognize 00 as representing 2000 and 99 as 1999, the 00 Epoch year elements will be rejected as being older than the ones already on file.
Some programs may permit updates overwriting existing elements without regard to the Epoch value. This will be the work around for those programs where the normal updates are rejected. Others which are not compliant in this regard may require that the tracking program Keplerian data base file be deleted completely before each update until the new Keplerian element files contain satellites with all Epoch year values of 00. This will be done automatically in those programs which do not create a Keplerian element data base file and instead, just read in the distributed Keplerian Element file itself.
OK then, just what is the status of our AMSAT distributed tracking programs with respect to Y2K compliance? First, some background. Back in 1985 when I first changed the ORBITS programs from an interpreted Basic program to a compiled Quick Basic program I ran up against this Y2K consideration. I decided at that time I didn't want to hear from a lot of people in fifteen more years, much less pay the postage for replies, etc. So I made the decision to force the user to input the Epoch year in a complete four digit value separate from the Epoch day. I then tested the program across the 1999/2000 transition boundary and it worked as it should have. I was happy and confident that I would never have to worry with that problem again. Never say never!
Time went by and in 1994 I began making inquiries as to what NASA was going to do about the published Keplerian elements. Were they going to change the format of the Epoch day or were they just going to roll the year value over to zero (00). The answer I received was inconclusive. "We didn't know yet." At that time I also began making inquires of a few of the AMSAT software authors as to whether their programs were Y2K compliant. I received some answers saying that it didn't appear so and a few that said yes. One said his program wasn't compliant and didn't expect it would be updated.
In June, 1996, I e-mailed as many of the software authors as I could find, asking them to make a Y2K compliance check of their programs and let me know what the status of the programs were, and whether or not they would be made compliant or not. My concern was that we should stop offering any programs that were not going to be made compliant. As a result of that inquiry we stopped offering one program. The author said that he did not intend to update it.
Then in October, 1997, at the AMSAT Symposium in Toronto, Philip Chien, KC4YER, and I met with Ken Ernandes and asked him if he could develop a set of test Keplerian elements for December, 1999 and January, 2000 that I could send to the software writers for their use in performing actual tests on their programs. He kindly agreed to do so and in a few weeks I received a TEST2000 zipped package via e-mail which I then sent to all the tracking software developers I could think of. Just for the fun of it, I decided to test the ORBITS programs again with the test Keplerian elements. It worked beautifully, tracking right up to midnight on the evening of December 31, 1999 and then into January 1, 2000 without a hitch. Then I tried to update the 1999 elements with the ones having 2000 as the Epoch year. Ugh!!! It refused to update, claiming the elements were older than the ones already in file. Back to the keyboard and compiler again. It had been so long since I had compiled a new version, I had a problem remembering how to get the compiler set up. I did get the fix in and it is now fully Y2K compliant ... I think. Remember, "Never say never."
The replies began coming in following the Y2K tests. Here are the Y2K testing results.
I suggest you visit some of the web sites listed in the resources below and find out more about the Y2K problem. You can also find other sites on the Internet by doing a search for the subject. Run the three simple tests to see if your PC will make the transition and if not, download a simple program to be run at boot time to see if that fixes the problem. There are such programs available on some of the Y2K web sites. Check with your PC manufacturer to see if there are ROM BIOS updates or boot time programs available for your PC that will fix the problem. After all is done, if your PC still fails Tests 1 and 2 above, you have the worst possible Y2K scenario. If you have date/time sensitive programs running on that PC, you should consider replacing it. If the PC fails Test 1 and passes Test 2, then at least you can manually set the date after booting it up. If it fails Test 3 however, there is no work around and all dates following February 29, 2000 will show the wrong day of the week. This may or may not be a problem for your particular applications.
Once you have run through the tests covered earlier in this paper, checked out your application programs and have satisfied yourself that all is well, then you should not have any further date/time problems, right? Remember, never say never. Those of you with some of the older GPS units, watch it on the evening of August 21, 1999 when the week counter rolls over from week 1023 to week 0. Also, watch out for the year 2038 when the signed long integer variable in the compiler that compiled your program is too small to contain the Julian date values. When this happens, I don't expect to still be around. However, I can look ahead and imagine that those who are, may wake in the middle of the night or look up from their work, depending on where they are, and wonder, "What was that"?
Pete Woytovech, Senior Programmer Dell BIOS Development, The Century Rollover and the PC System Date.
RighTime (The RighTime Company, Miami).
J. David McLaughlin, Systems Coordinator Simco County Mental Health Education, Testing Your PC's Hardware Year 2000 Readiness.
Roy Welch, W0SL, is Software Librarian for AMSAT-NA. Web page conversion by KB5MU.