Re: [art] Predictable Internet Time

Joe Touch <touch@isi.edu> Wed, 29 March 2017 14:35 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 E9A7B1242EA for <art@ietfa.amsl.com>; Wed, 29 Mar 2017 07:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 LJooWk7V4M2d for <art@ietfa.amsl.com>; Wed, 29 Mar 2017 07:35:45 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0B153124D37 for <art@ietf.org>; Wed, 29 Mar 2017 07:35:44 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v2TEZ7Jv015474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 29 Mar 2017 07:35:08 -0700 (PDT)
To: Nico Williams <nico@cryptonector.com>
References: <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> <f9429571-b9d5-75d4-9b46-b877a189a7bf@gmail.com> <20170328173916.GE7490@localhost> <e73d5c15-1ba3-8162-f7df-555e2e8588a6@isi.edu> <20170328224041.GJ7490@localhost> <9ddcde60-a915-a03d-dfc3-2c2c451c398c@isi.edu> <20170329000601.GK7490@localhost> <96ad09b7-7dc2-20e8-2aa4-793310d184f6@isi.edu> <20170329015811.GL7490@localhost>
Cc: art@ietf.org
From: Joe Touch <touch@isi.edu>
Message-ID: <111c86bc-c2c5-5050-edc0-82e40d36c570@isi.edu>
Date: Wed, 29 Mar 2017 07:35:06 -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: <20170329015811.GL7490@localhost>
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/nCtBGCH9eq_bKDD6smCwDP7RBOI>
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: Wed, 29 Mar 2017 14:35:47 -0000

Hi, Nico,


On 3/28/2017 6:58 PM, Nico Williams wrote:
> On Tue, Mar 28, 2017 at 05:15:58PM -0700, Joe Touch wrote:
>>>> time_t does not access a SI reference or frankly any other stable reference.
>>> The Open Group man pages I'm looking at don't reference SI, but so
>>> bloody what.  If it says "seconds", it means "seconds".
>> That's the trouble - seconds in SI are not seconds defined as 86400/day.
>> If the units don't match,  then a conversion needs to be included. If
>> the units aren't known, you can't convert accurately.
> POSIX does NOT define seconds in terms of days!  It does the opposite:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16
>
>     How any changes to the value of seconds since the Epoch are made to
>     align to a desired relationship with the current actual time is
>     implementation-defined. As represented in seconds since the Epoch,
>     each and every day shall be accounted for by exactly 86400 seconds. 
>
> There is NO reference to solar or sidereal days or any other
> astronomical definition of day.
OK - we agree that it defines "day" = 86400 "seconds".

It should be clear that it also never defines either "day" or "seconds".

"Seconds" can't be SI units unless there's a tiny cesium clock inside my
PC. "day" can't be apparent or mean solar time because it doesn't have a
sextant either.

> Unlike as with days, there is no multiplicity of generally accepted
> definitions of seconds, so there is no support for the idea that this
> text defines seconds in terms of days.
>
> The second sentence defines days in terms of seconds, not the other way
> around.
>
> The first sentence is a bit abstruse, but no matter, because in
> _practice_ on all systems I know of that claim to implement POSIX, or
> which don't but which are Unix or Unix-like systems, seconds since the
> epoch differs from UTC *only* by leap seconds -- just like TAI.
The text only states that the POSIX clock *started* with a known offset
to TAI and that the POSIX clock won't jump with leap seconds.

It never states anything else...

> ...
> POSIX seconds are not defined, indeed, but they can only be taken to be
> SI seconds -- anything else would be sheer madness and, anyways, not
> supported by actual practice.  I know of no POSIX or POSIX-ish system
> where this is not true.

I know of no POSIX system with a cesium atomic clock.

The issue is that POSIX really runs off of whatever local source of time
passage is available, and can (and does) drift from TAI on *each*
system. That drift can't be determined until your system tries to sync
with an external source (e.g., via NTP).

Joe