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/