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