DATE-OBS='31/12/99'

[Rob Seaman]

Peter Bunclark wrote:

> What is happening about the millenium?  Is there any proposed way of
> dealing with the 2-digit original spec. of the year of observation.

Previous discussion has centered on related issues within the WCS
proposal.  Looking back through the half dozen or so messages that
mention DATE-OBS, I see these keywords mentioned:

	MJD-OBS MJD-REF MJD-BEG MJD-AVG MJD-END MJD-WCS
	DATE-OBS TIME-OBS DATE-END TIME-END TIMEUNIT
	TIMESYS TIMEREF
	OBT_TIME
	DATE_OBS = 1995-11-16T21:21:15.721Z

(The DATE_OBS format is stated to agree with ISO 8601 as endorsed by
some group called the "Consultative Committee for Space Data Systems".)

To be fair, these obviously represent several different solutions to
the same set of problems, but these problems involve much more than
providing a simple human (and machine) readable UT date.

Perhaps in addition to a more rigorously correct keyword solution, a
more straightforward year 2000 fix should indeed be provided for the
simple astronomer-in-the-street.  Given the deliberate way that FITS
standards are considered, the WCS proposal may not be approved before
the end of the millenium in any case :-)

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.

Question:  Are there any examples (digitized plates, for instance)
of nineteenth century FITS data?  Any keyword changes should handle
pre-twentieth century data also.  (Someone else can suggest a solution
for dates BC...)

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

This may even provide a new funding source!  A recent U.S. congressional
subcommittee meeting placed the cost of upgrading government software
(to avert disaster) at 30 billion dollars.  Who wants to start writing
the grant proposal?

Rob Seaman

-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B