only predicts a year ahead. Applying that formula gives an uncertainty
>a year ahead of 21 ms.
The question is what domain of validity the above formula has ?
In the builletin they only apply it up to 40d.
For an argument of 10 years the result is 0.12 seconds.
For an argument of 100 years
Hydrogen survices
the testphase on Giove B.
--
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.
>
>(see http://www.cis.udel.edu/~mills/database/brief/clock)
Let me just note that not all of us in the NTP environment belive
that algorithm is optimal or even well understood.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD commit
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.
>
ery time to see if something changed.
Furthermore, you will not getaround a strong signature on the
leap-second table, because if anyone can inject a leap-second table
on the internet, there is no end to how much fun they could have.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[E
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
t filesystems store time as UTC anyway...
Actually, I tend to think these are in the minority, but most of
the non-UTC ones are of minor significance.
--
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.
des 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
Hospitals
and the list goes on.
6 months is simply not an acceptable warning to get, end of story.
--
Poul-Hen
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
>
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Sat 2007-01-06T19:36:19 +0000, Poul-Henning Kamp hath writ:
>> There are two problems:
>>
>> 1. We get too short notice about leap-seconds.
>>
>> 2. POSIX and other standards cannot inve
from the standards, it would cost only a
fraction of plan B.
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.
d YMDHMS format, so the kernel
need to know the trick as well. (There are other examples, but not
as well known).
--
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.
build in support for
MMDDHHMMSS.mmmuuunnnppp
BCD encoded timestamps, as long as they provide us with cheap
instructions to carry out the above operations, we're happy.
I should caution any hopes however, by mentioning that at this
time I have yet to see any CPU design getting a binary
t;; 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 to cold for that :-)
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
my .signature was used more often
in Pentagon than he was comfortable with.
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.
t;rubber" mean universal time. Stratum 0 devices for the
>latter would probably have to use radio.
This proposal is so patently badly researched that you should
not talk more about it until you have _really_ thought about
the implications, technical, scientifically and legally.
--
Poul-Hennin
bulletind.94
That's an interesting piece of data in our endless discussions about
how important DUT1 really is...
--
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.
ails. If
you want to reform calendars, do something radical so that people
can see the difference clearly.
--
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 ca
nnouncing them ~24 weeks in advance
>> in recent history.
>
>So much the worse. That means that if the Earth hiccups on March 7, the
>value of |DUT1| will not return to normal until May 31.
Given the angular momentum required for such a hiccup, I think we would
have more promi
consecutive days during which |DUT1| > 0.9s before the emergency leap
>second can be implemented; consequently, the current guarantee is only
>statistical, not absolute.
But is it physically relevant ?
Has anybody calculated how much energy is required to change
the Earths rotation fast enoug
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,
>
&
as they have volutarily promised
to be, and consequently, they could just send a letter to ITU
and say "we'll do it this way from MMDD, if you disagree,
then figure something else out."
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC
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
[EMA
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Sun 2006-12-31T07:59:35 +0000, Poul-Henning Kamp hath writ:
>> Rob, If you feel uncomfortable with calling leapseconds
>> discontinuities, then we can use the term arrhythmia instead.
>
>The point of my allegory abo
-
>overs.
Rob, If you feel uncomfortable with calling leapseconds
discontinuities, then we can use the term arrhythmia instead.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribu
As Warner, I and others have repeatedly emphasized: It is not the
step size that is the problem, it is the 6 month warning.
I don't care if you want to implement leap-milliseconds, as long
as you tell me 10 years in advance when they happen.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.2
In message <[EMAIL PROTECTED]>, Ashley Yakeley
writes:
>On Dec 27, 2006, at 14:32, Poul-Henning Kamp wrote:
>
>>> It's impossible to accurately represent a millisecond using binary
>>> fractions. That would be unacceptable for most sub-second use.
>>
>
In message <[EMAIL PROTECTED]>, Ashley Yakeley
writes:
>On Dec 27, 2006, at 06:29, Poul-Henning Kamp wrote:
>
>> That's a pretty bad format. Computers are binary and having
>> pseudo-decimal fields like tv_usec in timeval, tv_nsec in timespec
>> and picoseconds
tv_nsec in timespec
and picoseconds in Haskell is both inefficient and stupid.
The fractional part should be a binary field, so that the width
can be adjusted to whatever precision and wordsize is relevant.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/I
... which is exactly the kind of thing you can not do with any
{origin+offset} format, due to leap seconds.
--
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.
ap
minutes, leap-seconds or leap-microseconds, it's only a matter of
precision.
--
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.
rtunately, the Metre-Convention and the Longitude Conference
has nailed your left and right feet to the floor [1], so in practice
ITU-R gets to decide all time.
Poul-Henning
[1] Thus making the Warszawa Convention at lot less applicable.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL
gt;what time it is. Actually, GPS arises from our obsession with
>knowing what *place* we're at; its need for precise time is a mere
>technical detail of its implementation.
Absolutely not true. The original military requirements for GPS
demanded timetransfer better then 10 microseconds f
g, all the same.
--
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.
here it is harmless.
In the meantime, don't buy property near nuclear facilites.
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.
ll look at them without any formal training in
any kind of physics or natural science and conclude that "they
probably have religious significance" which is the default
explanation in that branch of history.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
ll appears to be in Title V, and
>at the moment the link in the document seems to be named Section 2.
It's still there in the PDF version, it's just not 508 anymore,
it's moved up a couple of notches because other stuff were
striken out.
--
Poul-Henning Kamp | UNIX since Zilog
or of
>about an order of magnitude. Good enough.
The ban on hand-held GPS for primary means of navigation is partly
because of the worries about the slowness of updates.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer
quot; mean solar time, but
not UTC.
But yes, likely as not, this is not a black helicopter job, but
rather sloppy or uninformed text-processing.
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since
e Secretary of Commerce.'.
That could sound like the drilling of a loophole :-)
--
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.
, Astron [pl. of 'Easter'],
>Thrimilch 'three-milking', Forelithe, Afterlithe, Wedmath 'weed-month',
>Halimath 'holy-month', Winterfilth '-filling', Blotmath 'sacrifice-month',
>Foreyule. At least some of these are obviously pre-C
I belive this was because the year followed the taxation cycle of the
government whereas the day+month followed the religiously inherited
tradtion.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-taho
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Fri 2006-04-14T09:43:45 +0200, Poul-Henning Kamp hath writ:
>> If you put a provisional table of leapseconds into your products and
>> reality turns out differently, who is liable for the discrepancies ?
>
>It'
s from implementing some variation
>of Steve's scheduling algorithm right now, today, this minute?
>
>All in favor, say aye!
aye!
--
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.
hat it will catch on later.
If you add 10 more leapsecond opportunities per year you will
decrease reliability of the provisional table, compared to if
there is only two opportunities per year.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
mmercial use of
computers in the Lyons Tea Shops chain in the UK. One of the special
gadgets that computer had was a multi-radix adder for dealing with
the quaint coinage in UK at the time.
The book is highly recommended.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED
lish, implement, and promote a new
>version (4?) of NTP that can also diseminate TAI, EOPs, leap-second
>tables, and other good things. I'm all for it.
There is already an effort to revise the NTP docs and I belive
the result is tentatively called NTPv4. There is some support
for dis
0 accommodate one extra (or one fewer) second seen to be
>such an imposition?
Be cause we only get 15 million seconds of advance notice.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never at
l time
> that no longer follows the Sun. I do not know which camp to join!
If we abandon leapseconds today to avoid getting computer problems,
we still have several hundred years of time to decide how to
deal with any long term effects.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.2
of us would not have an issue with them.
--
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.
lly appreciate the care with which you express yourself in order
to be fair to all parties.
Such a mastery of neutral and unloaded wording is wonder to behold.
Not.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | B
ousy clocks and we should stop using rotating bodies of geophysics for
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.
t
>: sounds quite doable when you think through it a bit. Not trivial, but
>: carefully doable without performance penalty.
>
>Anything that makes the Mills' kernel PLL more complicated is unlikely
>to be implemented correctly.
Actually the Mills PLL isn't implemented corr
factor will probably be measuring
(or having had measured) UT1 with maximum precision at the epoch.
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 ad
seconds after UTC midnight.
But the half second delta to UTC is also a non-starter.
--
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.
for time&date conversions.
Poul-Henning
PS: And this should not in any way 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 com
oblem rather
>> than add to the general kludgyness of computers.
>
>Do you find this "tone of voice" productive when collaborating? :-)
You know, I've been in computing for so long that I have become
alergic to kludges and "quick fixes" of all kinds. The wor
me_t" which would be deprecated. :-)
plenty_time_t :-)
--
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.
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
In message <[EMAIL PROTECTED]>, Markus Kuhn writes:
>Poul-Henning Kamp wrote on 2006-01-19 09:46 UTC:
>> > http://www.ietf.org/internet-drafts/draft-kuhn-leapsecond-00.txt
>>
>> The serious timekeeping people gave up on rubberseconds in 1972 and
>> I will objec
multitude of correct solutions.
--
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.
#x27;t come back until you have 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.
on the previous
leapsecond, so there is a good chance it is because of the leap
seconds that it fell out this time.
--
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.
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-Hen
resolved
>sooner if a leap second had occurred earlier - and is no longer
>directly pertinent to a discussion of future leap seconds?
Yeah, right
"This goes counter to my claims so it is of no importance".
Sorry, things don't work that way Rob.
--
Poul-Henning Kamp |
wich.
"Don't do like we do, do as we say..."
Yes, the irony 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.
here you want a real number to represent time 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 si
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
I just received email from Gregor Dudle at Metas and he confirmed
that HBG did bungle the leap second.
He says the bug is found and fixed "for the case there should ever
again be a leap second"
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather" writes:
>Poul-Henning Kamp said:
>> So the standards crew, POSIX, LSB or whoever would have to come up
>> with a new data type for holding timestamps,
>
>We already have one: struct tm.
Doesn't work.
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 b
uot;Denmark" as country, this is a far moure
daunting task than 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.
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 m
.
That is deeply unserious behaviour of a scientist Rob.
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.
es affected by unscheduled time
>steps) or an astronomical future (way too many leap
>seconds a year).
Amen.
--
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.
mentation
date for it.
>...but isn't what you are asserting precisely equivalent to saying
>that you are willing to support the issuance of one or more leap
>seconds - per day? If this will be "more suitable" a couple of
>thousand years from now - why not now?
No, I won&#x
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 dayli
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]
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 wo
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 WP
the "time-lords" a few decades forward would not
be out of order.
>(Despite some NTP servers 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 serve
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
In message <[EMAIL PROTECTED]>, Peter Bunclark writes:
>On Sat, 7 Jan 2006, Poul-Henning Kamp wrote:
>Research-quality telescopes, in particular all the ones built in the last
>few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error
>would be a complex ~10 arcsec
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
no
>overwhelming consensus on whether the status quo should be maintained
>or an alternative should be pursued."
... at that meeting.
The only consensus that matters is the ITU-R SG7A, which coincidentally
didn't reach one either.
--
Poul-Henning Kamp | UNIX since Zilog Zeus
the two functions
government control in the formula:
Civil Time(time) = UTC(time) +
TimeZoneOffset(country, subdivision, time) +
SeasonalOffset(country, subdivision, time)
>[various ramblings]
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[
we want to dictate
which timescale they should use.
--
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.
ime
Main-frame 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
r that I'll go after France 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.
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
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 I
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.
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 Lea
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 on
rning in that country can redefine
the two functions to make 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 att
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
ks and watches.
This is a rather empty statement because most clocks and watches
are built, sold, bought and adjusted to show civil time.
>> 4. the relationship between local civil time and international
>> civil time should be predicatable and easy to calculate with
Which is why t
second.
>
>Unfortunately, this is not the case with the DST bits.
>Users routinely complain that WWVB RC clocks do
>not handle DST correctly. This is because there is
>less than one day advance notice of a DST change.
DCF77 lights the bit for only one hour prior to the leap-second
m increases 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 PROTECT
er than a tangle of slip knots and Grannies.
We're not talking about knots here, this is not cryptography,
we are talking about 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 Kam
1 - 100 of 224 matches
Mail list logo
