Re: Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 03 January 2017 20:09 UTC

Return-Path: <hallam@gmail.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 1DF0E129B7A for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 12:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XQE6QEbar8OZ for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 12:09:40 -0800 (PST)
Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c:c01::230]) (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 4094D129B70 for <ietf@ietf.org>; Tue, 3 Jan 2017 12:09:40 -0800 (PST)
Received: by mail-wj0-x230.google.com with SMTP id v7so453687988wjy.2 for <ietf@ietf.org>; Tue, 03 Jan 2017 12:09:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Dyvzst+4iY+biJldjfbkWDQBg55TjhvjNCeBL/KrB3A=; b=LrRznvN1+MlUyi2HZGBph9481xmVT6bD1lfsHeFebij0XE8/pjZFrgtDVDdudOmv9l 1RZ84mpQx+r4tnyoUADq7y2TmqyheaA0WuF0zSThOm+sXRuNEnTs8DD7W/eJNzUvpNIL TbjM9QHqAVcA31/QwuqXQmn8ARsFo0wfyhG4yDXsvGPn2jvTLMYPtL2AaHT50MlJVUY9 VQx1LrfBeLGqOOTby18Bg1veVg6DRVkjS/UDA1DtBvtAt8vuXsMObtEFuzRGGNcAmyrj 1QmNBeD50g18ZMTe7tR69r3SxXd1loN9Sk50/i9zWQHLmYZeIjZ4ZBO7kzX4KBsWZ5kc IMDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Dyvzst+4iY+biJldjfbkWDQBg55TjhvjNCeBL/KrB3A=; b=hTRZShKbIG048cEDMs3fTUo3Ioxs0X5ybCBKZxxqWkd92RBIDqDizP1ouKJeDK3JYq cBKVdV4KVZGsYOIRdYkPiNoq15Ephmsg/BB5ayEu2vTkdwO0276bHTYDCldhScGjv92l JbyjkAQ5nY2bClIvoIjSQPkUyiZsmztnvErgYb2va65PFW6GzK83Lz7i6LCNfIOY4oLj Nc/9wo/3CCf6xsLtpsgDI+/GEGmqgRqCcYG4NYJ8Me4Vdnta0HqjSS30McyQ+wNafPwJ XVqQs88/pbnqusrpKnGJd8gVdNUBUV1DUp4NsLWUbDJ8vFRrVEqrJo9cy5HWyprgaDiy hiRQ==
X-Gm-Message-State: AIkVDXKiWqjTSb4PqeyLfJXpUzUqhHUzpH9fWefzdjreUMa0Hz1Nt/UKkqrtnM/MvYAbIk539IXlPTlhdmBlYg==
X-Received: by 10.194.187.103 with SMTP id fr7mr52533397wjc.99.1483474178666; Tue, 03 Jan 2017 12:09:38 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Tue, 3 Jan 2017 12:09:37 -0800 (PST)
In-Reply-To: <dd90490e-e6d8-5c91-56bc-7a7908cfd2fd@isi.edu>
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> <CAMm+Lwg8UzhyqNBrsxNb_8uFLCrL-iqpjPGwfycmvPEOcuE8LA@mail.gmail.com> <9cc49e0a-1aac-67e0-f198-4e0673340394@cisco.com> <CAMm+LwjSPnimVYmF0WmKT0zNxETt53fxVM+7D+Q2Rmi7nPFsHw@mail.gmail.com> <dd90490e-e6d8-5c91-56bc-7a7908cfd2fd@isi.edu>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 3 Jan 2017 15:09:37 -0500
X-Google-Sender-Auth: deTCJX1hpotlgI6JFZyG7v_FE7g
Message-ID: <CAMm+LwhhSVKLjoGiRVnEiD+U5JgF=NCbNZo4VGd9PJu1OuKB=Q@mail.gmail.com>
Subject: Re: Predictable Internet Time
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary=047d7bd6bc9c73f9210545363f81
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/-iPAjc65_aLSJ7zbXfW8j-8QQDQ>
Cc: 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 20:09:42 -0000

What governments decide, governments can undecide.

To take contribution to TAI as endorsement of UTC as ineluctable perfection
and thus the impossibility of changing it ever is a silly argument to make.

On Tue, Jan 3, 2017 at 3:01 PM, Joe Touch <touch@isi.edu>; wrote:

> You might consider that most governments have already agreed to cooperate
> - by contributing their national clock info to TAI, accepting the
> TAI-averaged result, and accepting the ITU's definition of UTC.
>
> I see no good reason to create a new time reference that would still
> ultimately need translation to TAI and UTC anyway, esp. given the
> translation would be complex on the smear-day.
>
> Joe
>
> On 1/3/2017 11:46 AM, Phillip Hallam-Baker wrote:
>
> On Tue, Jan 3, 2017 at 2:03 PM, Eliot Lear <lear@cisco.com>; wrote
>
>> On 1/3/17 7:24 AM, Phillip Hallam-Baker wrote:
>>
>> Umm, my proposal was to ignore the opinion of the ITU in this matter as
>> in everything else.
>>
>>
>> That doesn't work in all cases because there are often applications that
>> require that the clock time on a device not vary from UTC by some set
>> amount.  I think they're fixing for a big UTC leap second shindig in the
>> next few years, anyway.
>>
>> Eliot
>>
>
> ​My analysis of the politics of the situation is as follows
>
> * The decision makers are the governments, not the ITU
>
> *​ The governments will do whatever their banking and broadcast sectors
> tell them.
>
> * The banking and broadcast sections will do whatever Microsoft, Google,
> Apple, etc agree on provided that the transition is not going to be more of
> a problem than the status quo.
>
> ​* If ​there is a non ITU proposal on the table that threatens to replace
> ITU as the place where the decision is taken that stands a chance of being
> adopted, ITU will prefer to co-opt it rather than lose the appearance of
> control.
>
>
> We already have UT0, UT1 and UT2 and several other variants. The mapping
> from UT1 to UTC can be varied by committee.
>
>
>
>