Re: FreeBSD handles leapsecond correctly

In message: <20060102162117.GB14097_at_merlin.emma.line.org>
            Matthias Andree <matthias.andree_at_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