IETF Logo Mail Archive

Re: Predictable Internet Time

Cyrus Daboo <cyrus@daboo.name> Tue, 03 January 2017 19:54 UTC

Return-Path: <cyrus@daboo.name>
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 BDC77129B5C for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 11:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 ybQOYaicqwFM for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 11:54:54 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE5312940F for <ietf@ietf.org>; Tue, 3 Jan 2017 11:54:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 86B845FD2A01; Tue, 3 Jan 2017 14:54:53 -0500 (EST)
X-Virus-Scanned: amavisd-new at mydomain = daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUv3i80dzcwt; Tue, 3 Jan 2017 14:54:52 -0500 (EST)
Received: from [17.150.211.187] (unknown [17.150.211.187]) by daboo.name (Postfix) with ESMTPSA id 4F3565FD29F2; Tue, 3 Jan 2017 14:54:50 -0500 (EST)
Date: Tue, 03 Jan 2017 14:54:47 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: Ted Lemon <mellon@fugue.com>
Subject: Re: Predictable Internet Time
Message-ID: <C93A4EFBD3E91F4F714DF948@caldav.corp.apple.com>
In-Reply-To: <A193D619-7B59-4EFB-A773-B6F6E4FD5884@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>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="1054"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/RLY-P3gJMpqnz926_9VSfI2YRWE>
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: Tue, 03 Jan 2017 19:54:56 -0000

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

v2.23.0 | Report a Bug | By Email