DATE-OBS='31/12/99'

[Rob Seaman]

Preben makes good points about FITS DATExxxx keywords - however,
I continue to reach a different conclusion.

Extending the definition of DATE-OBS, and of the DATE "class" in general,
preserves the integrity of FITS better than deprecating an entire class
of keywords and replacing them with something else.  More to the point,
it preserves the integrity of the terabytes of twentieth century data
that the community has carefully observed, analyzed and archived.

It will also be much simpler to implement.

> 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 definition wouldn't be changed, it would be extended.

For two digit year fields, the definition would simply be clarified as
referring to twentieth century dates.  After all, this was clearly the
original intent.

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

The elided text continues '... (which is as good a system as any of the
others) ...'

I mention this not to provoke laughter (well, not *only* that), but to
point out that the current discussion is just a continuation of one the
founding authors started.  Their original solution to this problem was
not even a bad one.  Millions of lines of financial code will have to
be changed to avoid economic ruin at the millennium.  FITS just requires
a slight clarification and extension.

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

There would be no violation - and old software that cares about the date
can't just "skip" the fact that the keyword won't be meaningful anymore.

> 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

and later:

> With respect to the keyword name one could use 'OBS-DATE ' to avoid
> starting with 'DATE'. 

Note the necessary conclusion to be drawn.  Not only would "OBS-DATE"
replace "DATE-OBS", but the entire class of DATExxxx keywords would
be deprecated.  This is a major change to the FITS standard and
requires much larger modifications to current software than simply
adding 2 digits to the year when the original keywords are written.

With the DD/MM/YYYY modification, reading a FITS file would just require
adding an if-else clause when creating the same internal 4 digit year
(or unsegmented time) that the software will continue to use.  Support
for current data would be guaranteed since unmodified software will
continue to work.  Support for new data would be simple to achieve.

With any of the "new keyword" proposals, especially ones that change
the information content (as with ISO 8601), reading a FITS file would
involve some logic that would have to prefer OBS-DATE over DATE-OBS (or
the reverse) and a similar hierarchy for each DATExxxx keyword in turn.
Individual programmers would choose the keyword precedence for their own
code.  Large systems may not even agree from one module to the next.
Different systems by different groups would certainly drift apart.

Writing a FITS file would have even larger implications.  At some
point (that would vary from institution to institution and between
software package), a massive discontinuity would occur in the data
record.  This discontinuity won't even be finished on 1 Jan 2000,
since individuals would undoubtedly continue to use the old keywords
into the following decade.

Even if the DATE class keywords are deprecated, they will remain legal
FITS.  Is it reasonable (or useful) to allow DD/MM/YY dates to represent
21st century dates?  Or will this same discussion recur in 2096?

> I still support a more readable keyword than MJD-OBS to give time.

Amen to that.  If "once FITS, always FITS" is the first law of FITS,
then "keep it simple" is the zeroth law.

As an alternative, Guy Rixon has suggested:

> use MJD-OBS as the standard, machine-readable date descriptor, but
> always encode in its _comment_ the human-readable date and time.

MJD and ISO 8601 are useful standards - however, they address different
problems than DATE-OBS.

Comments shouldn't be used to store information that users will want to
use for header listings and boolean queries.

...and Mike Corcoran writes:

> A better approach in this spirit would be to explicitly define the year
> in a totally new keyword (YEAR-OBS or some such).  [...]  Absence of
> YEAR-OBS would imply the 20th century.  This is similar to Peter
> Bunclark's CENT-OBS but without the ambiguity of whether 20 means
> yr+2000 or 20th century.

There is no advantage in preserving the current imprecise DATE-OBS format
at all costs.

Human readability suffers with this approach - there is no way to guarantee
that YEAR-OBS would immediately follow DATE-OBS in the header.  Even if it
does, one or the other keyword may easily scroll out of a window, or fall
on the wrong side of a page break.

Every DATExxxx class keyword would also require a corresponding YEARxxxx
keyword.  Do we really want to reserve an entirely new class of keywords?
We would either have to deprecate all prior keyword usage starting with
"YEAR", or just reserve YEAR-OBS and deprecate all "DATE" keywords other
than DATE-OBS.

Prior discussion has centered on preserving FITS usage while introducing
unsegmented time standards (MJD or ISO 8601, for instance).  Separate
YEARxxxx or CENTxxxx keywords segment the time even further.

Whatever solution is adopted should be graceful, not just functional.
If functionality were the final word, I would instead advocate a
variation on DD/MM/YYYY:

    DATE-OBS= '24/06/96/19       '

This would undoubtedly break less current software and offers precisely
the same information, but aesthetically it's indefensible.  Not "breaking"
software is also not the same as not requiring software to change - the
millennium would still leave us with DATE-OBS='01/01/00/20' to deal with.

Rob
seaman at noao.edu