Re: [LEAPSECS] Mechanism to provide tai-utc.dat locally

From: M. Warner Losh <imp_at_BSDIMP.COM>
Date: Thu, 28 Dec 2006 18:31:43 -0700 (MST)

In message: <>
            John Cowan <> writes:
: Rob Seaman scripsit:
: > >I don't care if you want to implement leap-milliseconds, as long
: > >as you tell me 10 years in advance when they happen.
: >
: > Again - with no intent to minimize the issues - what supports this
: > assertion? Is there any reason to believe that 10 years advance notice
: > would encourage projects and vendors to do anything other than ignore
: > the requirement entirely? A statement that 10 years, or 600 years,
: > notice is all that is needed to resolve all the problems, smooth over
: > all the complications, is entirely too glib.
: You are confusing the question of fixity (which is what notice is
: about) with granularity. It's true that probably no one would bother
: to implement the ALHP. However, if computer technologists were handed a
: list of leap seconds from now until 2015, and told "Implement these," it
: wouldn't matter how many or how few leap seconds there were. But since
: you astronomers insist on a fixed maximum for |DUT1|, no such table
: can exist.
: The proposal is this: look at the trends, take your best shot at
: working out a leap-year schedule for 10 years in the future, and then
: live with it.

Let's turn the question around. What would the harm be if |DUT1| were
1.1s? 1.5s? 2.0s? Contrast this with the harm and difficulty that
the current 6 month scheduling window affords.

Received on Thu Dec 28 2006 - 17:34:08 PST

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:55 PDT