In message <BA93AFE7-C549-4478-9655-1AE717F11E28_at_noao.edu>, Rob Seaman writes:
>On Jul 30, 2005, at 12:05 AM, Poul-Henning Kamp wrote:
>
>> I have three times been through what ended up being total reinstalls
>> from backups because some operator by accident (or stupidity) set
>> the clock forward in time and then backward in time on a database
>> installation.
>
>Are you asserting that these problems had something - anything at all
>- to do with leap seconds?
No, they had everything to do with computers don't liking time to
jump around.
In order to test leapsecond handling, you need to jump the time
forward to end of june or december, afterwards you need to jump it
back.
Since operating systems and databases in particular croak when
you do that, testing for leapseconds is a major nightmare which
takes very significant down time to accomplish.
>Poor management of software
>systems doesn't seem like a strong justification - or even
>rationalization - for changing a completely unrelated international
>standard.
When you start out on a long march, you don't put a stone in your
boot deliberately, and if one is there already, you take it out.
Leapseconds is such a stone for real-world IT installations.
>The solution to ignorance - what you so generously characterize as
>"stupidity" - is education.
I agree in principle, but who is going to pay for it ?
And your plan looks a lot more feasible once you get a written confirmation
from all operating system vendors that they will not release a product if
the actual code has not correctly handled a real leap second.
>You are really just supporting the tired
>old notion of security through obscurity. As the traffic school cop
>pointed out: there are no accidents, only collisions.
Close, but no cigar:
I'm pointing out that UTC with leap seconds is unsafe at any speed.
>> Your workstation is not an "IT installation", it is just a
>> workstation.
>
>I was our Y2K team lead. For that period of time, my workstation was
>one of the primary development systems for an image processing
>software package used by half the astronomers in the world.
I'm sorry Rob, but this was what is normally called "a toy application"
in the context of Y2K.
>Why are we not discussing what new data structures, APIs, transport
>protocols, deployed systems, operating procedures, staffing and
>management issues will be necessary to implement such a major change
>less than two-and-a-half years hence? How is it that this "proposal"
>is completely devoid of any discussion whatsoever of its
>implementation and ramifications?
I think it is mainly because the people most in need of those
facilities are being BHA's about the entire thing and therefore do
not seem to prepare for the very likely situation that they won't
get things their way.
If I were a professional astronomer, I would be busy with all those
things, but as it is, I have not a single computer anywere which
will be negatively affected by missing leap seconds.
In that situation I don't really see the political soundness in me
imposing my ideas how to solve these problems on an astronomical
community which doesn't seem receptive to the need.
But if you find out that you're going to prepare for it, I'll be
more than happy to assist anyway I can. Getting DUT1 into the
NTP protocol would be one option (but unless stratum 1 servers
can get hold of DUT1 it doesn't really help us that much).
>UTC is the equivalent of ISO 8601 for the purpose of this never-
>ending discussion.
No, if that were so, it would be ISO that decided the fate
of leap seconds.
As it is, ISO8601 references UTC and is therefore based on UTC.
>In point of fact, many ISO 8601 compliant strings
>embedded in your databases implicitly assert that UTC ~ GMT.
Doesn't that mean that your database contains baseless assumptions ?
As I said earlier: it sounds a lot to me like astronomers made a blunder
when they used UTC without realizing that the properties of that timescale
is not in their control.
It would have been much smarter to use TAI, wouldn't it ? I thought
I heard some astronomer say in this discussion that all applications
which need proper timekeeping should use TAI ?
>Whatever happens to leap seconds in the future, proper interpretation
>of your archival records will continue to depend on interpolating the
>appropriate leap seconds.
You mean "just like the rest of astronomys N thousand years of records ?"
Some years ago I read with great interest about the problems trying
to nail Tycho Brahes observations to a usable timescale, and I can't
for the life of me think that the necessary interpretation of UTC is
any harder.
And if anything, if astronomers switched to TAI on 2008-01-01 they
would not run into this problem in the future.
>Or actually - not. Precisely because UTC
>~ GMT, typical civil usage allows you to completely ignore leap
>seconds when interpreting past data records.
Are you saying the reason we have leap seconds is because they
allow astronomers to be sloppy and get away with not handling
time correctly in their applications and databases ?
>There is a vast web of implications
>associated with civil time. Trying to sneak through a major change
>of philosophy to an international standard simply to avoid having to
>think about its implications seems craven and intellectually dishonest.
I think the sneakage happened in 1972 and we're trying to evict it.
>Wouldn't it make sense to conduct a
>risk analysis in advance of violating that standard worldwide?
That is absolutely something the astronomy business could do
to document what their systems can and can not tolerate.
Personally, I think it would be much smarter of them to come up
with a cost estimate, pad it a bit and say "We're ok with leapseconds
disappearing if we get $X to convert our systems" because that
would not be a waste of their time.
--
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 Sat Jul 30 2005 - 23:23:49 PDT