[time-nuts] GPSDO for my rubber duckie

Michael Sokolov msokolov at ivan.Harhan.ORG
Wed Aug 3 07:01:00 UTC 2011

Chris Albertson <albertson.chris at gmail.com> wrote:

> It's even less logical than that.  With "rubber seconds" tied to the
> Earth's rotation.   You ultra stable cesium clock is no longer running
> at a fixed frequency.

Wait a minute here, Chris...  Weren't you just telling me the other day
how important it is to maintain a distinction between primary
requirements, derived requirements and implementation details?
Cesium clocks and whatnot are implementation details, so let's set them
aside until we cover the primary requirements.

There two fundamentally different kinds of time: interval time and
time-of-day.  I realize that this mailing list is mostly inhabited by
people who care the most about the former, but there are some people for
whom the latter (time-of-day) is much more important.  I am one of the
latter people.

Since the beginning of human civilisation the notion of time of day had
absolutely nothing to do with interval time.  Interval time is a strictly
relative measure, yet ToD has always been an absolute measure of Earth's
position in the heavens.  (In the minds of the ancient peoples it was
relative to the gods.)

I wish to preserve the millennia-old time-of-day that is completely
separate and independent from interval time.  For me that is a basic
primary requirement.  As an engineer faced with an external requirement,
you can be as innovative as you want with how you implement it, but you
don't get to negate the requirement itself - basic primary requirements
are non-negotiable.

In my case the hard requirement is to provide a form of "time" that
represents Earth's position in heavens, just like the word "time" has
been defined for all those millennia before atomic clocks.  That is a
hard non-negotiable requirement.  If this requirement is a pita for
cesium clocks, tough.  Don't use a cesium clock if that device is not
suitable for the given task of satisfying the requirement at hand.

> (2) define the day as 60 x 60 x 24 seconds long. And let the length of
> a second be continuously variable or
> [...]
> Using #2 makes the job of maintaining a frequency standard more interesting.

I have never advocated for use of rubber seconds in frequency standards.
Frequency is the inverse of time interval, *not* of "true time" as in
time-of-day, hence it belongs in an entirely different department.

Clearly there exists a need for both kinds of time.  I have always
advocated for a two-tier time distribution architecture:

1. At the lower level you have your atomic clocks that tick independent
   of the Earth's rotation.  Use this timescale for all your "techie"
   applications, but *please* don't try to forcibly impose it on anyone
   who has not explicitly opted in.

2. At the higher "user-friendly" level, rubber duckies like the one I'm
   about to build take this fancy non-Earth-rotation-based "techie time"
   as input and produce old-fashioned Earth orientation time on output,
   or more precisely produce a synthetic timescale that is rubberized to
   pass as an acceptable approximation of the Earth's true position in
   the heavens relative to the gods.  Use *this* time for civil/social
   purposes, i.e., to tell grandmothers when to go to church, don't make
   them switch to Earth-decoupled time.


More information about the time-nuts mailing list