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 Fri, 12 Jan 2007, Tony Finch wrote:
> 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
>
That page does not seem to mention UTC... it does mention runnin
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 rath
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 cl
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
>
I tried to send this a few times the other day, but the list rejected
it. Figured I'd try one more time as a mail check as much as
anything else. Obviously not a particularly meaningful message.
Rob
--
Poul-Henning Kamp wrote:
And next thing, somebody is going to argue for GZIP encodi
09, 2007 2:22 AM
To: LEAPSECS@ROM.USNO.NAVY.MIL
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 ap
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 retros
From: Steve Allen <[EMAIL PROTECTED]>
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Mon, 8 Jan 2007 22:57:23 -0800
Message-ID: <[EMAIL PROTECTED]>
Steve,
> On Mon 2007-01-08T01:54:56 +, Zefram hath writ:
> > Possibly TT could also be used in so
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 and TAI are the same (up to
isomorphism in some "category of meas
On Mon 2007-01-08T01:54:56 +, Zefram hath writ:
> Possibly TT could also be used in some form, for interval calculations
> in the pre-caesium age.
Please do not consider the use of TT as a driver for the development
of any sort of commonplace API. In the far past no records were made
using TT
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 kerne
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 ntp's broken
timescale (assuming the kernel has an atomic seconds count timescale)
Ton
In message <[EMAIL PROTECTED]>, Zefram writes:
>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, bar
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 app
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:
>
> Conciseness is useful for network protocols. Bandwidth is increasingly
> the limiting factor: CPU speed and bulk storage sizes have been
> increasing faster. An NTPv3 packet is only 48 octets of UDP payload;
> if a leap second table is to be disseminated in t
In message <[EMAIL PROTECTED]>, Zefram writes:
>Clive D.W. Feather wrote:
>>Firstly, I agree with Steve when he asks "why bother?". You're solving the
>>wrong problem.
>
>Conciseness is useful for network protocols.
On the other hand, one should not forget that the OSI protocols was
killed by conc
Clive D.W. Feather wrote:
>Firstly, I agree with Steve when he asks "why bother?". You're solving the
>wrong problem.
Conciseness is useful for network protocols. Bandwidth is increasingly
the limiting factor: CPU speed and bulk storage sizes have been
increasing faster. An NTPv3 packet is only
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 sta
Daniel R. Tobias wrote:
>Formulas for UTC, as actually defined at the time, go back to 1961
>here:
But that involves rubber seconds, which is quite a big complication to add
to your TAI<->UTC conversion. If you're going to handle pre-1972 times,
I think you really need to decide what you'll do pr
On Sun, 7 Jan 2007, Daniel R. Tobias wrote:
>
> Formulas for UTC, as actually defined at the time, go back to 1961
> here:
You helpfully snipped the part where I said that it probably isn't
worth implementing rubber seconds.
> ftp://maia.usno.navy.mil/ser7/tai-utc.dat
> It appears the offset was
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
On Sun, 7 Jan 2007, M. Warner Losh wrote:
>
> Having tried it, there are a lot of little 33 second anomolies in many
> applications :-(.
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 tim
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 comm
In message: <[EMAIL PROTECTED]>
Rob Seaman <[EMAIL PROTECTED]> writes:
: What is correct is to have a 61 second minute occasionally, neither
: to redo the first second of the next day, nor to repeat the last
: second of the current day.
Unfortunately, that's not POSIX time_t. And when
Tony Finch wrote:
As http://www.eecis.udel.edu/~mills/leap.html shows, NTP (with kernel
support) is designed to stop the clock over the leap second, which I
don't call "correct". Without kernel support it behaves like a
"pinball
machine" (according to Mills).
Warner Losh wrote:
It implement
M. Warner Losh wrote:
> But ntp_gettime returns a timespec
>for the time, as well as a time_state for the current time status,
>which includes TIME_INS and TIME_DEL for psotive and negative leap
>second 'warning' for end of the day so you know there will be a leap
>t
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
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]>, 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 si
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
> M
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
> 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
>
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
UD
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes
:
>In message: <[EMAIL PROTECTED]>
>Tony Finch <[EMAIL PROTECTED]> writes:
>: 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?
>:
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
In message: <[EMAIL PROTECTED]>
Tony Finch <[EMAIL PROTECTED]> writes:
: 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 (prin
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 ti
Poul-Henning Kamp wrote:
there are only two classes of solutions.
Fix it or ignore it?
It's not a matter of clock precision or clock stability. It's only
a matter of how they count.
That will be news to Dave Mills.
a state of denial with respect to a particular lump of rocks
ability as
M. Warner Losh scripsit:
> Since the interface to the kernel is time_t, there's really no chance
> for the kernel to do anything smarter with leapseconds. gettimeofday,
> time and clock_gettime all return a time_t in different flavors.
It could be done in the C library, since the interface betwe
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
swit
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 ho
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 enumerat
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 ?
If it's not connected to the network, how is it keeping its clock
synchronised
In message: <[EMAIL PROTECTED]>
Ashley Yakeley <[EMAIL PROTECTED]> writes:
: On Jan 6, 2007, at 08:35, M. Warner Losh wrote:
:
: > So for the foreseeable future,
: > timestamps in OSes will be a count of seconds and a fractional second
: > part. That's not going to change anytime soon
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 ?
Well, I doubt very much that every computer cares. For the small subset
of mac
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 leap-
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 tab
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 p
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 c
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 point of
>view. Inevitably software authors woul
On Jan 6, 2007, at 08:35, M. Warner Losh wrote:
So for the foreseeable future,
timestamps in OSes will be a count of seconds and a fractional second
part. That's not going to change anytime soon even with faster
machines, more memory, etc. Too many transaction processing
applications demand ma
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 t
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 f
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
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:
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]>, 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 perfo
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes:
>In message: <[EMAIL PROTECTED]>
>Ashley Yakeley <[EMAIL PROTECTED]> writes:
>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
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. Tak
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 the
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 i
In message: <[EMAIL PROTECTED]>
Ashley Yakeley <[EMAIL PROTECTED]> writes:
: 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
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 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 rel
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 under
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 formats
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?
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 tim
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 gr
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 refer
Peter Bunclark wrote:
Hang on a minute, statistically planets in the Solar System do not
have a
large moon and yet are "upright"; for example Mars comes very close
to the
conditions required to generate a leapseconds email exploder.
I checked the DDA box on my AAS form, but nobody would mistak
From: Poul-Henning Kamp <[EMAIL PROTECTED]>
Subject: Re: [LEAPSECS] Introduction of long term scheduling
Date: Wed, 3 Jan 2007 11:45:52 +
Message-ID: <[EMAIL PROTECTED]>
> In message <[EMAIL PROTECTED]>, Peter Bunclark writes:
>
> >> Without the Moon, the Ear
On Wed, 3 Jan 2007, Poul-Henning Kamp wrote:
>
> >Hang on a minute, statistically planets in the Solar System do not have a
> >large moon and yet are "upright"; for example Mars comes very close to the
> >conditions required to generate a leapseconds email exploder.
>
> As far as I know the atmosph
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
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
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.
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 exac
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 e
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 Dece
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
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 conf
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 annou
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 prep
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 changes
> of this value a month in advance. Ther
In message <[EMAIL PROTECTED]>, John Cowan 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 them ~24 weeks in advance
>> i
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
> 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 implement
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 befor
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; consequent
> 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 Decemb
On Tue 2007-01-02T18:36:45 +, Ed Davies hath writ:
> >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 December and June, and second preference to the end of March
> >and September.
>
> Anybody got access to a
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 th
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 th
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?
As time goes on we'll need a quadratically increasing number of leap
seconds. The single leap sec at predicted intervals cannot handle that,
t
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
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 ab
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:
>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
1 - 100 of 105 matches
Mail list logo
