Re: the legacy of ephemeris time

2003-12-22 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Mon 2003-12-22T20:19:14 +0100, Poul-Henning Kamp hath writ: Time and effort, such as the above, spent on pondering the inconvenience potentially caused to civilizations a millenia, or even just a century in the future, is at best wasted

Re: the legacy of ephemeris time

2003-12-22 Thread Poul-Henning Kamp
. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: GPS will fail EVEN SOONER

2003-12-27 Thread Poul-Henning Kamp
format several times over before before 2057. Can we turn the alarmist tone down a bit ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: precision time web search

2004-05-05 Thread Poul-Henning Kamp
of the contents, and more than once in history it took somebody else to interpret for the masses. So take it as recognition for you skills in presentation :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since

Re: ITU Meeting last year

2005-01-20 Thread Poul-Henning Kamp
is in force. If that turns out to be 600 years, then it stands for 600 years, if ten years from now we find out what the real nature of time is and need to make a new timescale, then somebody had an easy job for 10 years. The one thing we don't need is flaming rethoric... -- Poul-Henning Kamp

Re: ITU Meeting last year

2005-01-20 Thread Poul-Henning Kamp
the torino meeting where this was laid out very well but I didn't save the URL, sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Re: ITU Meeting last year

2005-01-20 Thread Poul-Henning Kamp
in the presentation on http://www.ucolick.org/~sla/leapsecs/dutc.html I enjoyed your page a lot some time ago when I fell over it. Thanks a lot for the effort. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3

Re: ITU Meeting last year

2005-01-20 Thread Poul-Henning Kamp
into perspective nicely. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: two world clocks

2005-01-20 Thread Poul-Henning Kamp
to the timescale 100 years from now. Shouldn't we work to educate the public, not use their ignorance of some issue as justification for degrading service? Absolutely! but if you read your classics (relevant keywords: bread and circus) you would not expect much success. Poul-Henning Kamp also wrote

Re: two world clocks

2005-01-21 Thread Poul-Henning Kamp
and remove all the support for optionally represented leapseconds. There is a lot less left afterwards. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: two world clocks

2005-01-21 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Josep h S. Myers writes: On Fri, 21 Jan 2005, Poul-Henning Kamp wrote: instead of in front of it. As a Dane that sounds smart because time in Denmark is still not UTC based but based on mean solar time because our parliament has not gotten around to fix

Re: two world clocks AND Time after Time

2005-01-24 Thread Poul-Henning Kamp
lunchtime (or their VCR got unplugged). The sun doesn't have much say about it. Fully agreed. I would even venture to claim that a lot of todays teenagers are only mildly aware of the noon -- more light outside connection :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

Re: Time after Time

2005-01-24 Thread Poul-Henning Kamp
don't know when they will happen with long enough warning. 2. You can't test one when you need to. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: two world clocks AND Time after Time

2005-01-24 Thread Poul-Henning Kamp
of daily mental calculation, no? Noon has long required a calendar, an almanac, a longitude, and the ability to perform addition and subtraction. You forget a lawyer or at least a copy of the relevant laws in your area, because surely you're not assuming that my watch runs on UTC ? -- Poul-Henning

Re: two world clocks AND Time after Time

2005-01-25 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Clive D.W. Feather writes: Poul-Henning Kamp said: [That is, if the equinox was actually on March 9th, would anyone outside the astronomical community notice?] I doubt it. I'm not so certain about the summer and winter solstice however. here in the nordic

Re: GMT - UTC in Australia and elsewhere

2005-02-23 Thread Poul-Henning Kamp
. And that is actually a mistake because legally Denmark is still using mean solar time (in Copenhagen I belive) :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what

Leap second before 2007-12-31 ?

2005-04-13 Thread Poul-Henning Kamp
Looking at the current UTC-UT1 data, doesn't it look like a leap second before 2007-12-31 is more and more likely ? http://phk.freebsd.dk/misc/leap.png That would sort of defeat the idea behind the cut off date in the proposal ITU-R is looking at... -- Poul-Henning Kamp | UNIX

Re: Leap-second scare stories

2005-07-30 Thread Poul-Henning Kamp
with leapsecond handling, you have to wait an indeterminate amount of time before you can get to see if you have managed to fix the problem or to collect more diagnostic information. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD

Re: Who uses DUT1?

2005-07-30 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Tom Van Baak writes: WWV and WWVB and perhaps other national systems transmit DUT1 as a 3- or 4-bit signed number of 100 ms. As does MSF/Rugby in the UK. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956

Re: Wall Street Journal Article

2005-07-31 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Sun 2005-07-31T09:19:40 +0200, Poul-Henning Kamp hath writ: I don't hear the counter proposal from the astronomers to fix leap seconds. They're not broken. It was my distinct impression from reading http://www.ucolick.org/~sla

Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

2005-08-04 Thread Poul-Henning Kamp
to the nearest table I could find of leap seconds). Most if not all modern UNIXes already have the table of leapseconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: new beginning

2005-08-04 Thread Poul-Henning Kamp
was already too much and that DUT1 corrections would be needed pretty much all the time already ?) How about we go to leap minutes, scheduled 50 years in advance, would that work for you ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD

Re: new beginning

2005-08-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Thu 2005-08-04T09:27:20 +0200, Poul-Henning Kamp hath writ: So one feasible option is to predetermine all leapseconds (or leap minutes ?) for the next 50 years in advance. That means an UT1-UTC difference that could go as high as 20-30

Re: Stupid question from programmer: Why not just eliminate ALL UTC corrections ?

2005-08-05 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes: Poul-Henning Kamp wrote on 2005-08-05 12:17 UTC: Also, your UTS proposal is a total non-starter: Rubber seconds is not a usable solution. I beg to differ strongly, and I slightly suspect you live a bit in a dream world with regard to the short

Re: Precise time over time

2005-08-10 Thread Poul-Henning Kamp
not change the economics of the situation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Precise time over time

2005-08-11 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes: Poul-Henning Kamp wrote on 2005-08-10 18:26 UTC: If you want a really disturbing experience, visit a modern robotical slaughterhouse, and while you are there, observe and think about what a one second difference could do the the tightly

Re: Precise time over time

2005-08-11 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Thu 2005-08-11T14:40:10 +0200, Poul-Henning Kamp hath writ: Because the food industry is required to provide trackability for food and the requirement is UTC time. Not over here it isn't. I'm pretty sure the time stamps on the milk cartons

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
that the bounds on |UT1-UTC| increases to about a minute, worst case, but already given todays predictive capabilities, I think it will be possible to keep the difference within a handful of seconds. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: On Aug 11, 2005, at 12:46 AM, Poul-Henning Kamp wrote: As I understood the situation last week, nobody in the gang here had problems with leap seconds if we got a longer warning (40-50 years). So what prevents us from writing up our own

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Mark Calabretta writes: However, the question that naturally arises is the required timescale of the extrapolation. A figure of 50 years seems first to have been suggested by Poul-Henning Kamp (Aug/04, My personal opinion is that 50 years seems right, 20 years might

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Clive D.W. Feather writes: Poul-Henning Kamp said: As I said, 50 years seems right, and it does so because there is no currently running computer that has worked for 50 years. Actually, the programme machines that control the signalling of much of the London

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Greg Hennessy writes: On Fri, 2005-08-12 at 08:44 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Greg Hennessy writes: Will you support a proposal that keeps leap-second (or -minutes), but mandates that they be determined 40 or 50 years in advance

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
information at all. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
of the current proposal ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Precise time over time

2005-08-12 Thread Poul-Henning Kamp
think we can put an alternative proposal on WP7A's table while the other one is there too ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: vive le BIH!

2005-08-29 Thread Poul-Henning Kamp
educational level with regards to timekeeping. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Consensus rather than compromise

2005-08-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: Poul-Henning Kamp wrote: It is not unrelated to why some of us think that changing the definition of UTC is infinitely more possible than changing the rest of the worlds educational level with regards to timekeeping. Not unrelated, simply

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
already agree on the above statement. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
we need just one other, published, open, correctly implemented, and tested library and all your problems go away. No, because all sorts of governments and companies mandate POSIX compliance so you couldn't sell the resulting product. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL

Re: Consensus rather than compromise

2005-08-30 Thread Poul-Henning Kamp
still flash 12:00AM though. [2] Yes, I just saw the movie :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Comments on Civil Time decision tree

2005-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 26 Sep 2005, Poul-Henning Kamp wrote: On the other hand, even if we agree on one standard, or even just leave UTC as it is, are the astronomers and geophysiscists going to abandon UT1 ? If so, then this is the first I've heard

Re: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
sort, because it takes from up to twelve minutes to happen, but it does not coincide with the @@Cb return of the newly aquired almanac. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
leap seconds. Also, a GPS receiver that has cached the almanac can acquire satellites much more quickly than one who has to wait for the almanac to be downloaded. This is btw, the original design rationale for the almanac data set. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL

Re: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
which would confirm that the almanac was current. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Comments on Civil Time decision tree

2005-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Daniel R. Tobias writes : On 26 Sep 2005 at 16:09, Poul-Henning Kamp wrote: Other more laid back parliaments like the Danish have not been able to find time to revisit the issue since 18xx and still use solar time at some more or less random coordinate. You mean

Re: Comments on Civil Time decision tree

2005-09-26 Thread Poul-Henning Kamp
want it in. Right now, the clock on Mars Odyssey (as I type this) should be reading 2/0812228033. Dealing with things like leap seconds, local time conventions, and other time conversions are all handled here on Earth. But that strategy breaks down for human space flight ? -- Poul-Henning Kamp

Re: RAS hits the news

2005-09-27 Thread Poul-Henning Kamp
into the receive (which is probably why almanacs are still published by the GPS control segment people). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: WP7A press release

2005-11-18 Thread Poul-Henning Kamp
: IETF proved that standards work a lot better when anyone easily can get hold of them and everybody can afford to read them. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: International Conference on Civil Timekeeping (was Re: [LEAPSECS] WP7A press release)

2005-11-18 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: On Nov 18, 2005, at 5:21 AM, Poul-Henning Kamp wrote: As with any consensus-building, the weight is on whoever would like to see such emerge. For instance, just by debating the issue, the ITU is asserting that they own the UTC standard

Re: BBC - Leap second talks are postponed

2005-11-18 Thread Poul-Henning Kamp
ITC, International Time Coordinated. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: BBC - Leap second talks are postponed

2005-11-21 Thread Poul-Henning Kamp
convention, or some UN/ITU related thing) which has superseeded the old law, but on the book, it is wrong. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: a system that fails spectacularly

2005-12-07 Thread Poul-Henning Kamp
program the technology that runs our civilization. Think about it next time you press a button. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

Re: a system that fails spectacularly

2005-12-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: On Dec 7, 2005, at 11:57 AM, Poul-Henning Kamp wrote: ISO9000 certification only means that you have documented your quality assurance process. There is no requirement that your documentation pertains to or results in a quality product

Re: Lighter Evenings (Experiment) Bill [HL]

2005-12-19 Thread Poul-Henning Kamp
of traction in USA. And of course, that is the crux of the matter: such decisions have more to do with politics than science or even reason. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Schreiver AFB warns about leapsec

2005-12-20 Thread Poul-Henning Kamp
Thousands of observations had to be discarded Problem was also evident at Clear However, host system software receiving the 23:59:60 time hack may not know what to do. System dependent response. They clearly know what the problem with leap seconds is :-) -- Poul-Henning Kamp | UNIX since

Re: Schreiver AFB warns about leapsec

2005-12-20 Thread Poul-Henning Kamp
pressure venue. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Schreiver AFB warns about leapsec

2005-12-21 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Francois Meyer writes: On Tue, 20 Dec 2005, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED] on.fr, Francois Meyer writes : I second this too, 23:59:59 is the worst time to insert a leap second, since failing to implement it leaves you with the wrong

Re: Software requirements

2005-12-22 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Daniel R. Tobias writes: On 21 Dec 2005 at 21:33, Poul-Henning Kamp wrote: I suspect more real world computers are in roughly this situation as opposed to being absolutely dependent on being correct to the millisecond or microsecond at all times; the system clocks

text book example why Leapseconds are bad

2006-01-01 Thread Poul-Henning Kamp
http://lheawww.gsfc.nasa.gov/users/ebisawa/ASCAATTITUDE/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: NTP behavior in Australia

2006-01-02 Thread Poul-Henning Kamp
the event, two stratum 3 servers in the set still had the leap warning bits set. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Re: Where the responsibility lies

2006-01-03 Thread Poul-Henning Kamp
hours will grow less rapidly than the need for leapseconds. In short, leap hours are - well - dumb. A proposal that relies on their use, naive. Leap hours or leap seconds is only a matter of magnitude and frequency and consequently both are equally naïve. Poul-Henning -- Poul-Henning Kamp

Re: Longer leap second notice, was: Where the responsibility lies

2006-01-03 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Ed Davies writes: Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need to update the factory installed table

Re: Where the responsibility lies

2006-01-03 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Neal McBurnett writes: On Tue, Jan 03, 2006 at 08:32:08PM +0100, Poul-Henning Kamp wrote: If we can increase the tolerance to 10sec, IERS can give us the leapseconds with 20 years notice and only the minority of computers that survive longer than that would need

Re: Longer leap second notice

2006-01-04 Thread Poul-Henning Kamp
byzantine decision scenarios (I have three references, one say leap second, one says no leap second and one says nothing, what should I do ?) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never

Re: Diagram of CHU Leap-Second Recording and Atomic Clock

2006-01-04 Thread Poul-Henning Kamp
and the receiver will turn on more often to make sure it is still in sync. In the case of DCF77, that means that you'd have to be rather lucky for your clock to do the leapsecond in real time. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since

Re: civil time = solar time

2006-01-04 Thread Poul-Henning Kamp
local civil time and international civil time should be predicatable and easy to calculate with Which is why the longitude conference decided on a 1 hour quantum. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD

DCF77 leapsecond documented

2006-01-06 Thread Poul-Henning Kamp
into the capture data and you can also see the extra second going from 28430.638 to 28491.639 Rugby and HBG and France Inter will follow in the coming days if I can get my software to decode them. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC

Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)

2006-01-06 Thread Poul-Henning Kamp
it more so. Now tell me why you think Leap seconds are so important again. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained

Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], William Thompson writes: Poul-Henning Kamp wrote: Universal Time = confusing term which comes handy when trying to manipulate discussions about leap second futures. I have to take issue with this one. My point was that when you just say

Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: UTC UTC(time) = TAI(time) + Leap(time) Owned by ITU. IERS evaluates Leap(time) according ITU definition Not quite

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Michael Sokolov writes: http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt In this rather humorous document you have managed to say that POSIX screwed up badly. We already knew that :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

Re: Defining our terms (was Re: [LEAPSECS] Longer leap second notice)

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Poul-Henning Kamp writes: In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T00:32:44 +0100, Poul-Henning Kamp hath writ: At the beginning of 1984 and at the beginning of 2003 the branches of the IERS responsible for UT1 followed new IAU

HBG transmitted wrong info during leapsecond

2006-01-07 Thread Poul-Henning Kamp
Looks like the inserted the leapsecond after the minutemarker: http://phk.freebsd.dk/Leap/20051231_HBG/ -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can

Re: HBG transmitted wrong info during leapsecond

2006-01-07 Thread Poul-Henning Kamp
Inter's phase modulation. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
time and give each of them their own unique way of coping with leapseconds ? Ohh wait... That's what it looks like today already isn't it ? :-( -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
are we in a position to introduce a computer time scale in a pathetic attempt to paste over leap seconds. We can talk about _representation_ of a given timescale in computers, but there are far too many laws to rewrite if we want to dictate which timescale they should use. -- Poul-Henning Kamp

Re: The opportunity of leap seconds

2006-01-07 Thread Poul-Henning Kamp
) = UTC(time) + TimeZoneOffset(country, subdivision, time) + SeasonalOffset(country, subdivision, time) [various ramblings] -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
SG7A, which coincidentally didn't reach one either. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: You can find locate your countrys ITU-R representative and contact them with your input, just as well as I can for mine. You can try that, and you may succeed, but it is deceptive

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Ed Davies writes: Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can

Re: The opportunity of leap seconds

2006-01-08 Thread Poul-Henning Kamp
which reportedly still have not acknowledged the leap second, I think the overall indications are that the NTP network did better than 50 %.) My estimate is 50-70% of the pool.ntp.org servers did something close enough to the right thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year The Italian contribution to the November 2005 WP7A meeting could be interpreted

Re: The real problem with leap seconds

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time

Re: The opportunity of leap seconds

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes: On Sun, 8 Jan 2006, Poul-Henning Kamp wrote: finger [EMAIL PROTECTED] You mean [EMAIL PROTECTED] That would be quiet useful. Otherwise let's not bother with NTP protocol, just [EMAIL PROTECTED] I don't really care what the service

Re: interoperability

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today

Re: interoperability

2006-01-08 Thread Poul-Henning Kamp
timekeeping, and I am sure that they will think so themselves. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: interoperability

2006-01-08 Thread Poul-Henning Kamp
. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: interoperability

2006-01-09 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes: On Mon 2006-01-09T08:20:40 +0100, Poul-Henning Kamp hath writ: beginning (SI seconds are constant length). Yes, SI seconds are constant length, but the ghost of my general relativity teacher prompts me to assert that my SI seconds are not equal

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
it might appear. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes: On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: I don't think anybody dare even think about redefining POSIX time_t I wish people would stop making positive assertions about what other people are bound to think. What you mean in is, YOU

Re: The real problem with leap seconds

2006-01-09 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes: and you still cannot even get it reliably from your average local NTP server. This is a circular argument: The reason NTP doesn't provide it is that time_t needs UTC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED

Re: MJD and leap seconds

2006-01-10 Thread Poul-Henning Kamp
rather than deal with the complications of parsing a date. It tends to be written into the FITS header of practically every data file observed. So how do you deal with fractional days in that format ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since

Re: MJD and leap seconds

2006-01-10 Thread Poul-Henning Kamp
is rather notable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Report of Leap Second Problem with GPS Data

2006-01-14 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes: I invite derision with my flights of rhetoric. As published papers [1] document, you have way to go. Poul-Henning [1] George August, Anita Balliro et all, study of Rotation of the Earth, approx 1993. (find it yourself). -- Poul-Henning Kamp

Re: The real problem with leap seconds

2006-01-18 Thread Poul-Henning Kamp
understood and accepted that this is not the case. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
bytes) http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt The serious timekeeping people gave up on rubberseconds in 1972 and I will object with all that I can muster against reinventing them to paste over a problem that has a multitude of correct solutions. -- Poul-Henning Kamp

Re: Fixing POSIX time

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Neal McBurnett writes: On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote: Assign different timescales very different numeric epochs: TAI:1972-01-01 00:00:00 UTC For TAI I'd suggest 1958-01-01, when TAI and UT

Re: Fixing POSIX time

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes: I like this idea as well... Poul, maybe we should implement this on FreeBSD. I'd suggest working_time_t or correct_time_t as the name of the type to replace time_t which would be deprecated. :-) plenty_time_t :-) -- Poul-Henning Kamp

Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
become alergic to kludges and quick fixes of all kinds. The worse and the more hackish they are, the more red spots I get. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice

Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
be taken as a surrender on my part, I still think leapseconds are wrong in every way one can imagine. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately

  1   2   >