Re: Predictable Internet Time

Stewart Bryant <> Tue, 03 January 2017 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C23B129AE3 for <>; Tue, 3 Jan 2017 10:55:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e4C6qAIV55NA for <>; Tue, 3 Jan 2017 10:55:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4BFC129AE1 for <>; Tue, 3 Jan 2017 10:55:37 -0800 (PST)
Received: by with SMTP id sd9so267182614wjb.1 for <>; Tue, 03 Jan 2017 10:55:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=srnRtjY5fuzMZsF+nVrpXZX5LRRS3wNGo2RchwAjx3A=; b=aqBO8cG4V0RvDmUEeD9ERd+ZaEmza62mmVnZ1Z47K1KSJTpGy9oIGy4InrmZDFuBFG dDW6TY9yIM9Hvhhvp0gqbz5XpiGcgOE1jadPeLcTeMYHBvGXgY9LEChu5dxK+zrbHSCG gGONdTBR19Ich0/UrxHlDy99wMl3t8hCkvLyS+0pg/CcW4FdU3ELKy2RGRduBHlImUAr E1FhQnGc4Dd68aELQjc7r+PhPqbIP2F4uE9qMcluviA0EIxASI4DwT+lj80PzVnSQlzJ GzOB9634IVKakinGzARhuEHf0sbSRt1l7//pAXUgrjH+wwp+UopaJBY+mX8e2J2CcjQC pDcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=srnRtjY5fuzMZsF+nVrpXZX5LRRS3wNGo2RchwAjx3A=; b=dNTz+fb0bFyDorfVfAxULchhcWyiVmnSFrinMoNp8q/isl8n5IQngfiCVE6u9bz/qb NXZZkxbibUX5JEPv/UKgfXyY6Jd6OXUFIbiph7xptL8erd6SeTaAJRdZ9/3hUoGiHT8S 9GNcriw16N4JsFk5h7ywM/ZrQBvAW2TbOycjwsfYMObW1dPZ8mW9LloqUWzxSTucxiq2 KaGALc7xzdJ2exq06XbbUHjDp0/oi8MOOYDeLAX3u8/id7gPkBbzuP/q1bf1OtOS3TP+ 8a5RQXUwzKMBpX7mBIglcZ70naQFiADfQRrisHILKNnFc8l5/fcux4NBtpYoTlNsL6Uz z5Tg==
X-Gm-Message-State: AIkVDXL+nwTBSJq8el6Lic+nvpUXihg01LTiXnQB/D9yyOY354t1nOTwBPQ9p/TxGkJPlg==
X-Received: by with SMTP id kb11mr53077515wjd.131.1483469736222; Tue, 03 Jan 2017 10:55:36 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i132sm90680481wmf.14.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 10:55:35 -0800 (PST)
Subject: Re: Predictable Internet Time
To: Cyrus Daboo <>, Phillip Hallam-Baker <>
References: <> <> <> <> <> <> <> <> <> <>
From: Stewart Bryant <>
Message-ID: <>
Date: Tue, 03 Jan 2017 18:55:33 +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: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: IETF Discussion Mailing List <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Jan 2017 18:55:39 -0000

On 03/01/2017 18:38, Cyrus Daboo wrote:
> Hi Stewart,
> --On January 3, 2017 at 6:30:19 PM +0000 Stewart Bryant 
> <> wrote:
>> Only the UI needs the TZ information, the machine can operate just fine
>> with any timescale. That is you present the time in local time, but
>> operate in global time, and this is definitely an application that will
>> not care about leap seconds.
> 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.

Hi Cyrus,

I think that depends on what you consider to be the infrastructure and 
what you consider the application. I would like to see the CPU clocks, 
and in particular  the time transfer protocols just work on non-jumpy 
constant-duration-second time since that has to scale from 
sub-femtoseconds to millennia with sub-femtosecond accuracy without 
glitching and with unambiguous duration measurements.

If we distribute time in the infrastructure as  non-jumpy 
constant-duration-second time , then the iCal system can surely do the 
conversion to/from whatever format the human needs? Whether it talks to 
itself in human time or machine time is for those of you that design 
iCal to determine, but it sounds from what you say that it talks to 
itself in human time. Whether it does the conversion from machine time 
to human time, or whether the OS does it for outside the scope of the 
point I am making.

- Stewart