Date: Mon, 02 Jan 2006 22:13:44 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: matthias.andree@gmx.de Cc: phk@phk.freebsd.dk, current@freebsd.org Subject: Re: FreeBSD handles leapsecond correctly Message-ID: <20060102.221344.32719867.imp@bsdimp.com> In-Reply-To: <20060102162117.GB14097@merlin.emma.line.org> References: <m3psnaenl9.fsf@merlin.emma.line.org> <79206.1136213035@critter.freebsd.dk> <20060102162117.GB14097@merlin.emma.line.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20060102162117.GB14097@merlin.emma.line.org> Matthias Andree <matthias.andree@gmx.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060102.221344.32719867.imp>