Re: [art] Predictable Internet Time

Joe Touch <touch@isi.edu> Tue, 28 March 2017 18:21 UTC

Return-Path: <touch@isi.edu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6551294AB for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 11:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 RSvKPP7XTQik for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 11:21:34 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CAA1293F8 for <art@ietf.org>; Tue, 28 Mar 2017 11:21:34 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v2SIL2BK024853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 11:21:02 -0700 (PDT)
To: Tony Finch <dot@dotat.at>, Philip Homburg <pch-ietf-art@u-1.phicoh.com>
References: <m1csrkh-0000GYC@stereo.hq.phicoh.net> <alpine.DEB.2.11.1703281603500.13590@grey.csi.cam.ac.uk>
Cc: art@ietf.org
From: Joe Touch <touch@isi.edu>
Message-ID: <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu>
Date: Tue, 28 Mar 2017 11:21:02 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1703281603500.13590@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/5Pkd-5dDmYTMe2-u5bTPh4V1TwE>
Subject: Re: [art] Predictable Internet Time
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Mar 2017 18:21:36 -0000


On 3/28/2017 8:13 AM, Tony Finch wrote:
> Philip Homburg <pch-ietf-art@u-1.phicoh.com> wrote:
>> A few random comments.
> Good comments :-)
>
>> - There are two types of solar time. The actual solar time where the sun is
>> at the highest point at noon, and mean solar time.
> The usual term for the former is "apparent solar time". If you are talking
> about both then it's worth saying the difference between apparent and mean
> solar time is called the equation of time.

Will do.

>
>> - One thing I'd like to add is 'uptime' or more general, monotonic time.
> An interesting discussion re. compatible APIs for elapsed time:
> https://github.com/golang/proposal/blob/master/design/12914-monotonic.md
This is another example of the confusion that results when the time
scale is not clearly indicated or defined. Having Go read the "system
wall clock" is the source of the problem, and this doc explains a
variety of solutions.

I can add a new "monotonic clock" definition that uses an arbitrary
"tick" that is guaranteed to increase between reads and across reboots,
but is not comparable across machines.

>
>> - Another thing worth mentioning explictly is that for the distant future,
>> there is no way to convert between TAI and UTC because future leapsecond are
>> not yet defined. So TAI is good for computing intervals, except if it involves
>> timestamps more than a few months in the future.
> I think "distant future" isn't a very good description for "a few months" :-)
>
> The actual horizon is about 5 - 11 months, just before and just after
> bulletin C is published in January or July
Agreed, but not sure we need that level of detail.

Joe