On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote:
Calculating time intervals for times 6+ months in the future can be
the least of one's worries when one tries to code up a library to deal
gracefully with these different failure modes. The trivial case where
one has perfect knowledge of
Poul-Henning Kamp wrote:
I seriously don't belive you do equality comparisons at the 1msec
level in real world software. Please provide examples.
You know you're in trouble when PHK and I agree. One would think a
(double precision) floating point epsilon test might be what you
want. In
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: On Dec 27, 2006, at 12:02 AM, M. Warner Losh wrote:
:
: Calculating time intervals for times 6+ months in the future can be
: the least of one's worries when one tries to code up a library to deal
: gracefully with
On Wed, 27 Dec 2006, John Cowan wrote:
If we confine ourselves to the Gregorian calendar, a time interval can
be safely represented as a triple of months, minutes, and seconds.
It seems to me that that would put too much complexity at too low a level
but still without enough complexity to deal
On Thu, 28 Dec 2006, John Cowan wrote:
Distinguo. I am talking about time intervals; you are talking about
periodic events. Two different things.
Still, your minute/month system does not deal with variable-length days.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
SHANNON: SOUTH
Tony Finch scripsit:
Still, your minute/month system does not deal with variable-length days.
I assume you mean 23-hour or 25-hour LCT days? True. It does work
against UCT days, though, since they are uniformly 1440 minutes long.
--
Overhead, without any fuss, the stars were going out.
John Cowan wrote:
I assume you mean 23-hour or 25-hour LCT days? True. It does work
against UCT days, though, since they are uniformly 1440 minutes long.
Not should leap hours replace leap seconds.
I am talking about time intervals; you are talking about periodic
events. Two different things.
Amen!
M. Warner Losh wrote:
And avoiding the ugly 61 or 59 second minutes to define away the
problem...
It was the time lords who decreed that rubber minutes were prettier
than rubber seconds. We're now to skip right over rubber hours to
rubber days? Their aesthetic sense seems strangely
In message [EMAIL PROTECTED], Rob Seaman writes:
M. Warner Losh wrote:
And avoiding the ugly 61 or 59 second minutes to define away the
problem...
It was the time lords who decreed that rubber minutes were prettier
than rubber seconds. We're now to skip right over rubber hours to
rubber days?
In message: [EMAIL PROTECTED]
Poul-Henning Kamp [EMAIL PROTECTED] writes:
: We can get that only by increasing the DUT tolerance.
Yes. Letting DUT be bounded by +- 10s rather than +- 0.9s is going to
affect a tiny number of users. Having leapseconds only known 6 months
in advance
Poul-Henning Kamp wrote:
It is not an æsthetic issue, it is an issue of practical
implementation.
Well, it's both. The big question is practical implementation of what?
In these days of heavily computerized infrastructure, we need more
than half a years warning about discontinuities in the
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
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] 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
M. Warner Losh wrote:
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.
Indeed. Go for it. I look forward to reading your report. Who and
what interests
Rob Seaman scripsit:
Indeed. Go for it. I look forward to reading your report. Who and
what interests are adversely affected in each case? How are these
effects mitigated as a function of the limit on DUT1? Also, contrast
what benefits accrue. One would think that the responsibility for
John Cowan wrote:
It can't possibly be. Nobody can know what a change is going to
cost except those who are going to have to pay for it (or not
pay for it).
Are you really suggesting that the planning of technical projects is
impossible? One might expect some investment of time and money in
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: M. Warner Losh wrote:
:
: 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
M. Warner Losh wrote:
vague rumblings about astronomical software needing to be rewritten,
Unlike Y2K, there is no solid public proposal for astronomers to cost
against, but the cost is likely to dwarf Y2K in our community, since
algorithms and deployed services would have to change, not just
On Thu 2006-12-28T22:07:08 -0700, M. Warner Losh hath writ:
I know the benefits, but nobody has yet produced a study on why 0.9s
was chosen.
That's pretty easy. In 1969 the CCIR subcommittee was preparing its
unilateral decision to switch from rubber seconds and 200 ms steps
to leap seconds.
On Thu, 28 Dec 2006, M. Warner Losh wrote:
We've accepted a statistical solution for the leap-day problem now for
about 500 years.
The Julian calendar reform was in 46 BC. Astronomers still count Julian
years (365.25 days instead of exact years) when dealing with long MJD
intervals.
Tony.
--
21 matches
Mail list logo
