DATE-OBS='31/12/99'

[Frank Valdes]

I know I will be critized for the following but we are starting
to sound more like lawyers than astronomers.  

In article <199606270823.KAA17492 at ns2.hq.eso.org>, pgrosbol at eso.org (Preben Grosbol) writes:
From: pgrosbol at eso.org (Preben Grosbol)
Subject: Re: DATE-OBS='31/12/99'

>  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' ...'

>  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.

Will there really be "old" FITS readers in 2000?  In terms of making a
wrong interpretation the "old" FITS reader, illustrated above, using only
two digits for the year will interpret 1/1/00 as 1900 when 2000 is intended
which is also quite wrong.  The "old" unmodified reader will not have been
changed to understand any of the other keywords being proposed.

There are many reasonable suggestions but as an astronomer rather than
a lawyer I think continued use of DATE-OBS or any DATE keyword with
the simple change that years are four digits except that when two
digits are encountered the century is 1900 is desirable and we have
several years to fix "old" readers which will make a mistake regardless
of what is done.

For a new keyword I would wish to see an ascii orderable and human
readable value.  The ISO standard seems reasonable.  The keyword
might be DATE-ISO.  The question about separate dates for the date
the file is created and the date relevant to the data is another
quibble that has little basis in reality.  I have yet to find a reason
to be interested in the date the file is created.  The interest
for an astronomer is the date to be applied to the data.  So except
for the currently used practice of DATE any additional dates/times should be
considered to apply to the data.  When exactly (beginning of an integration,
etc.) needs to be specified by the data creator in some way with
keywords, comments to keywords, or an archived data dictionary specification.
This does not prevent data creators from indicating the date the file
was written if they feel the need.

I support use of MJD time stamps (such as MJD-OBS) but it is not a substitute
for a date/time that can be parsed by a human without a calculator.

Frank Valdes