Re: FreeBSD handles leapsecond correctly

On Tue, 2006-Jan-03 01:55:16 -0700, M. Warner Losh wrote:
>In message: <20060103061752.GE42228_at_cirb503493.alcatel.com.au>
>            Peter Jeremy <PeterJeremy_at_optushome.com.au> writes:
>: 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.

That brings you into the high-end OCXO range I think - though I was
thinking in terms of systems which needed to distinguish UTC and TAI
without any external references.

>: to tell the difference requires an atomic clock - which isn't common
>: in embedded systems.
>
>Unless those embedded systems deal with time.

Timing products are obviously a special case.  I still stand by my
"common" statement.

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

In this case, the problem is that the connection to the outside world
exists but does not provide the required information (UTC/GPS offset)
in a timely manner.  You could suggest that if the correct time is
that critical to the customer, maybe they should be using hot-standby,
not cold-standby spares :-).  Does Galileo handle this any better?

I now have a much better understanding of the background to your stance
on leap seconds.

-- 
Peter Jeremy