Re: Predictable Internet Time

Pete Resnick <> Tue, 03 January 2017 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F7D5129B50 for <>; Tue, 3 Jan 2017 11:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M5TdDjWRDDqs for <>; Tue, 3 Jan 2017 11:49:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C114E129B4F for <>; Tue, 3 Jan 2017 11:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1483472985; x=1515008985; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=YWOAkqQImWxXbRDe+K76ecXitSnQOQ7HhGD/kJPriTY=; b=Uj+PHXGUBzc4K2O+PfP7Nx5mCkyAa/EaYs8RUTpaARL1k5qRGGg06NDl SDJxQ9o5S3TjUiR5Zg5Ysxv7wy3HBywCdcwG4VnORyY3ErfhVQ1FbdRbR qvCOdXa+Xibd8LpPFtHvzHIsoyY7BPW/xvKmpVExw6qwkqHb5V/6QuINo w=;
X-IronPort-AV: E=Sophos;i="5.33,456,1477983600"; d="scan'208,217";a="347997017"
Received: from unknown (HELO ([]) by with ESMTP; 03 Jan 2017 11:49:45 -0800
X-IronPort-AV: E=McAfee;i="5700,7163,8397"; a="1265718982"
X-Amp-Result: CLEAN
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 03 Jan 2017 11:49:44 -0800
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 3 Jan 2017 11:49:44 -0800
From: Pete Resnick <>
To: Stewart Bryant <>
Subject: Re: Predictable Internet Time
Date: Tue, 03 Jan 2017 13:49:42 -0600
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_FBF4D9B7-5465-4988-AD14-9434A011C660_="
X-Mailer: MailMate (1.9.6r5319)
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Cc: Phillip Hallam-Baker <>, IETF Discussion Mailing List <>
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 19:49:47 -0000

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

> On 03/01/2017 18:38, Cyrus Daboo wrote:
>> Hi Stewart,
>> --On January 3, 2017 at 6:30:19 PM +0000 Stewart Bryant 
>> <> wrote:
>>> 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.
>> 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 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 

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

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

Pete Resnick <>
Qualcomm Technologies, Inc. - +1 (858)651-4478