[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

Re: Y2K Compliance with old W3IWI ORBIT program

Sorry to be slow in replying -- I was out of town. In response to
my posting about the (now antique) W3IWI program, Bob Freeway 
> [snip]
> 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.

The user typed in the elements manually into the old program. The program
assumed/required that the Keplerian elements were from the current year.
The program pre-dated the wide distribution of 2-line elements by packet/
Email/web channels. So the "00" responsibility fell to the person involved
and your question really becomes "Are human beings Y2K compliant?" ;<}

> 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.

The program in question predated MessDOS and the PC's RTC. The user 
typed in the date/time range he wanted, and the program produced a paper
(or virtual paper on the CRT) listing. Hence the user provided the "RTC"

> 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.

The user was provided with the year-end "trick" of using month=13 for
to provide a January carry-over. Sometime during January, he had to 
manually enter current-year elements and make sure that he had a valid
Jan 0.0 GMST entry for the new year (which was the reason I posted the
GMST values valid well into the new millenium).

> 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.

No disagreement in philosophy -- it's just that the program architecture
(using only current year numbers) made it inherentently free of the
ailments that subsequent programs may have.


As an aside to Bob -- Re the "Was 1600 a Leap Year?" question/issue:
In 1600, the issue was irrelevant and the concept was unknown. In the 
mid-1700's, in an attempt to rectify gross differences between the 
Julian and Gregorian calendars, there was a 12-day "leap year" step. 
The next time the 1600 rule we disagree about will be tested is in 3200, 
and I doubt either of us will be around to carry the argumemt forth! 

However, if you work thru the 4/100/400 leap-year rule for the current
rotation rate of the earth and its secular changes, you will find that
a correction to the 4/100/400 rule will have to be made sometime around
the Y3K millenium. The 1600 rule has been suggested formally as the
next level of correction step that will need to be made. 

The "1600 rule" was in vogue before the concept of leap-seconds was 
initiated in 1972 to keep UTC (based on UT1, the true rotation rate of
the earth) in step with AT (Atomic Time). The current leap-second rate 
is ~1sec/18 months, or ~one minute/century, or ~one day/1400 yrs, about 
the same as provided by the "1600 rule". 

[Another aside -- the precise length of day is hard to predict. The day
is gradully lengthening because of tidal frictional dissipation due to 
the moon and sun. The circulation of the atmosphere and oceans also cause
changes in our time/calendars -- at last week's American Geophysical
Union meeting, I gave a paper that showed how last winter's El Nino
affected the true length of day. It concluded with a plot that showed
that the cumulative effect of the El Nino was to make the earth lose
~0.17 seconds (i.e. an error in the time told by your sun dial!), but 
the current La Nina is already "buying back" some of the time you lost.
This occurred because the speed of the global winds changed. The angular
momentum associated with the winds caused the earth to spin more slowly
since angular momentum must be conserved.]

For those worried about 2-digit vs 4-digit years and Y2K, I hate to be an
alarmist, but many of the present "bandaid fixes" will again become a
8000 years hence (Y10K) when we will need to accommodate 5-digit years.

But then, of course, by Y3K or Y10K we may have re-adopted a lunar-based 
calendar like the ancient Mayans used (and the Hebrew calendar still uses), 
rendering the concept of leap-years irrelevant! 

73, Tom

Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org