Re: how to reset a clock
On Thu, 4 Jan 2007, Zefram wrote: Interval clock and real-time clock remain conceptually distinct. If you have a single clock counter alongside a variable epoch, the sum of the two is the effective real-time clock. I don't think you're gaining anything by not reifying it. I'm gaining simplicity. A count of seconds (perhaps fractional) is much simpler than a broken-down time. It's much simpler to keep a simple interval representation separate from leap second and time zone handling. Your points about recording adjustments across reboots are useful, thanks. The solution is to just let the clock run, never adjust it, and treat it as an independent seconds count. You don't care about it showing the wrong time, because you don't treat its output as an absolute time. Instead, collect your data on how far out it is (or rather, what absolute time - output function it is computing) and add the epoch in software. Any number of users of the same clock can do this without treading on each other's toes. I think that's what I was suggesting :-) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ THAMES DOVER WIGHT PORTLAND PLYMOUTH: WEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 AT FIRST IN THAMES AND DOVER, DECREASING 4 OR 5 LATER. ROUGH, OCCASIONALLY MODERATE LATER. SHOWERS DYING OUT. GOOD.
Re: how to reset a clock
On Thu, 4 Jan 2007, Tony Finch wrote: On Thu, 4 Jan 2007, Zefram wrote: The solution is to just let the clock run, never adjust it, and treat it as an independent seconds count. You don't care about it showing the wrong time, because you don't treat its output as an absolute time. Instead, collect your data on how far out it is (or rather, what absolute time - output function it is computing) and add the epoch in software. Any number of users of the same clock can do this without treading on each other's toes. I think that's what I was suggesting :-) Tony. Indeed isn't this Rob's ship's chronometer? Also in the context of the mythical device which has to run many years into the future without referring to external leap-second tables, when interaction is eventually resumed you have more chance of recovering the true value of timestamps if it had a chronometer on board and not an incorrectly-set UTC clock. If contact with the device never is recovered, why did it matter what it thought the time was? Peter.
Re: how to reset a clock
On 4 Jan 2007 at 10:53, Peter Bunclark wrote: Indeed isn't this Rob's ship's chronometer? Captain's log, stardate 30620.1... http://en.wikipedia.org/wiki/Stardate -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: how to reset a clock
Peter Bunclark wrote: Indeed isn't this Rob's ship's chronometer? Actually, I think it was Mr. Harrison's. (And Steve Allen has been basing his arguments more recently on this distinction.) This healthy debate between astronomical time and clock time has happened before. The answer is the same as before - both types of time are needed. (Some things never change.) I'm sure Pete is more familiar with this story than I am, but others may not be. Harrison attempted to build a perfect clock to win the Longitude Prize. Folks who haven't read Sobel's book should do so - my classmates at Villanova and I learned the story from an Augustinian priest who appeared old enough to have known Harrison personnally. Harrison's first glorious shipboard clock failed to take the prize due to a lack of compensation for centrifugal effects on a sailing vessel that must tack when sailing against the wind (or must wear through an even larger angle, bringing the wind across its stern). Compensation was needed for relativistic effects, if Newtonian rather than Einstein. (Some things never change.) Harrison invented or improved a variety of familiar mechanical doodads like the roller bearing and bimetallic temperature compensation. He likely could have succeeded in solving this particular problem, but there would always have been another physical improvement needed. (Some things never change.) Each improvement would have made the clock more complicated and eventually too fragile to possibly work on a constantly moving platform buffeted and often bathed by the salty sea. He created a second clock and was working on a third round of improvements when the idea we're discussing first occurred to him. He had been using a pocket watch as a mechanism to transfer time from stationary standard clocks (many built by himself) to his portable prototypes. He would reset the clock in one place and physically carry it to where the time was needed. If a roundtrip correction were needed, presumably he would note the time on either end and halve the difference. This is the standard synchrony or conventionality of simultaneity of special relativity - familiar to anyone who has looked under the hood of NTP. (Some things never change.) What Harrison recognized was that he didn't need to build a perfect clock - he merely needed to quantify and log the error inherent in the clock. By replacing a large and finicky better clock, with a small and robust, but more even-tempered, one, the rate of the clock could be regularized and its random and systematic errors could be minimized. That the rate of the clock was now guaranteed not to match the rate of the spinning Earth was no longer a bug, but a feature. By carefully calibrating the clock rate before leaving on a voyage, and checking it against astronomical observations throughout the voyage, it was possible to compute the mean solar time at the home port. (Some things never change.) Comparison with the local time, measured by sextant, then recovered the longitude directly. And, of course, a ship would not carry a single clock, but two or more. Friendly ships meeting at sea would also exchange clock readings - creating the first ensemble time scale. (Some things never change.) Thus was the chronometer born - and thus did Britannia rule the waves. The point is that time isn't just an unending count of seconds - it is the epoch of when the count was zero. That epoch often has significance in some periodic natural phenomena, usually related to Earth orientation. Rob
Re: how to reset a clock
Rob Seaman scripsit: And, of course, a ship would not carry a single clock, but two or more. Friendly ships meeting at sea would also exchange clock readings - creating the first ensemble time scale. (Some things never change.) English passenger at Irish railway station, pointing to the two clocks at either end: Why don't those clocks tell the same time? Irish stationmaster: Ahhh, what would we be wanting with *two* clocks if they told the same time? Eoghan Mac Eoghain -- It was dreary and wearisome. Cold clammy winter still held way in this forsaken country. The only green was the scum of livid weed on the dark greasy surfaces of the sullen waters. Dead grasses and rotting reeds loomed up in the mists like ragged shadows of long-forgotten summers. --The Passage of the Marshes http://www.ccil.org/~cowan
how to reset a clock
The time APIs that I am familiar with represent time as an interval based on a fixed implicit epoch. To reset a clock that is wrong, its couner value must be set to the correct value. This implies that the system's real time clock and interval timer must be separate, so that processes depending on correct relative time continue to work across RTC resets. Are there any APIs which have an explicit variable epoch, and which reset the clock by adjusting its epoch instead of its counter? This would eliminate the need for seperate interval and real-time clocks. (This post only considers abnormal resets of a grossly incorrect clock, and ignores corrections based on adjusting the clock's frequency.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ WIGHT PORTLAND PLYMOUTH: SOUTHWEST VEERING WEST OR NORTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9, LATER DECREASING 5 OR 6. ROUGH OR VERY ROUGH. OCCASIONAL RAIN. MODERATE OR GOOD.
Re: how to reset a clock
Tony Finch wrote: Are there any APIs which have an explicit variable epoch, and which reset the clock by adjusting its epoch instead of its counter? This would eliminate the need for seperate interval and real-time clocks. Interval clock and real-time clock remain conceptually distinct. If you have a single clock counter alongside a variable epoch, the sum of the two is the effective real-time clock. I don't think you're gaining anything by not reifying it. Where this concept wins is as an implementation strategy. When adjusting the counter of a PC RTC, for example, there is a problem of knowing whether you've done the adjustment when you reboot. There are well-known problems with DST adjustments being performed twice, by the same or another OS, but the same kinds of problems arise even without attempting to reflect DST in the clock. If you're collecting data on how far out the clock is and adjusting the clock accordingly, upon a reboot you can't tell whether you have made the latest adjustment. Two OSes sharing the machine don't know about each other's adjustments. The solution is to just let the clock run, never adjust it, and treat it as an independent seconds count. You don't care about it showing the wrong time, because you don't treat its output as an absolute time. Instead, collect your data on how far out it is (or rather, what absolute time - output function it is computing) and add the epoch in software. Any number of users of the same clock can do this without treading on each other's toes. I don't know of any implementation of this strategy for the PC RTC. I'll be doing one myself sometime soon, as I'm developing an OS in my spare time. -zefram
