DATE-OBS='31/12/99'

[Preben Grosbol]

In article <4qrl92$r5q at noao.edu>, Rob Seaman wrote:
> 
> I suggest the DATE-OBS definition simply be relaxed to allow a four
> digit year as well as a two digit year:
> 
>     DATE-OBS= '24/06/96          '  /  UT date
>     DATE-OBS= '24/06/1996        '  /  UT date
> 
> A two digit year would imply a twentieth century date.  The same rule
> could apply to DATE and other similar keywords.  This agrees with the
> "once FITS, always FITS" rule since existing data are still fully legal.
> DATE-OBS is a reserved, but not a mandatory keyword, so the 8 character
> limit for fixed format strings is not required.  Two digit years would
> not even need to be deprecated since archival data would continue to be
> analyzed.

 Although the extension of the year to four digits would be an 'easy fix'
it is not acceptable considering the FITS standard.  In the NOST
FITS document the definition is too clear to be changed i.e. 'YY [is] the
last two digits of the year'.  The original FITS paper Wells et al. (1981)
was not so exact but the meaning is clear.  It also states that 'Keywords
beginning with the generic string DATE are used to document various relevant
dates. Note that data value strings will be coded in the form 'dd/mm/yy' ...'

> Note that "once FITS, always FITS" doesn't require that old software
> has to handle new data - this is also moot since any FITS code that
> cares about the date keywords will break at the millenium anyway.
> It may even be regarded as a feature since programmers should be
> encouraged to address the issue and users should be encouraged to
> update their software...

 It may be reasonable with a few comments on the "once FITS, always FITS".
The statement given in the NOST document section.9 is more exact namely:
 'Any structure that is a valid FITS structure shall remain a valid
  FITS structure at all future times.'
This would be violated if a 4 digit year would be allowed in the data value
string.  It is correct that 'old' FITS readers are not expected to handle
'new data'. However, they should not produce wrong results reading a new
FITS file but rather skip new data structures (because they do not understand
them). 
 In the case of 4 digit years old readers may interpret the year as e.g.
1919 which would be unacceptable.  Digitized plates may well be that old
as Peter Bunclark indicated.

 Thus, a new keyword would be the only acceptable way considering the
FITS standard.  Evenso, the new keyword could not start with string
'DATE' as mentioned above (I should have checked more carefully before
my first posting).

 I still support a more readable keyword than MJD-OBS to give time.
Our internal software would in any case use MJD-OBS as time reference
if it exists. The ISO 8601 seems a good candidate for a new date/time
value string. With respect to the keyword name one could use 'OBS-DATE '
to avoid starting with 'DATE'. 

Preben Grosbol