no longer encode a
complete timestamp). My question is just whether such timestamps,
indicating both UTC as time-of-day and TAI as interval time, could
be a viable alternative to the frequent updates of leap second tables.
for being off-topic.
the question. But again, giving up
leap seconds in UTC is not the same as accepting atomic time as civil
TAI - ( UTC value when interpreted with
a fixed radix for the second field )
I avoided writing UTC for TAI - DTAI because this would contradict
the assumption that UTC is just TAI plus additional information.
Hope that clarifies things a bit.
DTAI jumps up by 1 s and the value of TAI for a given value of
TAI - DTAI is not unique), the UTC reading that corresponds to the
earlier TAI value shall be recorded with a second field = 60 s,
and the other UTC reading, with a second field 60 s.
Michael Deckers (still trying
close to UT1, but whose rate nevertheless is d( UTC ) = d( TAI )
and not d( UT1 ). Such a function cannot be continuous (and it
cannot be differentiable everywhere). At the latest discontinuity
of UTC, it jumped from a little bit after UT1 to a little bit before
On 2006-01-13, Ed Davies wrote:
Michael Deckers wrote:
. Why cannot UTC be simply taken as
the reading of a clock that runs at the same rate as TAI and
that is is set back by a second every once in a while?
UTC can be taken the way you suggest most
for a timezone
whose local time approximates UT1 up to a second.
, as a function of itself, UTC
trivially is both continuous and monotone).
[ITU-R TF.460-6] Recommendation ITU-R TF.460-6
Standard-frequency and time-signal
emissions. 2002 Geneva.
On 2006-01-11, David Malone wrote:
[A lot of discussion on this list seem to revolve around people
understanding terms in different ways. In an impractical example
of that spirit...]
Anyway: excuse me for repeating some basics of classical mechanics;
but I believe it to be
Mail list logo