Re: FreeBSD handles leapsecond correctly

Hit the delete key now if you don't care why I hate leapseconds so
much :-)

In message: <m3psnaenl9.fsf_at_merlin.emma.line.org>
            Matthias Andree <matthias.andree_at_gmx.de> writes:
: Poul-Henning Kamp <phk_at_phk.freebsd.dk> 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