Re: Predictable Internet Time

Phillip Hallam-Baker <> Fri, 21 April 2017 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DBDE129B8C for <>; Fri, 21 Apr 2017 13:29:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 g9QseNuf43-u for <>; Fri, 21 Apr 2017 13:29:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8CF8127B57 for <>; Fri, 21 Apr 2017 13:29:25 -0700 (PDT)
Received: by with SMTP id x184so111932877oia.1 for <>; Fri, 21 Apr 2017 13:29:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=6Iq74/u51xOgBPRrxsBlybcuIJOLuf8t8H/qWA45lq0=; b=rt/ywZumMzKYgkT4onRQ4zAoAqyjWlzNOYF/jG//JvW+QO3gR2wkXrVV5+NbLKzcXR rqr1YR6RJOR4TtWQU2hfN4qDHcVGKvS+vEEjQJ3cgloABDJk3adVCXJwDsS1QDbwp2NG xQl4BBDRjnRx/l6fp4RTWL/kD3GXEDECmvcB8cjIN8Oj81cKIK/ATV4GJ5zE/OhGWKNg Vo6ZRVO8Rg2q75O+Ut1trFPxa7uJZFkLXXp+T3ZJQmMz3RzObo+zE0+HLU26MzqT00/0 XUaz/pGj6eVlrIyNzwB5DW2hke4C4BnJez6v87aS5jLowuwWHqwu5CgSSDXZ/ylYhWXd YjdA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=6Iq74/u51xOgBPRrxsBlybcuIJOLuf8t8H/qWA45lq0=; b=GBM5f4kBJlyy8+yqOhg/xRmXDF/kpAzFkHEnrlKcSXzGy8DBm6BjmjtgN6WjushvCd U28kZRoEtPsSUVnhgti7zov5XIQwPyMKj7JDAGDlIg8xTuAg+N3YEzUU91hhv2DreuxT 6cbsdV4Lm0iH6QK/Ct2dty+toDvWERAgblzFffQEuI1I65Pog+g49TrTVMkt6W22KS2t yZfHp+Zq2wEN+/F4+WwwmeLiO7v59/IQC0KER1SDavldvB4a8/TZIws/TFn3ydYig85E /yQAvTDUnNA7rPTtk2PS9Qg+/bri1SOPGGtlHd9LsqBvGCE6ceoAVMkfheR5tJtRwkC2 fl5Q==
X-Gm-Message-State: AN3rC/5gQn3JI5RjMuFkvhNw7jp1hnrYdG1T5ID7hx0snIimSKR6kfEy 5U7MJXWWYCE3CxfnViCzUynLTKOt7w==
X-Received: by with SMTP id t197mr9071983oit.104.1492806565342; Fri, 21 Apr 2017 13:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Apr 2017 13:29:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <20170418222004.GB2856@localhost> <> <20170421172626.GG2856@localhost> <> <> <>
From: Phillip Hallam-Baker <>
Date: Fri, 21 Apr 2017 16:29:24 -0400
X-Google-Sender-Auth: SGffTjJ738bDI_FQwOurBjM0BLc
Message-ID: <>
Subject: Re: Predictable Internet Time
To: Joe Touch <>
Cc: Nico Williams <>, Paul Eggert <>, IETF Discussion Mailing List <>, Patrik Fältström <>
Content-Type: multipart/alternative; boundary="001a1137b4f80bb38f054db31d17"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Apr 2017 20:29:28 -0000

On Fri, Apr 21, 2017 at 2:41 PM, Joe Touch <> wrot

> On 4/21/2017 11:35 AM, Phillip Hallam-Baker wrote:
> ​To answer the issues raised:
> 1) POSIX already has this pretty much covered
> ​
> ​int clock_gettime(clockid_t *clock_id*, struct timespec **tp*);​
> ​So all that is required is to define clock identifiers for:
> TAI (The total number of seconds elapsed since the start of the epoch)
> UTC (The TAI value adjusted for UTC leap seconds, i.e. number of non leap
> second seconds since the start of the epoch)
> If these aren't already included, I'm surprised (at least UTC).

​Well I linked to the spec so you could have looked and checked. You are
wrong. The spec is ambiguous as to whether the value is UTC or not, hence
the need to be explicit. ​

> PIT (The TAI value adjusted for PIT leap seconds)
> We don't need PIT.
> ​That is your opinion, like the astronomers, you might just be wrong about
the requirements.

I can see the benefit of an IoT where time is absolutely predictable even
if it may be out of sync with UT by a few seconds.​ You might not but I
doubt you have the range of experience in realtime and process control that
I have.

​Unless a device actually deals in time, PIT is going to be just fine for
status messages and logs. The advantage over UTC being that you know
exactly what the device is trying to do which you don't have with UTC. You
don't know whether the device is keeping UTC or some heuristic.

TAI would be a possibility if we counted in seconds which we don't. We
track time by date and need to compare. The difference between UTC and TAI
is half a minute which is just too much to be viable.​

> All that is needed is to define the additional ones.
> ​2) No I did not move the goalposts. My original proposal was to solve the
> needless chaos caused be the idiotic notion of changing the definition of
> time at six months notice. The stupidity of that notion should be apparent
> to all.
> There is no getting around the fact that the rest of the planet accepts
> leap seconds. If that's not something you want to track, then use TAI and
> be off-sync with the rest of the world when they use UTC.

​Since the standard was only created in our lifetimes, it is hardly
immutable and fixed for all eternity.

The reason UTC is the standard is because it is what the ITU decided to use
and the broadcasters synchronize everything. That can change.