Re: [art] Fwd: New Version Notification for draft-touch-time-05.txt

[Tony Finch <[e-mail]>]

Joe Touch <[e-mail]> wrote:
> On 9/13/2019 12:41 PM, Tony Finch wrote:
> ....
> >    o  Ordering: to determine the relative sequence of events across
> >       systems, such as with Lamport clocks [La78] or Vector clocks
> >       [Fi88][Ma88].
> >
> > Lamport clocks and vector clocks don't use time, but the section heading
> > implies that they do.
>
> It depends on how you interpret 'time'.

I meant in the usual sense, as implied by the draft's terminology section.

> >    o  NTP [RFC5905]: the Network Time Protocol, used in the Internet to
> >       synchronize local clocks, in which dates are indicated by UTC
> >       values. NTP times track the time of the clock they connect to.
> >
> > NTP uses a unix-style count of seconds so it isn't able to represent UTC
> > values.
>
> The doc describes the time NTP provides not its representation in its
> protocol messages. It claims to sync within a few ms of UTC.

Your wording "UTC values" to me implies a vague description of the
representation of the timestamps. Perhaps you could re-word it to make it
clear that you meant something else.

> > Should PTP be added to the list of time scales? (Given section 7 talks
> > about selecting timescales I think it's worth pointing out one that is of
> > practical use in computing, as opposed to TAI which is a retrospective
> > paper clock.)
>
> PTP isn't a time scale; it's a system for reporting time. The problem is
> it reports multiple timescales that are already discussed.

The impression I get is that although PTP can transport different
timescales, it almost always uses a specific one which is different from
the other ones in the draft. (It differs from Unix time by the number of
leap seconds.)

It's a widely-available timescale, like many of the others listed in that
section, and I think readers would be surprised that it isn't listed in a
draft that's providing advice on choosing timescales.

> >    Unix time does not specify the definition of a 'second' or 'day',
> >    and so it is not clear whether it intends to track SI seconds (where
> >    time would be uniform) or solar time (where it would not).
> >
> > Unix time is defined in terms of struct tm fields, which are a
> > representation of a UTC time stamp. It explicitly says it doesn't
> > specify any relationship to real civil time.
>
> Civil time is neither SI nor solar. The statement above explains that
> even the duration of a second or day isn't defined for Unix time.

The problem with that paragraph is it sets up a false dichotomy. Unix time
does not intend to track solar time nor SI seconds, it tracks civil time,
which is a different third option. Leaving that option out is misleading.

> > Google deployed leap smear in 2011 (not 2017 as your reference states) and
> > they weren't the first to propose it.
>
> 2017 is the date of the published archival reference. That's not a
> statement of when it was deployed, which this document doesn't include.

   [Go17]    Google's approach to NTP leap smearing, proposed in 2017.
             https://developers.google.com/time/smear

The date 2017 doesn't appear on that page, and the page itself says
deployed in 2008 so I'm not sure why you say it isn't included. (I think I
got 2011 from my mail archives...) The reference doesn't match the title
nor the contents of the page it refers to.

> > 7.2. Hazards of some time scales
> >
> > It's worth mentioning that if you aspire to representing UTC correctly
> > then it cannot be done as a simple count of seconds, and Unix and NTP are
> > shining examples of getting it wrong.
> >
> > There should be a discussion of leap-second-related hazards in Unix time
> > and NTP.
>
> This isn't a time protocol design doc or advice on which protocol to
> use; it is advice on how to pick a time scale.

Exactly why I think it should discuss hazards of bad representations of
time. Especially since two of the main time systems it discusses suffer
from such bad representations.

> > The draft seems to give the impression that leap smear is a Google
> > peculiarity, but there are several other organizations doing it (see the
> > link to the leapsecs list above).
>
> It mentions Google only as notable examples.

Perhaps you could re-word it to make that more clear.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Southeast Iceland: Southeasterly 6 to gale 8, occasionally severe gale 9 at
first, backing northeasterly 4 to 6. Very rough or high, occasionally very
high in west at first. Rain. Good, occasionally poor.