From owner-freebsd-current@FreeBSD.ORG Tue Jan 3 05:10:50 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 639E716A41F for ; Tue, 3 Jan 2006 05:10:50 +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 E4A0743D53 for ; Tue, 3 Jan 2006 05:10:49 +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 k035AYWT017669; Mon, 2 Jan 2006 22:10:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 02 Jan 2006 22:10:46 -0700 (MST) Message-Id: <20060102.221046.75255380.imp@bsdimp.com> To: matthias.andree@gmx.de From: "M. Warner Losh" In-Reply-To: References: <73774.1136109554@critter.freebsd.dk> 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:10:35 -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:10:50 -0000 Hit the delete key now if you don't care why I hate leapseconds so much :-) In message: Matthias Andree writes: : Poul-Henning Kamp writes: : : > http://phk.freebsd.dk/misc/leapsecond.txt : > : > Notice how CLOCK_REALTIME recycles the 1136073599 second. : : Well, it is in accordance with POSIX, but that doesn't mean its : "correct". POSIX is broken by design. It does not define what happens to system time during a leap second. : How does the POSIX "consistency" babble, and particularly the FreeBSD 5 : or 6 implementation, make sure that "make(1)" or other application : doesn't see a file created on 2005-12-31T23:59:60.1Z as older than a : file created 0.9 seconds earlier, on 2005-12-31T23:59:59.2Z, because of : the time warp caused by POSIX's demand to ignore leap seconds? It doesn't. FreeBSD (and other systems) run in UTC. UTC is a timescale that jumps. There are inconsistancies in it, and math with UTC time stamps is consequently hard. : 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? Nope. That's not standard. Getting a leap second table is hard. You *MUST* have one, no matter what time scale you run in. If you run in UTC, you can get away with being blissfully ignorant (if you don't care about time_t subtraction accross leap seconds). If you run in TAI, you need to have a complete table in order to print times correctly. It is even worse than this. As of this instant, no one can tell me with absolute certainty, how many seconds will elapse between June 29, 2006 0:00:00 and July 2 0:00:00. No one. We'll know in a few days or weeks when Bulletin C is published. No one will know for sure the answer for Dec 30 2006 0:0:0 to Jan 2 2007, 0:0:0 until sometime in July. : The FreeBSD 6 zoneinfo stuff seems to be ready for leap seconds, if only : someone uses -L leapseconds with zic. It appears some systems (SUSE : Linux) have been doing such for a subdirectory right/ : (i. e. TZ=right/Europe/Berlin) for half a decade now. We could also add the right directory. But "right" here isn't really right. There are lots of issues with it for people that don't expect the system time to be in TAI... One has been able to add LEAPSECONDS=yes to make.conf for a very long time.nnn The biggest problem with compiling leap seconds into this is that you can only be sure that leap seconds are right for at most 6 months. Sure, you can make statistical statements about how likely a leap second is or isn't going to be, but this non-determinism is a big problem. There's no way you can deploy a system and have a sane leap second table without a connection to the outside world... I'll bet that the Debian system was installed 5 years ago with the so-called 'right' tables has only had the right leap table for this past leap seconds for 3-4 months tops. This last leap second was not announced until July 4, 2005. Leap seconds are evil. For such a simple concept, they are damn hard to get right. China's time broadcast was interrupted for 61s at the leap second. Others have reported anomalous behavior in the ntp stratum 1 servers, and other time signals had various anomalies (including the cool real-time spectrum trace of many time signals, with annotations: http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html). Leap seconds are hard and I hate them. But I've been paid for over 120 hours in the past couple of years to make sure that we got them right. It was some of these hours that ensured that the proper fixes to FreeBSD were integrated well in advance of this last leap second. Yet, I'd give up 3 weeks pay to never have to deal with leap seconds again :-). Warner