Re: ITC copped out on UTC again

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jan 23, 2012 at 4:52 AM, Alessandro Vesely <vesely@xxxxxxx> wrote:
>> The solution is simple - move to TAI. That is the _true_ time, what
>> the master clocks actually keep. UTC is just a variant for creatures
>> living on the surface of the Earth.
>
> Being one of those creatures, I voted for keeping leap seconds.  UTC
> seems to fit the global Internet quite nicely, although it has some
> problems.  When we'll inhabit faraway planets and use some other time
> reference, we'll be facing /more/ problems, not less.
>
>>> The problems caused by leap seconds are that they make it impossible for two
>>> machines to know if they are referring to the same point in future time and
>>> quite often introduce errors in the present.
>>>
>>> 1) No machine can determine the number of seconds between two arbitrary UTC
>>> dates in the future since there may be a leap second announced.
>>
>> Not true for TAI.
>
> TAI is computed after averaging several clocks, so it is not known in
> advance either.  Both UTC and TAI are labels, albeit the latter is
> smoother.

That is a dodge. While no time system is known perfectly in real time,
there are a number of clocks slaved to TAI that can be used to realize
TIA in real time to much better than microsecond accuracy (and, of
course, that is how we get real time UTC).  In any case, the use case
being mentioned is about the difference between arbitrary, but
specified, epochs, which is independent of the actual errors in the
time system being used.

>
>>> 2) If Machine A is attempting to synchronize with machine B on a future
>>> point in time, they cannot do so unless they know that they have the same
>>> view of leap seconds. If a leap second is announced and only one makes the
>>> correction, an error is introduced.
>>
>> Not true for TAI
>
> The problem is still ill-defined for faraway or accelerated machines,
> according to relativity.  For practical purposes, the divergence of
> their timekeeping is likely, unless they are well connected to a
> common time reference.  In that case, they can as well connect to one
> another, no?

It's not ill defined at all, as long as GR and SR are correct. Both
make very precise predictions about the difference between
measurements made between clocks keeping proper time (i.e., freely
running clocks). Einstein synchronization can always be done between
such clocks.

It is true that a sufficiently distributed set of clocks (say, Earth,
Mars and Venus) will not agree on the simultaneity of remote events,
but that lack of simultaneity can be exquisitely calculated, and even
used for navigation (see, e.g., the Sagnac effect).

And, of course, this is also orthogonal to the problem at hand, as
UTC, GPS time, TT, all  also experience from the same issues, and it
has nothing to do with leap seconds.

Regards
Marshall

> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]