[LEAPSECS] Of stepping motors and leap seconds

[Steffen Nurpmeso]

Tom Van Baak wrote in <F98D0943EDD5418E8C5594F14091D0C1 at pc52>:
  ...
 |Now back to Google and its ~24 hour smear. One feature of their approach \
 ...
 |I'm wondering how the LEAPSECS crowd feels about long or short smears. \
 |One way to measure this is the area under the curve. For a 24 hour \
 |smear the |error| ramp goes from 0 to 0.5 to 0 over 24 hours; so that's \
 |an integrated error area of 6 hour-seconds. For a short smear it's \
 |more like 1 second-second.
 |
 |/tvb
 |
 |[1] https://en.wikipedia.org/wiki/Lavet-type_stepping_motor
 |[2] https://en.wikipedia.org/wiki/Quartz_clock
 |[3] http://leapsecond.com/pages/32kHz/

My personal opinion is that the entire complex stinks.  It is not
about smear-x or smear-y but about notification as such.  It is
unfortunate that a non-monotonically increasing timestamp is
distributed: this is not "normal" in respect to nature.  At least
not on my level of physics, space people may have a different
view.  What would be needed would be a distribution of TAI (i say
TAI but mean a timestamp with properties that can be dealt with),
with a permanent distribution of an offset to civil time UTC.  And
a service that can be queried to gain the list of UTC adjustments
easily.  Say, NTP/[D]TLS and some DNS record service, as has come
up on this list.

I think it is completely ridiculous that the time is off for 24
hours, or six hours, or whatever.  I still like the UTS
proposal[1], but i would have nothing against a smaller fraction
as long as the clock monotonically increases and (software)
consumers have a realtime clock or better TAI clock available.  It
is about knowledge, DCF77 for example reports about leap seconds
one hour in advance only, and has forgotten about the fact one
second thereafter.  I mean, yet this is still enough to smear one
second.

With a normal analog watch, i come back the next morning and see
i am off one second, but currently i have no idea at all why this
has happened.  At least not via NTP as normally distributed,
unless i am mistaken, which can very well be the case since i am
sitting on RFC 2030, which extends DCF77 in sofar as the info is
available the entire day long.  This is not why i need, what
i would need in addition would be a leap info bit months
surrounding the leap, and an additional query i can perform which
gives more leap info on explicit request.

  [1] https://www.cl.cam.ac.uk/~mgk25/time/leap/utc-torino-slides.pdf

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)