In message <4ED158EC-6B80-11D9-BBE2-0003938249D6_at_noao.edu>, Rob Seaman writes:
>Poul-Henning Kamp replies:
>
>> The major problem with leapseconds in computer systems is that they do
>> not happen often enough to be testable,
>
>The current UTC standard allows scheduling leap seconds monthly. Is
>that frequent enough for you? The question isn't whether a leap second
>occurs. The question is how frequently do opportunities for a leap
>second occur.
I cannot test leapsecond handling once per month. I can test it once
every N years and very few IT projects are willing to wait for that,
and very few people are sober enough in Europe to do it and nobody
would be willing to say "We flunked, have to wait another N years
to use our new computer system".
>> I saw one test plan for a major safety-of-life system were they
>> dropped leap second testing because the sheer enormity of doing so,
>
>And you are asserting that this is a system that would not have better
>chosen an unsegmented timescale based on TAI?
Some of their critical interfaces are written in international
agreements and treaties, they have no choice in the matter, they
had to use UTC. The choice of UTC in the agreements is because it
is tied to civil time by the well known concept of timezones. They
could not use TAI without significantly increasing the risk of
human mistakes.
>Yes. I do want to know. Or rather, I want to have confidence that the
>bureaucrats pushing this silly initiative are actually investing in the
>world-wide inventory of time users that is warranted by a scheme to
>change every clock on the planet.
The problem here is that the so people who even know what a leap
second is that you cannot get meaningful data without sending people
who do know about it deep into their systems to find out.
I am almost willing to make the bet with you that it is cheaper to
deal with the systems which need UT1 than to find out how the
relevant part of the remaining IT systems deal with leapseconds.
>Sounds like a great business opportunity. There are large numbers of
>much more obscure standards that programmers manage to get right. What
>reliable evidence do we have that programmers are screwing up UTC
>left-and-right?
Until two years ago Microsoft Windows got it wrong for Denmark.
UNIX has a continuous timescale with no room for leapseconds which
is supposed to be "UTC".
>Couldn't we just invest in improving the NTP handling
>of leap seconds and in implementing new time handling facilities
>*before* we go about deprecating leap seconds?
There are many computers for which NTP is not an option for cost,
location or security reasons.
>These are either periodic effects or constant offsets. Leap seconds
>are due to a secular effect. That secular effect won't go away just
>because some folks wish very hard.
The present rate of leap seconds is constant for 99.9999% of the
population on this planet. It's true that it won't go away, but
we are perfectly capabale of ignoring it and adapting to it.
>> The numbers we attach to civil time have nothing to do with "noon",
>> "mid-day" and such mundane concepts.
>
>They actually have very precise, closed form approximations to those
>concepts. Many of us like the equation of time. Why throw it out?
Because it is only relevant to a small scientific minority and they
already know that they need to use a time different from civil time
to get the right result anyway.
>> On the other hand, astronomers and others that need UT1 will be able
>> to take the global timescale, (TAI, UTC or something else) and apply a
>> delta they pick up from a scientific entitity and use the result.
>
>As you imply, a vast amount of astronomical software and systems would
>indeed need to be modified quickly and reliably simply to preserve the
>current functioning of our systems.
Yes, but I don't belive this is a major cost or effort.
If the systems are NTP synchronized today, lets make IERS set up a
NTP server which serves UT1 time: that took care of anything
recently built.
Older systems may have a VLF or GPS time link, stick a new computer
in the middle to apply the UT1 correction: solved.
Systems where the clock is run island style is just an operational
procedure matter.
There, done! Give me or any other moderately qualified computer
person 3 weeks per site and we'll have it fixed. I'll even quote
you a price "cost & materials" just for an opportunity to visit all
these places :-)
If you really think the petty pieces of software you have to control
your telescopes is a big deal, then pop around here some day and
I'll show you how big a _real_ software project is.
>> I have met engineers writing train and air traffic control software
>> who didn't even know that leap-seconds existed.
>
>And you are asserting that the proper solution is not training and a
>coordinated development of precisely the global time distribution
>systems and APIs that are needed, but rather to ignore the problem
>entirely? Inexplicable indeed.
No I think a proper solution is to not burden people with a very
hard to handle and test correction which doesn't give them any
benefit, and leave the precision work to be done by the small
astronomical community that needs to deal with it.
>> I agree that the leap-hours thing is a slightly phony way to abolish
>> leap-seconds,
>
>New topic. One of the few points of consensus coming out of Torino was
>that any new civil timescale to be defined without leap seconds would
>be given a new name distinct from Universal Time (of whatever flavor).
>Universal Time was to be reserved for timescales synchronized to the
>rotation of the Earth. One might wonder at the reluctance of
>proponents to follow through on this easily comprehended consensus.
Renaming UTC would just be plain stupid as this term is already worked
into more legal paperwork than any of us could lift in our lifetime.
No, abolish leap-seconds, possibly be pretending they become leap-hours,
and keep the UTC name. Then let us get on with our lives.
If anything, UT1 should be renamed to "Earth 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 Fri Jan 21 2005 - 00:50:13 PST