On Tue 2000-08-22T10:05:43 -0700, Rob Seaman hath writ:
> John Cowan says:
> > A more sophisticated device could be set up to reckon 61 seconds
> > in certain minutes, provided those minutes were predictable in advance.
> > Even a wall clock or a watch could be programmed to do that at small cost.
> > But do you really foresee a future in which every wall clock and watch is
> > wired so that it can download the leap seconds from the Internet? That
> > is just too techno-optimistic for me to swallow.
>
> I don't know if it's optimistic - or perhaps just realistic - but
> certainly all sorts of consumer goods now include vast capabilities.
GPS itself is having no problems because it was designed with the
notion of UTC leaps. The GPS designers are sometimes cursed for
inventing another unsegmented timescale which differs by 19s from TAI.
But at a very low level GPS time does wander from TAI. It would have
been inappropriate to claim that the GPS satellites were broadcasting
TAI, and the solution that was chosen was a good one -- to invent a
new timescale, make it visibly different from TAI to avoid naive
mistakes, and provide an estimate of the difference.
Unix systems (and indeed, almost any system with as much complexity as
a modern digital wristwatch) are more than capable of handling the
notion of both a segmented and unsegmented timescale, but
unfortunately the Unix system clock routines date from before the
establishment of leap seconds with UTC. The advent of NTP brought the
notion of attempting to force segmented time onto an unsegmented set
of library functions. As a result NTP is the worst possible form of
time -- apparently unsegmented, apparently keeping SI seconds, but
actually segmented because the length of a second is different on days
surrounding leaps.
Cell phone service providers need good clocks in order to determine
accurate ranges for handoffs between cells. For this application the
best timescale is an unsegmented one, but aside from GPS there isn't
really a widely-available source of time for poles strung along
highways in the boonies, and most GPS receivers provide a direct
output of segmented UTC, not unsegmented GPS time.
The question is, should we redefine the existing meaning of the UTC
timescale (historically a very confusing thing to do) for the sake of
some systems whose operational hardware/software lifetime is probably
less than a decade?
Or should we ask the hardware and software system designers to build
the next generation of time-aware equipment with the same dual-time
capability as is in the now 20-year old GPS satellites?
I prefer the latter, but with that comes the responsibility of
defining protocols which will reliably and accurately deliver both
times to the equipment that needs them. I suspect that there are more
than a few good ideas about how such protocols work, and that there
are likely papers about that being prepared for the PTTI meeting in
November, but those abstracts aren't online yet.
Does the PTTI community lead or follow? Right now it appears that it
is following a trend of bad hardware/software system design. Is there
some reason that it can't point out that the current implementations
are suboptimal and lead the way toward better systems?
For lack of authoritative input this LEAPSECS forum is degenerating
towards a flame fest. If it continues in this direction much longer I
submit that it might better be shut down.
--
Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064
sla_at_ucolick.org Voice: +1 831 459 3046 http://www.ucolick.org/~sla
PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93
Received on Tue Aug 22 2000 - 11:19:38 PDT