Subject: Re: Predictable Internet Time

From: Nico Williams <[email-masked]>
Date: Tue, 18 Apr 2017 17:20:06 -0500

On Tue, Jan 03, 2017 at 05:34:11PM -0500, Phillip Hallam-Baker wrote:
> As I said, I want 30-100 years lead time so I can bake the schedule into
> devices and remove a trust dependency.

30 years' lead time for leap seconds?  Can't be done.

Leap seconds depend on events such as earthquakes.

You can estimate their frequency, but you can't estimate when they'll be
inserted.

Nico
--

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 19 Apr 2017 01:21:26 +0200

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

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 19 Apr 2017 07:18:29 +0200

On 19 Apr 2017, at 1:21, 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.
> 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.
>    Anything worse than labels on products "reduced functionality on Jan 1   after a leap second" ?

I want as potential fixes which I think are doable:

- an updated POSIX definition where the variable which holds the number of seconds since the epoch when converting back and forth to date actually will hold the number of seconds since the epoch.

- a slot in the NTP protocol not used today include the number of leap seconds so people get to know that.

FWIW I am a person that is against smear. I think a clock must be able to give the correct time and that timestamps should be correct. Either in seconds (and fractions of seconds) since the epoch or in correct date and time UTC. Both are increasing all the time. And because of that smear should not have to happen.

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

   Patrik

---

From: Nico Williams <[email-masked]>
Date: Wed, 19 Apr 2017 11:14:49 -0500

On Wed, Apr 19, 2017 at 07:18:29AM +0200, Patrik Fältström wrote:
> - an updated POSIX definition where the variable which holds the
> number of seconds since the epoch when converting back and forth to
> date actually will hold the number of seconds since the epoch.

So we should... brigade the Open Group?

> FWIW I am a person that is against smear. I think a clock must be able
> to give the correct time and that timestamps should be correct. Either
> in seconds (and fractions of seconds) since the epoch or in correct
> date and time UTC. Both are increasing all the time. And because of
> that smear should not have to happen.

+1

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

Sure.

Nico
--

---

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

Hi, all,

Again, this discussion is continuing over in ART at the advice of the IESG.

I'll post followups there.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 12:32:11 -0400

> You can estimate their frequency, but you can't estimate when they'll be

​Of course it can be done. I can show you one very simple algorithm that
allows every leap second to the end of time to be known right now:

"All leap seconds are abolished. UTC = TAI +37 for all future dates."

We do not need to let the astronomers mess around with time according to
their calendars. What I proposed was to define PIT in such a way that the
difference between PIT and UTC is highly unlikely to be more than 5 seconds
but the table of leap seconds is set 30 years ahead of time.

The basic scheme is to observe the current frequency of leap seconds (8 in
 the past 30 years) and use a simple linear extrapolation to approximate
that for the next 30 years. For dates after 2047, the leap second table and
approximation function will be updated so as to minimize the divergence
between PIT and UTC. If UTC is ahead of PIT in 2018, then an additional
leap second will be scheduled for 30 years in the future, unless a leap
second would have been scheduled for that date anyway in which it will
carry over to the next year.

​The scheme proposed guarantees complete predictability over a 30 year
timespan while ensuring that the deviation between PIT and solar time is
never more than a few seconds. If the frequency of leap seconds becomes too
high, the extrapolation function can be changed. At the end of the day, the
earth is only going to speed up its rotation for very brief intervals, the
long term trend is always downwards.​

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Apr 2017 12:26:27 -0500

On Fri, Apr 21, 2017 at 12:32:11PM -0400, Phillip Hallam-Baker wrote:
> Of course it can be done. I can show you one very simple algorithm that

That's moving the goal posts, and it's not your smeared time proposal.

Good, because smeared time is a terrible idea.  We don't need more time
standards to convert between.  Smearing time does not make UTC go away,
nor conversions to/from UTC.  Systems will always need to know about
leap seconds in order to convert to/from UTC because there will always
be parts of the system (or apps) that need TAI or something close to
TAI.  Smearing does not make that go away -- it solves nothing.

"Internet time" (that which we use in [new] Internet protocols) should
just be TAI.  And every existing Internet protocol should be updated to
indicate which time is used in practice, UTC or TAI, regardless of what
was originally specified.

Nico
--

---

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

> was originally specified.
I would be very glad of we defined Internet Time as TAI, but also expect
all protocols to understand both TAI and UTC if possible.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 14:35:30 -0400

> all protocols to understand both TAI and UTC if possible.

​To answer the issues raised:

1) POSIX already has this pretty much covered

http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html​

​int clock_gettime(clockid_t *clock_id*, struct timespec **tp*);​

​So all that is required is to define clock identifiers for:

TAI (The total number of seconds elapsed since the start of the epoch)
UTC (The TAI value adjusted for UTC leap seconds, i.e. number of non leap
second seconds since the start of the epoch)
PIT (The TAI value adjusted for PIT leap seconds)

POSIX already defines constants for CLOCK_PROCESS_CPUTIME_ID, CLOCK_REALTIME

All that is needed is to define the additional ones.

​2) No I did not move the goalposts. My original proposal was to solve the
needless chaos caused be the idiotic notion of changing the definition of
time at six months notice. The stupidity of that notion should be apparent
to all.

3) Screw the astronomers. Pluto is to a planet.​

---

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

On 4/21/2017 11:35 AM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Apr 21, 2017 at 1:57 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
> ​int clock_gettime(clockid_t /clock_id/, struct timespec */tp/);​
>  
> UTC (The TAI value adjusted for UTC leap seconds, i.e. number of non
> leap second seconds since the start of the epoch)
If these aren't already included, I'm surprised (at least UTC).

> PIT (The TAI value adjusted for PIT leap seconds)

We don't need PIT.

> POSIX already defines constants
> for CLOCK_PROCESS_CPUTIME_ID, CLOCK_REALTIME 
>
> ​2) No I did not move the goalposts. My original proposal was to solve
> the needless chaos caused be the idiotic notion of changing the
> definition of time at six months notice. The stupidity of that notion
> should be apparent to all.

There is no getting around the fact that the rest of the planet accepts
leap seconds. If that's not something you want to track, then use TAI
and be off-sync with the rest of the world when they use UTC.

PIT does nothing helpful except add yet another level of indirection and
confusion here.

> 3) Screw the astronomers. Pluto is to a planet.​

IMO, this issue is sufficently driven by "rough consensus and running
code" of the entire planet right now - where all governments already use
UTC.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 21 Apr 2017 16:29:24 -0400

On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <[email-masked]> wrot
​e​

> If these aren't already included, I'm surprised (at least UTC).

​Well I linked to the spec so you could have looked and checked. You are
wrong. The spec is ambiguous as to whether the value is UTC or not, hence
the need to be explicit. ​

> ​That is your opinion, like the astronomers, you might just be wrong about
the requirements.

I can see the benefit of an IoT where time is absolutely predictable even
if it may be out of sync with UT by a few seconds.​ You might not but I
doubt you have the range of experience in realtime and process control that
I have.

​Unless a device actually deals in time, PIT is going to be just fine for
status messages and logs. The advantage over UTC being that you know
exactly what the device is trying to do which you don't have with UTC. You
don't know whether the device is keeping UTC or some heuristic.

TAI would be a possibility if we counted in seconds which we don't. We
track time by date and need to compare. The difference between UTC and TAI
is half a minute which is just too much to be viable.​

> leap seconds. If that's not something you want to track, then use TAI and
> be off-sync with the rest of the world when they use UTC.
>

​Since the standard was only created in our lifetimes, it is hardly
immutable and fixed for all eternity.

The reason UTC is the standard is because it is what the ITU decided to use
and the broadcasters synchronize everything. That can change.

---

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

On 4/21/2017 1:29 PM, Phillip Hallam-Baker wrote:
>
>
> On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrot
> ​e​
>
>>     http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html
>>     <http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_getres.html>​
>>
>>     UTC (The TAI value adjusted for UTC leap seconds, i.e. number of
>>     non leap second seconds since the start of the epoch)
> ​Well I linked to the spec so you could have looked and checked.
You linked to an outdated 2004 spec.
The current spec is here: http://pubs.opengroup.org/onlinepubs/9699919799/

> You are wrong.
I can't be wrong. I said "IF", and you can't claim I'm not surprised
that these aren't already included.

> The spec is ambiguous as to whether the value is UTC or not, hence the
> need to be explicit. ​
While I agree, that is an issue for POSIX.

> ​That is your opinion, like the astronomers, you might just be wrong
> about the requirements.
>
> I can see the benefit of an IoT where time is absolutely predictable
> even if it may be out of sync with UT by a few seconds.​
For every reason you want PIT, we can already use TAI.

> You might not but I doubt you have the range of experience in realtime
> and process control that I have.
>
> ​Unless a device actually deals in time, PIT is going to be just fine
> for status messages and logs. The advantage over UTC being that you
> know exactly what the device is trying to do which you don't have with
> UTC. You don't know whether the device is keeping UTC or some heuristic.
>
> track time by date and need to compare. The difference between UTC and
> TAI is half a minute which is just too much to be viable.​

Any difference between the current date and UTC renders everything that
interacts with the real world incorrect.

>>     ​2) No I did not move the goalposts. My original proposal was to
>>     solve the needless chaos caused be the idiotic notion of changing
>>     the definition of time at six months notice. The stupidity of
>>     that notion should be apparent to all.
>
>     There is no getting around the fact that the rest of the planet
>     accepts leap seconds. If that's not something you want to track,
>     then use TAI and be off-sync with the rest of the world when they
>     use UTC.
>
>
That's true, but the organizations that pick times scales are not the
IETF. We use standards others manage in that regard, exactly because
we're not special - either time is largely local (in which case it
doesn't matter) or you need to interact with the rest of the world,
which agreed on UTC.

> The reason UTC is the standard is because it is what the ITU decided
> to use and the broadcasters synchronize everything. That can change.

OK, then let us know when any government picks PIT.

Until then, though, the Internet should not be picking something
different when there are already current standards that are sufficient.

Joe

---

From: Izaac <[email-masked]>
Date: Sat, 22 Apr 2017 11:18:39 -0400

>"All leap seconds are abolished. UTC = TAI +37 for all future dates."

Awesome. So code that up, deploy it, and get back to us with the results and a proposal in 2047.

-- 
Izaac