From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 20:50:40 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 780CE16A41F for ; Mon, 2 Jan 2006 20:50:40 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.uni-dortmund.de [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 971BF43D53 for ; Mon, 2 Jan 2006 20:50:39 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 5B5F744128; Mon, 2 Jan 2006 21:50:38 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17485-02; Mon, 2 Jan 2006 21:50:36 +0100 (CET) Received: from m2a2.dyndns.org (p5091360C.dip0.t-ipconnect.de [80.145.54.12]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 700AB440A8; Mon, 2 Jan 2006 21:50:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id BC291200A3B; Mon, 2 Jan 2006 21:50:35 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04166-04; Mon, 2 Jan 2006 21:50:32 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 8D44D201628; Mon, 2 Jan 2006 21:50:32 +0100 (CET) From: Matthias Andree To: "Poul-Henning Kamp" In-Reply-To: <80148.1136231640@critter.freebsd.dk> (Poul-Henning Kamp's message of "Mon, 02 Jan 2006 20:54:00 +0100") References: <80148.1136231640@critter.freebsd.dk> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 02 Jan 2006 21:50:32 +0100 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: Matthias Andree , 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 20:50:40 -0000 "Poul-Henning Kamp" 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... > > No POSIX compliant system can tell the difference, not even FreeBSD. Well, some systems appear to be cheating, at the expense of "length of a second"... >>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. > > Yes, that is a total non-starter, now we don't even know how long > seconds are going to be any more :-( ...as you word it. Some systems seem to actually be doing this, in a slightly different manner, today. Check Linux's kernel/timer.c (I was looking at SUSE 10.0, which is based on 2.6.13), if NTP tells Linux "heya, how 'bout a leap second insertion today", Linux will log a message at UTC midnight, slew the clock by 500 ppm and compensate over the next 2,000 seconds, without stepping backwards. You can argue that Linux's notion of a second is off (because it's actually 1,000.5 ms), and that the clock is off during these 33'20" - on the other hand, time of day is monotonic, a "make" process running during the leap second and its preceding second. > Computers should use UTC because UTC underlies civil timekeeping. I don't care the least about civil timekeeping if it breaks builds. The simple solution would be to block all file creations by non-realtime processes during that inserted leap second, which causes similar symptoms to an I/O load spike (or disk retry on read or whatever) that prevent 23:59:60. Yes, it's ugly. But at least it doesn't break builds. And tell me one reason why the leap second must be discontinued while the leap day (Feb 29th) can be carried on. It's the same story, irregular rollover, inserting one particular unit of time. > It's the definition of UTC that is the problem, not the choice of it. Seems like exchanging cause and effect. If it's got a problematic definition, why choose it? Of course FreeBSD won't change POSIX and we don't want to deviate from POSIX >>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"? > > If there are no more leap seconds, POSIX doesn't have to specify > how to deal with them. That one excess "if"... >>It appears all POSIX machines I look after got the leap second right one >>way or another[...] > > None of them got it right by any strech of the imagination because > it is impossible to get it right and be POSIX compliance. Wow, and you claim FreeBSD handles it correctly. -- Matthias Andree