From owner-cvs-src@FreeBSD.ORG Thu Oct 20 18:13:11 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B41616A41F; Thu, 20 Oct 2005 18:13:11 +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 EB34943D62; Thu, 20 Oct 2005 18:13:10 +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 j9KIBwrk012132; Thu, 20 Oct 2005 12:11:59 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 20 Oct 2005 12:13:18 -0600 (MDT) Message-Id: <20051020.121318.117917917.imp@bsdimp.com> To: bde@zeta.org.au From: "M. Warner Losh" In-Reply-To: <20051021011035.T1945@delplex.bde.org> References: <25112.1129812291@critter.freebsd.dk> <20051021011035.T1945@delplex.bde.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]); Thu, 20 Oct 2005 12:12:01 -0600 (MDT) Cc: cvs-src@FreeBSD.org, phk@phk.freebsd.dk, src-committers@FreeBSD.org, andre@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/vmstat vmstat.c src/usr.bin/w w.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 18:13:11 -0000 In message: <20051021011035.T1945@delplex.bde.org> Bruce Evans writes: : > You can by definition not implment difftime correctly since the : > time_t timescale does not contain any indication of leapseconds. : > : > This means that there is no way to tell which side of an inserted : > leapsecond a time(2) timestamp comes from: : > : > UTC time(2) : > 23:59:57 N-3 : > 23:59:58 N-2 : > 23:59:59 N-1 : > 23:59:60 N : > 00:00:00 N : > 00:00:01 N+1 : > : > Worst case, difftime() will be wrong by two seconds: taking the difference : > from one leapsecond to another and guessing wrong in both ends. : : It only has to be wrong by 1 or 2 seconds for short intervals when a leap : seconds occurs. Not adjusting makes difftime() wrong across all intervals : containing a leap second, with an error of the number of leap seconds in : the interval (+- 1 or 2 for leap seconds at endpoints). Where do you keep the table of leapseconds? How do you make sure it gets updated? As far as I know, there's no installed leap second data on the system, unless you've enabled the 'run in TAI instead of UTC' mode. Leaving aside the leap table issue for the moment, there's a more fundamental problem. You cannot possibly compute correct answers for times that are in the future, even a little ways in the future. What if time1 is June 30, 2006 23:59:58 and time2 is July 1, 2006 00:00:01. While neither of these seconds are ambiguous, no one on the planet can say today, with certainty, what the answer will be. We have to wait until early January when IERS issues the next Bulletin C. You cannot know today if the right answer is 2, 3 or 4. If there's a negative leap second at the end of June 30, then the answer is 2, if there's no leap second the answer is 3, if there is a positive leap second, the answer is 4. One can only predict what might happen. Until 6 months before the leap second, no one knows what the schedule will be. Have I mentioned my extreme and abiding love for leap seconds lately? Now you know why :-) Warner