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

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.

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

```