Re: [art] Predictable Internet Time

[Joe Touch <[e-mail]>]

Hi, Philip,


On 3/28/2017 7:05 AM, Philip Homburg wrote:
> In your letter dated Mon, 27 Mar 2017 12:34:10 -0700 you wrote:
>> I've submitted the time frame discussion intended to resolve this issue,
>> which also recently arouse on another mailing list. Further discussion
>> on this draft will occur on the ART mailing list ([e-mail]).
> A few random comments. I think a document like this is useful, though it
> might hard to strike the right balance between providing enough and too much
> detail.
Yeah - I struggled with that. I don't think everyone will be happy with
any particular boundary...

> - There are two types of solar time. The actual solar time where the sun is 
> at the highest point at noon, and mean solar time. Section 4 does not make
> that distinction, but it is mentioned in a later section. After far as I know,
> actual solar time is extremely rare (only sundials). Solar time is almost
> always mean solar time. I.e UT0 is already mean solar time.
Section 3 states that in the definition of a solar day. Section 4.2
explains that UT0 is one of many different "means", and that UT0 is the
most common in current use.

> - UTC (and TAI) doesn't really exist. They are realized at various labs all
>   over the world. The real value of UTC is coordinated only after the fact.
Although that's strictly true, there are also UTC and TAI sources that
provide the current time as close to UTC and TAI as known. I can add that.

>   This makes a statement that GPS time differs 25 ns from TAI a bit weird.
>   Maybe this is too much detail. 

See above - even in retrospect, GPS can differ from TAI by 25 ns (it's
in the spec for GPS). GPS isn't one of the clocks averaged into TAI
(AFAICT); it's a separate source that's sync'd to TAI to ensure the 25
ns max delta.

> - It is not clear to me why NTP would differ 100ms from TAI.
It's in the spec.

> - The epoch for NTP is 1900-01-01.
Yup - my error. WIll fix.

> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
> time is linked to UTC, 

That is incorrect. POSIX time is defined as 1/86400 of a day, which does
not take into account leap seconds at all (UTC does) and "day" is not
defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at
best a rough approximation of UT0.

> i.e. every value of time_t corresponds to a specific
> UTC timestamp. The inverse is not true, leapseconds cannot be represented in
> time_t.
See above, I think.

> - I can't find any reference where the epoch of TAI is defined as 1977-01-01.
It's from the updated definition of TAI, the one that started to take
account for time dilation and gravitational influences.
I'll see if I can find a citable ref for that.

> - Section 5.1.3 says 'Similarly, the earth's orbit around the sun varies and
> is slowing over time, resulting in an increasing stretching of a solar second.'
> It is the rotation of the earth around it's own axis that causes the
> solar second to become longer over time, not the rotation of the earth 
> around the sun.
I'll fix that...

> - One thing I'd like to add is 'uptime' or more general, monotonic time.

Uptime is just a printout of the delta of the POSIX time when a computer
started and the current POSIX time.

It might be useful to indicate that some computers just start their
clocks at boot as zero.

> Many network protocols need timers and timeout. There is however no need 
> to reference these to UTC, or TAI, etc. So computing time intervals using
> uptime is in many cases better because that also works if an external time
> reference doesn't become available until long after booting.

How/when to sync a "clock" to a time scale is important to note, but the
details are implementation issues.

"uptime" isn't used for timers; internal clocks are, e.g., the POSIX
time scale.

> - Another thing worth mentioning explictly is that for the distant future,
> there is no way to convert between TAI and UTC because future leapsecond are
> not yet defined. So TAI is good for computing intervals, except if it involves
> timestamps more than a few months in the future.
The doc mentions in various places that updated leapsecond information
is required to maintain UTC or derive TAI from UTC. I can mention that
we don't *expect* leapseconds to be added without at least a few months'
notice, and that this affects indicating future dates accurately.

Joe