DATE-OBS='31/12/99'

[William Pence]

Regarding how to fix the DATE-OBS problem, I support Rob Seaman's point
of view of extending the definition of the existing DATE-OBS keyword,
rather than deprecating the keyword and replacing it with an entirely
new one.  The main reason for this is that I think this is the cleanest
and most elegant solution and will also require the least amount of
effort for the FITS community to retrofit existing FITS readers.
Regardless of what solution is finally adopted, *all* existing FITS
software that reads the DATE-OBS (and DATE-END) keyword will have to be
modified.  It will be simpler to add more code to parse a more extended
DATE-OBS keyword format than it will be to add code to read and parse
an entirely new keyword if it does not find the DATE-OBS keyword in the
header.

I would go further than Rob, however, and suggest that we extend the
definition of DATE-OBS keyword to allow the full ISO 8601 data/time format,
in addition to the current dd/mm/yy format.  Thus all the following
examples would be legal:

     DATE-OBS= '24/06/98' 
     DATE-OBS= '2010-02-13T13:53:10.3Z' 
     DATE-OBS= '2010-02-13'

The FITS reading software can easily distinguish between the old and
new formats.  This does not invalidate any existing FITS files, so it
does not violate the 'once FITS always FITS' rule.  Also, this will not
'trick' any existing FITS readers into interpreting the wrong date
(which is one of the main drawbacks to the proposal to use a
'dd/mm/yyyy' format). 

This solution avoids the need to invent a new class of UTC-xxxx or
CAL-xxxx keywords.  It also eliminates the problem of deciding which
keyword is dominant if a FITS file contained both.

Bill Pence
HEASARC/GSFC/NASA