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