Re: Predictable Internet Time

Harald Alvestrand <harald@alvestrand.no> Wed, 04 January 2017 08:49 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D24129C4F for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 00:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.3
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl3wnbkhkQ6w for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 00:49:39 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27291129C49 for <ietf@ietf.org>; Wed, 4 Jan 2017 00:49:39 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 465F27C4C3D for <ietf@ietf.org>; Wed, 4 Jan 2017 09:49:37 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY_WriItdY3t for <ietf@ietf.org>; 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 mork.alvestrand.no (Postfix) with ESMTPSA id 398A57C4ADE for <ietf@ietf.org>; Wed, 4 Jan 2017 09:49:36 +0100 (CET)
Subject: Re: Predictable Internet Time
To: ietf@ietf.org
References: <m1cOYZ6-0000FAC@stereo.hq.phicoh.net>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <bf1a0b49-6f76-1ec8-0a70-bfff9be40c16@alvestrand.no>
Date: Wed, 4 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: <m1cOYZ6-0000FAC@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/G46UvuM30_JncpcVa3zk6_jm8Fw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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
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).

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