Re: [art] Predictable Internet Time

Joe Touch <touch@isi.edu> Tue, 28 March 2017 23:11 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 A3AF71294E0 for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 16:11:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oYwACm8FHfzB for <art@ietfa.amsl.com>; Tue, 28 Mar 2017 16:11:43 -0700 (PDT)
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 3AE4A126D05 for <art@ietf.org>; Tue, 28 Mar 2017 16:11:43 -0700 (PDT)
Received: from [128.9.184.151] ([128.9.184.151]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v2SNBR4a016066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 16:11:27 -0700 (PDT)
To: "Manger, James" <James.H.Manger@team.telstra.com>, "art@ietf.org" <art@ietf.org>, Nico Williams <nico@cryptonector.com>
References: <m1csrkh-0000GYC@stereo.hq.phicoh.net> <alpine.DEB.2.11.1703281603500.13590@grey.csi.cam.ac.uk> <809d2f85-0421-026b-f81d-6725e0548b6a@isi.edu> <20170328184301.GF7490@localhost> <8df1b619-d2c4-9830-a02f-372afa0077b3@isi.edu> <20170328190045.GG7490@localhost> <7096194a-aa8d-fb5a-dc9f-51670248bb88@isi.edu> <SYXPR01MB161579A2B0F94F50B13C1232E5320@SYXPR01MB1615.ausprd01.prod.outlook.com>
Cc: Tony Finch <dot@dotat.at>, Philip Homburg <pch-ietf-art@u-1.phicoh.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <38391306-8da7-b29c-45f8-517a2f207965@isi.edu>
Date: Tue, 28 Mar 2017 16:11:27 -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: <SYXPR01MB161579A2B0F94F50B13C1232E5320@SYXPR01MB1615.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: v2SNBR4a016066
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/I9-tDG7CAsSzmCXLEW_MsW83qpQ>
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 23:11:45 -0000


On 3/28/2017 3:56 PM, Manger, James wrote:
>>> leap second smearing
>> We certainly cannot even consider standardizing a conversion (even if that
>> were our purview) between time scales that include smearing until there
>> are smearing standards.
> It looks like the most valuable IETF contribution would be standardizing one smearing scheme (& getting Google, Java, ... to agree to it).

Ick. IMO, the most valuable contribution is to recommend the use of TAI
or UTC, IMO.

>
>> A key point in this doc is that smearing makes things horribly worse,
>> not better in any way, except to delude users into thinking otherwise.
> Given that a well-defined smearing scheme allows a simple and precise mapping to UTC, it is hard to see how that can be "horribly worse".
Even if we say that all interval calculations and conversions are
equally messy or not, why introduce yet another standard when we already
have TAI and UTC?
> Smearing moves the complexity of solar-vs-atomic-vs-civic time and the resultant leap seconds to a place where a huge number of systems can correctly handle that complexity by "doing nothing", while systems that care if time intervals can be 0.001% wrong (if 24hr is the smear standard) can still be more precise by making well-defined adjustments.

Doing nothing means smeared times are always wrong. When that smeared
time corresponds to a day or year change in another time zone, you've
really messed things up. That means doing nothing either means your
wrong or you're really wrong. The only solution is to convert out of the
smear back to UTC, but then why bother smearing at all?

Joe