Re: [art] Predictable Internet Time

[Philip Homburg <[e-mail]>]

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.

- 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.

- 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.
  This makes a statement that GPS time differs 25 ns from TAI a bit weird.
  Maybe this is too much detail. 

- It is not clear to me why NTP would differ 100ms from TAI.

- The epoch for NTP is 1900-01-01.

- It is not clear to me what 'Unix time' is in this context. Typically POSIX
time is linked to UTC, 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.

- I can't find any reference where the epoch of TAI is defined as 1977-01-01.

- 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.

- One thing I'd like to add is 'uptime' or more general, monotonic time.
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.

- 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.