On Fri 2000-09-08T11:06:42 -0400, John Cowan hath writ:
> That is exactly and in short the issue which brings me here, and probably
> lots of other people as well. Computers tick TAI by nature,
> but are typically set from a UTC(+-offset) source and need to communicate
> in UTC(+-offset) with their users. And not all of us, especially those
> working with embedded systems, can afford to receive satellite broadcasts
> or use Internet connections.
As an excercise in understanding the full spectrum of the problems
I'd like to propose an enumeration of the types of systems that exist.
I'm open to a complete reworking of this taxonomy.
Type 1: the systems that don't need to communicate with
anything else, at least not electronically.
Type 2: the systems that do need to communicate with something else.
Type 2.1: those systems which don't care what time it is.
Type 2.2: those systems which do care what time it is.
Type 2.2.1: systems which are too simple to include a time
protocol in their communications
Type 2.2.2: systems which are complex enough to include a time
protocol in their communications
In Type 1 I'll place analog clocks. This includes those hooked to AC
line current (which would otherwise be into type 2), for the down time
of the power grid in most areas is more than a few seconds per year.
The only systems which are inconvenienced by leap seconds are type
2.2.1.
I'll risk asserting that they are a temporary aberration in the
evolution of systems which will very soon be entirely replaced by type
2.2.2.
Obviously this is only true if we decide that leap seconds, i.e. not
having a secular drift of noon away from 12:00, are important.
Otherwise the engineers building the systems won't include the right
protocols. But I'll assert that if we do decide to keep leap seconds,
getting the time protocol right will be a matter of programmer pride.
--
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 Fri Sep 08 2000 - 10:43:02 PDT