From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 14:44:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A494C16A41F for ; Mon, 2 Jan 2006 14:44:02 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAFAD43D5A for ; Mon, 2 Jan 2006 14:44:01 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id A9E75BC50; Mon, 2 Jan 2006 14:43:55 +0000 (UTC) To: Matthias Andree From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 02 Jan 2006 15:00:50 +0100." Date: Mon, 02 Jan 2006 15:43:55 +0100 Message-ID: <79206.1136213035@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2006 14:44:02 -0000 In message , Matthias Andree writes: >Are there plans to add monotonous TAI clock interfaces to FreeBSD 7 so >we have an alternative to the differential CLOCK_MONOTONIC and the jumpy >CLOCK_REALTIME? Is any reader of this message aware of efforts to >standardize such a TAI clock? No such effort is underway, partly because it does not solve the problems. First of all, TAI is not a real-time clock, it is an after the fact paper clock. Second, reliably getting hold of the UTC-TAI delta is exactly the same job as reliably getting hold of leap-second information. Third, it sounds like you really havn't studied this to any dept since, quite clearly, you attack the problem from the wrong end (making FreeBSD non-portable) rather than the right end (make sure that computer standards represent time according to our definition of time). You can either fix POSIX to cope correctly with leap-seconds or you can abandon leap seconds which also fixes POSIX for the future, but adding non-standard timescales to FreeBSD will not solve the problem. I think abandonning leap seconds so that POSIX becomes correct is by several orders of magnitude the more economical solution. The fact that the global network of NTP servers which are run by the most "time" interested and motivated people in the computing world couldn't get a leapsecond right this time only reinforces this view. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.