Re: Predictable Internet Time

Joe Touch <> Tue, 28 March 2017 17:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50CDB126B72 for <>; Tue, 28 Mar 2017 10:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xOP6HWbvDvZh for <>; Tue, 28 Mar 2017 10:48:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5E9C1293F8 for <>; Tue, 28 Mar 2017 10:48:47 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id v2SHlUOv012884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Mar 2017 10:47:30 -0700 (PDT)
Subject: Re: Predictable Internet Time
To: Patrik Fältström <>
References: <> <> <> <> <> <> <> <>
Cc: Phillip Hallam-Baker <>, Tony Finch <>, IETF Discussion Mailing List <>, Jared Mauch <>
From: Joe Touch <>
Message-ID: <>
Date: Tue, 28 Mar 2017 10:47:30 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
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: Tue, 28 Mar 2017 17:48:52 -0000

Hi, Patrik,

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.

> 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.

> 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.

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


> On 27 Mar 2017, at 21:34, Joe Touch wrote:
>> Hi, all,
>> I've submitted the time frame discussion intended to resolve this issue, which also recently arouse on another mailing list. Further discussion on this draft will occur on the ART mailing list (
>> Joe
>> -----------
>> A new version of I-D, draft-touch-time-01.txt
>> has been successfully submitted by Joe Touch and posted to the IETF repository.
>> Name:		draft-touch-time
>> Revision:	01
>> Title:		Resolving Multiple Time Scales in the Internet
>> Document date:	2017-03-27
>> Group:		Individual Submission
>> Pages:		17
>> URL:   Status:
>> Htmlized: Htmlized: Diff: 
>> Abstract:
>>    Internet systems use a variety of time scales, which can complicate   time comparisons and calculations. This document explains these   various ways of indicating time and explains how they can be used   together safely. This document is intended as a companion to   Internet time as discussed in RFC 3339.