Re: Introduction of long term scheduling

2007-01-15 Thread Tony Finch
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.

Re: Introduction of long term scheduling

2007-01-12 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-12 Thread Steve Allen
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

Re: Introduction of long term scheduling

2007-01-11 Thread Clive D.W. Feather
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

Re: Introduction of long term scheduling

2007-01-09 Thread Zefram
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

Re: Introduction of long term scheduling

2007-01-09 Thread matsakis . demetrios
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

Re: Introduction of long term scheduling

2007-01-08 Thread Clive D.W. Feather
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

Re: Introduction of long term scheduling

2007-01-08 Thread Poul-Henning Kamp
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 conciseness to

Re: Introduction of long term scheduling

2007-01-08 Thread Zefram
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

Re: Introduction of long term scheduling

2007-01-08 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-08 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-07 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-07 Thread David Malone
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

Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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.

Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-07 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-07 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-07 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-07 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-07 Thread Daniel R. Tobias
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

Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-06 Thread Rob Seaman
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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.

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-06 Thread Steve Allen
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

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread Poul-Henning Kamp
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.

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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 even

Re: Introduction of long term scheduling

2007-01-06 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-06 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-06 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-06 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-05 Thread Tony Finch
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,

Re: Introduction of long term scheduling

2007-01-05 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-05 Thread Steve Allen
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

Re: Introduction of long term scheduling

2007-01-05 Thread Ashley Yakeley
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

Re: Introduction of long term scheduling

2007-01-05 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-04 Thread Michael Deckers
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

Re: Introduction of long term scheduling

2007-01-03 Thread Peter Bunclark
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

Re: Introduction of long term scheduling

2007-01-03 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-03 Thread Peter Bunclark
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 atmosphere is far

Re: Introduction of long term scheduling

2007-01-03 Thread Magnus Danielson
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 Earth could nod through large angles, lying

Re: Introduction of long term scheduling

2007-01-03 Thread Tony Finch
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

Re: Introduction of long term scheduling

2007-01-03 Thread Magnus Danielson
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

Re: Introduction of long term scheduling

2007-01-02 Thread Ed Davies
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

Re: Introduction of long term scheduling

2007-01-02 Thread John Cowan
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;

Re: Introduction of long term scheduling

2007-01-02 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-02 Thread Warner Losh
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;

Re: Introduction of long term scheduling

2007-01-02 Thread John Cowan
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

Re: Introduction of long term scheduling

2007-01-02 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-02 Thread M. Warner Losh
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

Re: Introduction of long term scheduling

2007-01-02 Thread Ed Davies
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

Re: Introduction of long term scheduling

2007-01-02 Thread Zefram
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

Re: Introduction of long term scheduling

2007-01-02 Thread James Maynard
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

Re: Introduction of long term scheduling

2007-01-02 Thread Daniel R. Tobias
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

Re: Introduction of long term scheduling

2007-01-02 Thread Rob Seaman
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

Re: Introduction of long term scheduling

2007-01-02 Thread Rob Seaman
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.

Re: Introduction of long term scheduling

2007-01-01 Thread Ed Davies
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

Re: Introduction of long term scheduling

2007-01-01 Thread Steve Allen
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.

Re: Introduction of long term scheduling

2007-01-01 Thread Poul-Henning Kamp
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]

Re: Introduction of long term scheduling

2007-01-01 Thread Steve Allen
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

Re: Introduction of long term scheduling

2007-01-01 Thread Magnus Danielson
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

Re: Introduction of long term scheduling

2007-01-01 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-01 Thread Poul-Henning Kamp
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

Re: Introduction of long term scheduling

2007-01-01 Thread Ed Davies
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

Re: Introduction of long term scheduling

2007-01-01 Thread Ed Davies
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

Re: Introduction of long term scheduling

2007-01-01 Thread Steve Allen
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