I can provide such an example.
At NASA/Goddard Space Flight Center, we run satellite orbit models which typical
generate ephemeris data on 1-minute intervals, synchronized with UTC. Our
spacecraft data streams are likewise time-tagged to UTC. The software which
implements the model has no means for accommodating the time/position
discontinuity which occurs every time a leap second is introduced. Currently we
handle this by "breaking" the orbit integration and the data stream at the
discontinuity, so that time and orbital motion are continuous before and after
the leap second.
Multiplied across many satellites and systems, this is a significant
inconvenience. Of course, there may be a software solution, but no one has come
up with a robust solution yet.
Fred Patt
Steve Allen wrote:
>
> I'm somewhat dismayed to realize that, other than the Unix system
> clock (which, if one tenth the effort which has gone into
> /usr/share{/lib}/zoneinfo had gone into leap seconds, would not still
> have a problem), this discussion list has not yet been able to name
> and discuss a single system which is more inconvenienced by leap
> seconds than it is by daylight savings time.
>
> Of the folks at USNO, on URSI Commission J, or attending PTTI I ask:
>
> What was this LEAPSECS mailing list supposed to accomplish?
>
> --
> 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
--
* Frederick S. Patt
* SAIC General Sciences Corporation
* Code 970.2, Goddard Space Flight Center
* Greenbelt, MD 20771
* Vox 301/286-5723 * Fax 301/286-0268
* Email frederick.patt_at_gsfc.nasa.gov
Received on Tue Sep 19 2000 - 13:10:58 PDT