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 <[EMAIL PROTECTED]> 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