In message <4DC46994-67A7-4D44-8849-6711AEA1ACE6_at_noao.edu>, Rob Seaman writes:
>On Aug 11, 2005, at 12:46 AM, Poul-Henning Kamp wrote:
>
>> As I understood the situation last week, nobody in the gang here
>> had problems with leap seconds if we got a longer warning (40-50
>> years).
>>
>> So what prevents us from writing up our own proposal to ITU ?
>>
>> I'm pretty sure that we could get a rather impressive list of
>> signatures from both camps if we did a bit of lobby work in our
>> respective communities.
>
>A reasonable idea. Of course, there is no reason to suppose that any
>such proposal would even get a reading from the committee.
If it gets put officially on their table by an ITU-R member state,
their rules does not allow them to ignore it.
Worst case it will take a few thousand CHF to get somebody accredited
as a WP sector member in order to get it put in their inbox.
>The question is whether a deterministic 50 year solution exists.
Not really, the question is how large excursions |UT1-UTC| would
take because of imperfect prediction.
>Would love some feedback from the Earth rotation experts as to the
>current and projected state of the art for making such predictions.
You are guaranteed to get that feedback if we put the proposal
officially in front of WP7A.
>The question of this scheduling horizon is independent of the leap
>second scheduling algorithm itself.
>I consider this a feature of my proposal.
>Sweeping leap seconds under the rug is not going to solve the
>underlying problems.) There is no reason that my proposal could not
>be combined with the 50 year predictive horizon to satisfy both of us.
Absolutely. No disagreement there, but I doubt the predictive
capability will be able to gain much performance from being allowed
to schedule a leapsecond on 2049-11-30 instead of 2049-12-31 at
this point in time. That of course is not the same as saying that
we can't in the future, so I'm open for it.
>As far as the maximum permitted size for DUT1 - some think 0.9
>seconds is too small. There appears to be a consensus among quite
>divergent thinkers here that 0.9 hours is much too big.
If we go to 50 years horizon, then the permitted size will have to
go. The size will be whatever the predictive capability results
in. I would think that we can keep it less than 5 seconds at this
point, and probably better than 1 second 20 years down the road.
If we put a cap on it, we have two conflicting requirements and we
gain nothing but trouble.
>It would be trivial, however, to convert the current UTC standard
>based on leap seconds into a standard based on leap minutes.
That is another option which might be workable, but the criteria
must still be set so that the leap-minute does not get announced
with 6 months notice.
But I think the predictive capability would already allow us to
hold it well inside a minute with a 50 second horizon and leapseconds.
I would even think that there would be time to change TF460 in a
structured way before we would hit the 1 minute, should something
unexpected but non-catastrophic happen to Earth.
>- are leap minutes likely to be more palatable to Kamp's
>caricature of a moronic Posix programmer?
What matters here is not the nature of the exceptional counting,
but the fact that we can narrow the scope to operating system
programmers if we have sufficient horizon.
If the horizon is long enough, we can make the operating system
do the right thing and then it will take a truly moronic programmer
to screw it up, as opposed to now where it takes a truly dedicated
programmer to get it right.
>I still argue that the way to encourage compliance to a
>standard is to make non-compliance a non-option. A project facing
>the prospect of dealing with a potential leap second monthly is a
>project that will actually expend the effort to get this right. A
>project facing an event 50 years - or even 10 years - in advance will
>simply ignore that event.
I disagree. The problem with the current short horizon is that
it involves the users in the event because they have to update
software to get it right.
If the horizon allows the knowledge to be safely put into the
operating system, knowing that it will be correct for the lifetime
of the system then only a few people for each operating system need
to be involved and get it right.
>Why don't we (the
>larger "we", including the folks with the power who haven't been
>participating in any discussions) simply regroup, withdraw the
>current silly proposal and define a process to patiently and
>prudently reach a consensus.
Because the people behind the current proposal is driven by economics,
not science.
If we want to stand a chance in this fight, we have to come up with
a competing propoposal with competitive economy and better science.
And we have to do it in the next few months.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Fri Aug 12 2005 - 00:11:14 PDT