Re: Predictable Internet Time

Stewart Bryant <stewart.bryant@gmail.com> Wed, 04 January 2017 09:21 UTC

Return-Path: <stewart.bryant@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 0DC28127A90 for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 01:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0WMMT0HO3u2I for <ietf@ietfa.amsl.com>; Wed, 4 Jan 2017 01:21:32 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 99144127078 for <ietf@ietf.org>; Wed, 4 Jan 2017 01:21:32 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id t79so450836102wmt.0 for <ietf@ietf.org>; Wed, 04 Jan 2017 01:21:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=KAMQ5i00xdhsX8aFv7b2esoIj7PzQBJRglvmPezc3DU=; b=VwurrqtnVKepGrX5JR1bqGpbbn4fJaS2OW/KLjtAG2N+JwIiF2XvXAfjuFUj7aNuW3 0kzkUQodto6UDlWm1n9W403QqUF42qF3l+cxQEmvzn5GvSr20jh8Zagst7Lx5/jq6k64 wlyZzml9bN++/fqfkKfRocIiFjIXn2f+hwmPWIFanuaGVERlp9acipixN+uy4PIfU9gm iohD1uOCaFm//cCO0w9kbUX33sZIPpobdpczqS1vjukO6EwMf4eRPEp/v1itGq83VtI9 drHjVAStnAxL7cA/HQoESZ6GenlbotaqoqccAu1Q4NURt4YhmkMrQlovA5uhUq9Xt9gp 9kDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KAMQ5i00xdhsX8aFv7b2esoIj7PzQBJRglvmPezc3DU=; b=qEDnfD/IP5LRloFv5c+eBIyr9N3g40RggwlXL+cet7fnnLH+5fM4PS/NckDL5fA7Gl WbNlQuE1190m10vBQFOe6rdOK7bJl/ngVF9iiInKaaQOjVq1iAIPkbAlC1UhEz9YHxTy 51aPPxXrtmfQL44ZULkriyNswXwjEns/Ag/P95mLwRVqtY1zzLV2/qa1tQXUD8OUmc3+ AYfnXVe8oq3LoMOaW8CtMrr8ZcxuVgNrmAf/IB7zGuIQtW+qLkKzJJ+Qi9CNPxTJkcKf hhGZhn1EldN4P2fqHvCzFkT0YXclOwQOJJA79Za8L4aQjuMPU07ebvMYqb8EWtRgW6xO aAmA==
X-Gm-Message-State: AIkVDXI0GF+E2ClwVO/Jn6sZ1CxDJahac/u/g2nQBiWhRjKp3bfLTSsbQzL3gKPQMSg5PQ==
X-Received: by 10.28.13.9 with SMTP id 9mr52597796wmn.50.1483521690760; Wed, 04 Jan 2017 01:21:30 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id ct7sm97314308wjc.2.2017.01.04.01.21.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 01:21:30 -0800 (PST)
Subject: Re: Predictable Internet Time
To: Cyrus Daboo <cyrus@daboo.name>, Ted Lemon <mellon@fugue.com>
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> <0bbfcd7c-11a7-0e7f-56f7-eee959b7a947@gmail.com> <CAMm+Lwi0sQyRE_2dMCkwTk7xTiK2JbHhHSPYMkdG2FeBw_6CNA@mail.gmail.com> <7BDE58D23ADF3BC046F8942D@caldav.corp.apple.com> <b27515e2-a36a-7bf2-0ca4-1fae31a9dc21@gmail.com> <04DD5DFCB528DCD404C81F78@caldav.corp.apple.com> <A193D619-7B59-4EFB-A773-B6F6E4FD5884@fugue.com> <C93A4EFBD3E91F4F714DF948@caldav.corp.apple.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <29873ae2-22a2-d59b-38a6-b06763eeaec3@gmail.com>
Date: Wed, 04 Jan 2017 09:21:29 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <C93A4EFBD3E91F4F714DF948@caldav.corp.apple.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/gWgVQkIf5a83-tOxRVdkqxHoBoY>
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 09:21:34 -0000


On 03/01/2017 19:54, Cyrus Daboo wrote:
> Hi Ted,
>
> --On January 3, 2017 at 1:51:54 PM -0500 Ted Lemon <mellon@fugue.com> 
> wrote:
>
>>> No that simply does not work. Repeating events or alarms may not 
>>> involve
>>> any UI at all, but the device may need to trigger those at a specific
>>> local time - that means time zone information has to be taken into
>>> account somewhere. This is a crucial fact of any calendaring and
>>> scheduling system that those of us who have been using iCalendar
>>> (RFC5545) fully appreciate.
>>
>> This is true, but any specific local time will always occur at a 
>> specific
>> universal time, so this isn't actually a problem.
>
> No! That is not true because a future local time is not guaranteed to 
> be at a specific universal time because local government can change 
> their time zone (or more likely) their daylight savings time 
> transition at any time between now and said future time. i.e., you 
> cannot "pre-cache" all the local time -> UTC mappings for a future 
> recurring event and then just use the UTC values, because the time 
> zone definition may change.
>

So an application sensitive to that needs to specify its timing in terms 
of local time, but that should not force the fundamental time 
distribution system to operate in that mode.

Maybe we need two time distribution systems, one that accurately does 
the ranging and flywheel management and distributes precision time for 
technical purposes, and a separate one that manages the offsets and 
jumps relative to the underlying precision continuous time distribution 
system.

Stewart