Re: Monsters from the id
On Jan 13, 2006, at 12:46 AM, John Cowan wrote: In the end, it will be impossible to maintain the notion that a solarday is 24h of 60m of 60s each: we wind up, IIRC, with the solar dayand lunar month both at about 47 current solar days. There's a lot of difference between what happens over a billion yearsand a million years. Length of day increases only about 20s per millionyears. Should we be here to care in a million years, only a 1/4 of 1/10 ofone percent tweak to the length of the "civil second" would suffice to allowour Babylonian clock paradigm to continue in use. Alternately, we mightdecide to add one second to just one minute out of each hour.I won't claim one of these would be the choice. There are manifoldoptions for representing time. But I do assert that our descendants - foras long as they may be regarded as human - will desire to have somecommon way to represent fractions of a day. And no matter whatrepresentation they choose, they will still face the quadraticaccumulation of leap seconds or their equivalent.Far from being a motivating factor for deprecating leap seconds, thequadratic clock lag resulting from the roughly linear tidal slowing ofthe Earth is precisely the strongest argument for preserving meansolar time as our common basis for timekeeping now and forever.Besides, it is simply a charming fact of life in the solar system thatour Moon is receding while the Earth spins down. Apollo era laserretro-reflectors show that for each second our day lengthens, theMoon's orbital radius grows by a mile or so.Time is a fundamental element of all that we do. Surely publicpolicy should not be governed by a drab and dystopian vision ofa fragmented planet scrabbling randomly to keep our disjointclocks aligned.The simplest - nay, the only - way to keep our clocks synchronizedone to the other is to keep them all tied to Mother Earth. "You think the Earth people think we're strange you think."Rob SeamanNOAO
Re: Report of Leap Second Problem with GPS Data
On Jan 13, 2006, at 6:26 AM, Richard Langley wrote: FYI. Thanks! Actual reports from the field, how novel! ** IGS Station Mail 12 Jan 14:59:42 PST 2006 Message Number 760 ** Author: Michael Moore Geoscience Australia Australian Regional GPS Network Geodetic Operation ADVISORY: High rate data, 1Hz 15 minute files, from the ARGN suffered a software problem due to the recently introduced UTC leap-second. Data from DOY 001 to DOY 009 is 1s off in the timestamps reported n the RINEX files. This problem only applies to the 1Hz 15minute files submitted from the ARGN. The software problem has been fixed, and all files from DOY 010 is reporting the correct time. RINEX headers for DARR from DOY 009, was incorrectly reporting an antenna height of 0.000. The headers have now been fixed to report the correct antenna height of 0.0025, and the data from DOY 009 has been resubmitted with the correct header information. I won't claim to know the intrinsic importance attached to this. Critical systems may depend on the information. But is it fair to sum up the situation by saying that a leap second triggered a couple of bugs (or perhaps one common bug), they were detected, have been fixed, and affected data products have been remediated? Also, it appears that some other data products were unaffected? So, the issue has been resolved - would likely have been resolved sooner if a leap second had occurred earlier - and is no longer directly pertinent to a discussion of future leap seconds? Well done, Geoscience Australia! Rob Seaman NOAO
Re: Report of Leap Second Problem with GPS Data
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Rob Seaman writes: : On Jan 13, 2006, at 6:26 AM, Richard Langley wrote: : : I won't claim to know the intrinsic importance attached to this. : Critical systems may depend on the information. But is it fair to : sum up the situation by saying that a leap second triggered a couple : of bugs (or perhaps one common bug), they were detected, have been : fixed, and affected data products have been remediated? Also, it : appears that some other data products were unaffected? : : So, the issue has been resolved - would likely have been resolved : sooner if a leap second had occurred earlier - and is no longer : directly pertinent to a discussion of future leap seconds? : : Yeah, right : : This goes counter to my claims so it is of no importance. : : Sorry, things don't work that way Rob. This time, there were no reports of death with the leap second, therefore they can't be too bad... :-) Warner
Re: Problems with GLONASS Raw Receiver Data at Start of New Year
On Jan 13, 2006, at 7:51 AM, Richard Langley wrote: The International GNSS Service (IGS) includes a sub-network of continuously operating GLONASS monitor stations (about 50) including one at the University of New Brunswick (UNB1). At UNB1 we lost C1 (coarse code on L1 frequencies), P1 (precision code on L1), and P2 (precision code on L2) observations on the 5 GLONASS satellites we were tracking at 00:01:30 GPS Time on 1 January 2006 along with phase jumps in L1 (carrier phase on L1) and L2 (carrier phase on L2). Perhaps you can expand on the meaning of all this. Presumably this would represent an infrequent occurrence? What are the implications for downstream systems? For that matter, what systems lie downstream? Code measurements were back at 00:04:00. So the problem extended for 2.5 hours from 00:01:30 - 00:04:00 GPS Time? Were there repercussions that have persisted after this? I have just learned from one of the IGS analysis centres that all January 1 IGS GLONASS observation files that they checked show a similar problem. The leap second has not been mentioned, but presumably we are to infer that it triggered this behavior? Would be absolutely delighted to learn more about the IGS, both in general and to provide context for interpreting this report. As with the previous mail, I won't claim to be able to attach an estimation of the importance of the events described. We obviously all believe leap seconds are worthy of discussion or we wouldn't be here. I presume many of us read RISKS Digest and can dream up scary scenarios. But there are also risks associated with *not* having leap seconds, with allowing DUT1 to increase beyond 0.9s, for instance. And events triggered by those risks would not draw worldwide scrutiny - they could occur year-round and the media circus would have moved on. Rob Seaman NOAO
Re: Report of Leap Second Problem with GPS Data
This goes counter to my claims so it is of no importance. and This time, there were no reports of death with the leap second, therefore they can't be too bad... :-) I invite derision with my flights of rhetoric. But this is an internet forum and a little leeway may be warranted. We all have our day jobs with more pragmatic requirements. For whatever reason, UTC is of importance to each of us - both the immediate day-to-day issues as well as the long term philosophical issues. Reports of significant misbehavior triggered by the leap second are to be expected. Honestly, I am surprised that there have been so few so far - but perhaps two weeks is about the right time for data to be gathered and turned into a report. I won't belabor the notion that the solutions to any problems revealed in these reports might indeed be expected to be a little more subtle than never issue another leap second. But let's imagine we were to identify a consensus vision for the path forward. (Seems a bit unlikely at the moment :-) So all the interested parties would be in agreement on the changes to be made to UTC (and/or TAI and/or whatever else) - and in agreement that any changes were needed at all. Again - just for the sake of argument. There would still need to be an implementation plan. That plan would need to analyze risks (and benefits) and costs. It would need to reveal a schedule, likely in stages over many years. If you believe there are significant risks associated with the complex system involved with the issuance of leap seconds, are significant risks not to be expected with making changes to that system? We're all concerned about risks. Unplanned changes to deployed systems are among the most dangerous. Rob
Re: Problems with GLONASS Raw Receiver Data at Start of New Year
Rob Seaman scripsit: But there are also risks associated with *not* having leap seconds, with allowing DUT1 to increase beyond 0.9s, for instance. And events triggered by those risks would not draw worldwide scrutiny - they could occur year-round and the media circus would have moved on. I'd expect to see a wave of breakage as DUT1 exceeded 0.9s for the first time, and a second wave as it exceeded 1s for the first time. After that, of course, the problems would no longer be relevant. :-) -- They tried to pierce your heart John Cowan with a Morgul-knife that remains in the http://www.ccil.org/~cowan wound. If they had succeeded, you wouldhttp://www.reutershealth.com become a wraith under the domination of the Dark Lord. --Gandalf
Re: Report of Leap Second Problem with GPS Data
In message [EMAIL PROTECTED], Rob Seaman writes: I invite derision with my flights of rhetoric. As published papers [1] document, you have way to go. Poul-Henning [1] George August, Anita Balliro et all, study of Rotation of the Earth, approx 1993. (find it yourself). -- 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: Problems with GLONASS Raw Receiver Data at Start of New Year
On Jan 14, 2006, at 11:20 AM, John Cowan wrote: I'd expect to see a wave of breakage as DUT1 exceeded 0.9s for the first time, and a second wave as it exceeded 1s for the first time. After that, of course, the problems would no longer be relevant. :-) I haven't been able to decipher what the humor is meant to be here - will gladly admit that this is likely a failure on my part. I won't ask you to explain the joke, but rather I suspect you had a more basic point you were seeking to make. Is there some reason that risks resulting from a diverging DUT1 can be expected to be mitigated (even in part) as it grows past 1s? If we discount the melodramatics of this list (will gladly admit to being one of the offenders), we are left with a rather interesting technical discussion of how best to deliver both interval time and earth orientation information to a variety of classes of users. Whatever the context of that discussion and of our own personal points of view, one large element of confusion is precisely that TAI mimics UTC mimics GPS mimics... We might more easily recognize the distinct character of each time-scale if neither their values or the representations of those values permitted them to masquerade one for the other. Atomic Time is naturally represented as an unending count of seconds. Universal Time is naturally represented as a fraction of a day (equivalent to an angle). It is that naive heuristics exist that claim to convert Atomic Time into fractional days - or alternately, to convert Universal Time into a count of seconds - that creates confusion between the two. Rob Seaman NOAO
