On Mon, 15 Jan 2007, Peter Bunclark wrote:
http://www.eecis.udel.edu/~mills/ipin.html
That page does not seem to mention UTC...
Look at the slides.
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
BISCAY FITZROY: VARIABLE 4, BECOMING SOUTHWESTERLY 5 TO 7 IN NORTHWEST
FITZROY.
On Mon, 8 Jan 2007, Steve Allen wrote:
Don't forget that UTC and TAI are coordinate times which are difficult
to define off the surface of the earth. For chronometers outside of
geostationary orbit the nonlinear deviations between the rate of a local
oscillator and an earthbound clock climb
On Fri 2007-01-12T18:35:55 +, Tony Finch hath writ:
According to the slides linked from Dave Mills's Timekeeping in the
Interplanetary Internet page, they are planning to sync Mars time to UTC.
http://www.eecis.udel.edu/~mills/ipin.html
Neverminding the variations on Mars with its rather
Rob Seaman said:
Feather's encoding is a type of compression. GZIP won't buy you
anything extra.
Actually, it might with longer tables. For example, LZW (as used by Unix
compress) can be further compressed using a Huffman-based compressor.
I'll join the rising chorus that thinks it need
not
Steve Allen wrote:
But it is probably safer to come up
with a name for the timescale my system clock keeps that I wish were
TAI but I know it really is not.
True. I can record timestamps in TAI(bowl.fysh.org), and by logging
all its NTP activity I could
Subject: Re: [LEAPSECS] Introduction of long term scheduling
On Jan 8, 2007, at 22:57, Steve Allen wrote:
GPS is not (TAI - 19)
What is GPS time, anyway? I had assumed someone had simply defined GPS to be
TAI - 19, and made the goal of the satellites to approximate GPS time, i.e.
that GPS
Rob Seaman said:
Which raises the question of how concisely one can express a leap
second table.
Firstly, I agree with Steve when he asks why bother?. You're solving the
wrong problem.
However, having said that:
So, let's see - assume:
1) all 20th century leap seconds can be
Poul-Henning Kamp wrote:
We certainly don't want to transmit the leap-second table with every
single NTP packet, because, as a result, we would need to examine
it every time to see if something changed.
Once we've got an up-to-date table, barring faults, we only need to check
to see whether the
On Mon, 8 Jan 2007, Zefram wrote:
Possibly TT could also be used in some form, for interval calculations
in the pre-caesium age.
In that case you'd need a model (probably involving rubber seconds) of the
TT-UT translation. It doesn't seem worth doing to me because of the
small number of
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: Unfortunately, the kernel has to have a notion of time stepping around
: a leap-second if it implements ntp.
:
: Surely ntpd could be altered to isolate the kernel from
Warner Losh wrote:
Actually, every IP does not have a 1's complement checksum. Sure,
there is a trivial one that covers the 20 bytes of header, but that's
it. Most hardware these days off loads checksumming to the hardware
anyway to increase the throughput. Maybe you are thinking of TCP or
So you think it is appropriate to demand that ever computer with a
clock should suffer biannual software upgrades if it is not connected
to a network where it can get NTP or similar service ?
I know people who will disagree with you:
Air traffic control
Train control
On Sat, 6 Jan 2007, M. Warner Losh wrote:
Most filesystems store time as UTC anyway...
POSIX time is not UTC :-)
Tony.
--
f.a.n.finch [EMAIL PROTECTED] http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 6 TO GALE 8, DECREASING 5 OR 6 LATER. ROUGH OR
VERY ROUGH. OCCASIONAL RAIN OR WINTRY SHOWERS.
On Sun, 7 Jan 2007, Rob Seaman wrote:
It's not the correct time under the current standard if the
timekeeping model doesn't implement leap seconds correctly. I don't
think this is an impossible expectation, see http://
www.eecis.udel.edu/~mills/exec.html, starting with the Levine and
Mills
In message [EMAIL PROTECTED], David Malone writes:
FWIW, I believe most hospitals are more than capable of looking
after equipment with complex maintenance schedules.
It is not just a questoin of ability, to a very high degree
cost is much more important.
--
Poul-Henning Kamp | UNIX since
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: Most filesystems store time as UTC anyway...
:
: POSIX time is not UTC :-)
True. It is designed to be UTC, but fails to properly implement UTC's
leap seconds and
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: If by some limp attempt you mean returns the correct time then you
: are correct.
:
: It's not the correct time under the current standard if the
: timekeeping model doesn't implement leap seconds correctly. I
On Sun, 7 Jan 2007, M. Warner Losh wrote:
[POSIX time] is designed to be UTC, but fails to properly implement
UTC's leap seconds and intervals around leapseconds.
From the historical point of view I'd say that UNIX time was originally
designed to be some vague form of UT, and the POSIX
On 8 Jan 2007 at 0:15, Tony Finch wrote:
How did you extend the UTC translation back past 1972 if the undelying
clock followed TAI? I assume that beyond some point in the past you say
that the clock times are a representation of UT. However TAI matched UT in
1958 and between then and 1972 you
On Sat, 6 Jan 2007, M. Warner Losh wrote:
OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance.
That's why leap second handling should be done in
In message: [EMAIL PROTECTED]
Tony Finch [EMAIL PROTECTED] writes:
: On Sat, 6 Jan 2007, M. Warner Losh wrote:
:
: OSes usually deal with timestamps all the time for various things. To
: find out how much CPU to bill a process, to more mondane things.
: Having to do all these
Warner Losh wrote:
leap seconds break that rule if one does things in UTC such that
the naive math just works
All civil timekeeping, and most precision timekeeping, requires only
pretty naive math. Whatever the problem is - or is not - with leap
seconds, it isn't the arithmetic involved.
In message [EMAIL PROTECTED], Tony Fin
ch writes:
On Sat, 6 Jan 2007, M. Warner Losh wrote:
OSes usually deal with timestamps all the time for various things. To
find out how much CPU to bill a process, to more mondane things.
Having to do all these gymnastics is going to hurt performance.
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh wrote:
:
: leap seconds break that rule if one does things in UTC such that
: the naive math just works
:
: All civil timekeeping, and most precision timekeeping, requires only
: pretty naive math.
In message [EMAIL PROTECTED], Rob Seaman writes:
Warner Losh wrote:
leap seconds break that rule if one does things in UTC such that
the naive math just works
POSIX time handling just sucks for no good reason.
I've said it before, and I'll say it again:
There are two problems:
1. We
On Sat 2007-01-06T19:36:19 +, Poul-Henning Kamp hath writ:
There are two problems:
1. We get too short notice about leap-seconds.
2. POSIX and other standards cannot invent their UTC timescales.
This is not fair, for there is a more fundamental problem:
No two clocks can
In message [EMAIL PROTECTED], Steve Allen writes:
On Sat 2007-01-06T19:36:19 +, Poul-Henning Kamp hath writ:
There are two problems:
1. We get too short notice about leap-seconds.
2. POSIX and other standards cannot invent their UTC timescales.
This is not fair, for there
On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:
B. i) Issue leapseconds with at least twenty times longer
notice.
This plan might not be so good from a software engineering point of
view. Inevitably software authors would hard-code the known table,
and then the software would fail
On Sat, 6 Jan 2007, Steve Allen wrote:
No two clocks can ever stay in agreement.
I don't think that statement is useful. Most people have a concept of
accuracy within certain tolerances, dependent on the quality of the clock
and its discipline mechanisms. For most purposes a computer's clock
On Jan 6, 2007, at 13:47, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED],
Ashley Yakeley
writes:
On Jan 6, 2007, at 11:36, Poul-Henning Kamp wrote:
B. i) Issue leapseconds with at least twenty times longer
notice.
This plan might not be so good from a software engineering
In message [EMAIL PROTECTED], Ashley Yakeley
writes:
Not necessarily. After seven months, or even after two years, there's
a better chance that the product is still in active maintenance.
Better to find that particular bug early, if someone's been so
foolish as to hard-code a leap-second table.
On Jan 6, 2007, at 14:43, Poul-Henning Kamp wrote:
So you think it is appropriate to demand that ever computer with a
clock should suffer biannual software upgrades if it is not connected
to a network where it can get NTP or similar service ?
Since that's the consequence of hard-coding a
On Jan 6, 2007, at 16:18, M. Warner Losh wrote:
Unfortunately, the kernel has to have a notion of time stepping around
a leap-second if it implements ntp. There's no way around that that
isn't horribly expensive or difficult to code. The reasons for the
kernel's need to know have been
In message: [EMAIL PROTECTED]
Ashley Yakeley [EMAIL PROTECTED] writes:
: On Jan 6, 2007, at 16:18, M. Warner Losh wrote:
:
: Unfortunately, the kernel has to have a notion of time stepping around
: a leap-second if it implements ntp. There's no way around that that
: isn't horribly
Warner Losh wrote:
Anything that makes the math
harder (more computationally expensive) can have huge effects on
performance in these areas. That's because the math is done so often
that any little change causes big headaches.
Every IP packet has a 1's complement checksum. (That not all
On Sat, 6 Jan 2007, Ashley Yakeley wrote:
Presumably it only needs to know the next leap-second to do this, not
the whole known table?
Kernels sometimes need to deal with historical timestamps (principally
from the filesystem) so it'll need a full table to be able to convert
between POSIX time
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: Warner Losh wrote:
: Anything that makes the math
: harder (more computationally expensive) can have huge effects on
: performance in these areas. That's because the math is done so often
: that any little change
On Thu, 4 Jan 2007, Michael Deckers wrote:
This leads me to my question: would it be helpful for POSIX implementors
if each and every UTC timestamp came with the corresponding value of DTAI
attached (instead of DUT1)? Would this even obviate the need for a leap
seconds table?
No,
Tony Finch wrote:
you need to be able to manipulate representations of times other
than the present, so you need a full leap second table.
Which raises the question of how concisely one can express a leap
second table. Leap second tables are simply a list of dates - in ISO
8601 or MJD
On Fri 2007-01-05T21:14:19 -0700, Rob Seaman hath writ:
Which raises the question of how concisely one can express a leap
second table.
Gosh, Rob, I remember toggling in the boot program and starting
up the paper tape reader or the 12-inch floppy disc drive, but now
I'm not really sure I
On Jan 5, 2007, at 20:14, Rob Seaman wrote:
An ISO string is really overkill, MJD can fit into
an unsigned short for the next few decades
This isn't really a good idea. Most data formats have been moving
away from the compact towards more verbose, from binary to text to
XML. There are good
Ashley Yakeley wrote:
As the author of a library that consumes leap-second tables, my ideal
format would look something like this: a text file with first line
for MJD of expiration date, and each subsequent line with the MJD of
the start of the offset period, a tab, and then the UTC-TAI seconds
On 2007-01-03, Poul-Henning Kamp commented on Bulletin D 94:
That's an interesting piece of data in our endless discussions about
how important DUT1 really is...
So it appears that DUT1, an approximation of UT1 - UTC, is not of much use,
even though it is disseminated with many time
On Tue, 2 Jan 2007, Rob Seaman wrote:
Daniel R. Tobias replies to Poul-Henning Kamp:
Has anybody calculated how much energy is required to change
the Earths rotation fast enough to make this rule relevant ?
Superman could do it. Or perhaps he could nudge the Earth's rotation
just
In message [EMAIL PROTECTED], Peter Bunclark writes:
Without the Moon, the Earth could nod through large angles, lying on
its side or perhaps even rotating retrograde every few million
years. Try making sense of timekeeping under such circumstances.
You mean like taking a sequence of atomic
On Wed, 3 Jan 2007, Magnus Danielson wrote:
Assuming you have corrected for another gravitational field, yes. The
current SI second indirectly assumes a certain gravitational force, we
is assumed to be at sea level whatever level that is.
Wrong. The SI second is independent of your reference
From: Tony Finch [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Wed, 3 Jan 2007 17:38:35 +
Message-ID: [EMAIL PROTECTED]
On Wed, 3 Jan 2007, Magnus Danielson wrote:
Assuming you have corrected for another gravitational field, yes. The
current SI
Steve Allen wrote:
On Mon 2007-01-01T21:19:04 +, Ed Davies hath writ:
Why does the One sec at predicted intervals line suddenly
diverge in the early 2500's when the other lines seem to just
be expanding in a sensible way?
...
I suspect that the divergence of the one line indicates that the
Warner Losh scripsit:
There's an exception for IERS to
step in two weeks in advance if the earth's rotation rate hickups.
So if I understand this correctly, there could be as many as 14
consecutive days during which |DUT1| 0.9s before the emergency leap
second can be implemented;
In message [EMAIL PROTECTED], John Cowan writes:
Warner Losh scripsit:
There's an exception for IERS to
step in two weeks in advance if the earth's rotation rate hickups.
So if I understand this correctly, there could be as many as 14
consecutive days during which |DUT1| 0.9s before the
Warner Losh scripsit:
There's an exception for IERS to
step in two weeks in advance if the earth's rotation rate hickups.
So if I understand this correctly, there could be as many as 14
consecutive days during which |DUT1| 0.9s before the emergency leap
second can be implemented;
Warner Losh scripsit:
There's no provision for emergency leapseconds. They just have to be
at the end of the month, and annoucned 8 weeks in advance. IERS has
actually exceeded this mandate by announcing them ~24 weeks in advance
in recent history.
So much the worse. That means that if
In message [EMAIL PROTECTED], Tony Fin
ch writes:
On Tue, 2 Jan 2007, Warner Losh wrote:
Curiously, BIH is currently, at least in the document I have, expected
to predict what the value of DUT1 is to .1 second at least a month in
advance so that frequency standard broadcasts can prepare for
In message: [EMAIL PROTECTED]
John Cowan [EMAIL PROTECTED] writes:
: Warner Losh scripsit:
:
: There's no provision for emergency leapseconds. They just have to be
: at the end of the month, and annoucned 8 weeks in advance. IERS has
: actually exceeded this mandate by announcing
Warner Losh wrote:
The IERS bulletin C is a little different than the ITU TF.460:
Leap seconds can be introduced in UTC at the end of the months of December
or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every
six months, either to announce a time step in UTC, or to
Warner Losh wrote:
Right now DUT1 is
+0.0s until further notice. From the last few B's, it looks like this
is decreasing at about 300ms per year. This suggests that the next
leap second will be end of 2008.
The way DUT1 is behaving at the
Ed Davies wrote:
Still, it's a strange assumption, given that TF.640 allows, I
understand, leaps at the end of any month. Unofficially, the
wording seems to be:
A positive or negative leap-second should be the last second
of a UTC month, but first preference should be given to the end
of
On 2 Jan 2007 at 19:40, Poul-Henning Kamp wrote:
Has anybody calculated how much energy is required to change
the Earths rotation fast enough to make this rule relevant ?
Superman could do it. Or perhaps he could nudge the Earth's rotation
just enough to make the length of a mean solar day
Daniel R. Tobias replies to Poul-Henning Kamp:
Has anybody calculated how much energy is required to change
the Earths rotation fast enough to make this rule relevant ?
Superman could do it. Or perhaps he could nudge the Earth's rotation
just enough to make the length of a mean solar day
Poul-Henning Kamp wrote:
That's an interesting piece of data in our endless discussions
about how important DUT1 really is...
The point is that by allowing it to grow without reasonable bound,
DUT1 would gain an importance it never had before.
Rob Seaman wrote:
... Obviously it would take at least N years to introduce a new
reporting requirement of N years in advance (well, N years minus six
months).
Sorry, maybe I'm being thick but, why? Surely the IERS could announce
all the leap seconds in 2007 through 2016 inclusive this week
On Mon 2007-01-01T17:42:11 +, Ed Davies hath writ:
Sorry, maybe I'm being thick but, why? Surely the IERS could announce
all the leap seconds in 2007 through 2016 inclusive this week then
those for 2017 just before the end of this year, and so on. We'd have
immediate 10 year scheduling.
In message [EMAIL PROTECTED], Steve Allen writes:
McCarthy pretty much answered this question in 2001 as I reiterate here
http://www.ucolick.org/~sla/leapsecs/McCarthy.html
What exactly is the Y axis on this graph ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
On Mon 2007-01-01T19:29:19 +, Poul-Henning Kamp hath writ:
McCarthy pretty much answered this question in 2001 as I reiterate here
http://www.ucolick.org/~sla/leapsecs/McCarthy.html
What exactly is the Y axis on this graph ?
Only McCarthy can say for sure.
Maybe someone elsewho was at the
From: Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Mon, 1 Jan 2007 19:29:19 +
Message-ID: [EMAIL PROTECTED]
Poul-Henning,
In message [EMAIL PROTECTED], Steve Allen writes:
McCarthy pretty much answered this question in 2001 as I
In message [EMAIL PROTECTED], Steve Allen writes:
One could say that it was never possible for the BIH/IERS to guarantee
that its leap second scheduling could meet the 0.7 s and then later
0.9 s specification because they could not be held responsible for
things that the earth might do. As such
In message [EMAIL PROTECTED], Magnus Danielson wr
ites:
From: Poul-Henning Kamp [EMAIL PROTECTED]
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Mon, 1 Jan 2007 19:29:19 +
Message-ID: [EMAIL PROTECTED]
Poul-Henning,
In message [EMAIL PROTECTED], Steve Allen writes
Poul-Henning Kamp wrote:
If you have subtle point, I'd love to hear it.
Not even close to a subtle point, I simply cannot figure out what the
graph shows...
Me too. Is this an analysis or a simulation? What are the
assumptions? What predicted intervals does he mean?
The bullet points
Steve Allen wrote:
On Mon 2007-01-01T17:42:11 +, Ed Davies hath writ:
Sorry, maybe I'm being thick but, why? Surely the IERS could announce
all the leap seconds in 2007 through 2016 inclusive this week then
those for 2017 just before the end of this year, and so on. We'd have
immediate 10
On Mon 2007-01-01T21:19:04 +, Ed Davies hath writ:
Why does the One sec at predicted intervals line suddenly
diverge in the early 2500's when the other lines seem to just
be expanding in a sensible way?
Upon looking closer I see a 200 year periodicity in the plot.
I begin to suspect that
70 matches
Mail list logo
