Re: Predictable Internet Time

Joe Touch <touch@isi.edu> Wed, 04 January 2017 00:23 UTC

Return-Path: <touch@isi.edu>
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 B1D0E129408 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 16:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.999
X-Spam-Level:
X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 F5XWaV6f8gFv for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 16:23:38 -0800 (PST)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 B503B1293F2 for <ietf@ietf.org>; Tue, 3 Jan 2017 16:23:38 -0800 (PST)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v040N4nN007519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 3 Jan 2017 16:23:04 -0800 (PST)
Subject: Re: Predictable Internet Time
To: Tony Finch <dot@dotat.at>
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> <f94415b6-d9f7-0a03-cf5b-ce39c109aa71@isi.edu> <1483475689.1348946.836323865.09305276@webmail.messagingengine.com> <94226b19-4690-ee8e-526e-04cc54e97b8e@isi.edu> <1483482794.1375510.836410009.6D0F7910@webmail.messagingengine.com> <fef56705-3037-eb92-b804-4aa43326a654@isi.edu> <1483485260.1384841.836469129.669D4C7B@webmail.messagingengine.com> <ad31b4f2-7104-d951-3f5b-81cbfc83b118@isi.edu> <1483488021.1394874.836501673.12EE46CD@webmail.messagingengine.com> <f333bf8a-2261-5441-6484-d8c3eec9514f@isi.edu> <1483488836.1397675.836530745.4A4F8676@webmail.messagingengine.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <a4fdc194-05be-a257-4cc4-e06fac54205c@isi.edu>
Date: Tue, 3 Jan 2017 16:23:03 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <1483488836.1397675.836530745.4A4F8676@webmail.messagingengine.com>
Content-Type: multipart/alternative; boundary="------------9791DFF165B556C45EB44550"
X-MailScanner-ID: v040N4nN007519
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/6SrlcSOiggnlICkU89x0L1J2o-o>
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: Wed, 04 Jan 2017 00:23:40 -0000


On 1/3/2017 4:13 PM, Tony Finch wrote:
>
> Joe Touch <touch@isi.edu>; wrote:
> >
> > You're right; I got it backwards. Except it admits it's an
> approximation:
> > "A value that approximates the number of seconds that have elapsed since
> > the Epoch."
>
> Thank you :-)
>
> This kind of confusion is why leap seconds don't work in practice.

No, it's just why Unix cannot compute the time since epoch without the
table of leap seconds.

Nobody said that keeping accurate time wouldn't require external
information.
>
> > However, when you are computing epoch time from UTC, you'd have to
> > account for the leap seconds since epoch to correct for the difference
> > in actual elapsed seconds.
>
> POSIX and NTP say you aren't allowed to account for leap seconds when
> computing seconds since the epoch from UTC.

Then they're both wrong. What do you want me to say?

We've understood the concept of local frames of time since the 1920s (or
should have). All we need to do is get our specs in line with reality.
Note that GPS does it right - it indicates time since an epoch and has
to be corrected to convert to UTC, and includes the delta to UTC in its
announcements.

Joe