Re: Predictable Internet Time

"Patrik Fältström " <> Wed, 29 March 2017 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2F80127241 for <>; Tue, 28 Mar 2017 22:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UKYNP0LXSZ-e for <>; Tue, 28 Mar 2017 22:52:19 -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 8F172129666 for <>; Tue, 28 Mar 2017 22:52:19 -0700 (PDT)
Received: from [] (unknown [IPv6:2a01:3f0:1:0:40c0:f25d:2a01:265]) by (Postfix) with ESMTPSA id 106A821903; Wed, 29 Mar 2017 07:52:16 +0200 (CEST)
From: Patrik Fältström <>
To: Joe Touch <>
Cc: Phillip Hallam-Baker <>, Tony Finch <>, IETF Discussion Mailing List <>, Jared Mauch <>
Subject: Re: Predictable Internet Time
Date: Wed, 29 Mar 2017 07:52:15 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_06216BC6-9D1F-4127-BB5B-A375C618C7E9_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6080)
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, 29 Mar 2017 05:52:22 -0000

On 28 Mar 2017, at 19:47, Joe Touch wrote:

> On 3/27/2017 11:37 PM, Patrik Fältström wrote:
>> Joe,
>> I have read your I-D and like it! Let me start there :-)
>> What I think is not clear enough is the problem with POSIX, and it should be more clear in some place, maybe section 6.1, that POSIX definition which is in use in quite a number of systems do not handle leap second very well. Too many do believe the time_t definitions include the number of seconds since epoch when in reality it does not (as you note in the definitions).
> I can make that more clear, but AFAICT POSIX time is *defined* as seconds since the Unix epoch *not counting* leap seconds at all.

Well, one of the problems is that the specification of POSIX time is a bit unclear.

>> One could even question whether it is Continuous as two seconds will have the same number since epoch around the addition of a leap second
> > It is Continuous by definition.
> When UTC adds a leap second, nothing different happens to POSIX time.

No, that is not correct if you look at the day when the leap second is added.

POSIX is number of (days * 86400) plus seconds inside the current day. This implies if there is a day with a leap second there will be 86401 seconds which also will be the first second the following day.

>> There are some people that have suggested a change, for example <> but I have not seen any movement. Maybe you know more than me on this?
> AFAICT, that's just attempting to redefine the <time.c> interface as returning UTC rather than POSIX time.

The UNIX time_t struct do deliver UTC, including leap seconds, but the number of seconds from epoch is wrong regarding leap seconds. Includes one leap second within the day of the leap second being added and without leap seconds otherwise.

> Which works *IF* your machine has access to updated leap-second information, e.g., via NTP.

Correct, if one have access to leap seconds, one could adjust the number of seconds and that could happen already today as POSIX definition is a bit unclear on this. But people have not implemented it. So instead for example Google smear the leap second over the day so that there is not bump in the road, and they run NTP servers that do give back this smeared time that differs from UTC.

All just because a. unclear information from POSIX and b. bad implementations in *ux.