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

[Tony Finch <[e-mail]>]

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.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
individual and social justice