Subject: Re: Predictable Internet Time

From: [email-masked]
Date: Sun, 01 Jan 2017 10:58:54 -0500

The (human) universe has competing time standards.  How much of
this problem is mitigated by time services?  I mean, if every device
that cared about a common time was kept in synch by timeservers, and
all the timeservers updated together, wouldn't that fix the problem? 
if so, the problem is really that not everything has access to
timeservers.  Many devices aren't always on the net, and when they
are they have better things to spend bandwidth on than constant time
updates.
   How much of this problem can be solved by better time services,
and how much of the problem cannot be?

Sandy Wills
interested lurker

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To:"IETF Discussion Mailing List" <[email-masked]>
Cc:
Sent:Sat, 31 Dec 2016 16:32:20 -0500
Subject:Predictable Internet Time

Well the astronomers are at it again. They are messing about with time
which is a terrible idea. Specifically they are adding another leap
second.
There are many arguments against leap seconds and the arguments in
favor really amount to the astronomers declaring that they are going
to rub our noses in it for as long as we let them. So here is an
alternative proposal.
The single biggest problem with UTC is that the decisions to add
seconds are made by a committee a few months in advance of the change.
And this results in time becoming unpredictable because it is never
possible to know if we are dealing with a corrected or uncorrected
time. For this reason, I have been using TAI as the basis for time
representation in my recent protocol proposals. This reduces but does
not eliminate the confusion.
Leap seconds occur at a rate of roughly ten per 25 years. So not
correcting means a drift of 40 seconds over a century

So to remove the confusion entirely, while preventing the need for a
discontinuous adjustment of the drift between UTC and TAI, I propose
the Predictable Internet Time (PIT) as follows.
PIT = TAI + delta (y) where
Where Delta (y) = int (37 + 0.4 * (y -2016) ) for y < 2116= 77 +
(UTC-Delta (y-100))
For values above 2116, PIT would make use of the table of UTC
corrections with a delay of one century. This would enable
manufacturers to build devices with built in correction tables for a
design life of one century which should meet everyone's needs except
Danny Hillis who is building a clock anyway.

A conversion to PIT would be feasible for most governments as it is
highly unlikely that the variance between UTC and PIT would ever be
greater than a few seconds.
The big problem with planning such a transition in the past is that
the alternatives on the table have been stopping further leap seconds
completely and continuing the UTC scheme. That would be a recipe for
disaster unless the EU and US both adopted TAI+36 seconds or whatever.
We could end up with a situation in which one side digs in its heels,
refuses to change and we end up with a 'give us back our eleven days'
type correction.
Nor is changing the definition of UTC to effect simultaneous change a
feasible solution because to do so would be to demand the astronomers
accept a diminution in their own prestige.
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.
While a variance of a second or three between New York and London
might be inconvenient, the inconvenience is going to be a lot worse
for the side not using PIT who have all the inconvenience of
unpredictable leap seconds plus the inconvenience of the difference.
The pressure on other governments to adopt PIT over is going to be
significant. It is hard to see that there would be any real
constituency for the UTC approach, the astronomers are much more
interested in buying telescopes than time in any case.

We could tweak the definition so that the corrections kick in sooner
but it should be possible to build for a minimum of a fifty year
service life.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 1 Jan 2017 14:24:18 -0500

There are two separate problems

The first problem is that every machine has a common understanding of the
current instant in time. In Windows as in UNIX, this is represented as the
number of seconds that have elapsed since a particular fixed date and time.

The main issues there are precision and extent. The original UNIX and
Windows time used 32 bit integers representing seconds. These have been
replaced with 64 bit representations expressed in ticks. For example, in
Windows:

ticksType: System.Int64
<https://msdn.microsoft.com/en-us/library/system.int64(v=vs.110).aspx>

A date and time expressed in the number of 100-nanosecond intervals that
have elapsed since January 1, 0001 at 00:00:00.000 in the Gregorian
calendar.
The second problem is the representation of time. That is the conversion to
a human readable form. And this is complicated by the fact that many
systems use human readable forms for communication between machines and
many of those systems fail when presented with a leap second.

Any code path that is only exercised for less than a second per year at
most is a code path that is unlikely to be properly tested. It is thus code
that is likely to fail.

This is one of the many reasons that leap seconds are such a terrible idea.
The other is that they are unpredictable. PIT is designed to deal with the
second problem.

To have a complete solution, the way forward would be to require systems
using PIT to use the 'time smear' approach that has been pioneered by
Akamai and is now used by Amazon, Google, etc. albeit in slightly different
and non standard ways.

Using time smearing, a program will never emit the time value 12:59:60 as
demanded by the standard. Instead the leap second is added to the machine
gradually over the course of 20 or 24 hours. This avoids the need to emit a
time value that could cause a system to fail at the cost of a modest
difference between the purported and actual value.

Oh and if you think leap seconds are bad in UTC, they are even worse when
the complications of time zones are considered. London, New York and
Mountain View all add leap seconds at slightly different times.

On Sun, Jan 1, 2017 at 10:58 AM, <[email-masked]> wrote:

>    The (human) universe has competing time standards.  How much of this
> problem is mitigated by time services?  I mean, if every device that cared
> about a common time was kept in synch by timeservers, and all the
> timeservers updated together, wouldn't that fix the problem?  if so, the
> problem is really that not everything has access to timeservers.  Many
> devices aren't always on the net, and when they are they have better things
> to spend bandwidth on than constant time updates.
>    How much of this problem can be solved by better time services, and how
> much of the problem cannot be?
>
> Sandy Wills
> interested lurker
>
>
> From:
> "Phillip Hallam-Baker" <[email-masked]>
>
> To:
> "IETF Discussion Mailing List" <[email-masked]>
> Cc:
>
> Sent:
> which is a terrible idea. Specifically they are adding another leap second.
>
> There are many arguments against leap seconds and the arguments in favor
> really amount to the astronomers declaring that they are going to rub our
> noses in it for as long as we let them. So here is an alternative proposal.
>
> The single biggest problem with UTC is that the decisions to add seconds
> are made by a committee a few months in advance of the change. And this
> results in time becoming unpredictable because it is never possible to know
> if we are dealing with a corrected or uncorrected time. For this reason, I
> have been using TAI as the basis for time representation in my recent
> protocol proposals. This reduces but does not eliminate the confusion.
>
> discontinuous adjustment of the drift between UTC and TAI, I propose the
> Predictable Internet Time (PIT) as follows.
>
> Where Delta (y) = int (37 + 0.4 * (y -2016) ) for y < 2116
> = 77 + (UTC-Delta (y-100))
>
> For values above 2116, PIT would make use of the table of UTC corrections
> with a delay of one century. This would enable manufacturers to build
> devices with built in correction tables for a design life of one century
> which should meet everyone's needs except Danny Hillis who is building a
> clock anyway.
>
>
> A conversion to PIT would be feasible for most governments as it is highly
> unlikely that the variance between UTC and PIT would ever be greater than a
> few seconds.
>
> The big problem with planning such a transition in the past is that the
> alternatives on the table have been stopping further leap seconds
> disaster unless the EU and US both adopted TAI+36 seconds or whatever. We
> could end up with a situation in which one side digs in its heels, refuses
> to change and we end up with a 'give us back our eleven days' type
> correction.
>
> 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.
>
> While a variance of a second or three between New York and London might be
> inconvenient, the inconvenience is going to be a lot worse for the side not
> using PIT who have all the inconvenience of unpredictable leap seconds plus
> the inconvenience of the difference. The pressure on other governments to
> adopt PIT over is going to be significant. It is hard to see that there
> would be any real constituency for the UTC approach, the astronomers are
> much more interested in buying telescopes than time in any case.
>
>
> We could tweak the definition so that the corrections kick in sooner but
> it should be possible to build for a minimum of a fifty year service life.
>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 2 Jan 2017 22:11:26 -0800

On 1/1/2017 11:24 AM, Phillip Hallam-Baker wrote:
> To have a complete solution, the way forward would be to require
> systems using PIT to use the 'time smear' approach that has been
> pioneered by Akamai and is now used by Amazon, Google, etc. albeit in
> slightly different and non standard ways.
>
> Using time smearing, a program will never emit the time value 12:59:60
> as demanded by the standard. Instead the leap second is added to the
> machine gradually over the course of 20 or 24 hours. This avoids the
> need to emit a time value that could cause a system to fail at the
> cost of a modest difference between the purported and actual value.

Smearing leads to differing interpretations of elapsed time for two reasons:

1) smearing isn't unambiguously specified
2) smearing doesn't match the clock standards set by the ITU (who
defines UTC)

A "complete" solution would have several properties:

- it would always indicate the correct UTC time
- it would calculate time differences accurately

There's no clear reason why that solution can't be split into parts,
e.g., using Unix time to calculate time differences and a (complex)
converter to deal with UTC leap seconds.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 01:24:09 -0500

Umm, my proposal was to ignore the opinion of the ITU in this matter as in
everything else.

They can define UTC how they like. I want something that works robustly and
predictably with no requirements to update tables of leap seconds.

And by robustly, I certainly do not mean people have to test corner cases
that will occur one time in 50 million.

On Tue, Jan 3, 2017 at 1:11 AM, Joe Touch <[email-masked]> wrote:

> 2) smearing doesn't match the clock standards set by the ITU (who defines
> UTC)
>
> There's no clear reason why that solution can't be split into parts, e.g.,
> using Unix time to calculate time differences and a (complex) converter to
> deal with UTC leap seconds.
>
> Joe
>

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 03 Jan 2017 07:29:26 +0100

There are a number of complicating factors here. One being that we have multiple time scales. Another being that parties do believe things are what they really are.

The main issue with smearing is that UNIX time is really not counting number of seconds from the epoch, which might be what people think. If it was, smearing would not be a good thing as the number of seconds from the epoch ends up being one less due to the smear than the continuous series of SI-Seconds. The number of seconds is guessing that each day have the same number of seconds. So leap seconds are ignored.

Instead the goal with the smear is only to be correct according to UTC.

A correct implementation would of course be to have the number of seconds from Jan 1 1970 be correct, and then a correct translation to UTC. Which requires (both) knowledge of the number of leap seconds -- which you only know for each 6 month interval (sort of). So one do not know the translation between number of seconds since epoch and UTC if you look say 3 years forward in time.

I think personally, as long as we do have leap seconds:

- we should have the leap second information available somewhere in clear machine readable format. Some suggestions exists, including encoding it in A-records in DNS ;-)

- we should look at having the time since epoch really be the number of SI-seconds since the epoch

- we should have translation between number of seconds and UTC take leap seconds into account

- we should fix the code that do not accept 61 seconds in a minute

Now, we can also say we should stop having leap seconds, but I feel that is a _different_ matter and different discussion. I am myself not clear over what is the correct thing regarding leap seconds.

What I am sure of is that I think most of the problems we have is because of bad programming (including in old UNIX days the priorities although correct at the time have continued to let the time_t definition continue to be wrong).

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Tue, 3 Jan 2017 07:43:05 +0100

Good morning, Patrik,

> - we should have translation between number of seconds and UTC take leap seconds into account

The TZDB at IANA contains the file "leapseconds" which is machine
readable, and provides a history of all leapseconds.  This provides you
the 1st and 3rd of your requirements.
> What I am sure of is that I think most of the problems we have is because of bad programming (including in old UNIX days the priorities although correct at the time have continued to let the time_t…

I'm of two minds as well.  On the one hand, the current system makes it
quite easy to do the wrong thing, and that's not good.  There are
utility functions such as pytz's normalize() and localize() functions
that people just don't know about, for instance.  On the other hand,
it's not just leap seconds.  It's timezones in general, it's DST
transitions, etc.  Getting rid of leap seconds only marginally improves
things, and gets really philosophical really quickly...

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 03 Jan 2017 07:59:03 +0100

On 3 Jan 2017, at 7:43, Eliot Lear wrote:

> The TZDB at IANA contains the file "leapseconds" which is machine readable, and provides a history of all leapseconds.  This provides you the 1st and 3rd of your requirements.

What is important is that the file include also known future leap seconds (and not) like the official memo. So that one can prep the local system with some predictability for the next say 5 months.

Maybe it does. My apologies for being lazy.

> I'm of two minds as well.  On the one hand, the current system makes it quite easy to do the wrong thing, and that's not good.  There are utility functions such as pytz's normalize() and localize() functions that people just don't know about, for instance.  On the other hand, it's not just leap seconds.  It's timezones in general, it's DST transitions, etc.  Getting rid of leap seconds only marginally improves things, and gets really philosophical really quickly...

The problem I have is that we now implement things like smearing which to me is a bad fix for something that is wrong in the first place (definition of time_t).

   paf

---

From: Eliot Lear <[email-masked]>
Date: Tue, 3 Jan 2017 08:25:30 +0100

Hi Patrik,

> Maybe it does. My apologies for being lazy.

IERS always issues the bulletins at least five months in advance of a
leap second, but generally not more than six (in one instance they
released an announcement just under five months in advance of NO leap
second).  At that point it is a matter of where we are with the TZ
release cycle, but I think the maintainer (Paul, CC'd) does tend to give
it some priority.

Eliot

---

From: Tony Finch <[email-masked]>
Date: Tue, 3 Jan 2017 14:08:21 +0000

> 2) smearing doesn't match the clock standards set by the ITU (who

Since leap smear is becoming more popular, it would be sensible to try to
get a consensus on the best way to do it if you do it. Clearly
organizations that do leap smear think (2) leap seconds are too much
trouble so it's better to diverge from official time in a controlled
manner.

To clear up (1) there are a few technical choices on which people seem to
be working towards some kind of agreement...

* If you centre the smear period over the leap second, your maximum error
  from UTC is 0.5s, which seems to be preferable to starting or ending the
  smear period on the leap second

* Linear smear works better than sigmoid smear, since it minimizes the
  rate divergence for a given smear period, and NTP's algorithms react
  better

* Longer smear periods are better, because they give NTP more time to
  react to the rate change, and they minimize the rate difference

It looks to me like a 24h leap smear from 12:00 UTC before the leap to
12:00 UTC after the leap has a good chance of becoming more popular than
other leap smear models.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames: West 5 to 7, veering northwest 6 to gale 8, perhaps severe
gale 9 later in Humber. Moderate or rough, occasionally very rough, becoming
high at times later in Humber. Rain then showers. Moderate or good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 11:33:14 -0500

I agree with most of what Patrik is saying. With one major difference, The
deviations file needs to be signed because it is a security issue.

And once you sign the file, the next question is... by whom.

I would much rather eliminate unnecessary trust dependencies than
perpetuate them.

Use of time zones at the protocol level is generally an option. XML Schema
uses UTC. Most implementations of IETF protocols use either UTC or UTC with
a numeric offset.

So it is an issue but mostly a UI issue rather than a security issue. It is
still necessary to have a signed table of the expected changes though
because agreeing to meet once a week at 10:00 London Time is not the same
as agreeing to meet once a week at 10:00 UTC+0 due to the fact that there
will be summer time half the year. A person in New York may attend meetings
in London and so the adjustments need to be known globally.

Contrary to what the calendar people tell me, these issues are not
'difficult'. What is difficult is using programs that make unfounded
assumptions about the adjustments to apply rather than letting these be set
by the user.

On Tue, Jan 3, 2017 at 1:29 AM, Patrik Fältström <[email-masked]> wrote:

> There are a number of complicating factors here. One being that we have
> multiple time scales. Another being that parties do believe things are what
> they really are.
>
> The main issue with smearing is that UNIX time is really not counting
> number of seconds from the epoch, which might be what people think. If it
> was, smearing would not be a good thing as the number of seconds from the
> epoch ends up being one less due to the smear than the continuous series of
> SI-Seconds. The number of seconds is guessing that each day have the same
> number of seconds. So leap seconds are ignored.
>
> A correct implementation would of course be to have the number of seconds
> from Jan 1 1970 be correct, and then a correct translation to UTC. Which
> requires (both) knowledge of the number of leap seconds -- which you only
> know for each 6 month interval (sort of). So one do not know the
> translation between number of seconds since epoch and UTC if you look say 3
> years forward in time.
>
> - we should have the leap second information available somewhere in clear
> machine readable format. Some suggestions exists, including encoding it in
> A-records in DNS ;-)
>
> Now, we can also say we should stop having leap seconds, but I feel that
> is a _different_ matter and different discussion. I am myself not clear
> over what is the correct thing regarding leap seconds.
>
> What I am sure of is that I think most of the problems we have is because
> of bad programming (including in old UNIX days the priorities although
> correct at the time have continued to let the time_t definition continue to
> be wrong).
>
>    Patrik
>

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Jan 2017 12:03:29 -0500

Hi Phillip,

--On January 3, 2017 at 11:33:14 AM -0500 Phillip Hallam-Baker 
<[email-masked]> wrote:

> assumptions about the adjustments to apply rather than letting these be
> set by the user.
>

Speaking as a "calendar" person - yes it is difficult but those 
difficulties are well understood and we have options in place for dealing 
with them. In particular, the tzdist protocol (RFC7808) provides an option 
for a more automated way to distribute the IANA tz data - including leap 
seconds. Leveraging that technology (with some additions for added security 
if needed) might be an option.

-- 
Cyrus Daboo

---

From: Jared Mauch <[email-masked]>
Date: Tue, 3 Jan 2017 12:07:38 -0500

I'd be interested to see your proposal in the NTP WG, at Chicago or earlier. 

I agree this is an area where there is need for improvement and assistance is welcome. 

Jared Mauch

> On Dec 31, 2016, at 4:32 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Well the astronomers are at it again. They are messing about with time which is a terrible idea. Specifically they are adding another leap second.
> 
> There are many arguments against leap seconds and the arguments in favor really amount to the astronomers declaring that they are going to rub our noses in it for as long as we let them. So here is an alternative proposal.
> 
> The single biggest problem with UTC is that the decisions to add seconds are made by a committee a few months in advance of the change. And this results in time becoming unpredictable because it is never possible to know if we are dealing with a corrected or uncorrected time. For this reason, I have been using TAI as the basis for time representation in my recent protocol proposals. This reduces but does not eliminate the confusion.
> 
> Leap seconds occur at a rate of roughly ten per 25 years. So not correcting means a drift of 40 seconds over a century
> 
> 
> So to remove the confusion entirely, while preventing the need for a discontinuous adjustment of the drift between UTC and TAI, I propose the Predictable Internet Time (PIT) as follows.
> 
> For values above 2116, PIT would make use of the table of UTC corrections with a delay of one century. This would enable manufacturers to build devices with built in correction tables for a design life of one century which should meet everyone's needs except Danny Hillis who is building a clock anyway.
> 
> 
> A conversion to PIT would be feasible for most governments as it is highly unlikely that the variance between UTC and PIT would ever be greater than a few seconds.
> 
> The big problem with planning such a transition in the past is that the alternatives on the table have been stopping further leap seconds completely and continuing the UTC scheme. That would be a recipe for disaster unless the EU and US both adopted TAI+36 seconds or whatever. We could end up with a situation in which one side digs in its heels, refuses to change and we end up with a 'give us back our eleven days' type correction.
> 
> Nor is changing the definition of UTC to effect simultaneous change a feasible solution because to do so would be to demand the astronomers accept a diminution in their own prestige.
> 
> 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.
> 
> While a variance of a second or three between New York and London might be inconvenient, the inconvenience is going to be a lot worse for the side not using PIT who have all the inconvenience of unpredictable leap seconds plus the inconvenience of the difference. The pressure on other governments to adopt PIT over is going to be significant. It is hard to see that there would be any real constituency for the UTC approach, the astronomers are much more interested in buying telescopes than time in any case.
> 
> 
> We could tweak the definition so that the corrections kick in sooner but it should be possible to build for a minimum of a fifty year service life.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Jan 2017 17:27:21 +0000

Smearing worries me.

If you have an application where tiny fractions of a second make no 
difference, then
a slow smear is a good approximation to no leap second.

However, there are some highly accurate implementations of NTP, and some 
highly
sensitive applications that use it, and having a long term interval 
error, which is what
happens during a smear, is harmful to those applications.

It seems to me that it might be better to freeze NTP on the current leap 
second
offset. Provide the current leap second offset to the application as a 
parameter
and let the application deal with it as it chooses.

- Stewart

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 12:27:50 -0500

I will write up a draft.

However, I'm not the inventor of time smearing, perhaps someone doing that
would want to work with me.

Looking at the problem of time smear, I think Google's 20 hour as opposed
to 24 hours approach is probably best. Most platforms use ticks (100
nanosecs on Windows). Using 20 hours means that each increment is exactly
even. Using 24 means that they are going to be slightly irregular and can
lead to variation.

The problem here is not so much the adjustments themselves but knowing
whether an adjustment has been applied or not. If there are two parties can
apply an adjustment, it is very common to see 0, 1 and 2 parties make it.

For any scientific data, times should use TAI and be done. Leap seconds
have no place in the physical sciences, astronomy included. Using UTC in
science is as barbarous as using imperial over metric.

Another related 'best practice' issue is that we should stop scheduling
flag days for midnight on 1st jan. The Internet protocol layer does not
have flag days but the WebPKI does and we need them because we regularly
phase out algorithms. SHA-1 stopped working when 2017 began in Edinburgh.
There is actually a very good reason for that first Thursday after the
first Monday business.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 12:42:42 -0500

Agree 100%

Hence my proposal for supporting multiple time scales for different
purposes:

1) TAI: Use this and only this for any and all purposes that involve
recording the time an event took place. Including forensic and scientific
purposes.

2) PIT: Use this for inter-machine communications. It may also be used to
present TAI in a human readable form because the mapping from TAI to PIT is
fixed.

3) Local Time Zones: For human display purposes

>From the conversation it seems that the best definition for PIT would be

PIT = TAI  + Smear ( Lag (UTC, 50 years ))

On Tue, Jan 3, 2017 at 12:27 PM, Stewart Bryant <[email-masked]>
wrote:

> sensitive applications that use it, and having a long term interval error,
> which is what

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Jan 2017 13:03:13 -0500

Hi Phillip,

--On January 3, 2017 at 12:42:42 PM -0500 Phillip Hallam-Baker 
<[email-masked]> wrote:

> present TAI in a human readable form because the mapping from TAI to PIT
> is fixed.
>

Please note that local time is needed not just for human display purposes 
but also for handling recurring events that are "anchored" to a local time. 
e.g., you want your thermostat to turn on at 6pm local time every day, but 
that has to account for daylight saving time changes etc. Thus when 
defining future data/time values, often (local time & time zone id) is 
required and must be part of the data interchange between devices. Thus the 
need to keep devices up to date with time zone changes (which was the 
primary impetus for the tzdist RFC7808 work).

-- 
Cyrus Daboo

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 10:23:56 -0800

+1

You can deny the ITU all you want, but we are not in control of the time
standards used by financial, governmental, etc. systems.

Note that everything below also assumes a consistent view of time
itself; conversion from "seconds since epoch measured locally" always
needs to be translated to UTC at sea level on Earth anyway.

Time within the machine should be measured relative to its own temporal
frame, but whenever we communicate with another machine we need to
strive to be as close to UTC as possible - warts and all. Anything else
- including and especially smearing - compromises *correct* behavior.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Jan 2017 18:25:13 +0000

On 03/01/2017 17:42, Phillip Hallam-Baker wrote:
> recording the time an event took place. Including forensic and 
> scientific purposes.
>
> 2) PIT: Use this for inter-machine communications. It may also be used 
> to present TAI in a human readable form because the mapping from TAI 
> to PIT is fixed.

It would, in my view, be better to use TAI for all inter-machine 
communications, and then allow applications that care, including 
non-scientific display of time to run the PIT algorithm locally.

There was a draft that I think Yaakov Stein and I wrote in the early 
days of TICTOC distinguishing transferred time from presentation time.

As far as I can see the only application that needs the PIT adapted 
version of time is an astronomers wall clock, after all most humans live 
with an error of an 0..2 hours between local astronomical time and the 
time-zone time, and most machines would be quite happy to live with what 
ever time they are using with no further leap seconds.

- Stewart

> On Tue, Jan 3, 2017 at 12:27 PM, Stewart Bryant 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Smearing worries me.
>
>     If you have an application where tiny fractions of a second make
>     no difference, then
>     However, there are some highly accurate implementations of NTP,
>     and some highly
>     sensitive applications that use it, and having a long term
>     interval error, which is what
>     It seems to me that it might be better to freeze NTP on the
>     current leap second
>     offset. Provide the current leap second offset to the application
>     as a parameter
>         Joe Touch <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 10:25:48 -0800

We really need to separate the frames of reference of time - there's no
need for smear for internal "seconds since epoch" time. Smear only
renders UTC values incorrect,, which is an invitation to have financial
and legal transactions fail and report local events (e.g., rates, etc.)
incorrectly.

We shouldn't propagate an incorrect solution.

Joe

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Jan 2017 18:30:19 +0000

On 03/01/2017 18:03, Cyrus Daboo wrote:
>> scientific
> Please note that local time is needed not just for human display 
> purposes but also for handling recurring events that are "anchored" to 
> a local time. e.g., you want your thermostat to turn on at 6pm local 
> time every day, but that has to account for daylight saving time 
> changes etc. Thus when defining future data/time values, often (local 
> time & time zone id) is required and must be part of the data 
> interchange between devices. Thus the need to keep devices up to date 
> with time zone changes (which was the primary impetus for the tzdist 
> RFC7808 work).
>

Only the UI needs the TZ information, the machine can operate just fine 
with any timescale. That is you present the time in local time, but 
operate in global time, and this is definitely an application that will 
not care about leap seconds.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Jan 2017 18:35:03 +0000

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.

- Stewart

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Jan 2017 13:38:45 -0500

Hi Stewart,

> not care about leap seconds.

No that simply does not work. Repeating events or alarms may not involve 
any UI at all, but the device may need to trigger those at a specific local 
time - that means time zone information has to be taken into account 
somewhere. This is a crucial fact of any calendaring and scheduling system 
that those of us who have been using iCalendar (RFC5545) fully appreciate.

-- 
Cyrus Daboo

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 13:39:37 -0500

> standards used by financial, governmental, etc. systems.

​Neither is the ITU. The governments, financial services etc are.

An ITU standard that predictably causes confusion and chaos every year is
ripe for replacement.​

> - including and especially smearing - compromises *correct* behavior.

​So you are for sticking with IPv4 as well?

Nothing can ever change because the ITU is in charge...​

​People are only in charge as long as other people let them. ​

> > - we should have the leap second information available somewhere in
> clear machine readable format. Some suggestions exists, including encoding
> it in A-records in DNS ;-)
> >

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Jan 2017 13:51:54 -0500

On Jan 3, 2017, at 1:38 PM, Cyrus Daboo <[email-masked]> wrote:
> No that simply does not work. Repeating events or alarms may not involve any UI at all, but the device may need to trigger those at a specific local time - that means time zone information has to be taken into account somewhere. This is a crucial fact of any calendaring and scheduling system that those of us who have been using iCalendar (RFC5545) fully appreciate.

This is true, but any specific local time will always occur at a specific universal time, so this isn't actually a problem.

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Jan 2017 18:55:33 +0000

On 03/01/2017 18:38, Cyrus Daboo wrote:
> No that simply does not work. Repeating events or alarms may not 
> involve any UI at all, but the device may need to trigger those at a 
> specific local time - that means time zone information has to be taken 
> into account somewhere. This is a crucial fact of any calendaring and 
> scheduling system that those of us who have been using iCalendar 
> (RFC5545) fully appreciate.
>

Hi Cyrus,

I think that depends on what you consider to be the infrastructure and 
what you consider the application. I would like to see the CPU clocks, 
and in particular  the time transfer protocols just work on non-jumpy 
constant-duration-second time since that has to scale from 
sub-femtoseconds to millennia with sub-femtosecond accuracy without 
glitching and with unambiguous duration measurements.

If we distribute time in the infrastructure as  non-jumpy 
constant-duration-second time , then the iCal system can surely do the 
conversion to/from whatever format the human needs? Whether it talks to 
itself in human time or machine time is for those of you that design 
iCal to determine, but it sounds from what you say that it talks to 
itself in human time. Whether it does the conversion from machine time 
to human time, or whether the OS does it for outside the scope of the 
point I am making.

- Stewart

---

From: Eliot Lear <[email-masked]>
Date: Tue, 3 Jan 2017 20:03:23 +0100

On 1/3/17 7:24 AM, Phillip Hallam-Baker wrote:
> Umm, my proposal was to ignore the opinion of the ITU in this matter
> as in everything else.

That doesn't work in all cases because there are often applications that
require that the clock time on a device not vary from UTC by some set
amount.  I think they're fixing for a big UTC leap second shindig in the
next few years, anyway.

Eliot

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 11:10:14 -0800

On 1/3/2017 10:39 AM, Phillip Hallam-Baker wrote:
>
>
> On Tue, Jan 3, 2017 at 1:23 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     +1
>

They nearly universally use UTC, which is managed by the ITU. Many
countries contribute their national time references to the TAI average,
to which the ITU adds leapseconds to derive UTC.

FWIW, GPS uses TAI and broadcasts the delta to UTC in its messages, and
even TAI messages are indicated in reference to UTC.

Joe

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Jan 2017 14:24:48 -0500

--On Tuesday, January 3, 2017 20:03 +0100 Eliot Lear
<[email-masked]> wrote:

>> Umm, my proposal was to ignore the opinion of the ITU in this
>> matter as in everything else.
> 
> That doesn't work in all cases because there are often
> applications that require that the clock time on a device not
> vary from UTC by some set amount.  I think they're fixing for
> a big UTC leap second shindig in the next few years, anyway.

Also, FWIW, UTC is a CCIR/ITU-R specification, not an ITU-T one.
If one wanted to claim that we ignore the opinion of the latter,
it would still be hyperbole, but perhaps understandable.  If we
were to start ignoring ITU-$ recommendations, a good deal of our
Layer 1 and 2 infrastructure would stop working.  I assume that
is not considered a desirable outcome independent of the
discussions we are having about time.

   john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 14:46:44 -0500

On Tue, Jan 3, 2017 at 2:03 PM, Eliot Lear <[email-masked]> wrote

> amount.  I think they're fixing for a big UTC leap second shindig in the

​My analysis of the politics of the situation is as follows

* The decision makers are the governments, not the ITU

*​ The governments will do whatever their banking and broadcast sectors
tell them.

* The banking and broadcast sections will do whatever Microsoft, Google,
Apple, etc agree on provided that the transition is not going to be more of
a problem than the status quo.

​* If ​there is a non ITU proposal on the table that threatens to replace
ITU as the place where the decision is taken that stands a chance of being
adopted, ITU will prefer to co-opt it rather than lose the appearance of
control.

We already have UT0, UT1 and UT2 and several other variants. The mapping
from UT1 to UTC can be varied by committee.

---

From: Pete Resnick <[email-masked]>
Date: Tue, 3 Jan 2017 13:49:42 -0600

On 3 Jan 2017, at 12:55, Stewart Bryant wrote:

>> specific local time - that means time zone information has to be 
>> taken into account somewhere. This is a crucial fact of any 
>> calendaring and scheduling system that those of us who have been 
>> using iCalendar (RFC5545) fully appreciate.
>>
>
> Hi Cyrus,
>
> what you consider the application.

I think you and Cyrus are disagreeing about the definition of "UI". 
Maybe "application" is better. At some point in the flow of things, a 
system that is going to interact with humans, whether it presents a UI 
on a screen or turns on a beeper or flips a relay that starts a 
sprinkler system, is going to have to know the current civil time for 
the action it is performing, and that's going to have to be machine 
calculated.

> I would like to see the CPU clocks, and in particular  the time 
> transfer protocols just work on non-jumpy constant-duration-second 
> time since that has to scale from sub-femtoseconds to millennia with 
> sub-femtosecond accuracy without glitching and with unambiguous 
> duration measurements.
>
> conversion to/from whatever format the human needs? Whether it talks 
> to itself in human time or machine time is for those of you that 
> design iCal to determine, but it sounds from what you say that it 
> talks to itself in human time. Whether it does the conversion from 
> machine time to human time, or whether the OS does it for outside the 
> scope of the point I am making.

Agree, but note the dependency: calendaring depends on some other entity 
to get the agreed universal time, and then it can do a conversion based 
on the time zone database information.

On 3 Jan 2017, at 12:51, Ted Lemon wrote:

> This is true, but any specific local time will always occur at a 
> specific universal time, so this isn't actually a problem.

Oh? Which specific universal time corresponds to 6pm local time on July 
1 2020 in Urbana, IL? It *will* occur at a specific universal time, but 
it does not *now* occur at a specific universal time, because Illinois 
can always change the law which tells you what "6pm local time on July 
1" means.

None of this is an unsolvable problem; we just need to be clear that at 
some point (and likely at many points), the computer is going to have to 
calculate a civil time from whatever agreed universal time you have, and 
it's not just "to present to the user at this particular moment".

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 03 Jan 2017 14:54:47 -0500

Hi Ted,

--On January 3, 2017 at 1:51:54 PM -0500 Ted Lemon <[email-masked]> wrote:

>> any UI at all, but the device may need to trigger those at a specific
>> local time - that means time zone information has to be taken into
>> account somewhere. This is a crucial fact of any calendaring and
> This is true, but any specific local time will always occur at a specific
> universal time, so this isn't actually a problem.

No! That is not true because a future local time is not guaranteed to be at 
a specific universal time because local government can change their time 
zone (or more likely) their daylight savings time transition at any time 
between now and said future time. i.e., you cannot "pre-cache" all the 
local time -> UTC mappings for a future recurring event and then just use 
the UTC values, because the time zone definition may change.

-- 
Cyrus Daboo

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 12:01:37 -0800

You might consider that most governments have already agreed to
cooperate - by contributing their national clock info to TAI, accepting
the TAI-averaged result, and accepting the ITU's definition of UTC.

I see no good reason to create a new time reference that would still
ultimately need translation to TAI and UTC anyway, esp. given the
translation would be complex on the smear-day.

Joe

On 1/3/2017 11:46 AM, Phillip Hallam-Baker wrote:
> On Tue, Jan 3, 2017 at 2:03 PM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote
>
>     applications that require that the clock time on a device not vary
>     from UTC by some set amount.  I think they're fixing for a big UTC
>     leap second shindig in the next few years, anyway.
>
>     Eliot
>
>
> *​ The governments will do whatever their banking and broadcast
> sectors tell them.
>
> * The banking and broadcast sections will do whatever Microsoft,
> Google, Apple, etc agree on provided that the transition is not going
> to be more of a problem than the status quo.
>
> ​* If ​there is a non ITU proposal on the table that threatens to
> replace ITU as the place where the decision is taken that stands a
> chance of being adopted, ITU will prefer to co-opt it rather than lose
> the appearance of control.
>
>
> We already have UT0, UT1 and UT2 and several other variants. The
> mapping from UT1 to UTC can be varied by committee.
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 15:06:57 -0500

+1

Case in point, the time displayed on my Honda Oddy does not correct for
daylight savings correctly because some pimple brain decided to vary the
date of the switchover and there is no way to update the firmware without
spending stupid amounts of money to do so.

This is the sort of thing I would like to be able to avoid in IoT. The
problem being that to do so requires vendors to think about problems as
something other than an excuse to sell a 'pro' version or updates.

One of the things that is really odd about time as a social construct is
just how easy it is to tamper with it. And 95% of the reason people do
tamper has nothing to do with purported benefits, it is to show that they
can.

When the UK went on to permanent summer time for a brief period, accidents
shot up in the mornings which is the only effect that can be attributed to
the change. The accident rate was reduced by more in the evenings but
subsequent analysis showed that the effect was due to drink driving being
banned at the same time.

The definition of time has always been driven by technology, Railway time
is the reason we have time zones in the first place. Solar noon at
Greenwich varies by +/- 15 minutes over the year.

Not being able to predict with accuracy when a future time expressed in
civil time will occur is a problem.

On Tue, Jan 3, 2017 at 2:54 PM, Cyrus Daboo <[email-masked]> wrote:

> No! That is not true because a future local time is not guaranteed to be
> at a specific universal time because local government can change their time

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 15:09:37 -0500

What governments decide, governments can undecide.

To take contribution to TAI as endorsement of UTC as ineluctable perfection
and thus the impossibility of changing it ever is a silly argument to make.

On Tue, Jan 3, 2017 at 3:01 PM, Joe Touch <[email-masked]> wrote:

> You might consider that most governments have already agreed to cooperate
> - by contributing their national clock info to TAI, accepting the
> TAI-averaged result, and accepting the ITU's definition of UTC.
>
>> Umm, my proposal was to ignore the opinion of the ITU in this matter as
>> in everything else.
>>
>>

---

From: Tony Finch <[email-masked]>
Date: Tue, 03 Jan 2017 20:21:58 +0000

"Phillip Hallam-Baker" <[email-masked]> wrote:

> to 24 hours approach is probably best.

Google plan to switch from 20h leap smear to 24h

https://developers.google.com/time/smear

Tony.

--

f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--
  zr8h punycode

---

From: Tony Finch <[email-masked]>
Date: Tue, 03 Jan 2017 20:34:49 +0000

Joe Touch <[email-masked]> wrote:

> need for smear for internal "seconds since epoch" time.

Well, the problem is that "seconds since the epoch" is not a count of
UTC seconds, it is a mapping from broken-down time to a linear time, and
the mapping is defined in a way that requires 86400 seconds per day and
does not accommodate leap seconds.

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

Leap smear exists mainly because "seconds since the epoch" does not
allow for leap seconds.

Tony.

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 13:21:06 -0800

> What governments decide, governments can undecide.

s/governments/IETF/

That's surely why the transition to IPv6 has happened so quickly.

>
> To take contribution to TAI as endorsement of UTC as ineluctable
> perfection and thus the impossibility of changing it ever is a silly
> argument to make.

I take it as active participation that endorses a common standard.

That's how standards work.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 13:25:40 -0800

On 1/3/2017 12:34 PM, Tony Finch wrote:
> UTC seconds,

Correct; it's UTC-(leap seconds since epoch start).

> it is a mapping from broken-down time to a linear time,

Seconds since epoch is as linear as it gets.

> and the mapping is defined in a way that requires 86400 seconds per
> day and does not accommodate leap seconds.

The conversion of epoch seconds to larger units is where the leap
seconds is counted.

A "day" as a unit of time is not exactly 86400 seconds (if it were, we
wouldn't need leap seconds).

> Leap smear exists mainly because "seconds since the epoch" does not

Seconds since epoch is unambiguous and linear.

It is in the conversion to other representations or aggregations where
leap seconds needs to be considered.

Joe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 16:57:10 -0500

The reason I think the 20 hour current scheme is better is this:

1 0.041666667 0.05
2 0.083333333 0.1
3 0.125 0.15
4 0.166666667 0.2
5 0.208333333 0.25
6 0.25 0.3
The second column is increments for the 24 hour change, the second for the
20 hour. As you can see, 24 hours means dealing with rounding. That is fine
for Internet apps but an unnecessary source of error for scientific.

Even if Google is converging, there should be coordination or else
different companies will converge in different ways. If the only advantage
of 24 over 20 is other people expect to do it that way, that is changeable.

One of the reasons I want this is to be able to define secure time for the
Mesh. The primary purpose of secure time is to be able to distribute a
monotonically increasing counter to nodes at separate locations and to
bound the need to store transaction IDs to guard against replay attacks.

I do not want to have to introduce a trusted party just to tell me the leap
second schedule so it can track the earth's rotation more precisely.

Instead, I want to fix the leap second schedule by means of a linear
approximation for the first 50 years and then by means of a table that is
calculated from the divergence between the UTC leap second schedule and the
PIT leap second schedule as follows

For y < 2057

PIT (y) = int (L(2016) + (y-2057)/2 )

For y >= 2057

PIT (y) = PIT (y-1) if (PIT (y-50) <= UTC (y-50))
            = PIT (y-1)+1 otherwise

With this scheme, the schedule for PIT leap seconds is always known in
advance for the next 50 years and will not diverge from UTC by more than 50
seconds unless the number of leap seconds added in a 50 year period exceeds
50.

The expected discrepancy between PIT and UTC is less than 8 seconds. Given
that solar noon varies by 1800 seconds over the course of a year, that is
near enough.

At the protocol level, I would expect trusted time providers to provide
trusted time and precise time separately. So if I have a time authority it
would issue a signed timestamp every minute on the minute and respond to
requests with an authenticated packet containing the signed timestamp, the
current time and the expected lag.

That way I can obtain a very high degree of trust that time X has passed
using NIST and the FSB as authorities and also set my clock for UI purposes.

Given the expiry of the Harber and Stornetta patent, signed timestamp
should include the prior signature in the output in an intelligent fashion
such as a Merkel tree.

---

From: Paul Eggert <[email-masked]>
Date: Tue, 3 Jan 2017 13:59:10 -0800

Eliot Lear wrote:
> I think the maintainer (Paul, CC'd) does tend to give it some priority.

Some priority, but not higher priority than other changes, and in
particular we don't necessarily generate a tz release immediately after
each IERS announcement.

For some perspective on this, here is a time line for the most recent
leap second:

1. 2016-07-06 announced by IERS

2. 2016-07-08 installed by NIST into
ftp://time.nist.gov/pub/leap-seconds.list

3. 2016-07-19 NIST file copied into the development repository at
https://github.com/eggert/tz/blob/master/leap-seconds.list

4. 2016-09-13 released as part of tzdb 2016g

5. 2016-12-31 leap second occurs

(2)'s date is estimated, as ftp://time.nist.gov/pub/leap-seconds.list is
a flaky FTP server mirror farm. Sometimes it works, sometimes it
doesn't. When it doesn't work, it doesn't work for what seems like days.
(It's been this way for years.) I got leap-seconds.list from someone
else who retrieved it (someone who I trusted).

We cannot use the IERS announcement directly in the tz database because
of copyright restrictions on the IERS files. We can use the NIST
leap-seconds.list file because it is in the public domain. The delay
between (1) and (2), and to some extent between (2) and (3), is due to
NIST. The delay between (3) and (4) is because there was no sense of
urgency until a few weeks before a predicted change - any
automated-update procedure that relies on tzdb should be able to turn
the crank in less than a month, because that's all the notice we often
get for time zone and daylight savings changes anyway.

I don't know why anyone would need more lead time for tzdb leap-second
updates (as opposed to time zone and DST updates). However, if there is
a need, they can get leap-seconds.list from the development repository
on GitHub, or from NIST if NIST is up, or simply by editing their
leap-seconds.list file by hand. It would be nice if leap-seconds.list
were distributed more reliably, of course.

---

From: Tony Finch <[email-masked]>
Date: Tue, 03 Jan 2017 22:33:14 +0000

> Seconds since epoch is as linear as it gets.

Except that that the number of leap seconds isn't constant, so it is
only superficially linear: there is a wrinkle at every leap second.

> wouldn't need leap seconds).

POSIX disagrees with you (and it is in denial about its agreement
with UTC).

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

:: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400

There's no allowance for the number of leaps since the epoch in that
specification.

Try the following (and sorry about the perl, but the date command isn't
portable enough). Note that the difference between the POSIX time_t
seconds since the epoch is 1s (...8800 - ...8799 == 1) but the elapsed
time was 2s.

$ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228799'

2016-12-31 23:59:59

$ perl -MPOSIX -e 'print strftime "%F %T\n", gmtime 1483228800'

2017-01-01 00:00:00

There is no distinct time_t value for 2015-12-31 23:59:60.

To make this message slightly more on-topic for this list, anyone who
cares about this subject should be aware that NTP timestamps work
exactly the same way as POSIX timestamps, except for a constant offset
between NTP time and POSIX time due to the different choice of epoch.
The relevant difference is that POSIX does not specify how leap seconds
are handled, whereas NTP has a couple of extra bits which allow the next
leap second to be transferred (in theory but often not in practice). NTP
also has no distinct timestamp value for the leap second, except if you
include the leap indicator bits.

Tony.

--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 3 Jan 2017 17:34:11 -0500

> were distributed more reliably, of course.
​As I said, I want 30-100 years lead time so I can bake the schedule into
devices and remove a trust dependency.​

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 03 Jan 2017 23:47:39 +0100

On 3 Jan 2017, at 20:10, Joe Touch wrote:

> They nearly universally use UTC, which is managed by the ITU.

UTC is managed by BIPM in Paris, based on the Metre Convention.

The governance of BIPM can be found here:

<http://www.bipm.org/en/about-us/governance/>

Leap seconds are defined by ITU-R, and decided upon by International Earth Rotation and Reference Systems Service (IERS). <https://www.iers.org/>

And possibly more pieces of the puzzle are needed.

So, "its complicated". ;-)

   Patrik

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 14:48:22 -0800

> only superficially linear: there is a wrinkle at every leap second.

Leap seconds are still seconds, which are counted in "seconds since epoch".

> POSIX disagrees with you (and it is in denial about its agreement with
> UTC).
>
> > >

Denial is not just a river in Egypt ;-)

>
> Try the following (and sorry about the perl, but the date command
> isn't portable enough). Note that the difference between the POSIX
> time_t seconds since the epoch is 1s (...8800 - ...8799 == 1) but the
> elapsed time was 2s.
>

In would presume that the same code would generate a time that is one
second behind UTC right now.

I.e., the Posix code is incorrect in claiming it reports UTC.

> The relevant difference is that POSIX does not specify how leap
> seconds are handled, whereas NTP has a couple of extra bits which
> allow the next leap second to be transferred (in theory but often not
> in practice). NTP also has no distinct timestamp value for the leap
> second, except if you include the leap indicator bits.

NTP reports seconds since epoch; it is in the conversion of that value
to display time that the issue of leap seconds comes into play. In that
case, some systems report 59-59-00 and others 59-00-00, i.e, repeating a
UTC value to account for the leap second in the human-readble output.
Internally, the number of seconds which have passed is correct and
include the leap second.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 14:55:01 -0800

> So, "its complicated". ;-)

Agreed. Arguably, UTC is calculated by BIPM including leap-second
recommendations by IERS, but the ITU represents its global adoption.

Details not particularly important to this discussion; the point is that
this is a complex issue that has already been addressed. I fail to see
why we just don't consider the Posix definition erroneous and move on...

Joe

---

From: Tony Finch <[email-masked]>
Date: Tue, 03 Jan 2017 23:14:20 +0000

Joe Touch <[email-masked]> wrote:

> Leap seconds are still seconds, which are counted in "seconds since

> epoch".

Can you you show me where in the POSIX spec linked below leap seconds
are counted? I thought they were not.

> second behind UTC right now.

I'm not sure what you mean. If you add (24+24+23)*3600 seconds to
1483228800 you get 23:00:00 today, which is the same length of time
after 2017-01-01 00:00:00. Nothing is one second behind now. Except it
has taken me more than 600 seconds to write this message.

> I.e., the Posix code is incorrect in claiming it reports UTC.

Yes, I agree.

> include the leap second.

But if the count of seconds includes the leap second, surely the number
representing the leap second could be printed properly as :60 ?

Tony.

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 15:21:24 -0800

On 1/3/2017 1:57 PM, Phillip Hallam-Baker wrote:
> The second column is increments for the 24 hour change, the second for
> the 20 hour. As you can see, 24 hours means dealing with rounding.
> That is fine for Internet apps but an unnecessary source of error for
> scientific.

It depends on your representation. In base 10, the second column has
repeating digits but not the third.

In base 2, they both repeat so it really doesn't matter.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 15:28:03 -0800

> are counted? I thought they were not.

 A leap second is just a way to stall the UTC representation so it takes
61 seconds for a particular minute to pass, but the seconds still pass
and the seconds since epoch ought to increment accordingly.

The Posic spec describes how to convert seconds since epoch to UTC; it
is that conversion where leap seconds come into play.

> I'm not sure what you mean. If you add (24+24+23)*3600 seconds
> to 1483228800 you get 23:00:00 today,

If 1483228799 is the correct number of TAI seconds since the Unix epoch
and if that accurately represents 2016-12-31 23:59:59, then 2017-01-01
00:00:00 should not have been output until 1483228801.

Since that wasn't accounted for, we are displaying a "Posix UTC" time
that is one second ahead of where UTC actually is.

> But if the count of seconds includes the leap second, surely the
> number representing the leap second could be printed properly as :60 ?

UTC defines it that way, so if you want to output the correct UTC value,
that is the only solution.

Any other solution - smear, repeating times (59-59-00 or 59-00-00) can
be generated, but would be incorrect relative to UTC.

Joe

---

From: Philip Homburg <[email-masked]>
Date: Wed, 04 Jan 2017 00:32:23 +0100

>?So you are for sticking with IPv4 as well?
>
>Nothing can ever change because the ITU is in charge...?
>
>?People are only in charge as long as other people let them. ?

The 'obvious' solution is to make programmers, from operating systems all
the way to application programmers, aware that there are different types
of time.

Most programmers should already know that there is a difference between
local time and UTC. We need to extend that a bit.

In particular, we need
- a monotonic 'uptime' that can be used for local timers, etc. independent of
  any external time source. 
- we need UTC. Civil time is UTC. We have no control over that. For many,
  many years we know that leap seconds are a problem, but we are still stuck
  with it. For many, many years we also know the daylight saving time is 
  silly. But we have good solution for the timezone stuff.
- we need a sensible time. There are many ways to define a sensible time,
  but TAI is available, so let's use that. For me, sensible time includes
  using SI seconds for keeping track of time.

The main thing is that, by and large, this is not a network problem. If a
system uses TAI internally, it can use UTC for NTP, for SMTP, HTTP, etc. The
only thing we may have to do at the network level is improve the availability
of an up-to-date leap second list.

The big thing is, making sure that operating systems offer TAI as a first
class citizen. Making sure that timers are set using MONOTONIC clocks and
making sure that applications that use subsecond precision for time
information internally use TAI and only convert to UTC for interacting
with users.

Unfortunately, there doesn't seem to be an IETF equivalent for operating
systems, so it will be completely random whether anything will happen in
this area or not.

---

From: Tony Finch <[email-masked]>
Date: Wed, 04 Jan 2017 00:00:21 +0000

Joe Touch <[email-masked]> wrote:

> is that conversion where leap seconds come into play.

No, it describes the reverse, how to convert broken-down UTC time to
seconds since the epoch. It multiplies minutes by a fixed 60s, hours by
a fixed 3600s, and days by a fixed 86400s. The rest of the formula is
dealing with Gregorian dates. There is no allowance for leap seconds.

> that is the only solution.

UTC does not define a seconds count, it is specified in terms of broken-
down time only, so that doesn't really answer my question about why you
say a system can't print a :60 UTC time when you say it has a seconds
count which includes leap seconds.

There's also a relevant example in the NTP RFC

https://tools.ietf.org/html/rfc5905#page-14

1972-01-01 00:00:00 - MJD 41317 - NTP 2272060800

1999-12-31 00:00:00 - MJD 51543 - NTP 3155587200

51543 - 41317 == 10226

(3155587200 - 2272060800) / 86400 == 10226

[note integer MJD numbers are always midnight]

No leap seconds, because each one is forgotten by NTP when the leap
indicator bits are reset.

Tony.

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 16:07:25 -0800

On 1/3/2017 4:00 PM, Tony Finch wrote:
> seconds since the epoch.

You're right; I got it backwards. Except it admits it's an approximation:
"A value that approximates the number of seconds that have elapsed since
the Epoch."

> UTC does not define a seconds count

UTC includes :60 as a valid time, as was indicated in the leap-second
announcement.

However, when you are computing epoch time from UTC, you'd have to
account for the leap seconds since epoch to correct for the difference
in actual elapsed seconds.

Joe

---

From: Tony Finch <[email-masked]>
Date: Wed, 04 Jan 2017 00:13:56 +0000

Joe Touch <[email-masked]> wrote:

> "A value that approximates the number of seconds that have

Thank you :-)

This kind of confusion is why leap seconds don't work in practice.

> in actual elapsed seconds.

POSIX and NTP say you aren't allowed to account for leap seconds when
computing seconds since the epoch from UTC.

Tony.

--

---

From: Joe Touch <[email-masked]>
Date: Tue, 3 Jan 2017 16:23:03 -0800

> This kind of confusion is why leap seconds don't work in practice.

No, it's just why Unix cannot compute the time since epoch without the
table of leap seconds.

Nobody said that keeping accurate time wouldn't require external
information.
> computing seconds since the epoch from UTC.

Then they're both wrong. What do you want me to say?

We've understood the concept of local frames of time since the 1920s (or
should have). All we need to do is get our specs in line with reality.
Note that GPS does it right - it indicates time since an epoch and has
to be corrected to convert to UTC, and includes the delta to UTC in its
announcements.

Joe

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 04 Jan 2017 08:14:31 +0100

On 4 Jan 2017, at 0:14, Tony Finch wrote:

> I'm not sure what you mean. If you add (24+24+23)*3600 seconds to 1483228800 you get 23:00:00 today, which is the same length of time after 2017-01-01 00:00:00. Nothing is one second behind now. Except it has taken me more than 600 seconds to write this message.

Well, if you look at the POSIX definition you see that it is clearly wrong the days when leap second is added:

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

2015-12-31 23:59:58 365th day 61409923198
2015-12-31 23:59:59 365th	 day 61409923199
2016-01-01 00:00:00   1st day 61409836800
2016-01-01 00:00:01   1st day 61409836801
									
2016-12-31 23:59:59 366th day 61441459199
2016-12-31 23:59:60 366th day 61441459200
2017-01-01 00:00:00   1st day 61441459200
2017-01-01 00:00:01   1st day 61441459201

I.e. the real problem we have is a broken POSIX definition.

    Patrik

---

From: Eliot Lear <[email-masked]>
Date: Wed, 4 Jan 2017 08:51:15 +0100

On 1/3/17 11:34 PM, 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.​
>

If you can predict the weather that far in advance, I think you should
go into the reinsurance business.

Eliot

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 4 Jan 2017 09:49:35 +0100

>   any external time source. 

FWIW, the W3C has switched to defining time inside a Web page in two
segments:
- Page load time, which is UTC-derived (POSIX time extended to
milliseconds), and can jump when the system clock is reset
- Events related to the page load time, which has floating-point
representation, and is guaranteed to be monotonic.

DOMHiResTimeStamp and related specs make for interesting reading
(although you'll feel at times like you're lost in a maze of twisty
little definitions, all different).

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 4 Jan 2017 09:21:29 +0000

On 03/01/2017 19:54, Cyrus Daboo wrote:
>>> involve
>> specific
> No! That is not true because a future local time is not guaranteed to 
> be at a specific universal time because local government can change 
> their time zone (or more likely) their daylight savings time 
> transition at any time between now and said future time. i.e., you 
> cannot "pre-cache" all the local time -> UTC mappings for a future 
> recurring event and then just use the UTC values, because the time 
> zone definition may change.
>

So an application sensitive to that needs to specify its timing in terms 
of local time, but that should not force the fundamental time 
distribution system to operate in that mode.

Maybe we need two time distribution systems, one that accurately does 
the ranging and flywheel management and distributes precision time for 
technical purposes, and a separate one that manages the offsets and 
jumps relative to the underlying precision continuous time distribution 
system.

Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 4 Jan 2017 10:11:06 -0800

> I.e. the real problem we have is a broken POSIX definition.
It's as correct as it claims to be - it's an approximation.

If anyone cares about a more precise back-calculation of Unix epoch from
UTC, they would definitely need to consult a leap-second file.

Joe

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Jan 2017 14:35:14 +0100

> *​ The governments will do whatever their banking and broadcast sectors

I doubt this statement would turn out to be true (since agreements on
standardized units of measurement is somewhat older than the interwebs
etc) but mostly I don't see how the political mess you propose is worth
the "win" of not having to deal with the odd leap-second now and then.

I could think of tastier fish to fry - for instance a way to do secure
time at Internet scale.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 5 Jan 2017 14:46:31 +0100

> I could think of tastier fish to fry - for instance a way to do secure

Yes, please.  I am reminded of the work that Ben Laurie pointed me to at
least be able to determine when someone is lying to you.

Eliot

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Jan 2017 15:57:52 +0100

> least be able to determine when someone is lying to you.

Yep roughtime. Might be fun to play with.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Jan 2017 11:03:43 -0500

> I could think of tastier fish to fry - for instance a way to do secure

​That was the reason I decided to kill the unpredictable leap seconds in
the first place.

As with many Internet infrastructure improvements, secure time isn't very
interesting on its own. It is interesting but not interesting enough to get
people to deploy.

Instead, I propose a one stop shop for all trust services:

* Trusted Time
* Trusted DNS resolution
* Trusted trust broker (c.f. XKMS, SCVP, ...)

I call this a Mesh portal.

The idea being that every Internet device that a person owns can be
connected to the ​Mesh portal of their choice that will serve as a one stop
shop for all three.

Note that trusted does not mean trustworthy. I certainly want to limit the
degree of trust required to the absolute minimum.

For trusted time, I would want the Mesh portal to run a local linked notary
log (c.f. blockchain) that would prevent clock rollback.The portal would
also run a notary service allowing transactions to be protected against
rollback.

So the local notary log would operate on a time interval of a minute. Every
15 minutes or so the Mesh portal would cross notify with a random selection
from a set of peers. Every hour the peer group would cross notify with a
member of a Meta notary set.

In this way the time is bounded as follows

Accurate to 100ms or better:
    On the authority of the portal alone

Accurate to 1 minute or better:
    On authority of portal with qualified accountability to relying parties

Accurate to 15 minute or better:
    On authority of portal with unqualified accountability to peer group

Accurate to 60 minutes or better:
    With full transparency

​Changes in the definition of time are driven by two things: technology for
telling time and the use made by technology. The time zone system we use
today has its origins in railway time developed by and for the railways.​

The type of application I would see this being used for is for notarizing
digital evidence during collection.

Right now, I am still at the design stage. As I said, I don't think this
system provides sufficient value on its own but it could if combined with
other purposes such as payment transfers etc.

The main reason I want the system is actually to service a next generation
PKI designed to service client side keys.