Re: Predictable Internet Time

Philip Homburg <> Tue, 03 January 2017 23:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7225C129479 for <>; Tue, 3 Jan 2017 15:32:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jQxajro3-kb3 for <>; Tue, 3 Jan 2017 15:32:32 -0800 (PST)
Received: from ( [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by (Postfix) with ESMTP id 3A7DD1294B3 for <>; Tue, 3 Jan 2017 15:32:32 -0800 (PST)
Received: from ([::ffff:]) by with esmtp (Smail #127) id m1cOYZ6-0000FAC; Wed, 4 Jan 2017 00:32:24 +0100
Message-Id: <>
To: IETF Discussion Mailing List <>
Subject: Re: Predictable Internet Time
From: Philip Homburg <>
In-reply-to: Your message of "Tue, 3 Jan 2017 13:39:37 -0500 ." <>
Date: Wed, 04 Jan 2017 00:32:23 +0100
Archived-At: <>
Cc: Phillip Hallam-Baker <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 23:32:38 -0000

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