On Fri 2007-01-05T21:14:19 -0700, Rob Seaman hath writ:
> Which raises the question of how concisely one can express a leap
> second table.
Gosh, Rob, I remember toggling in the boot program and starting
up the paper tape reader or the 12-inch floppy disc drive, but now
I'm not really sure I understand the need for compactness except in
formats which are specific to devices with very limited capacity.
I routinely carry around 21 GB of rewriteable storage. It's
hard to imagine that the current generation of GPS receivers
has less than 100 MB and I expect that by the time Galileo is
flying it will be routine for handheld devices to have GB.
I would much prefer to see the IERS produce a rather verbose,
self-describing (to a machine), and extensible set of data products.
Devices which prefer a more compact version are free to compile the
full form into something suitable and specific to their limited needs.
Most devices will be satisfied with only the leap second table.
A leap second table in a working format is just one form of the
"navigator's log" containing information for the conversion of the
ship's chronometer to and from other, more universal time scales.
Leap seconds are step functions, but in general the chronometer
offsets are likely to be splines of higher order.
That's something which might benefit from having a well-defined
API and a number of examples of code which uses the information
to varying degrees of accuracy.
Some devices will never have clocks guaranteed to be set to within a
second of real time, and for that purpose the POSIX time_t API is
just dandy. Other applications with access to other time sources
will want to use algorithms of more sophistication according to
their individual needs.
--
Steve Allen <sla_at_ucolick.org> WGS-84 (GPS)
UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99858
University of California Voice: +1 831 459 3046 Lng -122.06014
Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Received on Fri Jan 05 2007 - 21:05:50 PST