ITC copped out on UTC again
Phillip Hallam-Baker <hallam@gmail.com> Fri, 20 January 2012 14:20 UTC
Return-Path: <hallam@gmail.com>
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 8711921F85F7 for <ietf@ietfa.amsl.com>; Fri, 20 Jan 2012 06:20:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.281
X-Spam-Level:
X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pu6Aiuzh-BzP for <ietf@ietfa.amsl.com>; Fri, 20 Jan 2012 06:20:50 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A89B321F8643 for <ietf@ietf.org>; Fri, 20 Jan 2012 06:20:50 -0800 (PST)
Received: by obbwc12 with SMTP id wc12so935121obb.31 for <ietf@ietf.org>; Fri, 20 Jan 2012 06:20:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=xh11zY3v8iQXbSMzZ1a3UIVPvS66b2UnAb4rfNkP4cA=; b=uKz0knlcvq2qhy7kkjKiuQ0mh9oePskfvcNvfU44LKvO27IXyYjgvBVfvuTzRDuGMJ 19xwKjhOMVlG4zZnWjZNCcU5H9MgKMQQ9S1lSvXnCPZ607v+15YHomha9TtXVIOfB4cB fvDtudiNl5rsj9sBLwZ6McmUQiT9zixR/NpoU=
MIME-Version: 1.0
Received: by 10.182.159.70 with SMTP id xa6mr27043211obb.1.1327069250346; Fri, 20 Jan 2012 06:20:50 -0800 (PST)
Received: by 10.182.11.169 with HTTP; Fri, 20 Jan 2012 06:20:50 -0800 (PST)
Date: Fri, 20 Jan 2012 09:20:50 -0500
Message-ID: <CAMm+LwgtUzw9GB1Mc=zQ3Fr_RPrsfy7d59HH6fstvsgTN=_C+g@mail.gmail.com>
Subject: ITC copped out on UTC again
From: Phillip Hallam-Baker <hallam@gmail.com>
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="14dae9399771425d9604b6f663fd"
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 20 Jan 2012 14:20:51 -0000
If we are ever going to get a handle on Internet time we need to get rid of the arbitrary correction factors introduced by leap seconds. The problems caused by leap seconds are that they make it impossible for two machines to know if they are referring to the same point in future time and quite often introduce errors in the present. 1) No machine can determine the number of seconds between two arbitrary UTC dates in the future since there may be a leap second announced. 2) If Machine A is attempting to synchronize with machine B on a future point in time, they cannot do so unless they know that they have the same view of leap seconds. If a leap second is announced and only one makes the correction, an error is introduced. 3) In practice computer systems rarely apply leap seconds at the correct time in any case. There is thus a jitter introduced around the introduction of leap seconds as different machines get an NTP fix at different points in time. 4) Even though it is possible to represent leap seconds correctly in standard formats, doing so is almost certain to exercise code paths that should be avoided. Since the ITU does not look like sorting this out, I suggest we do so in the IETF. There is no functional reason that Internet protocols should need leap seconds. I suggest that the IETF plan to move to Internet Time in 2015, immediately after the next ITU meeting. Internet time would be TAI plus the number of leap seconds that have accumulated up to the next ITU decision point. So if UTC drops leap seconds at the next meeting the two series will be in sync, otherwise there will be a divergence. -- Website: http://hallambaker.com/
- Re: ITC copped out on UTC again Eliot Lear
- Re: ITC copped out on UTC again Tim Bray
- Re: ITC copped out on UTC again Nick Hilliard
- ITC copped out on UTC again Phillip Hallam-Baker
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Marshall Eubanks
- Re: ITC copped out on UTC again Marshall Eubanks
- Re: ITC copped out on UTC again Nick Hilliard
- Re: ITC copped out on UTC again Marshall Eubanks
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Nick Hilliard
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Ofer Inbar
- Re: ITC copped out on UTC again Michael Richardson
- Re: [IETF] Re: ITC copped out on UTC again Warren Kumari
- Re: ITC copped out on UTC again todd glassey
- Re: ITC copped out on UTC again Clint Chaplin
- Re: ITC copped out on UTC again Randy Presuhn
- Re: ITC copped out on UTC again Brian E Carpenter
- Re: ITC copped out on UTC again Phillip Hallam-Baker
- Re: ITC copped out on UTC again Bob Hinden
- Re: ITC copped out on UTC again Pete Resnick
- Re: ITC copped out on UTC again Eliot Lear
- Re: ITC copped out on UTC again todd glassey
- Re: ITC copped out on UTC again Michael Richardson
- Re: ITC copped out on UTC again Alessandro Vesely
- Re: ITC copped out on UTC again Eliot Lear
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Ray Bellis
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again Marshall Eubanks
- Re: ITC copped out on UTC again james woodyatt
- Re: ITC copped out on UTC again Tony Finch
- Re: ITC copped out on UTC again John C Klensin
- Re: ITC copped out on UTC again Steven Bellovin
- Re: ITC copped out on UTC again Brian E Carpenter
- Re: ITC copped out on UTC again james woodyatt