Re: Predictable Internet Time

Pete Resnick <presnick@qti.qualcomm.com> Tue, 03 January 2017 19:49 UTC

Return-Path: <presnick@qti.qualcomm.com>
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 6F7D5129B50 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 11:49:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
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 M5TdDjWRDDqs for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 11:49:45 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C114E129B4F for <ietf@ietf.org>; Tue, 3 Jan 2017 11:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; 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 Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by wolverine02.qualcomm.com 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 nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jan 2017 11:49:44 -0800
Received: from [10.64.104.67] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 3 Jan 2017 11:49:44 -0800
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: Predictable Internet Time
Date: Tue, 3 Jan 2017 13:49:42 -0600
Message-ID: <25CFBF4B-21BC-4EAA-8965-B501F79741D6@qti.qualcomm.com>
In-Reply-To: <b2c55c32-46b8-4bed-d8aa-e16327401447@gmail.com>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com> <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu> <alpine.DEB.2.11.1701031348430.7102@grey.csi.cam.ac.uk> <0bbfcd7c-11a7-0e7f-56f7-eee959b7a947@gmail.com> <CAMm+Lwi0sQyRE_2dMCkwTk7xTiK2JbHhHSPYMkdG2FeBw_6CNA@mail.gmail.com> <7BDE58D23ADF3BC046F8942D@caldav.corp.apple.com> <b27515e2-a36a-7bf2-0ca4-1fae31a9dc21@gmail.com> <04DD5DFCB528DCD404C81F78@caldav.corp.apple.com> <b2c55c32-46b8-4bed-d8aa-e16327401447@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_FBF4D9B7-5465-4988-AD14-9434A011C660_="
X-Mailer: MailMate (1.9.6r5319)
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mhN1jZUh75bxv2A8wcpwHzHGGNk>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
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: 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 
>> <stewart.bryant@gmail.com>; 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 
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.
>
> 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".

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