RE: [LEAPSECS] Upgrade, don't degrade

From: Seeds, Glen <Glen.Seeds_at_Cognos.COM>
Date: Tue, 10 Apr 2001 08:40:41 -0400

I agree wholeheartedly with Rob Seaman's contribution. I have not seen a
convincing argument to explain why applications that require precisely
synchronized time cannot at least in theory be satisfied with one of TAI or
UTC. If the most critical need is for linearity, use TAI (and if necessary,
convert to UTC or local time on demand). If civilian time is more
important, use UTC.

In reality, most applications mentioned (e.g. kitchen stove clocks, and even
most computers) do not really need synchronization this precise, and can in
fact operate quite happily with errors measured in seconds or even minutes.
For these, periodic manual synchronization with UTC (or some approximate of
it) is sufficient.

For the middle ground (computer service clusters), NNTP is easier to do than
UTC, but avoids the inconvenience and problems with manual synchronization.

There may be small appliances (such as advanced cell phones) that do require
precise synchronization, and for which the cost of intelligence is a
significant fraction of the cost of the appliance. For the immediate future,
most of the expensive smarts to do this can usually be placed in a shared
service that the appliance communicates with, rather than in the appliance
itself. For the slightly more distant future, the cost of technology is
dropping rapidly. It will soon become cost effective to embed all of the
necessary smarts in the appliance.

Having said all of that, I do understand that some *existing* applications
don't work properly with their current choice (which may be neither of the
above), and that fixing them may be expensive. However, I haven't seen a
proposal for reducing the cost of repair that satisfies all requirements
raised (which include usability and backward compatibility). Failing that,
we should fix the problem applications if/when the cost becomes warranted,
and until then live with them as they are. In the meantime, new applications
should take advantage of the existing standards. With any luck, these new
applications will eventually replace the old ones, and the problem will
disappear.

  /glen

Glen Seeds

Cognos, Inc.
3755 Riverside Dr.
P.O. Box 9707, Stn. T
Ottawa, Ont.
K1G 4K9

1-613-738-1440

-----Original Message-----
From: Rob Seaman [mailto:seaman_at_NOAO.EDU]
Sent: April 9, 2001 4:12 PM
To: LEAPSECS_at_clockdev.usno.navy.mil
Subject: [LEAPSECS] Upgrade, don't degrade

...
Received on Tue Apr 10 2001 - 05:51:19 PDT

This archive was generated by hypermail 2.3.0 : Sat Sep 04 2010 - 09:44:54 PDT