On 9/23/11 10:50 AM, Chris Albertson wrote:
I'd like to propose a standard description of a higher order model of
time and the transformation between raw clock and time (in some agreed
upon time scale).
A good time transform will let you transform between time scales at
points in the far future and far past. For example "what was the
date on the Chinese calendar for Jan 11th in 1,500BC" My point is
that you may want to apply your transform on times not near the
present.
Yes, in the general case, but in the spacecraft case, I think we're more
concerned about smoothness and such over time spans of days, maybe weeks
and months.
More about establishing time correlation between multiple
radios/spacecraft in a constellation, for instance.
Two timescales can have different phase and rate. At any instant in
time two real numbers are enough to transform the time from one system
to another. A linear equation is enough but the rate might change
over time. I think this means a second order polynomial.
ALmost certainly, if you want rate to be continuous.
Next I think you must always define the range where the polynomial is
valid. For example adding a leap second to one time scale invalidates
the polynomial and makes you use another one
So, how would one define that range, I'm thinking that it has to be in
terms of the "output" of the transformation (i.e. in the target timescale).
So a general purpose API would need to look at the epoch to be
transformed then select the correct polynomial.
Exactly
This amounts really to a table look up. But you need that to handle
things like conversion from UTC to a computer's internal time. A
computer's time can depend in silly things like the air conditioner in
the room cycling
Exactly.. or the slow and majestic movement of the heavenly bodies. For
instance, things in low earth orbit have fluctuations in temperature
every revolution (say, around 90-100 minutes) on top of roughly weekly
cycle (depending on the inclination) on top of an annual cycle. One
doesn't necessarily need to model such a thing directly, but whatever
scheme there is should accommodate this kind of change smoothly.
Actually, the really annoying one is where I have a good clock that's
stable, but I need to keep adjusting "time" to match someone else's
terrible clock. Most clock disciplining/time propagation models assume
your bad clock is following a better clock.
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
