Re: Predictable Internet Time

Harald Alvestrand <> Wed, 04 January 2017 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35D24129C4F for <>; Wed, 4 Jan 2017 00:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.3
X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yl3wnbkhkQ6w for <>; Wed, 4 Jan 2017 00:49:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27291129C49 for <>; Wed, 4 Jan 2017 00:49:39 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 465F27C4C3D for <>; Wed, 4 Jan 2017 09:49:37 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xY_WriItdY3t for <>; Wed, 4 Jan 2017 09:49:36 +0100 (CET)
Received: from [IPv6:2001:470:de0a:1::5ea] (unknown [IPv6:2001:470:de0a:1::5ea]) by (Postfix) with ESMTPSA id 398A57C4ADE for <>; Wed, 4 Jan 2017 09:49:36 +0100 (CET)
Subject: Re: Predictable Internet Time
References: <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Wed, 04 Jan 2017 09:49:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
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: Wed, 04 Jan 2017 08:49:41 -0000

Den 04. jan. 2017 00:32, skrev Philip Homburg:
>>> 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. 

FWIW, the W3C has switched to defining time inside a Web page in two
- 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).

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