Re: Predictable Internet Time

"Patrik Fältström " <> Wed, 19 April 2017 05:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA04B126C83 for <>; Tue, 18 Apr 2017 22:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0RfFJcMAN3FV for <>; Tue, 18 Apr 2017 22:18:32 -0700 (PDT)
Received: from ( [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BF49120724 for <>; Tue, 18 Apr 2017 22:18:32 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 35E4721D98; Wed, 19 Apr 2017 07:18:30 +0200 (CEST)
From: Patrik Fältström <>
To: Toerless Eckert <>
Cc: Nico Williams <>, Phillip Hallam-Baker <>, IETF Discussion Mailing List <>, Paul Eggert <>
Subject: Re: Predictable Internet Time
Date: Wed, 19 Apr 2017 07:18:29 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <20170418222004.GB2856@localhost> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_2CD5272D-254C-4CD3-81A3-52CF5DD099DD_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6082)
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: Wed, 19 Apr 2017 05:18:34 -0000

On 19 Apr 2017, at 1:21, Toerless Eckert wrote:

> Nice!
> Why not start to tackle the problem pragmatically before asking for standards when its clearly a political issue.
> a) RFC describing the problems developers and system deployments can face  because of leap seconds.
> b) And best current practices to get around those issues. Eg: Expect clock  smear on Jan 1 == reduced accuracy of ~1. Unless OS or other trusted  info source gives explicit indication: NO leap, no smear.
> c) And finally a description of the worst open issues when b) is applied.
>    Anything worse than labels on products "reduced functionality on Jan 1   after a leap second" ?

I want as potential fixes which I think are doable:

- an updated POSIX definition where the variable which holds the number of seconds since the epoch when converting back and forth to date actually will hold the number of seconds since the epoch.

- a slot in the NTP protocol not used today include the number of leap seconds so people get to know that.

FWIW I am a person that is against smear. I think a clock must be able to give the correct time and that timestamps should be correct. Either in seconds (and fractions of seconds) since the epoch or in correct date and time UTC. Both are increasing all the time. And because of that smear should not have to happen.

That said, I am not against a BCP explaining the issues due to for example the broken POSIX specification (which makes it hard to "do the right thing" in software).