Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Jan 2006 15:43:55 +0100
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        Matthias Andree <matthias.andree@gmx.de>
Cc:        current@freebsd.org
Subject:   Re: FreeBSD handles leapsecond correctly 
Message-ID:  <79206.1136213035@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 02 Jan 2006 15:00:50 %2B0100." <m3psnaenl9.fsf@merlin.emma.line.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <m3psnaenl9.fsf@merlin.emma.line.org>, Matthias Andree writes:

>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?

No such effort is underway, partly because it does not solve the
problems.

First of all, TAI is not a real-time clock, it is an after the fact
paper clock.

Second, reliably getting hold of the UTC-TAI delta is exactly the
same job as reliably getting hold of leap-second information.

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).

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.

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.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?79206.1136213035>