Re: Predictable Internet Time

"Patrik Fältström " <> Tue, 03 January 2017 06:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B43E129534 for <>; Mon, 2 Jan 2017 22:29:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6cFeqJuh-6cH for <>; Mon, 2 Jan 2017 22:29:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CA1A129432 for <>; Mon, 2 Jan 2017 22:29:29 -0800 (PST)
Received: from [] (unknown [IPv6:2a01:3f0:1:0:1444:9050:3204:5960]) by (Postfix) with ESMTPSA id 4521623C70; Tue, 3 Jan 2017 07:29:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1483424967; bh=H8T3oyIxM3zymi11h05z8es4glxB2BsxUVkwshc8F24=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wKfF01ZL7Otz9z5vYGv3ULzVS2boncjg4fnFiYgUtqgDlY7sfq7FALGCaLGAyUoG9 aj0Sj9ZCYVVjq3tWjKRTn+7uFcbpLwB1MM4v0OkwFpwz3xbLALjNTbD3VPZ3cdPTuZ kogWb2pRkv3uZaVTnIzsRCKfClo9Q0cEWjuZlMkg=
From: Patrik Fältström <>
To: Joe Touch <>
Subject: Re: Predictable Internet Time
Date: Tue, 03 Jan 2017 07:29:26 +0100
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_97C59FEA-9DF2-405B-A159-D725123F9652_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6072)
Archived-At: <>
Cc: Phillip Hallam-Baker <>, 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 06:29:31 -0000

There are a number of complicating factors here. One being that we have multiple time scales. Another being that parties do believe things are what they really are.

The main issue with smearing is that UNIX time is really not counting number of seconds from the epoch, which might be what people think. If it was, smearing would not be a good thing as the number of seconds from the epoch ends up being one less due to the smear than the continuous series of SI-Seconds. The number of seconds is guessing that each day have the same number of seconds. So leap seconds are ignored.

Instead the goal with the smear is only to be correct according to UTC.

A correct implementation would of course be to have the number of seconds from Jan 1 1970 be correct, and then a correct translation to UTC. Which requires (both) knowledge of the number of leap seconds -- which you only know for each 6 month interval (sort of). So one do not know the translation between number of seconds since epoch and UTC if you look say 3 years forward in time.

I think personally, as long as we do have leap seconds:

- we should have the leap second information available somewhere in clear machine readable format. Some suggestions exists, including encoding it in A-records in DNS ;-)

- we should look at having the time since epoch really be the number of SI-seconds since the epoch

- we should have translation between number of seconds and UTC take leap seconds into account

- we should fix the code that do not accept 61 seconds in a minute

Now, we can also say we should stop having leap seconds, but I feel that is a _different_ matter and different discussion. I am myself not clear over what is the correct thing regarding leap seconds.

What I am sure of is that I think most of the problems we have is because of bad programming (including in old UNIX days the priorities although correct at the time have continued to let the time_t definition continue to be wrong).