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

[Joe Touch <[e-mail]>]

Hi, Tony,

> On Nov 11, 2019, at 6:37 AM, Tony Finch <[e-mail]> wrote:
> 
> 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.

They’re a bit like Schrodinger’s cat - they jump only whey you look at them (or would need to). IMO, they are time scales for that reason.

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

Will do.

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

I haven’t found a public reference with enough detail on this. The only one I’ve found is Wikipedia, which has errors in its description of Unix time.

> It's a widely-available timescale,

I’m not sure I would agree with that - everything I’ve found says it’s limited to specialized industrial nets and systems; that’s another reason it’s not necessarily useful to add. 

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

The dichotomy is accurate - either time units are a physical constant or they’re defined relative to celestial events.

Civil time is just a time scale adopted by a government (or other type of group of people). I’m not aware of a civil time scale that isn’t based on one of those two.

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

Ahh - wrong ref. Google developed it earlier but didn’t turn it on for public use until 2017:
https://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/ <https://www.theregister.co.uk/2016/12/02/google_public_ntp_servers/>

I’ll correct that.

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

That’s perhaps another RFC.

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

Will do.

---