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

[Joe Touch <[e-mail]>]

Hi, Tony, 

Many thanks for the input. I will incorporate it and contact you if I
have any questions. 

Joe 

On 2019-09-13 12:41, Tony Finch wrote:

> I have read through the draft and I have a pile of pedantic comments...
> 
> In the introduction you say,
> 
> Many time frames contain discontinuities, some of which are regular
> (e.g., time zones, leap days, and daylight saving time shifts),
> whereas others are irregularly introduced as needed (e.g., leap
> seconds).
> 
> I think it's less misleading to say that daylight saving time shifts are
> only regular for a limited number of years, and it should be mentioned
> that changes to DST rules occur at irregular and unpredictable times.
> 
> Elaborating on your intro point 3, a rule of thumb I use for deciding when
> not to use UTC is if I need to work with times in the future that interact
> with people, in which case time needs to be described in local time in a
> particular place. The most common example is calendaring, but it can also
> occur for things like cron jobs that need to fit around office hours.
> 
> In section 4:
> 
> standard for the passage of time. Civil time is based on the
> rotation of the earth, and its goal is to ensure that a single
> geographic location has the same reference to the sun at the same
> time each day, including variations that support localized time to
> approximate that effect for other locations around the earth.
> 
> I think "same reference to the sun" needs to be clarified, or perhaps
> needs to gloss over the details more. The difference between mean solar
> time and apparent solar time can be over 15 minutes (equation of time),
> and DST can add another hour, so the sun is basically not in the same
> place at the same time on different days.
> 
> sun. Computational time can be non-uniform, such as when Unix system
> clocks are sped up to synchronize with civil time in a way intended
> to avoid discontinuity.
> 
> If this is referring to leap smear, then that's a slowdown.
> 
> 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.
> 
> o  Interacting with people: to exchange dates with the real world,
> as when indicating the civil date of an email transmission
> [RFC3339], web page [ISO98], or managing calendars [RFC5545].
> 
> Email date staps are specified in RFC 5321 and RFC 5322 and are not the
> same format as RFC 3339. The HTTP date header is specified in RFC 7231 not
> ISO 8601. I'm not sure what the 98 in the ISO anchor refers to (the
> current edition is dated 2019, this year).
> 
> 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 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
> 
> 4.3. Comparison of properties
> 
> Should the discussion of GLONASS etc. be moved to section 5 before the
> table in which they occur?
> 
> 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.)
> 
> 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.
> 
> 6.1.3. Not uniform
> 
> Some time scales replace discrete leap seconds with a leap smear,
> stretching the interval of one second over 10-20 hours before the
> corresponding leap second date [Go17].
> 
> I think the most common smearing approach in recent years is to centre the
> smear equally before and after the leap second, so the greatest difference
> from unsmeared time is 0.5s rather than 1s.
> 
> https://pairlist6.pair.net/pipermail/leapsecs/2016-September/006308.html
> 
> Google deployed leap smear in 2011 (not 2017 as your reference states) and
> they weren't the first to propose it.
> 
> https://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
> 
> https://www.cl.cam.ac.uk/~mgk25/time/utc-sls/
> 
> 6.1.4. Ordering
> 
> I think the leap smear example needs a caveat. Most implementations do the
> smear over several hours, not 2 seconds.
> 
> Section 6 could do with a subsection about the dangers of calculating with
> future times, e.g. DUT1 is not known after a few months in the future,
> time zones and DST rules change several times a year, etc.
> 
> 7.1. Selecting a time scale
> 
> If user presentation is primary, as for email or calendaring,
> implementers would probably select local time [RFC5545].
> 
> More practically, calendaring systems need to support a comprehensive
> database of local times, and they can't pick a single one as primary
> because that's a recipe for timestamps in secondary timescales becoming
> wrong when tz rules change.
> 
> 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.
> 
> 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).
> 
> That's probably enough nerdery for now...
> 
> Tony.