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
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.
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:
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
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
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
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