From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 05:14:16 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 DB54C16A41F for ; Tue, 3 Jan 2006 05:14:15 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49F4743D62 for ; Tue, 3 Jan 2006 05:14:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id k035DWul017706; Mon, 2 Jan 2006 22:13:32 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Jan 2006 22:13:44 -0700 (MST) Message-Id: <20060102.221344.32719867.imp@bsdimp.com> To: matthias.andree@gmx.de From: "M. Warner Losh" In-Reply-To: <20060102162117.GB14097@merlin.emma.line.org> References: <79206.1136213035@critter.freebsd.dk> <20060102162117.GB14097@merlin.emma.line.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Mon, 02 Jan 2006 22:13:32 -0700 (MST) Cc: phk@phk.freebsd.dk, 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: Tue, 03 Jan 2006 05:14:16 -0000 In message: <20060102162117.GB14097@merlin.emma.line.org> Matthias Andree writes: : I'm only annoyed that POSIX pretends leap seconds were non-existant, and : even more because I have no satisfactory answer to my question how : FreeBSD knows that a file created at 23:59:59.2 is older than a file : created at 23:59:60.1 if the timestamp is recycled but rather : unsubstantiated assumptions about the amount of research I have done. I : don't want to bore readers on mailing lists with epic breadth... It can't know. POSIX's time_t is ambiguous. Get annoyed, but get used to it. :-) : > Second, reliably getting hold of the UTC-TAI delta is exactly the : > same job as reliably getting hold of leap-second information. : : I'm aware of this problem, and I am aware that this is, according to : Dave Mills (which he underlined again in January 2004), the showstopper : that prevented NTPD from switching to TAI, because many applications : desire UTC and knowing leap seconds only 6 months in advance is too : short notice for autonomous appliances. Yup. : > 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). : : Wrong, I have read up a bit (Mills, Kuhn, your posts and FAQ entries), : and made up my mind - just because I'm not writing a dozen cubits of : parchment full with prose doesn't mean I don't know, and I am not : suggesting to warp time(3) or similar incompatible changes. : : (I omitted mention of Dan J. Bernstein who is also in the favor of the : TAI approach because that would lead to even more bikeshedding.) : : Markus Kuhn suggested adding a new interface, or as an alternative : solution, smoothing the UTC by slewing the clock ("UTS") for the past : 1,000 seconds before the insertion or deletion of the leap second. : : TAI is the monotonous timescale that computers should have been using : since Epoch, but I'm not sure who was there first, TAI or UNIX. : : Why "TAI is not a real-time clock" is irrelevant is that no-one uses : internal timestamps for presentation anyways. The goals are: 1. : consistent time across POSIX computers, 2. monotonic clocks inside POSIX : computers (which is an extension currently), 3. a time presentation to : end users that matches the astronomical view of "noon". There are no standards. No matter what we do here, we have to invent something. : > 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. : : Does POSIX specify a solution to the problem with the ordering of the : two files' age I outlined above? Not to my knowledge, so how can it : possibly be "correct"? Nope. Posix sucks. : > 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. : : Any precendents where the leap second didn't work? URL suffices. : : It appears all POSIX machines I look after got the leap second right one : way or another, the Linux machines slewed their clocks by 500 ppm, what : the Solaris 8 machines did, I didn't check, since I have more : interesting things to do on New Year's Day at 1 a.m., but they didn't : log any difficulties, the FreeBSD machines were offline and resynched : through ntpdate at bootup (no info), so I'm taking your word UTC remained : correct. FreeBSD properly stepped the time. Warner