On Tue 2003-01-28T16:31:03 -0700, Rob Seaman hath writ:
> oscillatory modes.) Just one more example (among many) is my long
> time participation in the FITS standards process. FITS is astronomy's
> universal data format, whose metadata standards rely explicitly on
> UTC.
For the sake of further seeding the discussion of standard this
explicit reliance deserves exposition.
The FITS standard was re-crafted hurriedly in 1997 because an
astute fellow noted that the original definition from 1980 was
so short-sighted that it would break in Y2K. The resulting
standards document contains the following:
The value of the DATE keyword shall always be expressed in UTC
when in this [the new Y2K-clean] format, for all data sets created
on earth.
The purpose of the DATE keyword is to indicate the creation date/time
of the FITS file. The trailing clause about "earth" is an explicitly
inserted safety valve due to my concerns that the required timescale
should be accessible to the writer of a FITS file. The presumption
was that UTC will be readily available on earth. For FITS file
authors on spacecraft or elsewhere the standard tacitly admits that
UTC may be neither available nor relevant, and that the timescale
which might be used in such a case is beyond the scope of the
document.
In actual practice this requirement is not always met because the
creation date of the file is usually determined by a call to the
operating system. The system clock may not know absolute time even as
well as my wristwatch does. Even if the system has access to NTP, the
letter of the standard is going to be violated near the insertion of
leap seconds. Very few systems have access to any actual form of UTC.
On the other hand, the loss to posterity of not knowing when a file
was created to within a second is rarely important, so science does
not suffer much from this violation of the standard.
Regarding the DATE-OBS keyword the standard says:
When the [new Y2K-clean] format with a four-digit year is used,
the default interpretations for time shall be UTC for dates
beginning 1972-01-01 and UT before. Other date and time scales
are permissible.
The DATE-OBS keyword is intended to record the date/time of the
observation. The language used here is much looser. The standard
gives the default interpretation, but does not give any means for
determining whether or not this default is in use. This was intended
to serve as a guide that FITS file authors should use a timescale
which has been most available throughout the history of most
astronomical observations. This was presumed to be UT (and not
necessarily UTC), but any other time scale is acceptable if the
mission requirements demand it.
The FITS standard has an appendix about time scales that goes into
further details about suggested practices and relativistic gotchas.
The content of the appendix is not binding.
During the drafting there were voices requesting that the new standard
should require the use of TAI rather than UT because (as noted above
with NTP) TAI is less ambiguous than UTC. This was struck down for
several reasons. One is that there are many astronomical observations
from before the advent of TAI (and there are ongoing efforts to
digitize old emulsion). Another reason is that TAI is simply not as
available as UT, and the standard cannot place such a steep
requirement on all the astronomical data acquisition systems in the
world. Another reason is that many sorts of observations are reduced
as if the observation occurred from a point other than the earth's
surface, and TAI does not make sense for observers at different
relative velocities and different depths in gravitational potentials.
The point of all this is that the specification of UTC in FITS is for
pragmatic purposes and for guiding usage toward the most precise
meaning that is possible for a document that holds no power over
pre-existing implementations. Several aspects were left intentionally
vague in the anticipation that social trends in time scale usage would
evolve.
Hopefully the time and frequency community who initiated this forum
are attempting to find a similarly sensitive way to handle the
leapseconds issues.
--
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 Wed Jan 29 2003 - 02:38:58 PST