[time-nuts] seeking a time/clock software architecture

[Jim Lux]

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.