On Fri, 29 Dec 2006, Rob Seaman wrote:
Folks keep fretting here about retrieving lists of leap seconds
autonomously, although no specific use case is proffered about why
one needs to use UTC to measure intervals across various and sundry
leap second events.
You need to do so in order to
On Fri 2006-12-29T07:43:56 +, Tony Finch hath writ:
Astronomers still count Julian
years (365.25 days instead of exact years) when dealing with long MJD
intervals.
Such intervals are almost always expressed in the IAU's time scale of
Terrestrial Time (TT) which is taken to be a more
On Thu 2006-12-28T18:31:43 -0700, M. Warner Losh hath writ:
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.
I have previously indicated that I believe this
Tony Finch wrote:
You need to do so in order to implement an accurate clock, since
the clock produces interval time and you need a way to convert its
output to time of day.
As Steve Allen has pointed out, it is in the nature of a clock to be
reset on occasion. What is NTP but a mechanism for
Rob Seaman scripsit:
Seems like? Chances are? Pick some other random technical issue -
say, automobile airbags, standardized educational testing, the lead
content of pigment in children's crayons, and so forth and so on.
Would seems like and chances are be phrases you would want to see
in
On 2006-12-09, Clive D.W. Feather challenged, and I couldn't resist:
For something more challenging, try the 8 Bank Holidays in England:
...
(8) Second weekday after 24th December.
second weekday after 24th December in Gregorian year( Y )
= Gregorian calendar( Y, December, 26
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
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.
--
M. Warner Losh said:
time_t is so totally broken, it isn't funny. That's the closest thing
to a standardized API there is for time. All others are stuff folks
have done here or there, but they aren't universal enough to be
considered.
Too bad the problems with time_t are well known, well
On Dec 26, 2006, at 23:02, M. Warner Losh wrote:
Of course, needing to know TAI-UTC offsets leads one to interesting
situations. What does one do if one has TAI time, but not UTC and a
conversion is asked for?
If it's a time in the future rather than just the current time, the
thread may
On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote:
It's impossible to accurately represent a millisecond using binary
fractions. That would be unacceptable for most sub-second use.
Reality check: with a 32bit fraction, the error would be 69 ps.
...which accumulates in arithmetic and causes
Rob Seaman scripsit:
Mucking with leap seconds is equivalent to redefining the
concept of a day.
Very true. And adopting the Egyptian-Roman calendar redefined
the concept of a month. Somehow civilization survived.
--
John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan
I must confess
On 27 Dec 2006 at 20:57, John Cowan wrote:
Very true. And adopting the Egyptian-Roman calendar redefined
the concept of a month. Somehow civilization survived.
Keeping months in sync with phases of the moon apparently turned out
to be insufficiently important to civilization to require it as
M. Warner Losh wrote:
Actually, the real answer is domain specific. There are many things
that don't really care (when do I need to make the next 20 house
payments, off by one second just doesn't matter at all since
transcations are batched on a daily basis a few days early).
In that case you
On Mon, 25 Dec 2006, Keith Winstein wrote:
Even if a program is able to calculate TAI-UTC for arbitrary points in the
past and near future, what should a library do when a program asks to
convert between UTC and TAI for some instant further than six months in
the future?
You should treat
On Tue 2006-12-26T17:10:34 +, Tony Finch hath writ:
You should treat this kind of conversion in the same way that you treat
local time zone conversions, which are also unpredictable.
This past year was fun in the state of Indiana as daylight time
happened for the first time ever in many
Tony Finch wrote:
You should treat this kind of conversion in the same way that you treat
local time zone conversions, which are also unpredictable.
I wish timezone data would come with a guaranteed validity period,
so that the library could say I don't know in the right places.
Unfortunately
On Wed, 27 Dec 2006, Zefram wrote:
So I'm not convinced that leap second uncertainty and timezone
uncertainty should be treated the same way.
I was thinking partly from the point of view of infrastructure: if you
have a mechanism that can keep the system's timezone database up-to-date,
then it
Good discussion.
On Mon 2006-12-25T15:42:12 -0500, Keith Winstein hath writ:
Even if a program is able to calculate TAI-UTC for arbitrary points
in the
past and near future, what should a library do when a program asks to
convert between UTC and TAI for some instant further than six
months in
In message: [EMAIL PROTECTED]
Zefram [EMAIL PROTECTED] writes:
: Keith Winstein wrote:
: what should a library do when a program asks to
: convert between UTC and TAI for some instant further than six months in
: the future?
:
: Refuse, of course. The correct
In message: [EMAIL PROTECTED]
Zefram [EMAIL PROTECTED] writes:
: Steve Allen wrote:
: and if I continue that practice
: I can later give you an estimate of how wrong I was when I told you.
:
: This is something that's missing from current
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: Hello, I just joined the leap seconds list. I wrote the time
: package for the Haskell programming language.
: http://semantic.org/TimeLib/
:
: I include code for making conversions between TAI and UTC, given a
:
39 matches
Mail list logo
