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

[Joe Touch <[e-mail]>]

Hi, Tony,

While addressing these comments, I had a few notes below.

Joe

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'. If it's a sequence of labels
used for absolute and relative ordering, then they are. They're just not
continuous with respect to "natural time", but then nearly all time
scales have that property in one way or another.

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

>  The NTP leap indicator bits are not synchronized with the
> occurrence of leap seconds so they don't disambiguate leapy timestamps.
> https://trac.ietf.org/trac/ntp/wiki/NtpVersionFourIssues

This is an issue with the protocol - that's not the focus of this doc.

> 4.3. Comparison of properties
>
> Should the discussion of GLONASS etc. be moved to section 5 before the
> table in which they occur?

It was left where it is; the table is just a summary of those systems.

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

I.e., the doc talks about time scales and systems that report ONE
timescale; not all protocols for representing or syncing 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.

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

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

--