DATE-OBS='31/12/99'

[Rob Seaman]

Peter Bunclark's summary is quite useful.  I'll respond first to a
few points from Preben's and Lucio's latest posts.

Preben says:

> It is very important not to fool old FITS readers.  Thus, the first
> 8 characters of data value strings for 'DATExxxx' keywords must be
> maintained as 'dd/mm/yy'.

But no matter what we do, the millennium will arrive and current FITS
software will be fooled.

The software has to change.  Period.  That being the case, let's change
it to both preserve (actually, enhance) the integrity of current data, as
well as to improve the quality (machine and human oriented) of future data.

> Although it may not be so 'graceful' Rob's proposal to add additional
> charaters may be the less harmfull.  To make it a little more readable
> I would rather suggest something like:
>
>     DATA-OBS= '24/12/01:2001'

This is better than my offhand suggestion, but I find either alternative
unacceptable.  'Graceful' is just a synonym for human-friendly.  Users
have to not just read this keyword, but write it as well upon occasion.
They have to use the date for generating queries and to format listings.
A date is a pretty fundamental piece of information to allow to be so
awkward.

Lucio says:

> Could one instead not assume that 2-digit dates refer to the year
> interval from 1979 to 2079 [...]  This will give us some more time ...

Please, no...let's fix the problem right.  Do we want to have to deal
with this until we die?

Peter follows his summary with his own suggestions:

> 1) We've been discussing at length the problem of a 2-digit year; also,
>    the slashes are redundant, the day-month-year order is confusing to
>    Americans (easily done), and the order is little-endian.

While date formats such as 19960628 are appropriate in various machine
generated identifiers, a human readable format needs punctuation.  I also
suspect that concern for Americans isn't central to your argument :-)

> 2) I would deprecate DATE-OBS from 1/1/2000; if FITS writers leave it out,
>    then old FITS readers won't misinterpret it.

Just deprecating the keyword isn't good enough.  If we're concerned about
current software, we have to fix the current problem.  The fix should be
as straightforward as possible, and in particular should not involve
extraneous solutions (like MJD) to other problems.

> 3) DATE-OBS = 'dd/mm/yyyy' is going to cause a lot of grief to old
>    software.  And much of this old software is sitting on old systems
>    in operational situations and nobody dares touch it...

Somebody will *have* to touch it!  A four digit year will cause no more
grief than just waiting for 1 January 2000 to arrive.

On the other hand, explicitly clarifying the current two digit year
format as referring to twentieth century dates is necessary to preserve
the integrity of archival data.  The dates recorded in the FITS files
that we've already carefully stored away should not be allowed to
become ambiguous.

A straw proposal:

    1) redefine DATE-OBS = 'DD/MM/YYYY'

    2) deprecate DATE-OBS as of midnight 31 December 1999

    3) implement OBS-DATE (or DATEOBS, or whatever) with a simple
       human-oriented date format to be determined

    4) implement MJD-OBS as a separate issue

The DATE keyword would be handled similar to DATE-OBS.  Are there other
DATExxxx keywords to worry about?

Note that #2 and #3 are only called for if the format is really as
offensive to the community as some have said.

A better proposal:

    1) redefine DATE-OBS = 'DD/MM/YYYY' (but write DD/MM/YY until 01/01/2000)

    2) implement DATE-ISO, which takes precedence if both are present

Rob
seaman at noao.edu