date:20060107

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)

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

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)

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

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 Markus Kuhn

Which was also noted at

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

Various other LF 2005 leap second recordings are listed at

  http://www.cl.cam.ac.uk/~mgk25/time/lf-clocks/#leapsec2005

Markus

--
Markus Kuhn, Computer Laboratory, University of Cambridge
http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain

Re: HBG transmitted wrong info during leapsecond

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

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 Ed Davies


Poul-Henning Kamp wrote:


What a weird concept...

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



and give each of them their own unique way of coping with leapseconds ?



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

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

Ed.

Re: The real problem with leap seconds

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 real problem with leap seconds

2006-01-07 Thread Rob Seaman


Hi Ed,


Poul-Henning Kamp wrote:


What a weird concept...

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



and give each of them their own unique way of coping with
leapseconds ?



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

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

Ed.


I was contemplating an answer along the same lines.  Yours is much
superior.

Rob

Re: The real problem with leap seconds

Ed Davies scripsit:

 (There's a small difference in practice in that the UTC to
 TAI conversion requires a lookup table which is not known
 very far into the future whereas the Gregorian calendar is
 defined algorithmically for all time.)

Well, yes.  But that's a matter of verbal labels.  The Gregorian calendar
extends to all future time: what is not known is the date on which it
will be replaced in civil use by a further refinement.  We know we will
need one eventually, both because of the current annual discrepancy of
about 27 seconds between the Gregorian and tropical years, and because
of future changes in the length of the tropical year.

--
John Cowan  [EMAIL PROTECTED]  www.reutershealth.com  www.ccil.org/~cowan
If a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect.  --Benjamin Disraeli

Re: The opportunity of leap seconds

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

Rob Seaman scripsit:

 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.

I think you are getting carried away by your own rhetoric here.  It will
be dark at night and light in the daytime even if we smash every clock
on Earth (not a bad idea, I think sometimes).  What you surely mean
is that it should be locally dark when local clocks say  and thereabouts,
and consequently light when they say 1200 and thereabouts.  There is
much room for adjustment around the midpoints, however.

 Whether we choose to bleed off the
 daily accumulating milliseconds one second or 3600 at a time, bleed
 them we must...and even people who loathe the very notion of leap
 seconds admit this.

NO, I DON'T ADMIT THAT.  On the contrary, I deny it, flatly, roundly,
and absolutely.

 (The craven ITU proposal is obligated to pay lip
 service to leap hours, though what they really are saying is let's
 close our eyes and wish it away.)  Time to move on.

The leap-hour proposal can be read as either (a) a serious proposal to
inject an hour into UTC at some future date, or (b) a cynical proposal to
abandon leap seconds and not replace them.

I think (a) is just as foolish as leap seconds, if not more so.  As for
(b), it may be the best political approximation to what I really want,
which is (c): abandon leap seconds altogether.

But then, soon enough, it won't be dark at !  Yes it will, just
not in the skies over Greenwich.  Practical difficulties can be overcome
by making secular changes to the offsets between LCT and UTC, just as is
done today when such problems arise.  (In the next two years, the U.S.,
to name just one country, will make two secular changes to its LCT offsets.)

The computerniks of the world already know how to handle such things,
so future migrations will not be a problem.

And people who want, for their legitimate purposes, to have access to UT1
will have to get it some other way.

--
It was impossible to inveigle   John Cowan [EMAIL PROTECTED]
Georg Wilhelm Friedrich Hegel   http://www.ccil.org/~cowan
Into offering the slightest apology http://www.reutershealth.com
For his Phenomenology.  --W. H. Auden, from People (1953)

Re: The real problem with leap seconds

Steve Allen scripsit:

 The changes in the length of any kind of year are slight by comparison
 to the changes in length of day.  Neglecting short period variations
 the length of the sidereal year has not changed much in a billion years.

That is to say, the current best approximation to the n-body problem of
the Solar System says that it hasn't.  Fair enough.  I merely threw that in
in case it was an issue.

 The Gregorian calendar was designed to match the vernal equinox year.

Thanks for the correction.

 The new fields being added to GPS signals make them able to count leap
 seconds for 3 years.  That's quite an example of engineering margin.

Indeed.  But then so is IPv6 (if we ever get it adopted widely).

--
John Cowan  [EMAIL PROTECTED]  www.ccil.org/~cowan  www.reutershealth.com
In the sciences, we are now uniquely privileged to sit side by side
with the giants on whose shoulders we stand.
--Gerald Holton

Re: The opportunity of leap seconds

Poul-Henning Kamp scripsit:

 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.

Chiropractors are by no means cheaper to hire than other doctors.
Nor are their treatments necessarily the worse because their theory
is crappy.

 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)

Indeed.  I did a quick look once at the number of secular changes to the
TimeZoneOffset function since the adoption of standard time in the
various countries; I may have posted the results here.  If not,
I'll try to dig them up.

--
John Cowan  [EMAIL PROTECTED]  www.reutershealth.com  www.ccil.org/~cowan
   There was an old manSaid with a laugh, I
 From Peru, whose lim'ricks all  Cut them in half, the pay is
   Look'd like haiku.  He  Much better for two.
 --Emmet O'Brien

Re: The real problem with leap seconds

2006-01-07 Thread Neal McBurnett

On Sat, Jan 07, 2006 at 04:02:04PM +0100, Poul-Henning Kamp wrote:
 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.

Yes  And with people that want to redefine existing time scales so
they mean one thing in one era, and another thing in a different era.
As happened with GMT, or the proposed changes to UTC.

 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.

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?

 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.

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 the way the ITU works undermines the sort of open and informed
discussion that is necessary for an issue so sweeping in its legal,
practical and philosophical implications.

The thing that is most flawed here is the process.

 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.

But it is inappropriate for ITU to do an end-run around the laws, and
redefine the timescale so that it swings an extra hour back and forth.

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

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.

But If a change were to be made one alternative appeared to be
preferred. The essence of this alternative was as follows: 1. Any
change should slowly evolve from the current UTC Standard in
transitioning to a uniform timescale, perhaps to be called Temps
International (TI). 2. A suggested date for inaugurating any change
would be 2022, the 50 TH anniversary of the UTC timescale. The date
suggested is influenced by the lifetimes of existing systems that
would be expensive to change.
[http://www.ien.it/luc/cesio/itu/annex_a.pdf]

So it is distressing to see committee members of the ITU headed in a
different direction.

Neal McBurnett http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

 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

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 M. Warner Losh

In message: [EMAIL PROTECTED]
Daniel R. Tobias [EMAIL PROTECTED] writes:
: On 7 Jan 2006 at 16:02, Poul-Henning Kamp wrote:
:
:  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.
:
: And, in many countries (including the United States), the legally-
: defined civil time is the mean solar time at some particular spot, or
: a fixed or seasonally-variable offset from it.  Any use of UTC-based
: time scales for determining civil time in such places is merely an
: approximation, currently to within a second, but perhaps varying by
: greater amounts if some new timekeeping plan is adopted.  Once UTC
: stopped being a sufficiently-close approximation to the solar mean
: time at the Prime Meridian (with sufficiently close possibly being
: of differing values depending on the particular purpose), it would be
: necessary to either stop using UTC for determining civil time in such
: countries, or to change the law to base the civil time on UTC instead
: of a solar standard.

The US's legislation leaves it to the commerce department to define
what the mean solar time is (or rather states that it is the mean
solar time, as determined by the secretary of commerce).  This is what
presumably gives us leap seconds and the like in our civil time and
when we insert them.  This is a political function: Up to a second of
tolerance is allowed and leap seconds are inserted whenever everybody
else does.  The same political decision could be made to say something
else, since it is the folks in DC could say that a minute is close
enough to solar mean and that's what we're going to do.

Warner

Re: The real problem with leap seconds

2006-01-07 Thread Steve Allen

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.

In the US the process is Byzantine.  Whereas it is apparently required
that draft contributions to the ITU be publicly available, it is
apparently not required that their availability be published outside
of predefined special interest groups.  I would describe more of what
I know, but given that my knowledge is assembled from little bits
gleaned from unrelated documents I'm not convinced I am right.

If anyone else cared to challenge me to post the rules of some other
nation I'll gladly rise to the challenge and post the US rules.

 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.

--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99858
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m

Re: The real problem with leap seconds

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.

Re: The opportunity of leap seconds

2006-01-07 Thread Rob Seaman

On Jan 7, 2006, at 11:37 AM, John Cowan wrote:Whether we choose to bleed off the daily accumulating milliseconds one second or 3600 at a time, bleed them we must...and even people who loathe the very notion of leap seconds admit this. NO, I DON'T ADMIT THAT. On the contrary, I deny it, flatly, roundly, and absolutely.Alternately, you could read what I said. I wasn't claiming all such people would admit it (though, of course, they should). I was pointing out that the ITU already felt obligated to admit it.We've long since devolved into a Monty Python sketch: Owner: Well, o'course it was nailed there! If I hadn't nailed that bird down, it would have nuzzled up to those bars, bent 'em apart with its beak, and VOOM! Feeweeweewee! Mr. Praline: "VOOM"?!? Mate, this bird wouldn't "voom" if you put four million volts through it! 'E's bleedin' demised! Owner: No no! 'E's pining! Mr. Praline: 'E's not pinin'! 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! If you hadn't nailed 'im to the perch 'e'd be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's off the twig! 'E's kicked the bucket, 'e's shuffled off 'is mortal coil, run down the curtain and joined the bleedin' choir invisibile!! THIS IS AN EX-PARROT!The leap-hour proposal can be read as either (a) a serious proposal to inject an hour into UTC at some future date, or (b) a cynical proposal to abandon leap seconds and not replace them.I think (a) is just as foolish as leap seconds, if not more so.Glad to hear you say it.The computerniks of the world already know how to handle such things, so future migrations will not be a problem.Thanks! I needed a good chuckle :-)

predicting leap seconds (was Re: [LEAPSECS] Where the responsibility lies)

2006-01-07 Thread Neal McBurnett

On Wed, Jan 04, 2006 at 07:36:17AM +0100, Poul-Henning Kamp wrote:
 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.

The Torino Colloquium had some discussion of this.

 Proceedings of the Colloquium on the UTC Timescale held by
 ITU-R SRG 7A
 http://www.ien.it/luc/cesio/itu/ITU.shtml

 Prediction of Universal Time and LOD Variation
 D. Gambis and C. Bizouard, (IERS)
 http://www.ien.it/luc/cesio/itu/gambis.pdf

After a bunch of nice graphs (not all of which were easy to interpret)
I found the periodogram (essentially a discrete Fourier transform of
the input data) interesting.  The way I read it (expert advice
welcomed), the broad peaks at 26 years (0.6 ms/d) and 52 years (0.3
ms/d) suggest that the most common pattern is a gradual cycle a few
decades long of lengthening and shortening of the day, presumably
driven by movements in the earth's mantle and core.

Page 14 of the pdf has a table:

 Skill of the UT1 prediction statistics over 1963-2003

Horizon   Prediction accuracy in ms
3 years   308
2 years   163
1 year 68
180 days   36
90 days21
30 days 7
10 days 3

Perhaps these are worst cases?  It would be nice to have confidence
intervals.

They presented these conclusions:

 Possibility to predict UT1 with a 1s accuracy at least over 4 years
 using a simple method : seasonal, bias and drift.

 New prediction methods are under investigation (Singular Spectrum
 Analysis, neural network,..)

 Possibility to use Core Angular Momentum prediction for decadal
 modeling

Steve Allen wrote:
 http://www.ucolick.org/~sla/leapsecs/McCarthy.html

 This deserves discussion and analysis and explanation.

I wrote Dennis McCarthy about that, and he said he'd look up the
details and get back to me next week.  But he did remind me of this,
which I remember seeing in data they published via ftp years ago:

 Regarding the accuracy of these long-term predictions, the IERS
 Rapid Service and Prediction Center located at the U. S. Naval
 Observatory does make predictions of Delta-T in the IERS Annual
 Report.  The algorithm for those predictions was determined
 empirically by testing a wide range of possibilities.  It is
 essentially an auto-regressive model using the past ten years of
 data.  The accuracy based on comparison of observations with what
 would have been predicted using that model is shown in the table
 below.  Note that the accuracy estimates are 1-sigma estimates and
 that excursions of 2-sigma (or more) may not be unexpected.

 +-+
 |Year in the Future|Accuracy (1s) (seconds|
 |--+--|
 |1 | .04  |
 |--+--|
 |2 | .08  |
 |--+--|
 |3 |  .3  |
 |--+--|
 |4 |  .8  |
 |--+--|
 |5 |  1.  |
 |--+--|
 |6 |  2.  |
 |--+--|
 |7 |  2.  |
 |--+--|
 |8 |  3.  |
 |--+--|
 |9 |  4.  |
 +-+

The http://www.iers.org/ points eventually to

 http://141.74.1.36/MainDisp.csl?pid=47-25786

but the links from there to the annual reports seem broken right now.

I still haven't seen any good data on predictions for periods of
longer than 9 years.

Neal McBurnett http://bcn.boulder.co.us/~neal/

Re: The real problem with leap seconds

From [EMAIL PROTECTED] Sat Jan  7 08:03:04 2006
Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by 
ivan.Harhan.ORG (5.61.1.3/1.36)
id AA14507; Sat, 7 Jan 06 08:03:03 GMT
Received: from rom.usno.navy.mil by [198.116.61.253]
  via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 
08:10:46 UT
Received: from ROM (rom.usno.navy.mil [10.1.4.27])
by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k077o0kU019926;
Sat, 7 Jan 2006 08:02:52 GMT
Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release
  1.8e) with spool id 0549 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan
  2006 08:02:52 +
Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by
  rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k0782pkM019980 for
  LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 08:02:52 GMT
Received: from santo.ucolick.org ([128.114.23.204]) by TS-FW.usno.navy.mil via
  smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006
  08:10:36 UT
Received: from localhost (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix)
  with ESMTP id 475575D715 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7
  Jan 2006 00:02:51 -0800 (PST)
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using
  TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client
  certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id
  D9F7C11419 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7 Jan 2006
  00:02:50 -0800 (PST)
Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org
  (8.13.1/8.12.10) with ESMTP id k0782ofC025400 for
  LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 00:02:50 -0800
Received: (from [EMAIL PROTECTED]) by geneva.ucolick.org (8.13.1/8.13.1/Submit) 
id
  k0782oFP025399 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006
  00:02:50 -0800
Date: Sat, 7 Jan 2006 00:02:50 -0800
From: Steve Allen [EMAIL PROTECTED]
To: Leap Second Discussion List LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: The real problem with leap seconds
Message-Id: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: [EMAIL PROTECTED]
User-Agent: Mutt/1.4.2.1i
Sender: [EMAIL PROTECTED]
Precedence: list
Status: RO

On Sat 2006-01-07T07:39:58 +, Michael Sokolov hath writ:

 http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt

If I read it right you have reinvented Markus Kuhn's UTS as seen in

http://www.cl.cam.ac.uk/~mgk25/uts.txt
http://www.cl.cam.ac.uk/~mgk25/time/leap/
http://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf

--
Steve Allen [EMAIL PROTECTED]WGS-84 (GPS)
UCO/Lick ObservatoryNatural Sciences II, Room 165Lat  +36.99858
University of CaliforniaVoice: +1 831 459 3046   Lng -122.06014
Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m

From [EMAIL PROTECTED] Sat Jan  7 12:28:40 2006
Received: from juno.usno.navy.mil (HELO [198.116.61.253]) ([198.116.61.253]) by 
ivan.Harhan.ORG (5.61.1.3/1.36)
id AA14637; Sat, 7 Jan 06 12:28:38 GMT
Received: from rom.usno.navy.mil by [198.116.61.253]
  via smtpd (for ivan.Harhan.ORG [208.221.139.1]) with SMTP; 7 Jan 2006 
12:36:23 UT
Received: from ROM (rom.usno.navy.mil [10.1.4.27])
by rom.usno.navy.mil (8.12.8/8.12.8) with ESMTP id k07BLaki031306;
Sat, 7 Jan 2006 12:28:29 GMT
Received: from ROM.USNO.NAVY.MIL by ROM.USNO.NAVY.MIL (LISTSERV-TCP/IP release
  1.8e) with spool id 0583 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan
  2006 12:28:28 +
Received: from TS-FW.usno.navy.mil (TS-FW.usno.navy.mil [10.1.1.3]) by
  rom.usno.navy.mil (8.12.8/8.12.8) with SMTP id k07CSRkM032500 for
  LEAPSECS@ROM.USNO.NAVY.MIL; Sat, 7 Jan 2006 12:28:28 GMT
Received: from mail.metronet.co.uk ([213.162.97.75]) by TS-FW.usno.navy.mil via
  smtpd (for rom.usno.navy.mil [10.1.4.27]) with SMTP; 7 Jan 2006
  12:36:12 UT
Received: from [192.168.26.3] (213-162-103-78.edmund434.adsl.metronet.co.uk
  [213.162.103.78]) by smtp.metronet.co.uk (MetroNet Mail) with ESMTP
  id 72B0F408240 for LEAPSECS@ROM.USNO.NAVY.MIL; Sat,  7 Jan 2006
  12:28:18 + (GMT)
Message-Id: [EMAIL PROTECTED]
Date: Sat, 07 Jan 2006 12:28:20 +
From: Ed Davies [EMAIL PROTECTED]
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
Mime-Version: 1.0
To: Leap Seconds Issues LEAPSECS@ROM.USNO.NAVY.MIL
Subject: Re: [LEAPSECS] The real problem with leap seconds
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [EMAIL PROTECTED]
Precedence: list
Status: RO

Steve

Re: The real problem with leap seconds

Please ignore this post.  It got away because I was connected to my UNIX
host from my girlfriend's PC over her cable Internet connection which is
probably the crappiest in the world as I was composing a reply to some
posts on this list, and as it crapped out on me, the mail process on the
UNIX host terminated and sent out whatever garbage was in its compose
buffer.

MS

Re: The real problem with leap seconds

Steve Allen [EMAIL PROTECTED] wrote:

 If I read it right you have reinvented Markus Kuhn's UTS [...]

Close to it, but...

Ed Davies [EMAIL PROTECTED] followed up:

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

Therein lies the key difference.  I have strived to make my argument as
independent of computers as I could.  To me the need for a real number
time scale is necessitated more by philosophy than computer science,
which is why I have resorted so much to the mathematical abstraction of
a real number in my paper.

My central argument still stands that current UTC is unsuitable for the
*philosophical* application of defining the abstract ideal scale of
civil time since it is not a scale in the mathematical definition of
this term (a real number).  I believe that the scale of civil time needs
to be a scale.  Furthermore, I believe that it should be related to the
cycle of day and night rather than completely decoupled from it, so I
won't support freezing the leap seconds for the next few centuries as a
solution.  That leaves me with my current position of arguing for a
coordinated time scale with elongated and shortened seconds.

MS

Re: The real problem with leap seconds

Poul-Henning Kamp [EMAIL PROTECTED] wrote:

 In this rather humorous document you have managed to say that POSIX
 screwed up badly.  We already knew that :-)

What does this have to do with POSIX?  The word POSIX does not appear in
my article.

MS

Re: The real problem with leap seconds