Re: FreeBSD handles leapsecond correctly

On Mon, 02 Jan 2006, Poul-Henning Kamp wrote:

> In message <m3psnaenl9.fsf_at_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.

That depends on what you consider "real time" (without dash). Ask two
experts and get three opinions. I don't mean to bikeshed here, I'm
neutral.

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

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

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

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

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

-- 
Matthias Andree