Re: UT1 confidence

2007-01-17 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Zefram writes:
IERS Bulletin A gives an expression for the uncertainty of its UT1-UTC
data predictions:

S t = 0.00025 (MJD-today)**0.75

where today is the MJD of the bulletin's publication.  The Bulletin
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 the result is 0.66 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.


Re: The Martian Chronicles

2007-01-15 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

Before somebody else calls me on it, I should point out that NTP
actually uses both:

The clock discipline algorithm functions as a nonlinear, hybrid
phase/frequency-lock (NHPFL) feedback loop.

(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 committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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 the point of obscurity.

And next thing, somebody is going to argue for GZIP encoding of the
list, and next thing you know, all programs need to drag libz in
to uncompress their leap-second table.

The major part of the InterNets success was that you could telnet
to pratically all servers, FTP, SMTP, NNTP etc, and you could see
what went on without a protocol analyzer with a price-tag of $CALL

the limiting factor: CPU speed and bulk storage sizes have been
increasing faster.  An NTPv3 packet is only 48 octets of UDP payload;
if a leap second table is to be disseminated in the same packets then
we really do want to think about the format nybble by nybble.

No we don't.

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.

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
[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: 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 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: 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.

That's why leap second handling should be done in userland as part of the
conversion from clock (scalar) time to civil (broken-down) time.

I would agree with you in theory, but badly designed filesystems
like FAT store timestamps in encoded 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.


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 get too short notice about leap-seconds.

2. POSIX and other standards cannot invent their UTC timescales.

These two problems can be solved according to two plans:

A. Abolish leap seconds.

B. i) Issue leapseconds with at least twenty times longer notice.
   ii) Ammend POSIX and/or ISO-C
   iii) Ammend NTP
   iv) Ammend NTP
   v) Convince all operating system to adobt the new API
   vi) Fix all the bugs in their implementations
   vii) Fix up all the relevant application code
   viii) Fix all tacit the assumptions about time_t.

I will fully agree, that while taking the much easier approach of
plan A, will vindicate the potheads who wrote the time_t definition,
and thus deprive us of a very satisfactory intelectual reward of
striking their handiwork 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.


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 is a more fundamental problem:

Yes, this is perfectly fair, this is all the problems there are.

And furthermore, the two plans I outlined represent the only
two kinds of plans there are for solving this.

They can be varied for various sundry and unsundry purposes, such
as the leap-hour fig-leaf and similar, but there are only
two classes of solutions.

No two clocks can ever stay in agreement.

This is not relevant.  It's not a matter of clock precision or
clock stability.  It's only a matter of how they count.

Yes, there is a cost of doing time right, and leap seconds are not to
blame for that cost.  They are a wake up call from the state of denial.

Now, it can be equally argued, that leap seconds implement a state
of denial with respect to a particular lump of rocks ability as
timekeeper, so I suggest we keep that part of the discussion closed
for now.

--
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: 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. The bug here, by the
way, is not that one particular leap second table is wrong. It's the
assumption that any fixed table can ever be correct.

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
Hospitals

and the list goes on.

6 months is simply not an acceptable warning to get, end of story.

--
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: A lurker surfaces

2007-01-03 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Zefram writes:

Would have been nice.  Actually, since the only real significance of
GPS time is that it's part of the signal format, they could just as
well have picked an unconventional but space-efficient encoding (say,
32-bit count of seconds, wrapping every 4 Gis).  I think GPS time is
best viewed as an encoding of TAI(GPS).

I have been told by a person who should know better than to tell
me such things that the choice of timescale in GPS is the result
of unmitigated incompetence and the signal format is sheer stupidity.

The fact that the UTC offset is in the Almanac instead of the
Ephemeris means that almost all of the rapid response weapons cannot
be used for tightly timed attacks until they have been primed with
an almanac.

He talked about the transmissions of the almanac being staggered
between the satellites rather than in tandem, to reduce the mean-time
to capture UTC-delta, but I did not find out if this was reality
or plan.

I guess one could use the raw-dump message to the Oncore and
decode the almanac by hand to find out if this is the case.

He also said that the quote in 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.


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 seconds, counting them
in a predicatable way and be happy that timekeeping has nothing
to do with geophysics ?

Yeah, I could live with that.

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 to cold for that :-)

--
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: 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 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 enough to make this rule relevant ?

--
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: 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 changes
 of this value a month in advance.  There's an exception for IERS to
 step in two weeks in advance if the earth's rotation rate hickups.

I was amused by the dates in
http://hpiers.obspm.fr/eoppc/bul/buld/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.


Re: A lurker surfaces

2007-01-02 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Ashley Yakeley writes:
M. Warner Losh wrote:
 GPS is also used for UTC today.  Many ntpd's are stratum 1 tied to a
 GPS receiver.

I imagine two parallel time infrastructures, one synchronised to TAI,
the other to 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-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: A lurker surfaces

2007-01-01 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:
On Sun 2006-12-31T07:59:35 +, 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 about unplanned pregnancies is that
all practically available time scales have arrhythmias.

We can live with arrhythmias as long as we get sufficient warning
about them.

Politicians who fumble the local timescale are answerable according
to their economy and whatever political system installed them.

But the leapsecond decision was taken 35 years ago on an entirely
different basis than applies to its consequences today, in particular
it is no longer relevant how long time the international mail takes
to reach the most remote parts of the globe from Paris.

--
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: 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] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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 the IERS could conceivably
start unilaterally issuing full decade scheduling of leap seconds and
claim that it *was* acting in strict conformance with ITU-R TF.460.

Considering that ITU has no power over IERS, IERS is only bound
by the letter of TF.460 as far 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 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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:

 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 ?

Unless you have a subtle point, I interprent it to be in seconds even if they
are incorrectly indicated (s or seconds instead of sec would have been
correct).

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...

The sawtooth corresponding to the prediction interval raises a big red
flag for me as to the graphs applicability to reality.

--
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: Mechanism to provide tai-utc.dat locally

2006-12-28 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:
M. Warner Losh wrote:

 And avoiding the ugly 61 or 59 second minutes to define away the
 problem...

It was the time lords who decreed that rubber minutes were prettier
than rubber seconds.  We're now to skip right over rubber hours to
rubber days?  Their aesthetic sense seems strangely malleable.

It is not an æsthetic issue, it is an issue of practical implementation.

In days no more than 100 clocks worldwide were precise enough to
care about rubber seconds, they were acceptable.

In days where no more than 1000 clocks worldwide were seriously
affected by leap seconds, they were acceptable.

In these days of heavily computerized infrastructure, we need more
than half a years warning about discontinuities in the timescale.

We can get that only by increasing the DUT tolerance.

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.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: Mechanism to provide tai-utc.dat locally

2006-12-27 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Zefram writes:
Ashley Yakeley wrote:

In the Haskell time library, I represent UTC time by what seemed to
me the simplest possible correct type. This is a record containing an
integer to represent day number (as MJD), and a fixed-point decimal
(picosecond resolution) to represent seconds since midnight. The
allowed range for this is 0 to 86400..

That's a pretty good format.

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 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/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: Equitable estoppel

2006-12-17 Thread Poul-Henning Kamp
The BIPM says
http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15RES=5
that UTC gives an indication of mean solar time, which it can only do
using leap seconds.

Steve,

This is rubbish and you know it.

UTC can give an indication of mean solartime with leap hours, leap
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.


Re: what time is it, legally?

2006-12-15 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Daniel R. Tobias writes:

 http://gauss.gge.unb.ca/papers.pdf/gpsworld.january01.pdf

One quibble with that article is that it gives the Global Positioning
System as an example of how humanity has been obsessed with knowing
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 for safe comms
purposes.

--
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: how posterity will measure time

2006-12-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:

So it seems that when it comes to communicating a span of time
to a civilization other than our own the solution that the best
minds have produced is an astronomical one.

The main reason for this is that the underlying charter specifically
mentioned that one or more discontinuities in higher civilization
must be expected.

In that context, and because the problem is purely earth-bound, an
astronomical solution seems to be a good idea.

Although, likely as not, when some future arkæologist finds the
inscriptions he will 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] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: how posterity will measure time

2006-12-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

I'd vote, myself, for using a subduction zone for this purpose,

Yes, that is the only scientifically appropriate response and I
will, for once, vote with you.

The interesting thing is, despite the fact that dumping it in a
subduction zone has pretty much exactly the properties desired,
including the amount of time before we risk seeing it back at the
surface, nobody is talking about that disposal option.

For reasons to convoluted to explain here, I have researched this
exact question a fair bit, and the conclusion is rather sad:

The material in question represents an enormous investment and
contains a literal zoo of oddball elements, and therefore nobody
can even contemplate throwing it away for good.

All repository projects, throughout the world, have as a fundamental
design requirement that the goods must be retrievable.

As the Swedish project says:  for when the next Einstein appears.

Hopefully we will reach a time where the politicians responsible
for the incomprehensible expenditures for nuke development in the
cold war are out of power and saner heads will decide to take
the garbage out where 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.


Re: catching up, AAS and US Senate

2006-09-13 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:
On Tue 2006-09-12T23:18:05 -0700, Steve Allen hath writ:
 It appears that the version as reported in the senate in July
 struck out all of section 508.  I could be wrong.

I receive word that the UTC text still 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 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: PT Barnum was right

2006-07-06 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], John Cowan writes:
Rob Seaman scripsit:

 Most troubling would be if two moving platforms are depending on GPS
 units with differing delays, e.g., two airplanes following neighboring
 flight paths.  How far does an airplane move in 2 seconds?  What is
 the minimum separation required by the FAA?

Jetliners travel at about 550 mi/hr, or 246 m/s.  Required horizontal
separation depends on circumstances, but is rarely less than 3 miles =
4828 m.  So if the discrepancy is 2 s, there is a safety factor 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   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: independence day

2006-07-05 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes
:

: That could sound like the drilling of a loophole :-)

As has been pointed out in the past, the Secretary of Commerce has had
the ability to define mean solar time to mean UTC (or something else,
if they felt the urge)...  I think this is just another attempt to
keep their options open, like they have now...

Yes, and no, mean solar time is something you measure whereas UTC
is an international standard from a UN body which USA has ratified,
so it makes sense to modify and interpret 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 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: independence day

2006-07-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:

In the middle of May some text about legal time in the US was
introduced into a US Senate bill regarding funding for NSF and NIST.
See section 508 of S.2802 introduced 2006-05-15, e.g.
http://thomas.loc.gov/cgi-bin/query/z?c109:S.2802:

`(b) COORDINATED UNIVERSAL TIME DEFINED- In this section,
the term `Coordinated Universal Time' means the time scale
maintained through the General Conference of Weights and
Measures and interpreted or modified for the United States
by the 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.


Re: building consensus

2006-06-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], John Cowan writes:
Rob Seaman scripsit:

Old English had its own set of month names entirely unrelated to
the Latin ones: if they had survived, they would have been Afteryule,
Solmath 'mud-month', Rethe[math] 'rough-month', 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-Christian.

They're practically all viking derived.

--
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: ideas for new UTC rules

2006-04-14 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:

==During the second five years after the date of adoption.
(YA+5 through YA+9)

On a semi-annual basis the IERS should publish an immutable schedule
of leap seconds predicted for five years into the future.

This would be a big improvement.

Along with the five-year immutable schedule published monthly, the
IERS should continue to publish the provisional schedule of leap
seconds for the next ten years.

I'm not sure I see how this is useful other than judging how well
the predictions turn out.

If you put a provisional table of leapseconds into your products and
reality turns out differently, who is liable for the discrepancies ?

Anyone can attempt to make their own provisional table already now,
yet nobody does it or at least nobody has admitted that they do so,
so I somehow doubt that 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
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: ideas for new UTC rules

2006-04-14 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

The reality is that the ITU-R specification is just a minor
footnote pertaining to obsolete technologies of time signal
transport.  One presumes nothing would stop the IERS from
publishing any scheduling algorithm such as you describe.

Actually, since ITU is an UN institution and IERS is not, decisions
made by former will take legal precedence over decisions made by
the latter in most countries.

The specification might benefit from dedicated IETF blessed

IETF is not really relevant here, POSIX is, and that takes us into
ISO territory, which means YAIO (yet another international organization)
which also doesn't have a real mandate.  (ISO standards only take
effect if the national Standards Institutes bless/ratify/translate
them.)

Actually - one presumes the IERS currently has the authority to
do both of these things.  Have never heard anyone suggest that
the next two leap seconds might not be announced simultaneously.
And the ITU-R has already signed off on the monthly scheduling
of leap seconds - this is the law of the land.

What precisely is stopping us 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.


Re: ideas for new UTC rules

2006-04-14 Thread Poul-Henning Kamp
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 a good question.  My immediate response is that my notions are
also part of the
Full Time-Scale-Aware Lawyer Employment act of {YA}

I don't want us to adopt anything that makes that necessary.

 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.

The motivation is that allowing ten more per year requires action on
the part of all systems to upgrade anything which now believes only
June and December (and they get ten years of notice to do so).  More
importantly, it allows the IERS to react better to any surprises in
decadal fluctuations of LOD.

How does it allow IERS to react better if their horizon is defined
as five or ten years ?

Paraphrasing Westly in the fireswamps of The Princess Bride
DUT1 signals?  I don't think they exist.
Well, I don't think anyone uses them.  If there are still many
applications for DUT1 signals, most likely they are for sextant-style
navigation.  If the leap seconds are being predicted five years in
advance then the annually published navigation almnacs can incorporate
projections which are as good as the broadcast signals.

Agreed.

--
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: An immodest proposal

2006-02-14 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes:

[*] All variable radix counting conventions are insane by (my humble)
definition :-).

Off-topic: While not exactly variable radix counting, I read a book
called A computer called LEO about the first commercial 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] | 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 tail wags the dog

2006-01-24 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

Quadratic despair still lurks, of course, since the month is
lengthening for exactly the same reason as the day.  Well, despair
would be lurking if we tried to match the length of the month (a
natural phenomenon) to an SI unit (such as the second).

You mean the kind of despair where every so often we would
have to put our finger on the scales to make them balance ?

Ie: Just like when we match the length of the day/year to the SI
second ?

I think the crucial insight here is that geophysics makes (comparatively)
lousy 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.


Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes:
A new Internet-Draft with implementation guidelines on how to handle UTC
leap seconds in Internet protocols was posted today on the IETF web
site:

  Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS),
  Markus Kuhn, 18-Jan-06. (36752 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   | 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: 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 were set nearly together.

I chose the time when TAI became constant rate so that
all the rubber seconds are confined to negative values.

 UTC:MJD's epoch.

That would be midnight in Greenwich of 1858-11-17.  I don't see the
connection, and picking a time for which we don't know UT1 pretty
accurately and authoritatively will cause all kinds of arguments.

Well, any number will do, as long as the epoch is unique (also
with respect to time_t.

 UT1:Flamsteads birthday ?
Cute.  1646-08-19

 NTP:defined in RFC1305

== 1900-01-01

It's all magic numbers and as such they don't have to give any
meaning.  We could just pull out a random number for each and
define that as the value of the timescale at some particular
well defined point in time, so it could be something like:

at 2006-03-01 00:00:00 UTC the timescales will have
the following values:

TAI:N1
UTC:N2
UT1:N3

etc.  Given that all the timescales count in SI seconds, that
would leave a bit of math for people to build the conversion
tables, but that could be a task to be done only once.

I like giving magic numbers som kind of meaning though, if
nothing else to honour birthdays of people who deserve it.

 Small platform implementations can use a smaller width,
 for instance 64 bits split 48/16 and easily transform
 to standard format by zero extension.

That would work for 9 million years or so.

Plenty, but the point is that bigger computers are multiple of
32 or these days 64 bits, so chosing 48 bits is just wasted
space and trouble on those.

 Different epochs will make it painfully obvious when people
 mix but don't match timescales in low quality implementations.

Now we just need a name for the proposal

I _really_ don't care what it's called, as long as it's defined correctly.

--
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: 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   | 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
In message [EMAIL PROTECTED], Rob Seaman writes:

 if you look at *any* form of PLL (circuit or software), then you
 will find that its very purpose is to implement rubber seconds,
 that is to implement phase adjustments via low-pass filtered
 temporary changes in frequency.

An excellent observation.

But missing the point entirely:  We use PLL because we want to
steer things to be synchronous, not because we see them as a
means to implement rubber seconds.

 1000 seconds is an incredible silly chosen number in an operational
 context.  At the very least make it 15, 30 or 60 minutes.

I would tend to agree with this.  The Babylonians must have their
kilogram of flesh.  How about 10 minutes - 5 before midnight and 5
after?

That's far to big a torque: 1. PPM

 Advantages:

 Sufficient resolution to represent any likely physical
 measurement or realizable frequency for the forseeable
 future (13.8e-18 seconds resolution).

Any guess at likely physical measurements is going to fall short
for some purposes.  For one thing, one might want to represent
theoretical values in addition to experimental.  That said, you are
likely correct for our purposes.

Heisenberg, Bohr and Planck has a lesson for you :-)

 Now, please show some backbone and help solve the problem 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 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 what can adequately be explained by incompetence.


Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes:

 Now, please show some backbone and help solve the problem rather
 than add to the general kludgyness of computers.

Been there, done that:

  http://www.cl.cam.ac.uk/~mgk25/time/c/

I remember looking at your proposal before and it suffers from a lot
of problems.

For instance it is pseudo-decimal while all contemporary computers
are binary.  This costs a fortune in performance and creates more
coding mistakes than you can count.

It doesn't have enough resolution for any of the people involved
in serious timekeeping (NIST, BIPM, Timing.com etc)

It is a two-part representation, which means that you face the silly
problem that the C language doesn't give you access to the carry
bit, but I guess that is really obscured by the use of pseudo-decimal.

It also to some extent confuses representation and presentation
which are two very different things.

So while well intentioned, you simply didn't go far enough.

My proposal tries to lay the groundwork for handling the entire
problem way into the future, by extending the range both upwards
and downwards and supports multiple timescales with enough room
for another 250 accidents of standardization in that area.

But I no longer think that any effort should be made
whatsoever to expose real-world applications to the time value 23:59:60.

That is not for us to decide really.  (And my proposal doesn't address
it btw, I'm only talking about the representation, not the presentation.)

If the leap-seconds are here to stay, and unless heavy duty political
power is brought to the issue by USA, that seems to be the case,
we will have to get used to 23:59:60.

And unless we handle it correctly, we will not be able to certify
POSIX systems in a lot of critical applications in the future.

Provided we define a convenient and sensible API for handling date
 time, 23:59:60 will not give people any more problems than any
other time of the day, because it will be entirely handled by the
library functions for timedate 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 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
In message [EMAIL PROTECTED], Tim Shepard writes:

 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.

As I learned from a recent posting to this mailing list, it seems that
even TAI has rubber seconds (adjustments to the rate is made from time
to time to compensate for errors that have been accumulating, making
TAI a better (more useful) approximation time).

Do you object to those adjustments (rubber seconds) to TAI as well?

As long as the corrections are of the small magnitudes we have seen
(10e-12 and below) and as long as they are applied to both TAI and
UTC at the same time, I have no trouble with them.

The reason I say 10e-12 is that only high end cesium and hydrogen
units are affected by that in practice, everybody else can just
ignore it.

Remember, we can also risk other fundamental units needing an adjustment,
the kilogram being in the high risk bracket here.

This draft bugs me a bit because it changes the length of a second (as
seen by its clients) by a rather large amount (a thousand ppm).

A change in rate of ten ppm could accomplish the phase change with
less than 1 day's warning before the UTC leap second insertion if
accomplishing it could be split between the 50,000 seconds before UTC
midnight and the 50,000 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.


Re: McCarthy point (was: Fixing POSIX time)

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes:

All I wanted to say is that for a good choice of epoch, it would be nice
if we agreed on it not only to within a few seconds (the leap-second
problem), but also to within a few milli- or microseconds (the SI/TAI
second problem). The latter seems much easier to do for 2000 than for
1972 or even 1958. In applications such as observing planetary motion
over many years, the difference matters.

Good point.

Presumably, the epoch will be defined relative to TAI or UTC to get
maximum precision, so the limiting 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 adequately be explained by incompetence.


Re: Internet-Draft on UTC-SLS

2006-01-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes:
In message: [EMAIL PROTECTED]
Markus Kuhn [EMAIL PROTECTED] writes:
: M. Warner Losh wrote on 2006-01-19 19:20 UTC:
:  Effectively, you'd have to have two time scales in the kernel.  UTC
:  and UTC-SLS.  You make it sound simple, but the hair in doing this may
:  be quite difficult.  There's more book for the kernel to keep, and it
:  would have to expose the bookkeeping to userland for ntp to work.
:  What makes this hard is that ntpd may introduce steers into the normal
:  system time at normal times which it doesn't want to confuse with the
:  steers in frequency that are used during a UTC-SLS operation.
:
: You correctly point out some of the design considerations that have to
: go into such code. You describe roughly one of the (several) different
: ways of implementing all this that I have in mind. In comparison to how
: complicated the Mills kernel PLL is already today, that does not
: actually sound like an overwhelming additional complexity. Actually, it
: 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 correctly in the first place,

The fact that the design is pretty baroque doesn't help.

--
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-18 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Francois Meyer writes:
On Mon, 16 Jan 2006, Mark Calabretta wrote:

1. UTC and TAI  share  the  same  rate,  the  same
   origin, the same second. And therefore :

UTC - TAI = 0

This is wrong, plain and simple wrong.

Please don'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.


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   | 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: MJD and leap seconds

2006-01-10 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes:
On Tue, 10 Jan 2006, Tom Van Baak wrote:
 have no leap seconds. Astronomers appear to avoid
 using MJD altogether.

Good grief.  MJD is used widely in astronomy, for example in variablility
studies where 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 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: MJD and leap seconds

2006-01-10 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

 2. Julian Date (JD)

 [...] For that
 purpose it is recommended that JD be specified as SI seconds in
 Terrestrial Time (TT) where the length of day is 86,400 SI seconds.

Let me see if understood that right:  In order to avoid computing
problems and to get precise time, astronomers rely on a timescale
without leapseconds, because the Earths rotation is too unstable
a clock for their purposes.

And in N years, for some value of N, JD's will start at midnight
instead of noon in Greenwich.

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.


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 to your SI seconds because we are in different reference
frames.

(This has nothing to do with leap seconds, [...]

You are absolutely right there, so why even bring it up ?

--
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], Clive D.W. Feather writes:

The real problem is not the 23:59:60, it's *predicting* when they happen.

I agree, the short prediction horizon is the major problem.

But 23:59:60 _is_ a problem too.

I don't think anybody dare even think about redefining POSIX time_t
and even if they did redefine it to contain leap-seconds, many tons
of software wouldn't be updated/recompiled to take advantage of it.

So the standards crew, POSIX, LSB or whoever would have to come up
with a new data type for holding timestamps, and while a number of
proposals have been floated over the years, none of them seem to
contain any real clue, so I don't think this is likely to happen.

But pressume for a moment that they did come up with a new standard,
the many tons of software would still not be rewritten to take
advantage of it, so we'd still be stuck with time_t's ostrich
behaviour for the forseeable future.

Unlikely as it is, it would allow people like Warner and me to write
software that Do The Right Thing.

A far more sensible idea is to just forget about leap-seconds from
now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary
kind of service (internet services instead of handwritten letters),
the astronomers to shut upcope and leaving the issue of the length
of day in 500 years to the people who live 500 years from now on.

It's the comparison between educating all programmers in the world
vs having the astronomers use a DUT which is larger than 1 second.

There is no doubt that from a humanistic point of view it would be
better to educate all the programmers, but considering that I still
suffer from web-forms that insist I enter a USA style phone number
when I have entered 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.


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 are against
suggesting changing (or augmenting) POSIX time.

No, I mean exactly what I wrote: I don't think anybody dare even
think about redefining POSIX time_t

The reason I mean that is that I've talked to a lot of the relevant
people and they're all totally morified about the consequences
of (time_t % 86400) not giving you the time of day.

Remember, most of these people are even afraid to extend time_t to
64 bits because of the possible fall-out :-(


--
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], 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] | 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-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 see where he is coming from on that
 one.

Since the usual response of the pro-leap second lobby to people
who want a uniform timescale is use TAI this is significant.
Do you have any information or references on why the BIPM director
said this?

As I understood it, it was mainly that TAI is a post-factum postal
timescale.


--
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 opportunity of leap seconds

2006-01-08 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:

 Something as simple as

 finger [EMAIL PROTECTED]

 Or even just a more stringent formatting of the bulletins on the ftp
 site could do it as well.

I do not believe that any of the IERS bureaus have internet
connections and servers which are anywhere near robust and redundant
enough to make that a reliable service.

There is a lot that could and should be done.

I'm certainly starting to get the impression that a modernization
project to move 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 servers did something close
enough to the right thing.

--
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-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 a suggestion that the international agencies in charge of
time scales need to get their heads together, pick one time scale with
no discontinuities, and abolish all others.

That sounds like the sensible partys platform to me.

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).

Klepczynski had implied that more clearly on pages 322 and 323 of
http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf
where he discusses getting all the satellite navigation systems
to use a single time scale.

It is the time scale that is the issue, it's the clock offset between
the systems.

If you have 2 GPS sats, one GLONASS and one GALILEO, you also need
to know the clock offsets between the three systems before you can
calculate a position.

If everybody gets their act together and hold the clock offsets small,
then it would be a wonderful world indeed, but I think the practical,
organizational and political problems will prevent that.

The other option is for the systems to broadcast their clock offsets
relative to the other systems.  For that to help rapid first fix
it must be a frequent broadcast (ie: non-almanac) otherwise you
might as well just wait until you get four birds in one system.

(And to see that psychology is not just relevant to astronomers,
read Matsakis on page 336.)

Yes, astronomers have psychology too, but the comments on that page
has nothing to do with leap seconds 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: 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 scale based on TAI.
What magic makes one acceptable and the other not?

I didn't say I thought the protest against more widespread use
made sense, I merely tried to relay it faithfully.

I does sound consistent with previously mentioned old fashionedness.

--
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 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 is called, but I agree that it
should be simple :-)

--
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
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).

Without further debating the meaning of civil time, consider the
implications of this two stage system.  The first stage conveys TAI
or something related to it by a constant offset.

Yes, too bad about the offsets (GPS etc) but as long as they don't change
with short notice, they can be dealt with.

The second stage at
any location (correct me if I misunderstand you) would be a secondary
clock disseminated at the direction of the local authorities.

Yes, just like now.

The DCF77 transmitter for instance sends out German legal time
which means that if you want UTC from it, you need to know the UTC
offset for summer/winter in Germany.

Governments and technical users would subscribe to the first stage
clock.  Businesses and civilians would subscribe to the second stage
clock(s).  Correct so far?

Almost.

What you overlook here is that computers tend to trancend governmental
boundaries.

Sensibly designed operating systems keep time in the form of the
first stage clock, and at the representation layer, knowing all the
worlds governmental decisions about getting from 1st to second stage
applies the appropriate conversions.

Badly designed operating systems keep time in local time which makes
interchange of information a nightmare across timezones.

Windows have got it right now I belive, but it used to be that a
file created and transmitted from Denmark at the end of the business
day would be older than a file created at the start of business day
in California, despite a strict ordering of the events.

For the sake of argument, let's discount the risks associated with
confusing one stage's clock with the other.

That's actually the good thing about the constant offset, it should
make it much easier to see if timestamps mix things that shouldn't be.

I won't belabor the many worldwide systems that must interoperate for
the benefit of all.  But these systems must interoperate not only
between themselves, but with natural phenomena.

Sure, and you can timestamp then on either timescale, because there
is a 1 to 1 translation between the two timescales [1].

You mention sunrise and sunset.

Since the introduction of timezones, one of the things which were
given up was the concept that sunrise/sunset happened on the same
numerical time at any given lattitude.

Denmark spans only a few hundred kilometers from east to west (not
counting Greenland this time), yet sunrise and sunset varies about
30 minutes from one side to the other.

Most people get the sunrise/sunset numbers out of the Almanac from
the Copenhagen Universitys Observatory [2] which lists sun rise/set
times for the observatory in Copenhagen and prints a table of
approximate geographical adjustment factors.

So already today, sunrise  sunset can only be determined using
auxillary tables of correction factors, tables which could trivially
absorb the DUT correction in addition to the longtude corrections.

The question is:  how precisely does this differ from the situation
now or in the past?  Whether by fiat or not, some common worldwide
stage two clock must exist.

BZZZT wrong.

The definition we started out with is:

The second stage at any location (correct me if I misunderstand
you) would be a secondary clock disseminated at the direction
of the local authorities.

Conversion from stage two to stage one (and back) is perfect, so
if I measure a supernova in Denmark on Danish Civil Time, I can
mail you my observations and you can convert it first to stage 1
and then to your local stage 2 to compare with your own observation.
Or more likely, convert your own stage 2 to stage 1 and compare
in the scientific time domain.

If Denmark or Elbonia decides to use a timezone which is offset from
stage one by 1h3m21s, then it still works, (but people travelling
abroad will probably vote differently in the next election)

I have heard no response to my discussion of techniques for achieving
synchronization - of the difference between naive fall back hours
and 25 hour days.  But how in practice is it envisaged that a scheme
for migrating time zones versus TAI would work, precisely?

The same way all changes in timezone seems to be carried out: by
_not_ adjusting the clock when going to summer or winter time.

In a couple of hundred years, the Danish Parliament (or its successor
in interest) will simply decide from -MM-DD HH:00, the Danish
Civil time will use offsets -3h and -2h (instead of presently
-1h/-2h) and the transition will happen on the switch from summertime
to wintertime by _not_ adjusting the clock.

That's been done many times throughout the world already.

If you look in NPL's decription of the Rugby timegrams:
http

Re: interoperability

2006-01-08 Thread Poul-Henning Kamp
 is less disruptive than
doing so, no matter which half of the year.

(We'll omit discussion of the fact that not all localities observe
daylight saving time in the first place.)

They have 600 years to find a solution and an implementation
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't entertain such a notion.  I seriously plan to not be
a nuisance to the world long before that.

And I happen to think that my (n)great-children should get to
decide for themselves about how to do 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
In message [EMAIL PROTECTED], Rob Seaman writes:


As I pointed out close to five years ago, the ultimate long term
remediation will likely involve redefining the length of the second:

Rob,

I think this shows how little you understand of the entire thing.

Several SI units are defined relative to the second these days and
therefore everybody involved in metrology have had nothing but
contempt for the notion of changing the second length.

To cut this part of the topic out in cardboard for you:

1. The Earths rotation and to a lesser degree its orbital motion
   are lousy timekeeping devices, many orders of magnitude worse
   than the best atomic frequency normals.

2. In metrology you use the best available method to implement a
   fundamental unit.


But there is something else which bugs me.

Throughout all of these interminable discussions it has become
clear to me that you argue backwards from the end (there must
be a UTC with leapseconds) rather than forward from the
beginning (SI seconds are constant lengt).

In our most recent little exchange, you started out proposing a two
(or three) timescale solution without leap seconds, and then when
I showed that it worked out just the way we wanted, you started
to redefine the timescales so that one of them had to be UTC with
leapseconds.

You also keep harping about how day and night will switch places
without leapseconds, while at the same time dismissing the
governmentally defined local timezones as irrelevant, despite the
fact that they do the heavy lifting (four orders of magnitude more
than leapseconds) of holding the sun high in the sky at noon.

In other words, you are not arguing in good fait and behave
more like a religious zealot than anything else.

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.


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 Universal Time, how will we know
if you mean UTC, UT0, UT1 or UT2 ?

It's obvious from the current definition
and terminology used with Coordinated Universal Time that the original intent
was that UTC would be more-or-less synchronous with UT0, UT1, UT2.  The current
debate is whether we should move away from that original intent.

Correct: we are talking about what the Leap(time) function should 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 attribute to malice what can adequately be explained by incompetence.


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.  The endorsement for the usage of UTC comes from CGPM,
and that is predicated on the existence of leap seconds.

This is irrelevant.

The CGPM may endorse which timescale they think should go into legal
time, but if they change their mind UTC will still exist until ITU
does something about that.

A secondary issue is that even if CGPM decided to say Use FOO instead
nobody would take much notice until ITU and a lot of other people
agreed and did their respective paperwork.

But in the original agreement, UTC and TAI were defined solely by the
BIH according to the rules of the CCIR.  Both the BIH and the CCIR are
defunct.  TAI was transferred from BIH to the BIPM.  Determination of
the UTC offset was transferred from BIH to IERS.  But IERS is not
a single entity, it is an ensemble of entities.

Lets waste a lot of time splitting red tape, why don't we ?

At the beginning of 1984 and at the beginning of 2003 the branches of
the IERS responsible for UT1 followed new IAU recommendations and
changed the rules by which UT1 is calculated.  The current version
of UT1 has a notably different flavor and long-term purpose than
the version of UT1 which was in place when UTC with leap seconds
was originally defined by the CCIR.

But that matter, because ITU-R (successor of CCIR) defined Leap(time)
in terms of UT1 without specifying how UT1 was arrived at.

--
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], 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] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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 recommendations and
changed the rules by which UT1 is calculated.  The current version
of UT1 has a notably different flavor and long-term purpose than
the version of UT1 which was in place when UTC with leap seconds
was originally defined by the CCIR.


  doesn't
 v
But that matter, because ITU-R (successor of CCIR) defined Leap(time)
in terms of UT1 without specifying how UT1 was arrived at.


oops...

--
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.


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 adequately be explained by incompetence.


Re: HBG transmitted wrong info during leapsecond

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes:

Which was also noted at

  http://wwwhome.cs.utwente.nl/~ptdeboer/ham/sdr/leapsecond.html

Right, but I think my data has a bit more resolution etc.

I'm demodulating Rugby right now (will take half a day or so)
and after 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.


Re: The real problem with leap seconds

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Ed Davies writes:


Also, Markus wasn't proposing UTS as a civil timescale but just
for use within computer systems, etc.

What a weird concept...

Why not go the full distance and define a timescale for each
particular kind of time-piece:

Wrist Watch time

Wall clock time

Grandfather clock time

Tower clock time

Television time

Embedded system time

Appliance time

Router time

PC time

Windows server time

Commercial UNIX time

Free UNIX time

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 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], Ed Davies writes:


Ignoring the ridiculous parody - no, it's not a weird concept.
Different timescales are useful for different purposes.  Get
used to it.

I have no problems with different timescales for different purposes.

For instance I very much wish the Astronomers would start to use
UT1, which is very much their timescale, and stop abusing UTC,
which isn't, as a convenient approximation.

But I have big problems with people who want to introduce more
timescales without thinking through the legal and technical
complications.

The question is, where in the range of possible timescales is
it most useful to put civil time.

Civil time is in the hands of individual governments, and they
tend to expect their computers to use the same time as the
rest of their country.

Nobody here is in any position to do anything about civil time
or legal time, neither 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   | 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 opportunity of leap seconds

2006-01-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

Astronomers use UT1.  Astronomers use UTC.  Astronomers are among the
biggest users of TAI and GPS and likely any other timescale you care
to name.

And they certainly have a lot of trouble seeing the rest of the world
in for the brightness of their own majesty.

The only timescale I am interested in here is UTC, and astronomers
are not even close to registering as a marginal group in the user
communities of UTC.

What Astronomers use UTC for, in your own many times repeated words,
is a convenient approximation of UT1, and consequently it follows
that if instead of an approximation astronomers used the Real Thing,
leap seconds could harmlessly be removed from UTC.

By your logic, the U.S. Surgeon General should be a chiropractor.

Once the US government tries to shoulder their national deficit
that would undoubtedly be a good idea.

[various ramblings]

Canoli = common basis for diverse time usage worldwide
Eclair = baseline representation of Earth orientation

Unless we *completely* change our notion of Canoli, Canoli is tightly
constrained to follow Eclair simply by the fact that today and
tomorrow and the million days that follow are all required to be dark
at night and light in the day.

Wrong on all points.

Light of day and darkness of night already is, and for all relevant
future can be, assured by governmental adjustments of 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
[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], Neal McBurnett writes:

 Civil time is in the hands of individual governments, and they
 tend to expect their computers to use the same time as the
 rest of their country.

Yes again.  And they are free to choose TAI if they want a uniform
time scale.  But why take the choice of a UTC that remains within 0.9s
of the earth's average rotation rate?

Well, the BIPM doesn't really want anybody to use TAI, their director
said as much last year, and I can see where he is coming from on that
one.

The snippy answer to why UTC was adopted for civil timekeeping would
be Because they got bad advice, but that would be grossly unfair
since nobody (but possibly Dave Mills) at that time could be expected
to foresee what computer networks would result in and how that would
affect the needs for timekeeping.

Just like the variable rate atoms of the sixties where a bad idea
we now know that the variable length days that replaced them are
bad.

I'm not old enough to have any axe to grind about the last couple
of redefinitions of time, but I can see where they both went wrong
(insisting on using the unprecise and unstable clock to discipline
the stable and precise clock) and I want us to stop that mistake.

Here we disagree.  I guess you're confirming what is in fact the
current problem as I see it.  We're here because an ITU committee,
shrouded in secrecy, is trying to redefine UTC and the international
distribution of time signals, which most jurisdictions rely on one way
or another as civil time.

But you overlook that ITU is an international organization under
the UN aegis.

If ITU in their plenary assembly decides to do something, no matter
how stupid, (X.400 for example), that is nontheless the will of
the governments of the world.

You can find locate your countrys ITU-R representative and contact
them with your input, just as well as I can for mine.

There is nothing hidden, undemocratic or revolutionary about it.
The ITU _process_ does actually work.

I will agree that a lot of what ITU churns out, UTC with leapseconds
and X.400 being my best examples, are rubbish.

Some folks here suggest that legislatures just change their timezones
periodically, forced by the actions of the ITU.  But data was
presented in Torino suggesting a cost to NASA and US DoD of a half a
billion dollars to study, re-engineer and test their systems if UTC
diverges markedly from UT1.  Not an easy thing for a legislature to
deal with.  Again - it's a process problem

Let me channel something that gets said a lot here:

They should have used the right timescale from the beginning.

It sounds like they should have used UT1, doesn't it ?

And why is it that IT related costs matter so much if they come from
people worried about the effect of lack of leapseconds, while at
the same time, they don't matter at all if they come from people
worried about the effect of leapseconds ?

Clearly what's good for the goose is good for the gander, right ?

The only time there has been an inclulsive international meeting
devoted to the issue, at the colloquium in Torino, There was 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 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 to assert
that is easy to do.

As far as I know, pretty much anybody can get observer status in the
working group for a modest/outrageous (take your pick) amount of money.

 There is nothing hidden, undemocratic or revolutionary about it.
 The ITU _process_ does actually work.

Agreed, you just have to be prepared to play the Byzantine games.

Well, that's politics for you.  Just because one doesn't like the
rules doesn't mean that they're not fair.

--
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.


DCF77 leapsecond documented

2006-01-06 Thread Poul-Henning Kamp
My VLF/LF capture has started to yield information now.

I captured the antennasignal from my home-brew loop antenna
(http://phk.freebsd.dk/loran-c/Antenna/) with an Adlink 9812
ADC card at 12 bits and 5 million samples per second.

In total I have 400GB of capture, almost 8 seconds around
the leapsecond.

Some crude software-radio and some CPU hours later, here is the
DCF77 behaviour during the leapsecond:

At midnight, local time the leap warning bit is turned on:
 v
24410.639 001011100101011000111000110110100110101  23:53 0
24470.639 00101001010000111000110110100110101  23:54 0
24530.639 001011010101011000111000110110100110101  23:55 0
24590.638 001010110101011000111000110110100110101  23:56 0
24650.638 0010010000111000110110100110101  23:57 0
24710.638 00101000110000111000110110100110101  23:58 0
24770.639 001011001101011000111000110110100110101  23:59 0
24830.639 001010001001101  00:00 0
24890.638 000010001001101  00:01 1
24950.638 0011101010001001101  00:02 1
25010.638 00101001101  00:03 1
25070.639 0011100110001001101  00:04 1
25130.639 00011001101  00:05 1
25190.639 001110111001101  00:06 1
25250.638 001110001001101  00:07 1

And at 00:00 UTC the leapsecond happens and the leap warning bit turns off:

28010.639 001001011001101  00:53 1
28070.639 00111001010110001001101  00:54 1
28130.638 000101011001101  00:55 1
28190.638 0011101101011001101  00:56 1
28250.638 0011010110001001101  00:57 1
28310.639 00111000110110001001101  00:58 1
28370.639 000011011001101  00:59 1
28430.638 0011110110011010 01:00 1
28491.639 0010110011011001101  01:01 0
28551.639 0010101011011001101  01:02 0
28611.638 0010111001011001101  01:03 0
28671.638 0010100111011001101  01:04 0
28731.638 0010110101011001101  01:05 0
28791.639 0010101101011001101  01:06 0
28851.639 001011011001101  01:07 0

The first column is the number of seconds 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 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


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

2006-01-06 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:


Perhaps what we need is simply to define our terms.  A lot of the
friction on LEAPSECS undoubtedly comes from conflicting meanings.

Good point.


Civil Time = the common basis for diverse time usage worldwide

No.

Civil Time is a legal term, and you have no power to redefine it.

Civil Time =
Legal Time =
what the applicable law says the clock should show.

Solar Time ~ Mean Solar Time ~ Universal Time ~ GMT ~ UTC ~ UT1 =
various approximations to the baseline of Earth orientation

No, No, No.

Solar Time ~ Mean Solar Time ~ UT1 =
various astronomical/geophysical concepts.

GMT = Legal time in the UK, defined by parliament.

UTC = Standard defined by ITU-T, based on SI seconds.

Universal Time = confusing term which comes handy when trying to
manipulate discussions about leap second futures.

Standard Time ~ Local Mean Time ~ Local Apparent Time ~ Sidereal
Time ~ Daylight Saving Time, etc = not pertinent to our discussion

(Partially) Wrong again.

Daylight Saving Time is a component of Legal time and very
relevant to our discussion.


So lets try again, and let us focus on only the bits we need to look at:


TAI
TAI(n) = TAI(n - 1) + 1 SI second

Owned by BIPM / Metre Convention

UTC
UTC(time) = TAI(time) + Leap(time)

Owned by ITU.
IERS evaluates Leap(time) according ITU definition

Civil Time(country)

Civil Time(time) = UTC(time) +
 TimeZoneOffset(country, subdivision, time) +
 SeasonalOffset(country, subdivision, time)

Owned by government of country. Some politically
backwards countries like Denmark have not after a century
managed to get their laws aligned with reality, but that
is merely a matter of political unexpediency.


At this level we don't need to look at UT1 or any of the other
timescales.  99.999% of the Earths population only see those
manifested as hidden variables in the Leap(time) function.

So what we are discussing here is only the Leap(time) function.

You will notice that this function has one argument only: time.

As surprising as this may seem, that is actually the way it is.

Leap(time) is a function that is defined as evaluating to an integer
number of SI seconds as a function of time and it is defined piecemal
with a horizon of 6 to 12 months from the present.

Once IERS have made up their mind, the function doesn't change
again, even if we find out that Earth Orientation was different
from what they thought it was.

Behind the scenes, IERS uses UT1 to decide how Leap(time) develops because
that is how ITU defined the function, but that is a hidden process because
nobody can evaluate it definitively apart from IERS.


If you look at the functions
TimeZoneOffset(country, subdivision, time)
and
SeasonalOffset(country, subdivision, time)

You will find that with a margin of a couple of hours to both sides
their values tend to make the statement sun highest in the sky at
12:00 true.  This trend is of course not accidental.

You will also appreciate that should the relevant governments feel the
desire, they can redefine both functions without consulting anybody but
the citizens of the country in question.

If in a hypothetical scenario, the citizens of country N notices
that because of continental drift, stupid politicians or the way
the UTC timescale is defined, the sun doesn't tend to be highest in
the sky around noon, they are perfectly free to elect some politicians
who with what goes for sufficient warning 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 attribute to malice what can adequately be explained by incompetence.


Re: Longer leap second notice

2006-01-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:
Hi Warner,

 A more apt comparison would be to the leap year rules that we
 have.  We know the rules going
 forward a thousand years or so.

Apt indeed.  Leap seconds are scheduled at least six months in
advance.  That's about one part in 15 million.  A thousand year
horizon for scheduling leap days is one part in 365,250.  So we're
already doing 50 times better than Julius Caesar and Gregory XIII.

This comparison is utter rubbish, and you know it.

Little support - and again, to a certain level of precision (easily
better than a second per day), all parties must certainly agree that
civil time (as we know it) IS mean solar time.

Since you keep repeating this Nixon cannot have won, nobody I know
voted for him falsehood let me express myself in very simple terms:

No, I do *NOT* agree that civil time is mean solar time.

Got it ?

Civil time is at best local solar time +/- up to several hours in
either direction depending who you are and where you are.

Seveal geographical/political regions have actively chosen to
increase the distance between mean solar time and local time during
various stretches of time, often in periodic fasion and sometimes
with far too little thought before the decision.

We keep hearing use an appropriate timescale and in the same emails
we hear UTC is a convenient approximation of UT1.

Sounds to me like that argument should be backfired:  If you need UT1,
then use an appropriate timescale: UT1, don't force the majority
of UTC users to suffer because you use the wrong timescale.

Can't argue with that - although ultimately a single well tied knot
is stronger 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 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: Diagram of CHU Leap-Second Recording and Atomic Clock

2006-01-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Tom Van Baak writes:

As for your Skyscan clock, I have several dozen
similar consumer RC clocks here and none has
ever adjusted itself for a leap second in real-time

The majority of such clocks only run the receiver for some part of
the day to save power.

One particular kind I examined ran the receiver until it had sync,
then powered the receiver down for 23 hours and repeated the cycle.

My local clockaholic told me that some of the more modern ones
sleep based on battery voltage:  As the voltage drops, the chance
of slips in the mechanism 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 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: civil time = solar time

2006-01-04 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

I said:

 all parties must certainly agree that civil time (as we know it) IS
 mean solar time.

Ed says:

 saying that it IS civil time is probably a bit strong.

Probably a bit strong is not precisely a staunch denial.

[...]

This is simply a classic exercise in applying epsilon constraints.

Yes, another inappropriate method used to sell your bogus argument.

It's bogus because neither local time nor civil time is a
continous variable but a quantified variable (because of the timezones)

The minimum epsilon constraint which is valid for a quantified
variable is the unit of quantum.  That is why all digital measurements
by definition have an uncertainty of at least +/- 1 digit.

The longitude conference defined the unit of quantum as 1 hour but
despite this I belive a few localities (.au ?) have opted for a
30minute quantum.

  1. local civil time matches apparent solar time roughly

Because local civil time have chosen timezones appropriate for
this purpose.

  2. the relationship between local civil time and apparent solar
 time is constant enough in any one place

Uhm no.  Politicians have decided to make it flip 15 degrees forth
and back with summertime regulations.

  3. the rate of local civil time is constant at least to the
 precision of most clocks 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 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 since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


Re: Where the responsibility lies

2006-01-03 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:
John Hawkinson replies:

I think PHK has demonstrated the ability (and willingness :-) to hold
up his own end of an argument.  Should we ever find ourselves at the
same conference, I'll buy him a beer in anticipation of a rousing
discussion.

I'll be happy to bring booze as well :-)

There are several issues confounded here.  First, an untested
assertion that eliminating leap seconds will simplify time handling.
DUT1 looms large in astronomical software and one would have to be
convinced that this is not an issue with other disciplines.

But it's exactly the fact that DUT1 already exists that bugs me.

If you already have to cope with DUT1 anyway, how much difference
can it possibly make if the definition says
 |DUT1|  .9
or
 |DUT1|  10sec
or
 |DUT1|  1 hour

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 of leapseconds.

Third, leap seconds are a mechanism to realize mean solar time in
practice.

As would leap-hours (or jumping timezones) be.  It's only a matter of
the tolerance we accept on DUT1.

As far as I know, less than 1% of people on this planet actually
have the sun straight south at 12:00 local time today and a quite
sizeable minority (a lot of China) lives perfectly happy with the
sun being further than 15 degrees from south at local 12:00.

It follows from this, that a proposal for a 1hour tolerance on
DUT1 is perfectly feasible without odd things happening to the
cows milk etc.

The acknowledgment of a contingent need for
leap hours shows that the authors of the ITU proposal understand this.

I think the leap hours is a political tool to make the proposal go
through without commiting anybody to anything for the next couple
of hundred of years.

Fourth, the need for leap seconds is growing quadratically as the
Earth continues to slow.  We have no business making ad hoc policies
based on the rarity of events that are becoming more frequent.  The
need for leap hours will grow just as rapidly - and much more
dramatically.  A solution that ignores real world constraints is no
solution.

Uhm, no.

There are three orders of magnitude difference between a leap second
and a leap hour, and consequently the need for leap 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   | 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: 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 of leapseconds.

PHK can reply for himself here but, for the record, I think RS's
reading of what he said is different from mine.  My assumption is
that PHK is discussing the idea that leaps should be scheduled many
years in advance.  They should continue to be single second leaps -
just many more would be in the schedule pipeline at any given
point.

Obviously, the leap seconds would be scheduled on the best available
estimates but as we don't know the future rotation of the Earth this
would necessarily increase the tolerance.  In theory DUT1 would be
unbounded (as it sort of is already) but PHK is assuming that there'd
be some practical likely upper bound such as 10 seconds.

Am I right in this reading?

yes.

--
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: 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 to update the factory
 installed table of leapseconds.

Do you have any evidence for this assertion?

It is an educated guess.

The IERS have already indicated that they belive they could do prediction
under the 0.9 second tolerance with two or three year horizon.

Anyone have a prediction algorithm in mind, and a result of running it
on the last several decades or centuries of data?

Makes a great subject for science, doesn't it ?

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: NTP behavior in Australia

2006-01-02 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:
Here is one indication of NTP response to the presence of low stratum
servers which did not behave well.

http://members.iinet.net.au/~nathanael/ntpd/leap-second.html

I grabbed a set if IP#'s from pool.ntp.org and monitored them in the 24
hours before and 8 hours after the leap.

Out of a set of 12 IP#'s two public stratum 1 servers never set the
leap bit, but did apply the leapsecond locally.

One of the 12 was a stratum 1 using DCF signal, and that one as expected
only set the leap warning one hour before the event.

Ten hours after 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 by incompetence.


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: 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 of
practically all computers are just not sufficiently accurate for
that.  If computers start having an actual atomic clock on board,
maybe things will be different.

The trick is how you efficiently and precisely determine which
computers do and which do not need to cope correctly with leapseconds,
and subsequently, how you determine which of the ones that need to,
will do so.

Y2K has shown us that just ask people is so far from the correct
solution that it is almost better as a negative indication.

--
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 day  (month  and  possibly
 year) at the very second it occurs.

 That is probably one of the strongest arguments for retaining that
 moment of insertion:  That way computer bugs are more likely to
 be noticed.

UTC is not a debugging tool, it is an  international
standard. Software is an an issue  but  I  think  it
cannot justify in itself  that  leap  second  impact
should be as large as possible.

It must be wonderful to live in a world where software can just be
ignored or marginalized at whim, I really envy you.

--
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.


Schreiver AFB warns about leapsec

2005-12-20 Thread Poul-Henning Kamp
There is an interesting PowerPoint (sigh...) at Schriever AFB's GPS
support center:

https://www.schriever.af.mil/GpsSupportCenter/archive/advisory/Leap_Second_Event.ppt

Amongst the nuggets:

 Large error makes data unusable for some applications
 Eglin radar missed the leap second in 1998
 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 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-20 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

An interesting observation:

- Leap second occurs at an awkward time - New Years Eve

Maybe obscurity in scheduling and implementation is not a desirable =20
characteristic after all.  Perhaps the problem would solve itself =20
through market forces if leap seconds were simply required to occur =20
on normal business days at 9:00 am EST, just in time for the opening =20
of the NYSE.

They already happen during business hours in Asia.  Since most of the
US debt is owned by asia these days, it may even be a more efficient
market 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: Lighter Evenings (Experiment) Bill [HL]

2005-12-19 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Markus Kuhn writes:

The crudest approach would probably be

I would be all for it :-)

  a) N+S America:   use local time of Cuba (~ UT =
- 5.5 h)

Unless you substitute something other than Cuba, your proposal will
never get one inch 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 attribute to malice what can adequately be explained by incompetence.


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.

That was kind of my point, too.  We have standards bodies that don't
promulgate their standards.  [...]

You need to look even further down the foodchain, starting from the bottom:

* First comes people who make buying decisions based on price.

* Then comes engineers who are only in it for the money.

* Then comes product managers cutting corners to push out a cheap product early.

* Then comes companies who only care about money


The kind of people who even care enough to think about participating
in standards writing, are leagues above those four by the simple
fact that they actually do care in the first place.

And as we all know from the standards we work with, even those people are pretty
underperforming to begin with.


In an ideal world, I would love to educate them all about the errors
of their ways, but I'm too old to seriously contemplate such a
project.

Leapseconds are simply too technically tricky for the species we
are dealing with.  They are OK if confined to science labs, but out in
the real world where people think McDonalds food does not make you fat
leap seconds are just no feasible.

--
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: a system that fails spectacularly

2005-12-07 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Brian Garrett writes:

And you've gotta love the interpretation of UTC as Universal Time Code in
the Canadian report.  If they don't understand what UTC is, or at the very
least understand that their users are going to be confused by their
misleading use of the acronym, it's hardly a surprise that a leap second is
going to pull the rug off their code and expose the bugs they've swept
underneath it.

Some of us have been trying to drive this point though for some time:

  99.99% of all programmers have no idea what a leap-second is.

And these are the people who 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 be explained by incompetence.


Re: BBC - Leap second talks are postponed

2005-11-21 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:
On Nov 21, 2005, at 1:53 AM, Clive D.W. Feather wrote:

 It is NOT CALLED daylight saving and it is NOT saving any daylight.

I don't know where you are, but in Denmark we gain close to 60
minutes extra daylight per day except for june/july, so we do
in fact save the daylight for better use.

 It is summer time.

Ok, then.  Anybody have a suggestion for a general term for which
daylight saving and summer time are special instances?

Well, local languages have their private definitions, in Denmark it
is summertime/wintertime.

 The Danish version talks about UTC, which is cute since in Denmark
 legal time is still mean solar time at the Copenhagen Observatory,

How does this work in practice?  Lots of web hits show Copenhagen in
the Central European Timezone, one hour ahead of Greenwich (ignoring
the whole summer time issue).  Its longitude appears to be 12.66
degrees east, or 50 minutes ahead.

Of course we use the same time as everybody else around us, (UTC +
1h/2h) but legally that is approx 14 minutes and 33 seconds wrong.

In all likelyhood, a lawyer would point to some international convention
or other about time (the meter 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 adequately be explained by incompetence.


Re: WP7A press release

2005-11-18 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Rob Seaman writes:

The attached WP7A press release states that the working party has
decided that more time is required to build consensus.  It does not,
however, suggest that any other proposals will be entertained.

Neither does it in any way bar new proposals.

I don't think there is even anything in the WP7A rules that would
allow them to bar new proposals, provided these were submitted
properly.

But I think you read their message wrong.

I don't think they said We'll try to build concensus.

As I read it, they more or less told USA that their proposal was
nice and all that, but that since it did not come with a concensus
or majority, they ain't going to touch it.

The to weight, as I understand it, is therefore on USA and the
leap-second aware computer people.

With respect to the secrecy and lack of awareness of the ITU standards
I can only agree:  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 attribute to malice what can adequately be explained by incompetence.


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.  Is this actually
the case?  I suspect that a squadron of lawyers would likely find
that the International Telecommunications Union is the appropriate
international body to transport time signals relating to, well,
international telecommunications - but what exactly is that?  Clearly
other time signal providers exist, e.g., GPS and NTP.  But who owns
the underlying concept of Universal Time or the UTC flavor of same?
Perhaps this is the first consensus position to identify.

(Along these lines I find it a far more interesting question who
owns the leap-day formula.  Is it still the pope ?  :-)

I see neither reason nor advantage to move UTC from ITU which is an
UN body where all citizens of the planet have a voice to a semi-closed
priesthood like IERS or BIPM where only scientists have a voice.  In
particular not given that these particular scientists seem to be
very behind the curve when it comes to modern technologies like
data/tele networks etc.

--
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-18 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Peter Bunclark writes:
On Fri, 18 Nov 2005, Ed Davies wrote:
 On the other hand, I rather snigger at the reservation of the
 word universal to mean time based on the Earth's rotation.
 It's all rather parochial but it is the established terminology.
Doesn't Universal hint at the join of the SI second and Solar Time?

Oftentimes labels of X are put on things to give the impression of
a good bit more X than is actually at hand.

I suspect that Universal in UTC has the same lineage as democratic
in The Democratic Republic of Congo.

UTCs proper name would have been 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: RAS hits the news

2005-09-27 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Steve Allen writes:

The inclusion of calendar year is an interesting addition to the
original week-based scheme.  The week-based scheme was perhaps chosen
while noting that the week remained intact when Pope Gregory (and
then, eventually, all the protestants) switched calendars.

I think you are far overestimating 1970 electronics :-)  The week
based scheme was a compromise forced by number of bits available
and how much electronics could be dedicated to the task of receiving
the signals.  For a long time the almanac was something you had to
manually enter 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 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 about it.

Of course not.

And that was exactly my point: civil and scientific timekeeping was
two different issues and they have different semantics and needs.

Most of this argument is still centered around the unarticulated
question: who owns UTC.

Wouldn't it be fair if the non-scientific (ie: civil) world told
the astronomers (and any other scientists) to bugger off and not
impose scientific requirements on civil time ?

After all, scientists have several timescales of their own already,
and plenty of means to implement them, whereas UTC is the only
agreed upon and widely available civil timescale.

--
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: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], Tom Van Baak writes:

I am wondering, though,
if anyone knows of an example of a GPS receiver
that caches the delta value from the last power-up?
It seems to me this would take care of the delay in
all but the most extreme cases.

Most receivers will cache the almanac if they have a piece of CMOS
RAM for it. The Oncore series certainly do.

But appearantly the Oncore only uses the Almanac to get a quick
first fix when you power it back up, and for this even a quite old
almanac will do since in general the orbits are quite stable.

The Oncore doesn't seem to trust the cached/uploaded almanac beyond
that, until it has received confirmation that it is indeed the
current almanac.

I'm not quite sure what confirmation it takes to satisfy the Oncore
on this point, but it looks like it is the specific sub-frame of
the almanac which contains a timestamp of some 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 attribute to malice what can adequately be explained by incompetence.


Re: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes:
In message: [EMAIL PROTECTED]
Rob Seaman [EMAIL PROTECTED] writes:
: The question is whether at least 20 minutes (presuming this to be
: accurate) is intrinsic to the system design or is rather a result of
: poor implementation by some receiver manufacturers.

A cold GPS receiver takes about 20 minutes to get the almanac data
from the GPS constellation.  It is intrinsic to GPS that this is the
case.  You cannot get around this.

Actually I think the number is around 15 minutes from the time you
get code data from the first satellite.

(I have always wondered why the almanac isn't staggered between
the satellites, that way you get get it at least four times faster
on average).

Others are
cold only if they have been off so long that they have no way of
knowing the current correct leap count.  Given that BIPM only
publishes 6 months in advance, this means that the longest a receiver
can be off is about 6 months.

I think you risk confusing two things here.

At least the Oncore receives will happily use a 2 year old alamanc
to aid in getting first fix.

But they will not use anything but the current almanac to report
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 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: RAS hits the news

2005-09-26 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], M. Warner Losh writes:

I think that it depends on the model of oncore receiver. The M12+
appears to cache the almanac wrt leap seconds for a period of time
after power is removed from them (I'm sure it does this if the power
is off for minutes, I'm sure it doesn't if it is off all weekend, but
don't know where the cutoff point is).

The real test is to power off, disconnect antenna and power on.  If
it reports leap second status then, it must clearly trust the
cached almanac 100%.

My conclusion was that it didn't until it had seen a timestamp
from a satellite 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 like the U.S. Congress?
http://tycho.usno.navy.mil/260.html

...the standard time of the first zone shall be based on the mean
solar time of the sixtieth degree of longitude west from
Greenwich... (and so on for all the other zones)

Well, at least they had the sense to use a longitude divisible by
15.  Not so lucky in Denmark: 50°19'

 Imagine for instance that we send a probe out of the solar system
 at seriously high speeds and it manages to get as far as 6 light
 months away:  Under the current UTC rules we would be unable to
 upload a leap-second warning and get it there before it is too late.

I would suppose that such a space probe would have little need to be
synchronized with earthly solar time, and thus might be best off
operating on TAI, with any adjustments to UTC for the sake of humans
observing it on Earth being done at the Earthly end of things.

Again: merely trying to point out that the only one timescale
argument Rob pushes doesn't work.

--
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], Randy Kaelber writes:
On Mon, Sep 26, 2005 at 02:33:00PM -0400, Daniel R. Tobias wrote:

 I would suppose that such a space probe would have little need to be
 synchronized with earthly solar time, and thus might be best off
 operating on TAI, with any adjustments to UTC for the sake of humans
 observing it on Earth being done at the Earthly end of things.

That's the way we do it for interplanetary stuff now.  Data from
spacecraft are typically returned in spacecraft clock time (SCLK, which is
pronounced sclock) and then translated to whatever time base you 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   | 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
In message [EMAIL PROTECTED], John.Cowan writes:
Rob Seaman scripsit:

 [B]ut we already agree on a common
 position that civil time needs to mimic solar time for most purposes.

Kashi, Kashi, Kashi.

It's interesting that no matter how much we keep telling him
otherwise, Rob still claims that we 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
In message [EMAIL PROTECTED], Peter Bunclark writes:

 The POSIX definition makes it impossible to correctly handle leap
 seconds with any complying implementation of the standard, and
 therefore applications which needs to be *truly* leapsecond compliant,
 cannot use the standard libraries.

So 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 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
In message [EMAIL PROTECTED], Rob Seaman writes:

Yes, I assert that we already agree on what I'm saying - or trying to
say here.  Let's put aside six years of squabbling about details and
look at the larger picture.

John Cowan and others on the leap seconds suck side of the
discussion have often said things that indicate that, whatever the
tolerance, there is some common sense connection between darkness and
the concept of midnight:

 as long as the clock doesn't say noon when it's midnight

But apart from a select little crew of time-nuts and the geographically
gifted, nobody has UTC on their clock:  They have local time which
is some number of minutes offset from UTC.

We could replace UTC with TAI, or kill leapseconds in UTC and let
it keep its offset from TAI or do a myriad of other things and still
keep the clock as people see it on their wrist [1] in sufficient
sync with the light of day through minor acts of timezone adjustments.

If you want to get me to agree with you on something resembling the
statement you made, then it is this:

Local Legal/Civilian time will probably always have the sun
highest in the sky somewhere around 12:00 through political
modification of timezone affiliation.

It follows trivially from there that it doesn't matter a dingos
fetid kidneys [2] to legal/civilian time what UTC does with relation
to the Sun, as long as it is not something ridiculous as monthly
leapseconds.

Poul-Henning


[1] VCR's will probably 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: vive le BIH!

2005-08-29 Thread Poul-Henning Kamp
In message [EMAIL PROTECTED], John.Cowan writes:
Clive D.W. Feather scripsit:

 The problem here is Microsoft, whose software appears to believe that the
 current LCT here is GMT Daylight Time.

How thoroughly stupid.  Nevertheless, when I talked to the teleconference
organizer, it became thoroughly clear that for him GMT meant the time
on my wristwatch or wall clock, and that he had no idea that anyone had
any other meaning for the abbreviation.

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.

--
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.


  1   2   >