Re: [LEAPSECS] Equitable estoppel
In message: <17799.12498.783147.528864_at_gromit.timing.com>
John E Hein <jhein_at_timing.com> writes:
: Peter Vince wrote at 20:15 +0000 on Dec 18, 2006:
: > >For the moment, if leap seconds is to be abbandoned, I would favour the leap
: > >minute instead.
: >
: > Is that not sitting on the fence, and ending up with the worst of
: > both worlds? It is neither as precise as leap (micro, milli, or
: > whole) seconds, nor as long term as leap hours. It would put off the
: > updates for only a few tens of years, by which time experience of
: > them would have been lost, and our descendants would end up with Y2K
: > type problems.
: >
: > Peter Vince
:
: One of the problems described on this list in the past is that of leap
: tables in devices designed to operate over 10-20 years without
: availability of leap second updates. Being able to rely on a table
: that is good for that long makes the job of the designer much easier.
As would a schedule for the next 10 years, say something like:
Dec 2007
Jun 2009
Jun 2010
Dec 2012
Dec 2013
Jun 2015
Jun 2016
Dec 2018
...
The state of the art is such that we have a high confidence of being
able to predict things out at least 18 if not 36 months and still
keeping within the 0.9s performance goal. If that were loosened a
little, then we could schedule things out 10 years or so. It could
even be phased in so that the next two leap second opportunities could
be scheduled after the first of the year, and the two following that
after June, etc until. While annoying, at least it would be known far
in advance and start to feel more like a leap day rather than a total
pita.
: In this respect, leap minutes would be "better" than leap seconds.
Then a leap hour would be 60 times better[*] Of course, a leap minute
would happen once or twice a lifetime. A leap hour happens once every
100 generations or so...
: Do not mistake this comment as an advocation of leap minutes.
Ditto for me...
Warner
[*] And 3600 times more disruptive and less likely to get right...
Received on Mon Dec 18 2006 - 20:33:51 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:55 PDT