Re: FreeBSD handles leapsecond correctly

In message: <20060103061752.GE42228_at_cirb503493.alcatel.com.au>
            Peter Jeremy <PeterJeremy_at_optushome.com.au> writes:
: On Mon, 2006-Jan-02 22:10:46 -0700, M. Warner Losh wrote:
: >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...
: 
: The Islamic calendar is based on lunar _sightings_: If it's cloudy,
: the calendar shifts a day.  This wreaks even more havoc than the
: odd leap-second and many Islamic countries have therefore switched
: to using almanac based dates.
:
: Actually, I'd suggest that you can't build a system that keeps any
: sort of accurate time without a connection to the outside world or a
: quite substantial budget.  If you assume a leap second every 5 years
: then the difference between UTC and TAI is about 6e-9 - being able

Actually, that's wrong.  If you assume a leap second every 18 months
you'd be better off, in the long run.

: to tell the difference requires an atomic clock - which isn't common
: in embedded systems.

Unless those embedded systems deal with time.  I build GPS based NTP
servers, amoung other things, in my day job.  You have to get the
right second every time, or people won't buy your products.  This
every time includes cases where the GPS reciever has been a powered
down spare for the past 9 months and therefore has no notion of the
leap seconds that have accumulated.  This means it has to have an
extra long startup period while the GPS receive gets a new almanac.
This long wait is irritating to a customer, as you might imagine.
However, having to handle both cases in your code base is irritating
to a programmer.  We can't start broadcasting time without being
certain that it is right.

The probelm with the dormant system is that we can learn only what the
current table is, not what all the past leap seconds were if a GPS
receiver has been off for a while, unless the computer is connected to
the internet (most of ours are not).  This creates difficulties when
populating leap second tables, as well as any elapsed time
computations with times starting in the past.  This limts what you can
do, but not substantially as you can usually recover the last leap
second if it was recent enough.  GPS gives only the current and future
values, which is mostly good enough for most things.

However, testing these different scenarios can be a royal PITA.
Knowing that you need to test them is even harder.  Knowing what the
actual GPS receiver will report over a leap second is also important.
Assume that the receiver will lie to you, because they all do in some
manner.  This requires that you build lots of knowledge of the rules
of leap seconds into your application.  The more of these you build
in, the more changes that you'll have a bug like some GPS paced
clocked had back on September 30 where they glitched a second because
the leap second future indicator was turned on in GPS more than 3
months before the leap second happened (the data in GPS correctly said
end of year, but these clocks glitched).  Other GPS receivers have
problems where they won't report the correct UTC GPS offset until a
new almanac is downloaded after a leapsecond (if you relied on this
data, then woe be to you).

: >Leap seconds are hard and I hate them.
: 
: Which of the competing alternatives would you prefer?

Kill all leapseconds.  They don't matter.  Move the time zones every
few hundred/thousand years to keep in sync.  Noon is an artificial
construct these days anyway, as solar noon can vary by an hour in most
normal timezones (and more in the weird edge cases like Togo).

Failing that, decide today what the next 10 years of leap seconds will
be and publish that table.  Append to it yearly 1 years (or more)
worth of future leap seconds.  This would require allowing DUT1 to
grow beyond .9s, but would keep things right on the average and be
more predictable than the mess we have today.

Warner