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
.
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.
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
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
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
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
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
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.
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
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
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
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
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
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
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
.
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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.
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.
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
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.
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
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.
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
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.
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
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
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
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.
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
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
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
: 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
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
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.
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
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
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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
) = 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
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.
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
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
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
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
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
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
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
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.
.
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 me to assert that my SI seconds are not
equal
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], 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
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
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
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.
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
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.
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
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
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
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
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 - 100 of 135 matches
Mail list logo
