[art] Predictable Internet Time

[Philip Homburg]

In your letter dated Mon, 27 Mar 2017 12:34:10 -0700 you wrote:
>I've submitted the time frame discussion intended to resolve this issue,
>which also recently arouse on another mailing list. Further discussion
>on this draft will occur on the ART mailing list (***@ietf.org).

A few random comments. I think a document like this is useful, though it
might hard to strike the right balance between providing enough and too much
detail.

- There are two types of solar time. The actual solar time where the sun is
at the highest point at noon, and mean solar time. Section 4 does not make
that distinction, but it is mentioned in a later section. After far as I know,
actual solar time is extremely rare (only sundials). Solar time is almost
always mean solar time. I.e UT0 is already mean solar time.

- UTC (and TAI) doesn't really exist. They are realized at various labs all
over the world. The real value of UTC is coordinated only after the fact.
This makes a statement that GPS time differs 25 ns from TAI a bit weird.
Maybe this is too much detail.

- It is not clear to me why NTP would differ 100ms from TAI.

- The epoch for NTP is 1900-01-01.

- It is not clear to me what 'Unix time' is in this context. Typically POSIX
time is linked to UTC, i.e. every value of time_t corresponds to a specific
UTC timestamp. The inverse is not true, leapseconds cannot be represented in
time_t.

- I can't find any reference where the epoch of TAI is defined as 1977-01-01.

- Section 5.1.3 says 'Similarly, the earth's orbit around the sun varies and
is slowing over time, resulting in an increasing stretching of a solar second.'
It is the rotation of the earth around it's own axis that causes the
solar second to become longer over time, not the rotation of the earth
around the sun.

- One thing I'd like to add is 'uptime' or more general, monotonic time.
Many network protocols need timers and timeout. There is however no need
to reference these to UTC, or TAI, etc. So computing time intervals using
uptime is in many cases better because that also works if an external time
reference doesn't become available until long after booting.

- Another thing worth mentioning explictly is that for the distant future,
there is no way to convert between TAI and UTC because future leapsecond are
not yet defined. So TAI is good for computing intervals, except if it involves
timestamps more than a few months in the future.

[Tony Finch]

Philip Homburg <pch-ietf-***@u-1.phicoh.com> wrote:
>
> A few random comments.

Good comments :-)

> - There are two types of solar time. The actual solar time where the sun is
> at the highest point at noon, and mean solar time.

The usual term for the former is "apparent solar time". If you are talking
about both then it's worth saying the difference between apparent and mean
solar time is called the equation of time.

> - One thing I'd like to add is 'uptime' or more general, monotonic time.

An interesting discussion re. compatible APIs for elapsed time:
https://github.com/golang/proposal/blob/master/design/12914-monotonic.md

> - Another thing worth mentioning explictly is that for the distant future,
> there is no way to convert between TAI and UTC because future leapsecond are
> not yet defined. So TAI is good for computing intervals, except if it involves
> timestamps more than a few months in the future.

I think "distant future" isn't a very good description for "a few months" :-)

The actual horizon is about 5 - 11 months, just before and just after
bulletin C is published in January or July.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
North Hebrides, Bailey, Fair Isle, Faeroes, Southeast Iceland: Easterly 5 to
7, occasionally gale 8 in western Southeast Iceland. Moderate or rough.
Occasional drizzle. Good, occasionally poor.

[Joe Touch]

On 3/28/2017 8:13 AM, Tony Finch wrote:
> Philip Homburg <pch-ietf-***@u-1.phicoh.com> wrote:
>> A few random comments.
> Good comments :-)
>
>> - There are two types of solar time. The actual solar time where the sun is
>> at the highest point at noon, and mean solar time.
> The usual term for the former is "apparent solar time". If you are talking
> about both then it's worth saying the difference between apparent and mean
> solar time is called the equation of time.

Will do.

>
>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
> An interesting discussion re. compatible APIs for elapsed time:
> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
This is another example of the confusion that results when the time
scale is not clearly indicated or defined. Having Go read the "system
wall clock" is the source of the problem, and this doc explains a
variety of solutions.

I can add a new "monotonic clock" definition that uses an arbitrary
"tick" that is guaranteed to increase between reads and across reboots,
but is not comparable across machines.

>
>> - Another thing worth mentioning explictly is that for the distant future,
>> there is no way to convert between TAI and UTC because future leapsecond are
>> not yet defined. So TAI is good for computing intervals, except if it involves
>> timestamps more than a few months in the future.
> I think "distant future" isn't a very good description for "a few months" :-)
>
> The actual horizon is about 5 - 11 months, just before and just after
> bulletin C is published in January or July
Agreed, but not sure we need that level of detail.

Joe

[Nico Williams]

On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote:
> On 3/28/2017 8:13 AM, Tony Finch wrote:
> >> - One thing I'd like to add is 'uptime' or more general, monotonic time.
> > An interesting discussion re. compatible APIs for elapsed time:
> > https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
> This is another example of the confusion that results when the time
> scale is not clearly indicated or defined. Having Go read the "system
> wall clock" is the source of the problem, and this doc explains a
> variety of solutions.

Better data types -and strong typing- are needed:

- Unix-like TAI (seconds since epoch, admitting not leap seconds)
- Unix-like UTC (seconds since epoch, with leap seconds)
- both with variations like real versus integer, or seconds +
microseconds, etc..
- broken-down time without leap seconds
- broken-down time with leap seconds
- formatted time (with a zone indicator to indicate whether UTC or TAI)
- perhaps other forms

Then there's intervals. Having variations on intervals based on whether
or not they admit leaps seems silly though, so intervals are a bit
easier.

Nico
--

[Joe Touch]

Hi, Nico,


On 3/28/2017 11:43 AM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote:
>> On 3/28/2017 8:13 AM, Tony Finch wrote:
>>>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
>>> An interesting discussion re. compatible APIs for elapsed time:
>>> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
>> This is another example of the confusion that results when the time
>> scale is not clearly indicated or defined. Having Go read the "system
>> wall clock" is the source of the problem, and this doc explains a
>> variety of solutions.
> Better data types -and strong typing- are needed:
Unix defines only POSIX time right now, FWIW.

AFAICT, wouldn't specing Unix interfaces to the different times below be
out of scope for the IETF?

> - Unix-like TAI (seconds since epoch, admitting not leap seconds)
> - Unix-like UTC (seconds since epoch, with leap seconds)
> - both with variations like real versus integer, or seconds +
> microseconds, etc..
> - broken-down time without leap seconds
> - broken-down time with leap seconds
> - formatted time (with a zone indicator to indicate whether UTC or TAI)
> - perhaps other forms
>
> Then there's intervals. Having variations on intervals based on whether
> or not they admit leaps seems silly though, so intervals are a bit
> easier.
>
> Nico

[Nico Williams]

On Tue, Mar 28, 2017 at 11:47:20AM -0700, Joe Touch wrote:
> On 3/28/2017 11:43 AM, Nico Williams wrote:
> > On Tue, Mar 28, 2017 at 11:21:02AM -0700, Joe Touch wrote:
> >> On 3/28/2017 8:13 AM, Tony Finch wrote:
> >>>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
> >>> An interesting discussion re. compatible APIs for elapsed time:
> >>> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
> >> This is another example of the confusion that results when the time
> >> scale is not clearly indicated or defined. Having Go read the "system
> >> wall clock" is the source of the problem, and this doc explains a
> >> variety of solutions.
> > Better data types -and strong typing- are needed:
>
> Unix defines only POSIX time right now, FWIW.

POSIX defines POSIX time. Unix and Unix-like systems use it.

(Nothing stops any Unix-like OS from including extensions.)

> AFAICT, wouldn't specing Unix interfaces to the different times below be
> out of scope for the IETF?

Yes and no.

First, the IETF has and does specify some APIs. (BSD sockets bindings
for IPv6, GSS-API, and various others.)

Second, the IETF could define abstract APIs but refrain from specifying
C bindings for APIs and recommend to the Open Group and others that they
standardize those based on the abstract APIs. (GSS-API, for example,
defines both, abstract and programming-language-specific bindings.)

Regardless, how could we address our time issues without specifying what
amounts to.. type conversions? That's an API by whatever name you wish
to call it. Best call it an API, define "types" and "type conversions"
or "functions" that do the same.

Obviously, for leap second smearing, besides an API there is also
behavior (smearing).

There's some difficulty with typing smeared time in that a smeared time
would be closer to UTC than POSIX time, but *pretending to be POSIX
time*. Which makes it difficult to have strong typing (which you get
becomes a run-time matter!), but makes it easy to inject the new type in
existing object code.

But it may still be necessary to convert smeared time (when you know
that's what it is) to other time forms, and there has to be a canonical,
reproduceable, non-host-dependent way to do it, else you end up with a
synchronization problem.

Nico
--

[Joe Touch]

Hi, Nico,


On 3/28/2017 12:00 PM, Nico Williams wrote:
> ...
>> Unix defines only POSIX time right now, FWIW.
> POSIX defines POSIX time. Unix and Unix-like systems use it.
>
> (Nothing stops any Unix-like OS from including extensions.)
Agreed.
>
>> AFAICT, wouldn't specing Unix interfaces to the different times below be
>> out of scope for the IETF?
> Yes and no.
>
> First, the IETF has and does specify some APIs. (BSD sockets bindings
> for IPv6, GSS-API, and various others.)

Only network APIs, AFAICT>

> Second, the IETF could define abstract APIs but refrain from specifying
> C bindings for APIs and recommend to the Open Group and others that they
> standardize those based on the abstract APIs. (GSS-API, for example,
> defines both, abstract and programming-language-specific bindings.)
>
> Regardless, how could we address our time issues without specifying what
> amounts to.. type conversions?
*our* time issues are mostly that we need to know the time frame being
used, and to appreciate that there's no single solution that can be used
to calculate intervals AND correspond to civil time that avoids the need
for constantly-updated external information. No closed system is
sufficient for that.

> ...
>
> Obviously, for leap second smearing, besides an API there is also
> behavior (smearing).

I sincerely hope we can stop referring to this nonstandard technique. We
certainly cannot even consider standardizing a conversion (even if that
were our purview) between time scales that include smearing until there
are smearing standards.

A key point in this doc is that smearing makes things horribly worse,
not better in any way, except to delude users into thinking otherwise.

Joe

[Nico Williams]

On Tue, Mar 28, 2017 at 12:07:38PM -0700, Joe Touch wrote:
> On 3/28/2017 12:00 PM, Nico Williams wrote:
> >> AFAICT, wouldn't specing Unix interfaces to the different times below be
> >> out of scope for the IETF?
> > Yes and no.
> >
> > First, the IETF has and does specify some APIs. (BSD sockets bindings
> > for IPv6, GSS-API, and various others.)
>
> Only network APIs, AFAICT>

Network protocols often depend on or relate to time, thus there's a
nexus.

> > Regardless, how could we address our time issues without specifying what
> > amounts to.. type conversions?
>
> *our* time issues are mostly that we need to know the time frame being
> used, and to appreciate that there's no single solution that can be used
> to calculate intervals AND correspond to civil time that avoids the need
> for constantly-updated external information. No closed system is
> sufficient for that.

If you can keep track of who needs time in what form...

And if you can't... then what's the point of adding PIT?

> > ...
> >
> > Obviously, for leap second smearing, besides an API there is also
> > behavior (smearing).
>
> I sincerely hope we can stop referring to this nonstandard technique. We
> certainly cannot even consider standardizing a conversion (even if that
> were our purview) between time scales that include smearing until there
> are smearing standards.

Agreed.

> A key point in this doc is that smearing makes things horribly worse,
> not better in any way, except to delude users into thinking otherwise.

Agreed!

Nico
--

[Joe Touch]

On 3/28/2017 12:19 PM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 12:07:38PM -0700, Joe Touch wrote:
>> On 3/28/2017 12:00 PM, Nico Williams wrote:
>>>> AFAICT, wouldn't specing Unix interfaces to the different times below be
>>>> out of scope for the IETF?
>>> Yes and no.
>>>
>>> First, the IETF has and does specify some APIs. (BSD sockets bindings
>>> for IPv6, GSS-API, and various others.)
>> Only network APIs, AFAICT>
> Network protocols often depend on or relate to time, thus there's a
> nexus.
Mostly they depend on continuous time, which is already pointed out.

>
>>> Regardless, how could we address our time issues without specifying what
>>> amounts to.. type conversions?
>> *our* time issues are mostly that we need to know the time frame being
>> used, and to appreciate that there's no single solution that can be used
>> to calculate intervals AND correspond to civil time that avoids the need
>> for constantly-updated external information. No closed system is
>> sufficient for that.
> If you can keep track of who needs time in what form...
>
> And if you can't... then what's the point of adding PIT?

I don't think there is. Managing time across systems requires some sort
of coordination, either to unify time units or entire time scales. Once
you recognize that, it's sufficient to use UTC + locale.

Joe

[Manger, James]

>> leap second smearing

> We certainly cannot even consider standardizing a conversion (even if that
> were our purview) between time scales that include smearing until there
> are smearing standards.

It looks like the most valuable IETF contribution would be standardizing one smearing scheme (& getting Google, Java, ... to agree to it).


> A key point in this doc is that smearing makes things horribly worse,
> not better in any way, except to delude users into thinking otherwise.

Given that a well-defined smearing scheme allows a simple and precise mapping to UTC, it is hard to see how that can be "horribly worse".

Smearing moves the complexity of solar-vs-atomic-vs-civic time and the resultant leap seconds to a place where a huge number of systems can correctly handle that complexity by "doing nothing", while systems that care if time intervals can be 0.001% wrong (if 24hr is the smear standard) can still be more precise by making well-defined adjustments.

--
James Manger

[Joe Touch]

On 3/28/2017 3:56 PM, Manger, James wrote:
>>> leap second smearing
>> We certainly cannot even consider standardizing a conversion (even if that
>> were our purview) between time scales that include smearing until there
>> are smearing standards.
> It looks like the most valuable IETF contribution would be standardizing one smearing scheme (& getting Google, Java, ... to agree to it).

Ick. IMO, the most valuable contribution is to recommend the use of TAI
or UTC, IMO.

>
>> A key point in this doc is that smearing makes things horribly worse,
>> not better in any way, except to delude users into thinking otherwise.
> Given that a well-defined smearing scheme allows a simple and precise mapping to UTC, it is hard to see how that can be "horribly worse".
Even if we say that all interval calculations and conversions are
equally messy or not, why introduce yet another standard when we already
have TAI and UTC?
> Smearing moves the complexity of solar-vs-atomic-vs-civic time and the resultant leap seconds to a place where a huge number of systems can correctly handle that complexity by "doing nothing", while systems that care if time intervals can be 0.001% wrong (if 24hr is the smear standard) can still be more precise by making well-defined adjustments.

Doing nothing means smeared times are always wrong. When that smeared
time corresponds to a day or year change in another time zone, you've
really messed things up. That means doing nothing either means your
wrong or you're really wrong. The only solution is to convert out of the
smear back to UTC, but then why bother smearing at all?

Joe

[Joe Touch]

Hi, Philip,


On 3/28/2017 7:05 AM, Philip Homburg wrote:
> In your letter dated Mon, 27 Mar 2017 12:34:10 -0700 you wrote:
>> I've submitted the time frame discussion intended to resolve this issue,
>> which also recently arouse on another mailing list. Further discussion
>> on this draft will occur on the ART mailing list (***@ietf.org).
> A few random comments. I think a document like this is useful, though it
> might hard to strike the right balance between providing enough and too much
> detail.
Yeah - I struggled with that. I don't think everyone will be happy with
any particular boundary...

> - There are two types of solar time. The actual solar time where the sun is
> at the highest point at noon, and mean solar time. Section 4 does not make
> that distinction, but it is mentioned in a later section. After far as I know,
> actual solar time is extremely rare (only sundials). Solar time is almost
> always mean solar time. I.e UT0 is already mean solar time.
Section 3 states that in the definition of a solar day. Section 4.2
explains that UT0 is one of many different "means", and that UT0 is the
most common in current use.

> - UTC (and TAI) doesn't really exist. They are realized at various labs all
> over the world. The real value of UTC is coordinated only after the fact.
Although that's strictly true, there are also UTC and TAI sources that
provide the current time as close to UTC and TAI as known. I can add that.

> This makes a statement that GPS time differs 25 ns from TAI a bit weird.
> Maybe this is too much detail.

See above - even in retrospect, GPS can differ from TAI by 25 ns (it's
in the spec for GPS). GPS isn't one of the clocks averaged into TAI
(AFAICT); it's a separate source that's sync'd to TAI to ensure the 25
ns max delta.

> - It is not clear to me why NTP would differ 100ms from TAI.
It's in the spec.

> - The epoch for NTP is 1900-01-01.
Yup - my error. WIll fix.

> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
> time is linked to UTC,

That is incorrect. POSIX time is defined as 1/86400 of a day, which does
not take into account leap seconds at all (UTC does) and "day" is not
defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at
best a rough approximation of UT0.

> i.e. every value of time_t corresponds to a specific
> UTC timestamp. The inverse is not true, leapseconds cannot be represented in
> time_t.
See above, I think.

> - I can't find any reference where the epoch of TAI is defined as 1977-01-01.
It's from the updated definition of TAI, the one that started to take
account for time dilation and gravitational influences.
I'll see if I can find a citable ref for that.

> - Section 5.1.3 says 'Similarly, the earth's orbit around the sun varies and
> is slowing over time, resulting in an increasing stretching of a solar second.'
> It is the rotation of the earth around it's own axis that causes the
> solar second to become longer over time, not the rotation of the earth
> around the sun.
I'll fix that...

> - One thing I'd like to add is 'uptime' or more general, monotonic time.

Uptime is just a printout of the delta of the POSIX time when a computer
started and the current POSIX time.

It might be useful to indicate that some computers just start their
clocks at boot as zero.

> Many network protocols need timers and timeout. There is however no need
> to reference these to UTC, or TAI, etc. So computing time intervals using
> uptime is in many cases better because that also works if an external time
> reference doesn't become available until long after booting.

How/when to sync a "clock" to a time scale is important to note, but the
details are implementation issues.

"uptime" isn't used for timers; internal clocks are, e.g., the POSIX
time scale.

> - Another thing worth mentioning explictly is that for the distant future,
> there is no way to convert between TAI and UTC because future leapsecond are
> not yet defined. So TAI is good for computing intervals, except if it involves
> timestamps more than a few months in the future.
The doc mentions in various places that updated leapsecond information
is required to maintain UTC or derive TAI from UTC. I can mention that
we don't *expect* leapseconds to be added without at least a few months'
notice, and that this affects indicating future dates accurately.

Joe

[Tony Finch]

Joe Touch <***@isi.edu> wrote:

> Section 3 states that in the definition of a solar day. Section 4.2
> explains that UT0 is one of many different "means", and that UT0 is the
> most common in current use.

No, UT1 is the most common form of mean solar time. (UT0 is basically
mean solar time at a particular observatory; UT1 is corrected for polar
motion so it is globally consistent.)

> GPS isn't one of the clocks averaged into TAI (AFAICT); it's a separate
> source that's sync'd to TAI to ensure the 25 ns max delta.

Well, GPS is an ensemble clock (each sat has its own clock) which is
steered with reference to UTC(USNO). UTC(USNO) feeds into the BIPM paper
clocks.

The USNO says that GPS's maximum deviation from UTC(USNO) is 1us though
in practice it is within a few hundred nanoseconds. The NAV message has
additional information that allows GPS receivers to get the UTC(USNO) time
to within 40ns.

http://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer

> > - It is not clear to me why NTP would differ 100ms from TAI.
>
> It's in the spec.

Where in which spec?

> Uptime is just a printout of the delta of the POSIX time when a computer
> started and the current POSIX time.

CLOCK_MONOTONIC cannot be reset, so it is more reliable than that.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Trafalgar: In southeast, variable 3 or 4. In northwest, southerly 5 to 7. In
southeast, slight or moderate. in northwest, moderate or rough. In southeast,
fair. In northwest, rain or showers. Good, occasionally poor.

[Joe Touch]

On 3/28/2017 1:12 PM, Tony Finch wrote:
> Joe Touch <***@isi.edu> wrote:
>
>> Section 3 states that in the definition of a solar day. Section 4.2
>> explains that UT0 is one of many different "means", and that UT0 is the
>> most common in current use.
> No, UT1 is the most common form of mean solar time. (UT0 is basically
> mean solar time at a particular observatory; UT1 is corrected for polar
> motion so it is globally consistent.)
Yes - mistyped (the doc is correct on that - it says UT1 is the
particular mean that is in common use).

>
>> GPS isn't one of the clocks averaged into TAI (AFAICT); it's a separate
>> source that's sync'd to TAI to ensure the 25 ns max delta.
> Well, GPS is an ensemble clock (each sat has its own clock) which is
> steered with reference to UTC(USNO). UTC(USNO) feeds into the BIPM paper
> clocks.
>
> The USNO says that GPS's maximum deviation from UTC(USNO) is 1us though
> in practice it is within a few hundred nanoseconds. The NAV message has
> additional information that allows GPS receivers to get the UTC(USNO) time
> to within 40ns.
>
> http://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfer

The GPS spec guarantees that its max deviation is 25 ns AFAICT (see the
cited ref in the doc).

>
>>> - It is not clear to me why NTP would differ 100ms from TAI.
>> It's in the spec.
> Where in which spec?

It's in the definition of NTP strata. Stratum 0 is the a reference clock
itself; stratum 1 is connected to the clock directly, stratum 2 is
connected to stratum 1 over the net. I'll dig up a specific citation for
that...

>
>> Uptime is just a printout of the delta of the POSIX time when a computer
>> started and the current POSIX time.
> CLOCK_MONOTONIC cannot be reset, so it is more reliable than that.
It is guaranteed monotonic only while the system is running. I don't
know what "reliable" means, but it isn't guaranteed to be preserved
across a boot.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html

Joe

[Philip Homburg]

[Just responding to text in many different e-mails]

>> actual solar time is extremely rare (only sundials). Solar time is almost
>> always mean solar time. I.e UT0 is already mean solar time.
>Section 3 states that in the definition of a solar day. Section 4.2
>explains that UT0 is one of many different "means", and that UT0 is the
>most common in current use.

Very confusing to have two completely different definitions of Solar day in one
item. Later you use solar time sometimes as mean, sometimes as 'apparent'.

>> This makes a statement that GPS time differs 25 ns from TAI a bit weird.
>> Maybe this is too much detail.
>
>See above - even in retrospect, GPS can differ from TAI by 25 ns (it's
>in the spec for GPS). GPS isn't one of the clocks averaged into TAI
>(AFAICT); it's a separate source that's sync'd to TAI to ensure the 25
>ns max delta.

Given the complexities of dealing with time at the nanosecond level, maybe
it is better to ignore those issues in this document. I.e, GPS and Galilelo
are synced to TAI (with some fixed offset). GLONASS tracks UTC. And leave it
at that.

>> - It is not clear to me why NTP would differ 100ms from TAI.
>It's in the spec.

Can you be more specific.

>> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
>> time is linked to UTC,
>
>That is incorrect. POSIX time is defined as 1/86400 of a day, which does
>not take into account leap seconds at all (UTC does) and "day" is not
>defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at
>best a rough approximation of UT0.

I was going to propose that for this document we treat POSIX time as
NTP time minus 2208988800. Unfortunately, the latest NTP RFC (5905) doesn't
seem to actually define NTP time. So that doesn't help.

>But as others have pointed out, that is either a lie or an error: POSIX
>simply does not and cannot account for leap seconds in a numeric type
>representing seconds since an epoch. Perhaps we can say that the
>reference to UTC was meant to be to TAI. Either way the definition of
>seconds can only plausibly be SI.

The way I read it, the following formula

tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

converts between a time_t value and a broken down UTC time. Just about
every piece of software assume this to be true. I.e, if you run ls then
the times shown by ls are based on this formula.

Of course this implies that time_t is horribly broken in many different ways,
but we already know that.

So if you subtract two time_t values, you don't get the real number of
seconds between the two points of time they represent because leapseconds
are ignored. If tm_sec == 60, i.e. during a leap second, you get the same
time_t value as the first second of the next minute.

>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
>
>Uptime is just a printout of the delta of the POSIX time when a computer
>started and the current POSIX time.
>
>It might be useful to indicate that some computers just start their
>clocks at boot as zero.

The main thing is that monotonic time can never go backward. Ntpd will hapily
step the (POSIX) time backwards. So you need a separate clock, which POSIX
calls CLOCK_MONOTONIC (see clock_settime).

>I can add a new "monotonic clock" definition that uses an arbitrary
>"tick" that is guaranteed to increase between reads and across reboots,
>but is not comparable across machines.

Note that monotonic time is typically not maintained across reboots.

>Better data types -and strong typing- are needed:
>
> - Unix-like TAI (seconds since epoch, admitting not leap seconds)

If we can get the opengroup to add CLOCK_TAI then we can have this. One
problem is that there doesn't seem to be a sensible epoch for TAI.

> - Unix-like UTC (seconds since epoch, with leap seconds)
> - both with variations like real versus integer, or seconds +
> microseconds, etc..

I'd like to treat time_t as something that is synchronized with UTC and behaves
rather weird around a leap second.

> - broken-down time without leap seconds

Not sure why that would be desirable, but that's what have now.

> - broken-down time with leap seconds

A 'tai_gmtime' could do that.

>Then there's intervals. Having variations on intervals based on whether
>or not they admit leaps seems silly though, so intervals are a bit
>easier.

If you want to set a timer based on an interval, then it may make sense to
know if leap seconds need to be counted or not.

>The obvious argument against smeared time is that we already have _two_
>time standards, and we don't need a third. All we need is to carefully
>pick one or the other in each specification, and preferably TAI time in
>all cases.

There is (right now) no meaningful way to convert 2020-01-01 00:00:00 UTC
to a TAI time value.

[Joe Touch]

On 3/29/2017 4:36 AM, Philip Homburg wrote:
> [Just responding to text in many different e-mails]
>
>>> actual solar time is extremely rare (only sundials). Solar time is almost
>>> always mean solar time. I.e UT0 is already mean solar time.
>> Section 3 states that in the definition of a solar day. Section 4.2
>> explains that UT0 is one of many different "means", and that UT0 is the
>> most common in current use.
> Very confusing to have two completely different definitions of Solar day in one
> item. Later you use solar time sometimes as mean, sometimes as 'apparent'.

That's on my list to fix (I'm typing that summary to post to the list in
a minute or two)...
>
>>> This makes a statement that GPS time differs 25 ns from TAI a bit weird.
>>> Maybe this is too much detail.
>> See above - even in retrospect, GPS can differ from TAI by 25 ns (it's
>> in the spec for GPS). GPS isn't one of the clocks averaged into TAI
>> (AFAICT); it's a separate source that's sync'd to TAI to ensure the 25
>> ns max delta.
> Given the complexities of dealing with time at the nanosecond level, maybe
> it is better to ignore those issues in this document. I.e, GPS and Galilelo
> are synced to TAI (with some fixed offset). GLONASS tracks UTC. And leave it
> at that.
>
>>> - It is not clear to me why NTP would differ 100ms from TAI.
>> It's in the spec.
> Can you be more specific.

I'm tracking that down - it's because of the strata.

>
>>> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
>>> time is linked to UTC,
>> That is incorrect. POSIX time is defined as 1/86400 of a day, which does
>> not take into account leap seconds at all (UTC does) and "day" is not
>> defined as related to SI units (UTC is). AFAICT, a POSIX "day" is at
>> best a rough approximation of UT0.
> I was going to propose that for this document we treat POSIX time as
> NTP time minus 2208988800. Unfortunately, the latest NTP RFC (5905) doesn't
> seem to actually define NTP time. So that doesn't help.

I think I see the issue here.

Unix time is a count since epoch, but never defines second or day. It
emulates TAI, but there's no definition of how it drifts (or not) from TAI.

POSIX *time* is this Unix time.

The POSIX time API allows access to two different clocks: a local
realtime clock and a local monotonic clock. The API *approximates* UTC
by trying to convert its internal time to what it thinks is UTC. When
that realtime clock is updated by NTP, the API can present an accurate
UTC value. When not, it likely presents something that is TAI+offset,
because it doesn't track leaps.

It's important to differentiate these; I've been talking almost
exclusively about POSIX *time*, not the POSIX time API.

>
>> But as others have pointed out, that is either a lie or an error: POSIX
>> simply does not and cannot account for leap seconds in a numeric type
>> representing seconds since an epoch. Perhaps we can say that the
>> reference to UTC was meant to be to TAI. Either way the definition of
>> seconds can only plausibly be SI.
> The way I read it, the following formula
>
> tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> converts between a time_t value and a broken down UTC time.
See above. This is just an *approximation* that tries to convert Unix
time to something close to UTC, but because it doesn't track leaps, it
really emulates TAI.


> Just about
> every piece of software assume this to be true. I.e, if you run ls then
> the times shown by ls are based on this formula.
>
> Of course this implies that time_t is horribly broken in many different ways,
> but we already know that.
If time_t is an integer (i.e., you're not referring to the struct tm or
some other API), then it is supposed to be the Unix time...

> So if you subtract two time_t values, you don't get the real number of
> seconds between the two points of time they represent because leapseconds
> are ignored.
You do (or should) get the real seconds.

You can't subtract two struct tm's that way, though.

>
>>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
>> Uptime is just a printout of the delta of the POSIX time when a computer
>> started and the current POSIX time.
>>
>> It might be useful to indicate that some computers just start their
>> clocks at boot as zero.
> The main thing is that monotonic time can never go backward.

It can on reboot.

> Ntpd will hapily
> step the (POSIX) time backwards. So you need a separate clock, which POSIX
> calls CLOCK_MONOTONIC (see clock_settime).
We really need to differentiate between the POSIX time scale and the
POSIX time API. You're talking about the POSIX time API. POSIX time
itself should never go backwards...

>
>> I can add a new "monotonic clock" definition that uses an arbitrary
>> "tick" that is guaranteed to increase between reads and across reboots,
>> but is not comparable across machines.
> Note that monotonic time is typically not maintained across reboots.
I'll point that out too..

>
>> Better data types -and strong typing- are needed:
>>
>> - Unix-like TAI (seconds since epoch, admitting not leap seconds)
> If we can get the opengroup to add CLOCK_TAI then we can have this. One
> problem is that there doesn't seem to be a sensible epoch for TAI.
TAI defines its epoch as 1977-01-01

When you say "sensible", is the problem in representing times before
that epoch? They can be denoted as negatives...

>
>> - Unix-like UTC (seconds since epoch, with leap seconds)
>> - both with variations like real versus integer, or seconds +
>> microseconds, etc..
> I'd like to treat time_t as something that is synchronized with UTC and behaves
> rather weird around a leap second.

time_t should be the Unix time, which can't sync to a time scale with
leaps like UTC

the POSIX time API does have a struct tm, which might derive a UTC
approximation.


>
>> - broken-down time with leap seconds
> A 'tai_gmtime' could do that.
>
>> Then there's intervals. Having variations on intervals based on whether
>> or not they admit leaps seems silly though, so intervals are a bit
>> easier.
> If you want to set a timer based on an interval, then it may make sense to
> know if leap seconds need to be counted or not.
That would depend IMO on whether the timer is supposed to trigger on an
exact date or at the end of an exact interval. That's worth noting.


>
>> The obvious argument against smeared time is that we already have _two_
>> time standards, and we don't need a third. All we need is to carefully
>> pick one or the other in each specification, and preferably TAI time in
>> all cases.
> There is (right now) no meaningful way to convert 2020-01-01 00:00:00 UTC
> to a TAI time value.

True, but that's also because that UTC date is indeterminate. Until you
know the leaps between now and then, you don't know when that date will
actually occur.

Joe

[Michael Thornburgh]

> From: art [art-***@ietf.org] on behalf of Philip Homburg [pch-ietf-***@u-1.phicoh.com]
> Sent: Tuesday, March 28, 2017 7:05 AM

[...]
> - It is not clear to me what 'Unix time' is in this context. Typically POSIX
> time is linked to UTC, i.e. every value of time_t corresponds to a specific
> UTC timestamp. The inverse is not true, leapseconds cannot be represented in
> time_t.
[...]

while this has been the case so far, this is not true in general. there can be negative leap
seconds, for which there will be values of time_t with no corresponding UTC time.
fortunately there have not been any negative leap seconds yet.

as i mentioned on a different mailing list [0], unix/posix time is a (deficient) time representation form,
but people use it as a time keeping form (as if it's actually the "uptime" since the unix
epoch). i'm sure it was initially envisioned as both, even though that's wrong.

really unfortunately (or at least annoyingly) for timekeeping, "1970-01-01 00:00:00 UTC" isn't
a whole number of seconds offset from TAI. UTC's ticks weren't synchronized to TAI ticks until
1972-01-01 00:00:10 TAI / 1972-01-01 00:00:00 UTC. so having 1970-01-01 00:00:00 UTC
as a timekeeping epoch is the wrong choice anyway. as i indicated in [0], i think the
right choice is 1970-01-01 00:00:10 TAI as the timekeeping epoch.

because solar time is variable, the standardized second is useful, and it is useful for
civil time to be in close agreement with solar time, there will need to be leap seconds or
at least periodic civil time steps. therefore, the representation of civil/human time in something
like a time_t or a struct timeval is wrong, especially for future times. the correct choice should
represent civil/human time in something like a struct tm or ISO 8601 or something.

[0] https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0424.html

[Joe Touch]

Moving this to ART...


On 3/28/2017 10:39 AM, Nico Williams wrote:
> On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote:
>> Yes, the system should use a leap-second-free constant-duration-seconds time
>> for everything. It is only humans that need the variable jumpy version of
>> time presented to them, and that is a UI issue.
> I don't think that's quite right.
>
> Unix time is canonically a count of seconds since an epoch and admits no
> leap seconds.

Unix time also uses a completely different definition of a "second" than
UTC.

There is no simple conversion between Unix time and UTC. Conversion
requires accurate assessment of the local Unix clock vs SI to determine
a rate conversion as well as knowing the table of leap seconds since the
Unix epoch.

> ...
> It's all about data typing.

That is certainly one problem, but not the only one.

Joe

[Nico Williams]

On Tue, Mar 28, 2017 at 02:40:07PM -0700, Joe Touch wrote:
> On 3/28/2017 10:39 AM, Nico Williams wrote:
> > On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote:
> >> Yes, the system should use a leap-second-free constant-duration-seconds time
> >> for everything. It is only humans that need the variable jumpy version of
> >> time presented to them, and that is a UI issue.
> > I don't think that's quite right.
> >
> > Unix time is canonically a count of seconds since an epoch and admits no
> > leap seconds.
>
> Unix time also uses a completely different definition of a "second" than
> UTC.

Did I.. say otherwise?

> There is no simple conversion between Unix time and UTC. Conversion
> requires accurate assessment of the local Unix clock vs SI to determine
> a rate conversion as well as knowing the table of leap seconds since the
> Unix epoch.

You're complicating things. Forget the local clock. To convert a time_t
value to UTC requires just a list of leap seconds (and some arithmetic).

There's no need to assess the quality of the local clock or anything of
the sort.

> > ...
> > It's all about data typing.
>
> That is certainly one problem, but not the only one.

It's really the main one, IMO. In any case, smearing seems very wrong:
you end up with more problems because you go from roughly two kinds of
time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new
thing). If people had a hard time interoperating with two kinds of
time, imagine how it would be with THREE kinds of time. And if the
smearing formula ever needs updating, then we'd be in trouble. (Earth's
rotation normally _slows_ over time, but the 2004 earthquake _sped up_
Earth's rotation. A few big ones and we might need negative leap
seconds. PIT's formula can't predict these events.)

Just specify, in each protocol, the use of TAI (x)or UTC. Done.

Nico
--

[Joe Touch]

On 3/28/2017 3:40 PM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 02:40:07PM -0700, Joe Touch wrote:
>> On 3/28/2017 10:39 AM, Nico Williams wrote:
>>> On Tue, Jan 03, 2017 at 06:35:03PM +0000, Stewart Bryant wrote:
>>>> Yes, the system should use a leap-second-free constant-duration-seconds time
>>>> for everything. It is only humans that need the variable jumpy version of
>>>> time presented to them, and that is a UI issue.
>>> I don't think that's quite right.
>>>
>>> Unix time is canonically a count of seconds since an epoch and admits no
>>> leap seconds.
>> Unix time also uses a completely different definition of a "second" than
>> UTC.
> Did I.. say otherwise?
Yes, below....
>
>> There is no simple conversion between Unix time and UTC. Conversion
>> requires accurate assessment of the local Unix clock vs SI to determine
>> a rate conversion as well as knowing the table of leap seconds since the
>> Unix epoch.
> You're complicating things. Forget the local clock. To convert a time_t
> value to UTC requires just a list of leap seconds (and some arithmetic).
time_t does not access a SI reference or frankly any other stable reference.

If you don't have a stable time unit, accurate conversion isn't possible.

If you do have a stable time unit, you need the ratio of that time unit
to SI.

> There's no need to assess the quality of the local clock or anything of
> the sort.
>
>>> ...
>>> It's all about data typing.
>> That is certainly one problem, but not the only one.
> It's really the main one, IMO. In any case, smearing seems very wrong:
> you end up with more problems because you go from roughly two kinds of
> time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new
> thing). If people had a hard time interoperating with two kinds of
> time, imagine how it would be with THREE kinds of time. And if the
> smearing formula ever needs updating, then we'd be in trouble. (Earth's
> rotation normally _slows_ over time, but the 2004 earthquake _sped up_
> Earth's rotation. A few big ones and we might need negative leap
> seconds. PIT's formula can't predict these events.)
>
> Just specify, in each protocol, the use of TAI (x)or UTC. Done.
I agree.

Joe

[Nico Williams]

On Tue, Mar 28, 2017 at 04:02:46PM -0700, Joe Touch wrote:
> On 3/28/2017 3:40 PM, Nico Williams wrote:
> > Did I.. say otherwise?
> Yes, below....

You're picking non-nits.

> >> There is no simple conversion between Unix time and UTC. Conversion
> >> requires accurate assessment of the local Unix clock vs SI to determine
> >> a rate conversion as well as knowing the table of leap seconds since the
> >> Unix epoch.
> > You're complicating things. Forget the local clock. To convert a time_t
> > value to UTC requires just a list of leap seconds (and some arithmetic).
>
> time_t does not access a SI reference or frankly any other stable reference.

The Open Group man pages I'm looking at don't reference SI, but so
bloody what. If it says "seconds", it means "seconds".

> If you don't have a stable time unit, accurate conversion isn't possible.

Sure, but POSIX time clearly uses the only definition of seconds that
matters.

Also, time is relative. These seconds are seconds at mean sea level on
Earth, but they might vary nonetheless. At some point precision is not
so interesting, but knowing 1490745768 is 2017-03-29T00:02:48Z, that's
kinda important, and that will be true in any local frame of reference,
even in space, far from Earth, and under large accelerations. Sure, two
such observers won't agree as to current time because of relativistic
effects, but they will agree that 1490745768 is 2017-03-29T00:02:48Z.

> If you do have a stable time unit, you need the ratio of that time unit
> to SI.

It's very safe to assume it's 1. Anything else would be insane.

> > It's really the main one, IMO. In any case, smearing seems very wrong:
> > you end up with more problems because you go from roughly two kinds of
> > time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new
> > thing). If people had a hard time interoperating with two kinds of
> > time, imagine how it would be with THREE kinds of time. And if the
> > smearing formula ever needs updating, then we'd be in trouble. (Earth's
> > rotation normally _slows_ over time, but the 2004 earthquake _sped up_
> > Earth's rotation. A few big ones and we might need negative leap
> > seconds. PIT's formula can't predict these events.)
> >
> > Just specify, in each protocol, the use of TAI (x)or UTC. Done.
>
> I agree.

Isn't that the important bit of information here?

Nico
--

[Joe Touch]

On 3/28/2017 5:06 PM, Nico Williams wrote:
> ...
>> time_t does not access a SI reference or frankly any other stable reference.
> The Open Group man pages I'm looking at don't reference SI, but so
> bloody what. If it says "seconds", it means "seconds".
That's the trouble - seconds in SI are not seconds defined as 86400/day.
If the units don't match, then a conversion needs to be included. If
the units aren't known, you can't convert accurately.

>
>> If you don't have a stable time unit, accurate conversion isn't possible.
> Sure, but POSIX time clearly uses the only definition of seconds that
> matters.
>
> Also, time is relative. These seconds are seconds at mean sea level on
> Earth, but they might vary nonetheless. At some point precision is not
> so interesting, but knowing 1490745768 is 2017-03-29T00:02:48Z, that's
> kinda important, and that will be true in any local frame of reference,
> even in space, far from Earth, and under large accelerations. Sure, two
> such observers won't agree as to current time because of relativistic
> effects, but they will agree that 1490745768 is 2017-03-29T00:02:48Z.
2017 is 1.4e9 seconds after the Unix epoch. If the Unix and SI "seconds"
unit is off by one part in a (US) billion, then you're off by 1.5 seconds.

>
>> If you do have a stable time unit, you need the ratio of that time unit
>> to SI.
> It's very safe to assume it's 1. Anything else would be insane.
s/insane/undefined/

That's the problem. I appreciate it would be nice if there were a
definition (as a start), and if the defined unit were SI, but it isn't,
AFAICT. If you have a ref to the contrary, I'd be more than glad to
include it and correct the doc accordingly.

>
>>> It's really the main one, IMO. In any case, smearing seems very wrong:
>>> you end up with more problems because you go from roughly two kinds of
>>> time (UTC vs TAI-ish) to three kinds of time (UTC vs TAI-ish vs the new
>>> thing). If people had a hard time interoperating with two kinds of
>>> time, imagine how it would be with THREE kinds of time. And if the
>>> smearing formula ever needs updating, then we'd be in trouble. (Earth's
>>> rotation normally _slows_ over time, but the 2004 earthquake _sped up_
>>> Earth's rotation. A few big ones and we might need negative leap
>>> seconds. PIT's formula can't predict these events.)
>>>
>>> Just specify, in each protocol, the use of TAI (x)or UTC. Done.
>> I agree.
> Isn't that the important bit of information here?
To you and me, perhaps, but there are others on this thread that are
misled by what POSIX is and how easy/hard it is to convert to TAI/UTC...

Joe

[Nico Williams]

On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote:
> >> time_t does not access a SI reference or frankly any other stable reference.
> > The Open Group man pages I'm looking at don't reference SI, but so
> > bloody what. If it says "seconds", it means "seconds".
> That's the trouble - seconds in SI are not seconds defined as 86400/day.
> If the units don't match, then a conversion needs to be included. If
> the units aren't known, you can't convert accurately.

POSIX does NOT define seconds in terms of days! It does the opposite:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16

How any changes to the value of seconds since the Epoch are made to
align to a desired relationship with the current actual time is
implementation-defined. As represented in seconds since the Epoch,
each and every day shall be accounted for by exactly 86400 seconds.

There is NO reference to solar or sidereal days or any other
astronomical definition of day.

Unlike as with days, there is no multiplicity of generally accepted
definitions of seconds, so there is no support for the idea that this
text defines seconds in terms of days.

The second sentence defines days in terms of seconds, not the other way
around.

The first sentence is a bit abstruse, but no matter, because in
_practice_ on all systems I know of that claim to implement POSIX, or
which don't but which are Unix or Unix-like systems, seconds since the
epoch differs from UTC *only* by leap seconds -- just like TAI.

Also, POSIX does refer to UTC:

A value that approximates the number of seconds that have elapsed
since the Epoch. A Coordinated Universal Time name (specified in
terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days
since January 1 of the year (tm_yday), and calendar year minus 1900
(tm_year)) is related to a time represented as seconds since the
Epoch, according to the expression below.

But as others have pointed out, that is either a lie or an error: POSIX
simply does not and cannot account for leap seconds in a numeric type
representing seconds since an epoch. Perhaps we can say that the
reference to UTC was meant to be to TAI. Either way the definition of
seconds can only plausibly be SI.

The text is sufficiently ambiguous (because of its errors, for example)
that you could remotely plausibly make these claims that you do, but
practice does not bear them out.

> > It's very safe to assume it's 1. Anything else would be insane.
>
> s/insane/undefined/
>
> That's the problem. I appreciate it would be nice if there were a
> definition (as a start), and if the defined unit were SI, but it isn't,
> AFAICT. If you have a ref to the contrary, I'd be more than glad to
> include it and correct the doc accordingly.

POSIX seconds are not defined, indeed, but they can only be taken to be
SI seconds -- anything else would be sheer madness and, anyways, not
supported by actual practice. I know of no POSIX or POSIX-ish system
where this is not true.

Running code, _running code_.

> > Isn't that the important bit of information here?
>
> To you and me, perhaps, but there are others on this thread that are
> misled by what POSIX is and how easy/hard it is to convert to TAI/UTC...

Maybe, but so are you. Not that that is particularly important to
making a successful argument against smearing, but that such errors are
distracting.

The obvious argument against smeared time is that we already have _two_
time standards, and we don't need a third. All we need is to carefully
pick one or the other in each specification, and preferably TAI time in
all cases.

Nico
--

[Nico Williams]

On Tue, Mar 28, 2017 at 08:58:12PM -0500, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote:
> > >> time_t does not access a SI reference or frankly any other stable reference.
> > > The Open Group man pages I'm looking at don't reference SI, but so
> > > bloody what. If it says "seconds", it means "seconds".
> > That's the trouble - seconds in SI are not seconds defined as 86400/day.
> > If the units don't match, then a conversion needs to be included. If
> > the units aren't known, you can't convert accurately.
>
> POSIX does NOT define seconds in terms of days! It does the opposite:

Although I can see how to waterboard the spec to get either answer. If
it were right about POSIX time being UTC (which it's not in practice),
then you'd be quite right about it defining seconds in terms of days...

Would that make POSIX a smeared time standard? Sure seems that way!

[Joe Touch]

On 3/28/2017 7:58 PM, Nico Williams wrote:
>> POSIX does NOT define seconds in terms of days! It does the opposite:
> Although I can see how to waterboard the spec to get either answer. If
> it were right about POSIX time being UTC (which it's not in practice),
> then you'd be quite right about it defining seconds in terms of days...
>
> Would that make POSIX a smeared time standard? Sure seems that way!
POSIX never claims that its "days" sync to UTC, UT, or TAI days. As
such, there's no smearing assumed.

Joe

[Joe Touch]

Hi, Nico,


On 3/28/2017 6:58 PM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote:
>>>> time_t does not access a SI reference or frankly any other stable reference.
>>> The Open Group man pages I'm looking at don't reference SI, but so
>>> bloody what. If it says "seconds", it means "seconds".
>> That's the trouble - seconds in SI are not seconds defined as 86400/day.
>> If the units don't match, then a conversion needs to be included. If
>> the units aren't known, you can't convert accurately.
> POSIX does NOT define seconds in terms of days! It does the opposite:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
>
> How any changes to the value of seconds since the Epoch are made to
> align to a desired relationship with the current actual time is
> implementation-defined. As represented in seconds since the Epoch,
> each and every day shall be accounted for by exactly 86400 seconds.
>
> There is NO reference to solar or sidereal days or any other
> astronomical definition of day.
OK - we agree that it defines "day" = 86400 "seconds".

It should be clear that it also never defines either "day" or "seconds".

"Seconds" can't be SI units unless there's a tiny cesium clock inside my
PC. "day" can't be apparent or mean solar time because it doesn't have a
sextant either.

> Unlike as with days, there is no multiplicity of generally accepted
> definitions of seconds, so there is no support for the idea that this
> text defines seconds in terms of days.
>
> The second sentence defines days in terms of seconds, not the other way
> around.
>
> The first sentence is a bit abstruse, but no matter, because in
> _practice_ on all systems I know of that claim to implement POSIX, or
> which don't but which are Unix or Unix-like systems, seconds since the
> epoch differs from UTC *only* by leap seconds -- just like TAI.
The text only states that the POSIX clock *started* with a known offset
to TAI and that the POSIX clock won't jump with leap seconds.

It never states anything else...

> ...
> POSIX seconds are not defined, indeed, but they can only be taken to be
> SI seconds -- anything else would be sheer madness and, anyways, not
> supported by actual practice. I know of no POSIX or POSIX-ish system
> where this is not true.

I know of no POSIX system with a cesium atomic clock.

The issue is that POSIX really runs off of whatever local source of time
passage is available, and can (and does) drift from TAI on *each*
system. That drift can't be determined until your system tries to sync
with an external source (e.g., via NTP).

Joe

[Philip Homburg]

>I know of no POSIX system with a cesium atomic clock.
>
>The issue is that POSIX really runs off of whatever local source of time
>passage is available, and can (and does) drift from TAI on *each*
>system. That drift can't be determined until your system tries to sync
>with an external source (e.g., via NTP).

To be completely pedantic, a single cesium clock will also drift from TAI/UTC.

There is no such concept as being in sync with TAI without external
corrections.

To be even more pedantic, of course that depends on the desired accuracy.
A cesium clock could easily stay within one hour from TAI for a period of a 100
years. A random PC with a quarz crystal at room temperature would have a hard
time doing that.

[Joe Touch]

On 3/29/2017 7:53 AM, Philip Homburg wrote:
>> I know of no POSIX system with a cesium atomic clock.
>>
>> The issue is that POSIX really runs off of whatever local source of time
>> passage is available, and can (and does) drift from TAI on *each*
>> system. That drift can't be determined until your system tries to sync
>> with an external source (e.g., via NTP).
> To be completely pedantic, a single cesium clock will also drift from TAI/UTC.
>
> There is no such concept as being in sync with TAI without external
> corrections.

Yes - I got email off-list about this and need to update the doc to
remind us that TAI is actually determined post-facto, though its current
value is approximated.

> To be even more pedantic, of course that depends on the desired accuracy.
> A cesium clock could easily stay within one hour from TAI for a period of a 100
> years. A random PC with a quarz crystal at room temperature would have a hard
> time doing that.

Right - I will update the doc accordingly. AFAICT, POSIX time implies
(but never states) that it uses a local reference clock to emulate TAI.

Joe

[Philip Homburg]

>Right - I will update the doc accordingly. AFAICT, POSIX time implies
>(but never states) that it uses a local reference clock to emulate TAI.

Not TAI, UTC.

Every time_t value has a specific interpretation as a UTC timestamp. Obviously,
without correction a free running clock will go wrong with leap seconds. But
that doesn't change that it is some approximation of UTC and not TAI.

By and large, current Unix systems have no idea about TAI. There are no
(commonly available) APIs that give you TAI.

[Joe Touch]

On 3/29/2017 8:13 AM, Philip Homburg wrote:
>> Right - I will update the doc accordingly. AFAICT, POSIX time implies
>> (but never states) that it uses a local reference clock to emulate TAI.
> Not TAI, UTC.

POSIX doesn't include leaps. It can't track UTC.

Maybe we're talking across things -

POSIX defines only one internal clock - the Unix one that starts at the
Unix epoch and counts up.

time_t is supposed to return an integer of this count

If you're referring to a time_t structure that indicates days, weeks,
months, etc., you're talking about a *conversion* that *approximates*
UTC, but really basically converts the Unix clock as close as it can to
TAI and ignores the leaps.

> Every time_t value has a specific interpretation as a UTC timestamp.
There is an intended correlation between Unix dates and UTC dates, but
it isn't exact - the equation is indicated as approximate.

> Obviously,
> without correction a free running clock will go wrong with leap seconds. But
> that doesn't change that it is some approximation of UTC and not TAI.
POSIX says it doesn't track leaps, which means (at best) it emulates
TAI, not UTC. Even if the documentation of the time_t structure and
commands indicate otherwise...

> By and large, current Unix systems have no idea about TAI. There are no
> (commonly available) APIs that give you TAI.

The time_t struct is a conversion of the Unix count since epoch into a
"UTC-like" format, but it really is much more an emulation of TAI than UTC.

But it *is* really neither, because it isn't sync'd to anything.

Joe

[Philip Homburg]

>> Every time_t value has a specific interpretation as a UTC timestamp.
>There is an intended correlation between Unix dates and UTC dates, but
>it isn't exact - the equation is indicated as approximate.

Quoting the opengroup docs, and this is the last thing I will say
about POSIX time:

"4.16 Seconds Since the Epoch
"
"A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
"
"If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:
"
"tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
" (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
" ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400

Feel free to define POSIX time as you wish. This what the opengroup says
about it.

[Joe Touch]

On 3/29/2017 9:11 AM, Philip Homburg wrote:
>>> Every time_t value has a specific interpretation as a UTC timestamp.
>> There is an intended correlation between Unix dates and UTC dates, but
>> it isn't exact - the equation is indicated as approximate.
> Quoting the opengroup docs, and this is the last thing I will say
> about POSIX time:

We've all been referring to this.

The problem is that POSIX never defines second, and that this entire
paragraph starts with "a value that approximates".
It also refers to "a Coordinated Universal Time name", that's a data
structure, not an assurance that seconds since epoch actually
synchronizes to UTC.

Joe

> "4.16 Seconds Since the Epoch
> "
> "A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below.
> "
> "If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types:
> "
> "tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 +
> " (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 -
> " ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
>
> Feel free to define POSIX time as you wish. This what the opengroup says
> about it.
>

[Joe Touch]

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.

-----

[Joe Touch]

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

[Philip Homburg]

In your letter dated Mon, 17 Apr 2017 14:32:57 -0700 you wrote:
>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.

[Joe Touch]

Hi, Philip,


On 4/18/2017 7:47 AM, Philip Homburg wrote:
> In your letter dated Mon, 17 Apr 2017 14:32:57 -0700 you wrote:
>> A new version of I-D, draft-touch-time-02.txt
> 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
> defined as two different things. But worse, the term 'solar day' is used
> unqualified throughout the document.
I will check and fix that.

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

[John Hawkinson]

Joe Touch <***@isi.edu> wrote on Tue, 18 Apr 2017
at 08:03:38 -0700 in <0751aeaa-56ae-e953-3b76-***@isi.edu>:

> > 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.
> can you clarify?

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.

--***@mit.edu
John Hawkinson

[Joe Touch]

> On Apr 18, 2017, at 8:02 PM, John Hawkinson <***@MIT.EDU> wrote:
>
> Joe Touch <***@isi.edu> wrote on Tue, 18 Apr 2017
> at 08:03:38 -0700 in <0751aeaa-56ae-e953-3b76-***@isi.edu>:
>
>>> 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.
>> can you clarify?
>
> 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.

Uncertainty sounds good.

>
>> The 25ns of GPS is the result of a claim in the GPS spec.
>
> You should probably cite it explicitly.

I'll dig that one up.

>
>> The 100ms is from a claim in NTP documentation.
>
> 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
> 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.
>
> --***@mit.edu
> John Hawkinson

[Michael Thornburgh]

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 [art-***@ietf.org] on behalf of Joe Touch [***@isi.edu]
Sent: Monday, April 17, 2017 2:32 PM
To: ***@ietf.org
Subject: Re: [art] summary of updates - draft-time-touch

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: [mangled URL removed]
Status: [mangled URL removed]
Htmlized: [mangled URL removed]
Htmlized: [mangled URL removed]
Diff: [mangled URL removed]

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.

[Joe Touch]

Hi, Michael,.

Thanks for the detailed feedback.

Can you clarify as per below?

On 4/18/2017 3:01 PM, Michael Thornburgh wrote:
> 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.
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.

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

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

---

[Steve Allen]

On Mon 2017-04-17T14:32:57 -0700, Joe Touch hath writ:
> A new version of I-D, draft-touch-time-02.txt
> has been successfully submitted by Joe Touch and posted to the
> IETF repository.

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 <***@ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
1156 High Street Voice: [phone] Lng -122.06015
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

[Joe Touch]

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:
> On Mon 2017-04-17T14:32:57 -0700, Joe Touch hath writ:
>> A new version of I-D, draft-touch-time-02.txt
>> has been successfully submitted by Joe Touch and posted to the
>> IETF repository.
> 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 <***@ucolick.org> WGS-84 (GPS)
> UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855
> 1156 High Street Voice: [phone] Lng -122.06015
> Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
>
> _______________________________________________
> art mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/art

[Nico Williams]

On Wed, Mar 29, 2017 at 04:53:01PM +0200, Philip Homburg wrote:
> >I know of no POSIX system with a cesium atomic clock.

The preceding bit about POSIX seconds being unable to be SI seconds
without an atomic clock speaks for itself. Joe may be the only one who
believes that.

> >The issue is that POSIX really runs off of whatever local source of time
> >passage is available, and can (and does) drift from TAI on *each*
> >system. That drift can't be determined until your system tries to sync
> >with an external source (e.g., via NTP).

Which... most do.

> To be completely pedantic, a single cesium clock will also drift from TAI/UTC.
>
> There is no such concept as being in sync with TAI without external
> corrections.

To be even more pedantic that may not be meaningfully possible or useful
or desirable due to being in an irregular orbit around Earth (e.g.,
frequently using thrusters to adjust it) or not in orbit around Earth,
and not on Earth.

This is not a helpful distraction. It's wasting everyone else's time.
Also yours and mine.

Nico
--

[Joe Touch]

On 3/29/2017 8:30 AM, Nico Williams wrote:
>>> The issue is that POSIX really runs off of whatever local source of time
>>> passage is available, and can (and does) drift from TAI on *each*
>>> system. That drift can't be determined until your system tries to sync
>>> with an external source (e.g., via NTP).
> Which... most do.
Then you're reporting NTP time, not Unix time.

And that's when you're clock jumps - because you're looking at UTC, not
the Unix clock anymore.

Joe

[Joe Touch]

On 3/28/2017 12:16 PM, Nico Williams wrote:
>> With a suitable definition, PIT could create a condition in which it would
>> only take a decision by one major government to force a change on the
>> astronomers. The commercial advantages of PIT over UTC are obvious - fewer
>> things are going to break for no good reason. That is an argument that
>> every politician is willing to listen to.
> Do we have this much influence? If we do, why not just... lobby for
> fixing UTC and creating an TAC (tempt astronomique coordiné) to serve,
> for astronomers, the function that UTC serves today.
We don't need TAC; we already have UT. IERS already broadcasts the
UTC-UT1 delta.

Joe

[Dale R. Worley]

Joe Touch <***@isi.edu> writes:
> I've completed an update that rolls in the changes below as well as a
> 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

[Joe Touch]

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


On 4/18/2017 8:29 AM, Dale R. Worley wrote:
> Joe Touch <***@isi.edu> writes:
>> I've completed an update that rolls in the changes below as well as a
>> 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

[Dale R. Worley]

(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

[Joe Touch]

On 4/18/2017 11:14 AM, Dale R. Worley wrote:
> (BTW, "draft-time-touch" in the subject line is incorrect! I made it
> 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
> 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.
Yeah - that's intended to be background.

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

[Joe Touch]

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

[Joe Touch]

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