Re: A lurker surfaces

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Mon, 01 Jan 2007 19:44:05 -0700 (MST)

In message: <0701012222.AA10926_at_ivan.Harhan.ORG>
            msokolov_at_IVAN.HARHAN.ORG (Michael Sokolov) writes:
: The people who complain about leap seconds screwing up their interval
: time computations are usually told to use TAI. They retort that they
: need interval time *between civil timestamps*.

Actaully, interval deltas are needed, but it is in TAI time. There
needs to be, in the systems I've done, a timescale without leapseconds
to keep all the measurements sane. In addition, many of the systems
I've done have other functions they do also, some of which need to
present UTC to the user. As much of a pita that leapseconds are
today, having the converion between TAI and UTC (or put another way:
between GPS and UTC or LORAN and UTC) would make these systems
signficantly more difficult to get correct.

There's also times when our systems take in events that are
timestamped using UTC time, so we need to back correlate them to TAI
or whatever internal timescale we're using. Some of that is because
UTC is the standard for exchanging time, part of that is because the
events in question are measured in whatever timescale is present on an
NTP server.

: To me that seems like
: what they are really measuring as "interval time" is not physical
: interval time, but how much time has elapsed *in civil society*. Hence
: my idea of civil interval time that's completely decoupled from physical
: time and is instead defined as the turning angle of the clock on the
: Kremlin tower.

Actually, you are wrong. The intervals is in the number of pps that
have happened, or fractions thereof. Civil time does intrude because
that's what people use right now to know time fo day. In the systems
I've done, you need to know both.

The requirements, as you may have noticed, for my needs aren't that
the intervals be done in TAI (we use a variant of LORAN time due to
historical accident, but with a 1970 epoch), but rather that UTC and
these time scales be convertable between one another.

Like I've said a number of times, saying 'just use TAI' isn't viable
because of the conversion issue. Using TAI (or something with the no
leapsecond regualrity that TAI gives) is necessary for the algorithms
to work. However, external pressures also require that some things be
done in UTC time and that some of the external sources of data use UTC
time and that needs to be back correlated to the internal timescale
that we're using.

The algorithms, btw, basically integrate frequencies of different
clocks, over time, to predict phase difference. In this case, you
definitely want to use an interval, and not whatever weirdnesses civil
time happened to do in that interval. Using an civil time interval
would introduce errors in algorithms. These algorithms are used to
estimate how well the clocks are doing, but other parts of the system
need to play our UTC for things like NTPD and IRIG.

Warner
Received on Mon Jan 01 2007 - 18:46:08 PST