Re: Predictable Internet Time

"Patrik Fältström " <paf@frobbit.se> Tue, 03 January 2017 06:59 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A695A129410 for <ietf@ietfa.amsl.com>; Mon, 2 Jan 2017 22:59:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9n1QNzt4GCA for <ietf@ietfa.amsl.com>; Mon, 2 Jan 2017 22:59:05 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A75A129400 for <ietf@ietf.org>; Mon, 2 Jan 2017 22:59:05 -0800 (PST)
Received: from [77.72.226.187] (unknown [IPv6:2a01:3f0:1:0:1444:9050:3204:5960]) by mail.frobbit.se (Postfix) with ESMTPSA id 5113026604; Tue, 3 Jan 2017 07:59:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1483426743; bh=rVDRYiqT7Ukr8DDIU7JpVT9hErX/g4scwrZMsyurA6k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YjyylLTn34QZmXfW7nYSBHYRpu6vzeSma9teeEdBP2H9QfMwDGvJ7ZOmasPj2LufX vGnLMkxiIQ6Aik7bvmNyqVHMeKUep0o3WicoKWr6ok96Y4jv7WGNGtEU6RjJn7H6AH mIE55oe1+2FD7bpv8Oo29Tz/8W6LJhUY5/Ad2VdU=
From: Patrik Fältström <paf@frobbit.se>
To: Eliot Lear <lear@cisco.com>
Subject: Re: Predictable Internet Time
Date: Tue, 03 Jan 2017 07:59:03 +0100
Message-ID: <B2E6846E-F25B-4792-8E13-B5D898B67223@frobbit.se>
In-Reply-To: <7bc1a350-549c-c649-81c6-bcd19cff36d7@cisco.com>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com> <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu> <B990A5A4-D62B-4E10-9FF7-7BA4377C0958@frobbit.se> <7bc1a350-549c-c649-81c6-bcd19cff36d7@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_E5B78895-F13D-40D4-BADE-AD703772957E_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
X-Mailer: MailMate (2.0BETAr6072)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MvteUG31KPtGmTgcIhAjd44ZTZk>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 06:59:06 -0000

On 3 Jan 2017, at 7:43, Eliot Lear wrote:

> Good morning, Patrik,
>
> On 1/3/17 7:29 AM, Patrik Fältström wrote:
>> 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
>
> The TZDB at IANA contains the file "leapseconds" which is machine readable, and provides a history of all leapseconds.  This provides you the 1st and 3rd of your requirements.

What is important is that the file include also known future leap seconds (and not) like the official memo. So that one can prep the local system with some predictability for the next say 5 months.

Maybe it does. My apologies for being lazy.

>> - 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).
>
> I'm of two minds as well.  On the one hand, the current system makes it quite easy to do the wrong thing, and that's not good.  There are utility functions such as pytz's normalize() and localize() functions that people just don't know about, for instance.  On the other hand, it's not just leap seconds.  It's timezones in general, it's DST transitions, etc.  Getting rid of leap seconds only marginally improves things, and gets really philosophical really quickly...

The problem I have is that we now implement things like smearing which to me is a bad fix for something that is wrong in the first place (definition of time_t).

   paf