The following text was approved on 1997-11-10 by a formal vote of the IAU FITS Working Group, the body which controls the FITS standards under the authority of the International Astronomical Union. The rules specified below are now a part of the FITS standards. -Don Wells (Chair, IAU-FWG) -=-=-=-=-=-=-=-=-=- Precise re-definition of DATE-OBS Keyword encompassing the millennium Peter Bunclark 1996 Nov 19 Amended: Arnold Rots 1997-10-24T21:03:30 1) Introduction Although this document formally defines the format of the value field of the DATE-OBS keyword, the same format applies to the value field of all keywords beginning with the string "DATE" that have a value containing date, and optionally time, information. Known examples of such keywords, used in the exchange of date information, are DATE, DATE-OBS, DATE-END, and DATE-MAP. We shall refer to these keywords collectively as DATExxxx. The original DATExxxx keywords, including in particular DATE-OBS, have several shortcomings which make it desirable to alter the definition: 1.1) The year is expressed in only two digits; currently, digitized astronomical data span more than a century; and furthermore, the implied most-significant two digits of the year will change from 19 to 20 shortly. 1.2) The timescale of DATExxxx is not defined. 1.3) The relation of DATE-OBS to the start, middle or end of an observation is not defined. 1.4) The order of day, month, year is least-significant first, so lists of dates cannot be sorted simply on the ASCII collating sequence. 2) Scope Three main issues are addressed: 2.1) The format of date strings to be used in any DATExxxx keyword. 2.2) The future of the DATE-OBS keyword itself. 2.3) The specification of the time scales (time systems) used. 3) The Date-String format Proposal 3.1) A DATExxxx field in the old format of 'DD/MM/YY' will explicitly refer to a year 1900-1999. The very few instances of digitized nineteenth-century plates represented as FITS files (only files created before this proposal went into effect) must be handled as special cases. 3.2) The new format is a restricted subset of ISO-8601, being one of two options: a) 'CCYY-MM-DD' b) 'CCYY-MM-DDThh:mm:ss[.sss...]' represents a calendar year, the ordinal number of a calendar month within the calendar year, and
the ordinal number of a day within the calendar month. represents the hour in the day, the minutes, the seconds. The value of the integer part of the seconds field is normally in the range [0..59] but may take the value 60, if the time scale is UTC, to indicate a leap second. The literal 'T' is the ISO 8601 time designator. In the short form (a), there must not be any additional terminator/separator (such as T). In the long form, there must be a 'T' time designator between the date and the time. The decimal point character is an ASCII full-stop (hexadecimal value 0x2E). The number of decimal places in the `seconds' field may be arbitrarily long, up to the FITS header-card limitations. 3.3) Only fully-specified date or date/time strings are permitted. No fields may be defaulted, no leading zeroes omitted. The decimal part of the seconds field is optional. 4) Use of the DATE-OBS keyword 4.1) The name of the keyword shall remain DATE-OBS. 4.2) Henceforth, DATE-OBS shall be assumed to refer to the start of an observation. Other interpretations must be clearly explained in the comment field. 4.3) The default interpretation of all DATExxxx keywords shall use the Gregorian Calendar for the date portion. 4.4) The value of the DATExxxx keywords, with the exception of DATE (see section 5), shall be expressed in the principal time scale or time system of the HDU to which they belong. The default interpretation shall use UTC (for dates since 1972) or UT (for dates before 1972). If there is any chance of ambiguity as to which is the principal time scale, the choice shall be clarified in comments. 4.5) It is recommended that the time scale or time system be specified explicitly. However, implementors can be assured that the error resulting from ignoring the time scale specification and making the default assumption will not exceed 1000 s for the period 1001-01-01 through 3000-12-31. 4.6) By default, times will be deemed to be as measured at the detector (or in practical cases, at the observatory) for TAI and times that run synchronously with TAI (i.e., UTC and TT). In the case of coordinate times (such as TCG and TCB) and TDB which are tied to an unambiguous coordinate origin, the default meaning of time values will be: time as if the observation had taken place at the origin of the coordinate time system. These defaults follow common practice; a future convention on time scale issues in FITS files may allow other combinations but shall preserve this default behavior. 5) Use of the DATE keyword 5.1) The date-time string value of the DATE keyword indicates the creation time of the HDU. 5.2) The value of the DATE keyword shall always be expressed in UTC whenever the date-string format defined in this proposal is used, in all HDUs created on earth. 6) Examples Three legal representations of the date of October 14, 1996, are possible: DATE-OBS= '14/10/96' / Original format, means 1996 Oct 14. DATE-OBS= '1996-10-14' / Date of start of observation, by default UTC. DATE-OBS= '1996-10-14T10:14:36.123' / Date and time of start of obs. in UTC. 7) Transition FITS readers must continue to interpret the old format, as a twentieth century date (with the year "00" to be interpreted as "1900"), indefinitely. Readers should be altered as soon as possible to cope with the new format. In order to give adequate time for the major package writers to revise their software, FITS writers should commence writing the new format between 1999-01-01T00:00:00 and 2000-01-01T00:00:00. FITS writing code which must be distributed and operated before 1999-01-01 should be coded to test the current year to decide whether to use the old date format or the new format. Cases of DATE-OBS before 1900-01-01 should always be written with the new format.