# Re: Y2K Compliance with old W3IWI ORBIT program

• Subject: Re: [amsat-bb] Y2K Compliance with old W3IWI ORBIT program
• From: "Bob Freeway" <bfreeway@xxxxxxxxxxx>
• Date: Sat, 05 Dec 1998 13:58:28 PST

```
> Date: 1998-Dec-03 [Thu] 06:22:56 +0000

> My old ORBIT program is old enough to vote! I wrote it in the late
> '70s and it still seems to be used. It was originally done in 8080
> NorthStar disk BASIC and then others ported it to Micro\$oft
> GW-BASIC, Commode-Door 64s, etc. I'm amazed it is still in use.
>
> Way back then, in the days of yore, memory and CPU cycles were very
> precious, so I took a couple of shortcuts:
>  1. You had to manually enter Keplerian elements by hand.
>  2. It used very rudimentary calendar & sidereal time routines.
>
> It is the second item that really has to be addressed. The "trick" I
> used was that you had to manually enter the Greenwich Mean Sidereal
> Time (GMST) for January 0.0 (really Dec.31 of the previous year),
> and you had to enter a new GMST constant by hand each year. The
> internal calendar routine figured out the elapsed day of the year
> (i.e. 32 = Feb.1), added on the desired UTC expressed as a fraction
> of a day (i.e. 0.250 for 06:00 UTC), and multiplied the total
> (i.e. 32.25) times the sidereal-to-solar ratio (1.002737909) in
> order to get the current sidereal time. The simple calendar
> calculation assumed that years evenly divisible by 4 are leap
> years with 366 days.
>
> Given the utter simplicity of this scheme, it has no Y2K problem
> since Year 2000 is a leap year. The Leap-year algorithm is:
>  a. If a year is evenly divisible by 4, it IS a Leap Year (1996
>  yes);
> b.   Except: If it is divisible by 100 it is NOT a Leap Year (1900
>  no);
> c.   Except: If it is divisible by 400 it IS a Leap Year (2000 yes);
> d.   Except: If it is divisible by 1600 it is NOT a Leap Year (3200
>  no).

There is NO 1600 Year Rule for Leap Years!!!
This has been discussed ad nauseum at news:comp.software.year-2000
See International Standard ISO 8601 for the definitive answers as well.

That aside, there are several other points....

What assumptions does the program make for the elements? Does it assume
that they are all 19xx years? or has extra logic been added to make sure
that year '00' is seen as 2000 not 1900.

There is more than one problem with the year 2000 here:
1. Will the computer have the right date and time in it after the end of
1999? IBM PCs default back to 1900 in the RTC / 1980 in DOS for example,
as explained elsewhere. If the clock is wrong, predictions for 'now'
will be wrong, after the end of 1999.
2. Kepler elements use only two digits for the year. If the year is
assumed to be prefixed with '19' then predictions made in 2000, using
'00' elements will result in wrong positions. The software will start
the calculations with an initial satellite position in 1900, and step
through 100 years of orbits to show your where the satellite is 100
years later rather than just a few days later.
3. Using in the year 2000, some 1999 Elements, may, if the computer
assumes that '00' is 1900 show you where the satellite was in 1900
rather than where it is in 2000.

I'm not saying that the program discussed here has any of these
afflictions, but these are the things that need to be looked at in any
tests that anyone carries out. These points haven't been made very clear
so far in this discussion.

Cheers,

Bob.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
----
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org

```

AMSAT Home