Subject: Re: [art] summary of updates - draft-time-touch

From: Joe Touch <[email-masked]>
Date: Mon, 17 Apr 2017 14:32:57 -0700

Hi, all,

I've completed an update that rolls in the changes below as well as a
few other issues raised off-list.

Joe

A new version of I-D, draft-touch-time-02.txt
has been successfully submitted by Joe Touch and posted to the
IETF repository.

Name:		draft-touch-time
Revision:	02
Title:		Resolving Multiple Time Scales in the Internet
Document date:	2017-04-17
Group:		Individual Submission
Pages:		17
URL:            https://www.ietf.org/internet-drafts/draft-touch-time-02.txt
Status:         https://datatracker.ietf.org/doc/draft-touch-time/
Htmlized:       https://tools.ietf.org/html/draft-touch-time-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-touch-time-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-touch-time-02

Abstract:
   Internet systems use a variety of time scales, which can complicate
   time comparisons and calculations. This document explains these
   various ways of indicating time and explains how they can be used
   together safely. This document is intended as a companion to
   Internet time as discussed in RFC 3339.

On 3/29/2017 9:43 AM, Joe Touch wrote:
> Hi, all,
>
> So I have a set of things to update so far. Please let me know if I
> missed something. I will have an update out by the end of this week.
>
> I'm hoping this update can help us converge...
>
> Joe
> ---------
>
> - clarify TAI as a post-facto average
> - clarify prev definition of astronomical second as instantaneous:
>
> 1/31556925.9747 of the tropical year as of the instant
> 1900 January 0 at 12:00:00 Ephemeris Time.
>
> - clarify UT1 as a a measure of the orientation angle of the earth upon
> which international agreement bases the notion of calendar days.
> - consider cleaning up the UT definitions, noting mostly that UT1 is the
> only one in use (and not getting into the detail of UT0 and UT2)
> - clean up the POSIX definition (it's not solar; more like a local clock)
> - this is all at mean sea level (we're ignoring relativistic effects)
> - reminder that the POSIX "equation" is approximate
> - a light discussion about implementation issues (e.g., struct timeval
> vs struct tm vs. ISO 8601)
> - fix NTP epoch to 1900-01-01
> - clarify the two solar times as "apparent" vs "mean"
> - reminder that timers either end on a date or specify an interval
> - reminder that future times in UTC are indeterminate
> - UTC is known only into some future (e.g., a few months) that you know
> about scheduled leaps
> - earth rotation, not orbit, causes most of solar time variation
>
> One other thing that came up is the difference between "POSIX time"
> (previously called Unix time) and the POSIX time API. The API can access
> a variety of time scales, including UTC (e.g., when NTP is running), an
> emulation of UTC, an emulation of Unix time, or direct access to a
> monotonic counter (which may or may not be reset on reboot). I think
> this is Nico's issue with data types, and it's worth clarifying.
>
> -----

---

From: Philip Homburg <[email-masked]>
Date: Tue, 18 Apr 2017 16:47:02 +0200

>A new version of I-D, draft-touch-time-02.txt

I wonder if I should read this. In the terminology section Solar day is now
defined as two different things. But worse, the term 'solar day' is used
unqualified throughout the document.

The '25ns' sillyness of GPS with respect to TAI is still there. I now have
an idea where the 100ms for NTP is coming from. That's really sad.

With this kind of silly stuff still in there it is not worth trying to
make sense of the document.

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 08:03:38 -0700

Hi, Philip,

On 4/18/2017 7:47 AM, Philip Homburg wrote:
> I wonder if I should read this.
Probably it would be useful before commenting. It's at least IETF custom.

>  In the terminology section Solar day is now
I will check and fix that.

> an idea where the 100ms for NTP is coming from. That's really sad.
can you clarify?

The 25ns of GPS is the result of a claim in the GPS spec.

The 100ms is from a claim in NTP documentation.

If you'd like to provide further feedback based on the contents, I'd be
glad to consider them.

Joe

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 18 Apr 2017 11:29:12 -0400

> few other issues raised off-list.

I can see this as being valuable, but it seems to me that the writing
needs to be clarified and made more exact in many places.  A typical
example is that "civil time" appears in the Introduction and other
places, but it isn't listed in either "Terminology" or "Time scales".
But since the whole point of the draft is making the use of time clearer
and more exact, this is a critical matter.

Dale

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 08:54:26 -0700

Hi, Dale,

Thanks for the catch. I'll fix that in the next update.

It's a complex document so I would not be surprised if my first attempt
to organize the information had bugs. I'm glad to fix them if you have
other suggestions.

Joe

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 18 Apr 2017 14:14:13 -0400

(BTW, "draft-time-touch" in the subject line is incorrect!  I made it
hard for me to find your message again.)

I was thinking again...  What is the purpose of this draft?  It seems to
me (having only skimmed it) that the essence is the seven
recommendations given at the end of the Introduction.  But a lot of the
text is taken up with assessing various existing time scales in details
which aren't directly relevant to the recommendations.  If you pared
down the draft to what is needed to support the recommendations (and
possibly the task of assisting the designer to choose a good primary
time scale for an application), how much complexity would be avoided?

Dale

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 11:25:42 -0700

> hard for me to find your message again.)

Sorry - not enough coffee...

The next version will be draft-touch-art-time, keeping with the
convention that also includes the intended WG of interest...

> I was thinking again...  What is the purpose of this draft? 

I tried to indicate that in the abstract/intro.

It originated in response to two different threads on "hey, the IETF
should standardize some new time scale" - one to be purely monotonic and
the other to standardize Google-like leapsecond smear.

The point of the doc is to encourage people to use existing solutions
and not believe there's a shortcut that gets around needing to know/deal
with leap seconds, time zones, and coordination.

>  It seems to
> which aren't directly relevant to the recommendations. 
Yeah - that's intended to be background.

>  If you pared
I'm open to suggestions on how far back to pull that background.

The reason for including it is to have the doc be somewhat
self-contained in justifying the recommendations.

Joe

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 18 Apr 2017 22:01:49 +0000

Joe, all.

i have several problems with this draft.  as others have mentioned, i think it's too long and complicated.  also, i feel that several of the definitions in section 3 Terminology are inaccurate or imprecise.

below are my proposals for some of the Terms:

 o Instant: a point in time.

 o Time scale: the assignment of names to points in time.

 o Date: the name of an instant in a time scale.  alternatively: the name of a day in a calendar.

 o Unit of time: this is unnecessary

 o Epoch: a point in time that is the anchor/origin/beginning of a time scale.

 o Clock: an apparatus that measures (and typically reports) the passage of time.  a clock may report the time according to a time scale.

 o Solar day: TL;DR.  please make more concise.  "mean solar day" would be useful to UT1 and therefore UTC.

 o Tropical year: TL;DR.  is this necessary if you have "mean solar day"?

 o Second: the basic unit of time, having multiple different definitions:

   * 1/86400 of a day / mean solar day.

   * SI second: 9192631770 periods of the radiation corresponding to the hyperfine transition of the ground state of cesium 133 at 0K.  (note that sea level is NOT part of the definition of the SI second)

 o Leap second: an extra second irregularly inserted into or removed from the Coordinated Universal Time time scale to keep it within 0.9 seconds of UT1.

 o Leap day: this is unnecessary.

section 4.2 Time scales: 

 o TAI (International Atomic Time): an ensemble coordinate time scale based on the SI second at mean sea level ("on the geoid"), determined after-the-fact by the weighted contributions of numerous atomic clocks in laboratories around the world, adjusted to account for gravitational time dilation caused by the altitude of each clock (among other gravitational effects).  TAI may appear to tick faster or slower than the SI second depending on the location (especially altitude) of the observer; therefore, free-running atomic clocks may diverge from TAI.  only approximations of TAI are available in real-time.

i think it's important to make the above points about TAI because it illustrates why having an atomic clock on your desk or in your computer isn't good enough.

 o UTC (Coordinated Universal Time): an approximation of UT1 based on TAI *adjusted* with leap seconds.

later, in section 5, there is the implication that UTC is discontinuous.  UTC is continuous and ticks at the same rate as TAI.  leap seconds are not discontinuities.  the counting is non-uniform in that occasionally and irregularly there are minutes that don't have the *usual* number of seconds in them.

POSIX time has discontinuities because it is fundamentally flawed.

there are other problems with the document, but i think dealing with them will be easier once the issues above are addressed.

-mike

________________________________________
From: art [[email-masked]] on behalf of Joe Touch [[email-masked]]
Sent: Monday, April 17, 2017 2:32 PM
To: [email-masked]
Subject: Re: [art] summary of updates - draft-time-touch

Hi, all,

Joe

Name:           draft-touch-time
Revision:       02
Title:          Resolving Multiple Time Scales in the Internet
Document date:  2017-04-17
Group:          Individual Submission
Pages:          17
URL:            [mangled URL removed]
Status:         [mangled URL removed]
Htmlized:       [mangled URL removed]
Htmlized:       [mangled URL removed]
Diff:           [mangled URL removed]

Abstract:

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 15:35:50 -0700

Hi, Michael,.

Thanks for the detailed feedback.

Can you clarify as per below?

>  o Instant: a point in time.
Why is point more precise or accurate than moment?

>  o Time scale: the assignment of names to points in time.

A time scale is the set of all such assignments according to a single
system, not just the act of making the assignment, e.g.:

    Time scale: a system for assigning names to instants and intervals.

(the latter because time scales include names of intervals)

>  o Date: the name of an instant in a time scale.  alternatively: the name of a day in a calendar.
Those names are indicated as intervals from an epoch, so this can be
combined as:

    Date: the name of an instant in a time scale, indicated as an
interval from an epoch.

I disagree with the alternate definition. "Monday" isn't a date.

>  o Unit of time: this is unnecessary
OK.

>  o Epoch: a point in time that is the anchor/origin/beginning of a time scale.

Again, we ought to use "instant" here...  and "origin" seems the closest
IMO:

    Epoch: an instant used as the origin of a time scale

>  o Clock: an apparatus that measures (and typically reports) the passage of time.  a clock may report the time according to a time scale.
I disagree. Clocks don't report time passage; timers do. Clocks report
only the current value, and always in a time scale (what would a clock
be if it didn't? it might be a timer, but not a clock).

>  o Solar day: TL;DR.  please make more concise.  "mean solar day" would be useful to UT1 and therefore UTC.
I'm glad to hear suggestions. The trouble with this definition - and the
entire list, and the entire doc - is that for everyone who thinks its
too long, there's someone else who points out something to add.

UT1 isn't specified in terms of any mean.

>  o Tropical year: TL;DR.  is this necessary if you have "mean solar day"?

Both are needed because both are used for different definitions of a second.

>    * SI second: 9192631770 periods of the radiation corresponding to the hyperfine transition of the ground state of cesium 133 at 0K.  (note that sea level is NOT part of the definition of the SI…
Good point.

It is TAI refers to sea level (you fix that later).

>  o Leap second: an extra second irregularly inserted into or removed from the Coordinated Universal Time time scale to keep it within 0.9 seconds of UT1.
I was hesitant to claim that this term was exclusive to UTC, but if we
agree, then OK.

>  o Leap day: this is unnecessary.
Probably...
> i think it's important to make the above points about TAI because it illustrates why having an atomic clock on your desk or in your computer isn't good enough.
OK....

> later, in section 5, there is the implication that UTC is discontinuous.  UTC is continuous and ticks at the same rate as TAI.  leap seconds are not discontinuities.  the counting is non-uniform in…
Good point. I'll fix that.

> POSIX time has discontinuities because it is fundamentally flawed.
I tried to clarify that POSIX is really two different things:
    - an API to a variety of time scales or approximations thereof (some
flawed)
    - Unix time, the counting of (undefined seconds) in fixed numbers of
seconds per day since a particular epoch

> there are other problems with the document, but i think dealing with them will be easier once the issues above are addressed.

OK - let me know what you think of the above and I'll work on a rev once
we converge.

---

---

From: John Hawkinson <[email-masked]>
Date: Tue, 18 Apr 2017 23:02:04 -0400

Joe Touch <[email-masked]> wrote on Tue, 18 Apr 2017

> > an idea where the 100ms for NTP is coming from. That's really sad.

A problem here is that your ID conflates a known offset with
with a typical uncertainty with a theoretical maximum uncertainty.
You label the field "d-TAI" and name it a delta, but it isn't one.
And the name is evocative of DUT1, which is different kind of thing.

It might be better to adopt a standard name for this field
(uncertainty? imprecision? +/-?; I am not sure) rather than coining
your own.

> The 25ns of GPS is the result of a claim in the GPS spec.

You should probably cite it explicitly.

> The 100ms is from a claim in NTP documentation.

You should *definitely* cite this one explicitly. While I have no doubt
it is there, that's not what people with untuned run-of-the-mill
ntp systems encounter in the public Internet. (And I'm not sure
it is really an upper bound either -- I don't think a 101ms error
is appreciably less likely than a 99ms error?) And of course,
people with finely tuned ntp systems easily achieve far better than 1ms.

[email-masked]
  John Hawkinson

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Apr 2017 20:54:11 -0700

> On Apr 18, 2017, at 8:02 PM, John Hawkinson <[email-masked]> wrote:
> 

Uncertainty sounds good.

> You should probably cite it explicitly.

I'll dig that one up.

> You should *definitely* cite this one explicitly.

http://www.ntp.org/ntpfaq/NTP-s-algo.htm

A time difference of less than 128ms between server and client is required to maintain NTP synchronization. The typical accuracy on the Internetranges from about 5ms to 100ms, possibly varying with network delays. A recent survey[2] suggests that 90% of the NTP servers have network delays below 100ms, and about 99% are synchronized within one second to the synchronization peer.

(Worth noting as an upper range of what might be safely assumed)

> While I have no doubt

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 09:13:08 -0700

Continuing this in ART, as advised by the IESG:

On 4/18/2017 4:21 PM, Toerless Eckert wrote:
> Nice!
>
> Why not start to tackle the problem pragmatically before asking for standards
> when its clearly a political issue.
>
> a) RFC describing the problems developers and system deployments can face
>   because of leap seconds.
That's what draft-touch-time attempts to do.

> b) And best current practices to get around those issues. Eg: Expect clock
>   smear on Jan 1 == reduced accuracy of ~1. Unless OS or other trusted
>   info source gives explicit indication: NO leap, no smear.

BCP is to use UTC and track leap seconds if you can, or be clear when
that's not possible and your clock (basically) approximates TAI (i.e.,
UTC without leap seconds, such as when not connected to a network).

Nobody should "expect" clock smear - clock smear is just deliberately
inaccurate time.

> c) And finally a description of the worst open issues when b) is applied.
>    Anything worse than labels on products "reduced functionality on Jan 1
>    after a leap second" ?

The IETF doesn't have standards compliance so we can't dictate labels,
so I'm not sure why this is useful to consider.

Joe

>
> Cheers
>     Toerless
>
> On Tue, Apr 18, 2017 at 05:20:06PM -0500, Nico Williams wrote:
>> On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote:
>>> As I said, I want 30-100 years lead time so I can bake the schedule into
>>> devices and remove a trust dependency.
>> 30 years' lead time for leap seconds?  Can't be done.
>>
>> Leap seconds depend on events such as earthquakes.
>>
>> You can estimate their frequency, but you can't estimate when they'll be
>> inserted.
>>
>> Nico
>> --

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 09:18:33 -0700

Again, response moved to ART...

On 4/18/2017 10:18 PM, Patrik Fältström wrote:
> ...
> I want as potential fixes which I think are doable:
>
> - an updated POSIX definition...
I'd be glad to hear how that works out, but it's out of scope here AFAICT.
> - a slot in the NTP protocol not used today include the number of leap seconds so people get to know that.
That seems productive...
> That said, I am not against a BCP explaining the issues due to for example the broken POSIX specification (which makes it hard to "do the right thing" in software).
Again, that seems out of scope for the IETF.

AFAICT, though, it is important to understand what information we need
protocols to report, which goes to point #2 above.

Joe

---

From: Steve Allen <[email-masked]>
Date: Fri, 21 Apr 2017 10:57:17 -0700

> has been successfully submitted by Joe Touch and posted to the

UT0 is not "rarely used", but UT0 belongs in this document for the
sake of history.  UT0 was the only form of date/time which was
available from any source up to around 1950.  Thus UT0 was the basis
of official/legal times until then.  Various radio broadcast sources
of time differed from others by 0.1 second or more until after 1960.
UT0 had become unavailable from any source before the late 1980s.
A reference document for UT0 (and the other forms of UT) is Sadler (1978):
http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1978QJRAS..19..290S

UT2 is not "rarely used", but UT2 belongs in this document for the
sake of history.  UT2 became available starting around 1956.  In 1959
UT2 became the recommended goal for radio broadcast time signals, and
thus UT2 underlay the basis of official/legal times for just over a
decade.  No technical body was fully comfortable with the concept of
UT2, and the folks doing radio broadcast time signals did not claim to
be providing UT2.  No sources were providing UT2 nor anything based on
UT2 starting with the inception of leap seconds in 1972.
Reference documents for the use of UT2 are CCIR Recommendation 319
(1959) and CCIR Recommendation 374 (1963,1966).

UT1R does not belong in this document.  UT1R is never used as a time
scale.  It serves little purpose other than to guide the eye toward
seeing the rapid changes in earth rotation that result from large
atmospheric storm systems and the slower trends of UT1 resulting from
oceanic and core/mantle interactions.

UT1 is more than "widely used as the basis of calendar days".
UT1 is the conventional measure of mean solar time descended from GMT.
Twenty six nations agreed to use mean solar time as the basis of the
Universal Day (the calendar day for diplomacy, commerce, etc.)  in the
text of Resolution 5 at the International Meridian Conference in 1884,
and GMT remains the legal basis of time in many countries.

Ephemeris Time does not precede Universal Time.  ET did not exist
until the 1950s.  UT had existed since the 1884 International Meridian
Conference, and the name Universal Time was agreed at IAU in 1928.
https://www.iau.org/static/resolutions/IAU1928_French.pdf
The reference for "Newcomb's tables" in the section on ET is
"Tables of the Four Inner Planets" 2nd edition (1898)
https://ia801005.us.archive.org/11/items/06AstronomicalPapersPreparedForTheUse/06-Astronomical_Papers_Prepared_for_the_Use_text.pdf

The list of major satellite navigation system times woefully ignores India:
https://en.wikipedia.org/wiki/Indian_Regional_Navigation_Satellite_System

--
Steve Allen                    <[email-masked]>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           http://www.ucolick.org/~sla/   Hgt +250 m

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Apr 2017 11:22:36 -0700

Hi, Steve,

Thanks for the updates - I'll roll them in. My apologies in particular
for not tracking India's system and including it.

Joe

On 4/21/2017 10:57 AM, Steve Allen wrote:
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art