Re: Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 03 January 2017 20:07 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 0D602129702 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 12:07:03 -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, 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 DT6k-ZmiAriz for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 12:07:01 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AF5791296AF for <ietf@ietf.org>; Tue, 3 Jan 2017 12:07:00 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id a197so393105135wmd.0 for <ietf@ietf.org>; Tue, 03 Jan 2017 12:07:00 -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=aSv/Tjkn+gnne1UV3E13Li8L/geujX+lz5lF05XAR0Y=; b=QyyDja1yTdVLR4uNgPfVsnVfmai2l+XdPkzVR9h7MTlLB1kOX48HrITBG8CCgrybl9 oWBM8LzUoQIQYU8EGyKFi6QLxMQRUyFV6Jb/oIu+5wG1WAWSkWNRm1azpn9VU3UqrmMG 3UgFWmys1Bb2zjH2IDTfmV+mPM4UMzupQRE3wfg1lApkxPIzMC3ZG3+/eD4Z0keWRKTy FO6NH+58CVPi30x/ZULyEAOcv8J0U6padOWRjPyMr5/w+uzBhH+0MwmQHZ5fBJyT9QHl ZNRf43mAUrrFdgyFrzMKqc7ln6dyxalOn6yfMgakBclFBlKlwbHPzScPUeMkzvelhnf6 YWEg==
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=aSv/Tjkn+gnne1UV3E13Li8L/geujX+lz5lF05XAR0Y=; b=RUpuGSSRVZGiyhiiAGzGXNX2cCxISj6nuaKl9ZvcdDC4zSl2qMfbmHV/waXzu8oe8S uPRuSE4aCOT7jd7ch5FpWW6TuZ9HkBb+Jv4tDSIQzXXGP0fM6Yd1F9A+GVCX/eSJVmxD P00cA4O5WIxilxNILJ8fephmmwyhxZkv4AXlzbF3CCHhruRo+edfsTt7EpCyHTgubYRF DMSrL7+zidbRm+I8HmWgNHGcUDH7dnTlwbz8r+AmTYVDS2g3zmZjmaRBzZGcXO6PjFz+ g9J2nm6aJH37/rg592KLFGm/8KzpGk6bcrSe6/6ZJbcrUw6XLUWN0A/MTL6ZrL4fpUGj R/vg==
X-Gm-Message-State: AIkVDXKM9n1vhlCdz3v7d7yPaQ5Vo5ldZRWXA0vTkrUypXtaVOMNhn1yfJUn+eqNiZvfGeOXo5KKGoHqGTQypw==
X-Received: by 10.28.211.72 with SMTP id k69mr50906840wmg.137.1483474019097; Tue, 03 Jan 2017 12:06:59 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Tue, 3 Jan 2017 12:06:57 -0800 (PST)
In-Reply-To: <C93A4EFBD3E91F4F714DF948@caldav.corp.apple.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: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 3 Jan 2017 15:06:57 -0500
X-Google-Sender-Auth: jyHCOKz6rMHmDQWc6RlxeAj-s8Y
Message-ID: <CAMm+LwgWSp7R=vZfWNXTsk4DjCDAWo4PVNnYsGPrewZp2Ng0hw@mail.gmail.com>
Subject: Re: Predictable Internet Time
To: Cyrus Daboo <cyrus@daboo.name>
Content-Type: multipart/alternative; boundary=001a11470106f1248505453635b8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/T3xEU94Y-qjYJGIA6TNLa7at04w>
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:07:03 -0000

+1

Case in point, the time displayed on my Honda Oddy does not correct for
daylight savings correctly because some pimple brain decided to vary the
date of the switchover and there is no way to update the firmware without
spending stupid amounts of money to do so.

This is the sort of thing I would like to be able to avoid in IoT. The
problem being that to do so requires vendors to think about problems as
something other than an excuse to sell a 'pro' version or updates.

One of the things that is really odd about time as a social construct is
just how easy it is to tamper with it. And 95% of the reason people do
tamper has nothing to do with purported benefits, it is to show that they
can.

When the UK went on to permanent summer time for a brief period, accidents
shot up in the mornings which is the only effect that can be attributed to
the change. The accident rate was reduced by more in the evenings but
subsequent analysis showed that the effect was due to drink driving being
banned at the same time.

The definition of time has always been driven by technology, Railway time
is the reason we have time zones in the first place. Solar noon at
Greenwich varies by +/- 15 minutes over the year.


Not being able to predict with accuracy when a future time expressed in
civil time will occur is a problem.



On Tue, Jan 3, 2017 at 2:54 PM, Cyrus Daboo <cyrus@daboo.name>; 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.
>
> --
> Cyrus Daboo
>
>