Re: Viruses, ITU, and PTTI
> Other news - at the ITU meeting, Dr. Ronald Beard accepted the
> responsibility of chairing a study group on the leap second issue,
> and to coordinate with other professional societies. He is now a
> subscriber of this listserv.
I presume Dr. Beard and the study group will also have access to the
previous messages to this list?
> Ron and others were also present at the PTTI session on leapseconds.
> I will mail out any written versions of the papers as they come in,
> and hopefully will also include a transcript of the taped discussion.
Thanks - a transcript would be excellent.
> I would say the audience was quite partisan in favor of a change,
Exactly what change was proposed?
And how large was the audience? What interests do they serve? Is there
a quantification of "quite partisan" beyond "I would say"?
> but I also think one strong argument was made against a change, based
> upon the cost of paying contractors to go through large amounts of
> computer code for high-tech space-based systems. The obvious solution
> occurred to me - if a proposed change is announced with a long enough
> lead time (and it would be), such "legacy systems" would have time to
> adjust.
Um - surely the lessons of Y2K haven't escaped us so quickly? And are
"high-tech space-based systems" a complete and accurate summary of the
affected systems enumerated in the survey and on this list? Supplying
time to adjust also doesn't address who exactly pays for the changes.
Note that many of the Y2K "fixes" amount to resetting the time bombs
into the future using windowing techniques. Is the idea simply to allow
contractors to rescope their contracts decade-by-decade such that entire
space missions have lifespans that don't cross leap second boundaries?
I'm also not sure "high-tech" and "legacy" go together. If (for instance)
GLONASS's leap second handling is currently broken, it would surely cost
roughly the same amount to implement fixes to bring it into compliance
with the current leap second standard as it would to match some future
variation.
The whole point of "legacy" is that such systems should be frozen and
kept in a "lockbox". Sounds like fuzzy math to me.
> Fortunately for all, Mother Earth is cooperating by not slowing down
> as much as expected.
This is backwards. The Earth is going to do what it's going to do. Any
viable standard needs to support the extreme range of what the planet is
capable.
It is certainly shortsighted to base the entire reasoning for making a
change to such a fundamental standard on current technological limitations
of legacy systems that likely first entered their design phase about the
time the UTC standard was implemented. It seems to me that UTC and leap
seconds are a reasonably well thought out mechanism that support the
requirements of matching Earth time to atomic time rather better than
they are currently being given credit.
Any update to that standard should both improve the standard - but should
also be targeted at long-term (multi-hundred year) requirements - not the
restrictions of NASA and DoD contractors who have no interest in the
standard as a scientific or civil mechanism, but only as a maintenance
headache.
> PS to Steve Allen: can you send the files to me at dnm_at_orion.usno.navy.mil?
Hi Steve - perhaps you can do me a favor and send the first few messages
my way, too? The first message after I subscribed was:
Date: Thu, 6 Jul 2000 21:01:22 +0000
From: "Demetrios N. Matsakis" <dnm_at_ORION.USNO.NAVY.MIL>
Subject: Politics of Redefining UTC
Thanks.
Rob Seaman
National Optical Astronomy Observatory
Received on Sun Dec 10 2000 - 22:51:19 PST
This archive was generated by hypermail 2.3.0
: Sat Sep 04 2010 - 09:44:54 PDT