DATE-OBS='31/12/99'

[Rob Seaman]

Preben Grosbol writes:

> It is clear that all major organizations will be able to implement
> the change but there are also smaller sites.

and Peter Bunclark writes:

> some old FITS readers cannot be updated - don't have source, don't
> have library, can't remember how to use a line editor..
> Software which *is* maintainable is not a problem.

If, for some reason, FITS readers cannot be updated - isn't it also
likely that the corresponding FITS writers can't be updated either?
On the other hand, astronomers reducing FITS files written elsewhere
already have larger compatibility issues to deal with than DATE-OBS.

If software cares about DATE-OBS (or DATE, or DATE-END, or...) it will
break whether or not anybody can fix it.  If the software doesn't need
to know the date, it's not likely to bother to parse it.

Should a fundamental decision be driven by unmaintainable software?

Our primary concern should be for the integrity of the FITS standard,
and only secondarily for any particular software.

- Deprecating the DATE keywords is a very large change to the standard.

- Expanding the allowed formats to include DD/MM/YYYY or YYYY-MM-DD is
  a small change.

- Clarifying the meaning of DD/MM/YY to refer explicitly to twentieth
  century dates is NO change at all - and is necessary to avert a threat
  to the astronomical data record.

In any event the easiest fix is simply to add the century digits when
writing the same old keywords, and to add an if-else clause keying off
the length (or format) of the value when reading those keywords.

We also continue to discuss apples and oranges.  MJD clearly addresses
a different need than a human readable (and writable) date.  I would
argue that this is also true of full blown ISO date/times.  Removing
the ability to include a human readable date (in a standard keyword) in
FITS headers would be a drastic change to the standard.  Would the "F"
still stand for "Flexible"?  Readable ASCII headers are central to FITS.

A few comments about ISO 8601 and FITS:

- It is a closed standard - nothing has changed since Carl Malamud's
  "Exploring The Internet", you still have to buy a copy of the standard.
  Presumably we could not reprint selections from the ISO standard
  within the FITS standard.

- When we talk about implementing ISO 8601 dates in FITS, we don't
  really mean that.  We mean implementing a subset of the allowed ISO
  formats.  A FITS keyword should not have so many degrees of freedom.
  (FITS users typically don't need to know the week of the year, for
  instance.)

- The code to parse even a limited subset of ISO 8601 is much more
  complicated than parsing a simple date.

- Issues of keyword precedence are impossible to avoid.  FITS usage
  already includes many redundant keywords - do we want to require more?

- Why should the FITS date keyword (whatever it is) be required to
  include a time, anyway?  If the FITS is ingested into an archive,
  are we to assume that there won't be separate date and time fields
  in the relational database?  Will users be required to phrase SQL
  queries using the full ISO syntax for periods of time?  A date is
  a useful piece of information separate from the time.

- Alternately, would FITS allow truncating ISO-OBS (or whatever) after
  the date?  Imagine the logic required to coherently implement a keyword
  that may or may not contain time information...or that may or may not
  include the seconds, minutes, hours, days or months fields.  Even the
  year is optional - "19" is a legal ISO value denoting the 20th century.

- ISO dates/times refer to the local time zone by default - the "Z" (or
  an explicit hour offset) is required to denote UTC.  For instance:

        "The following strings all indicate the same point
         of time:  12:00Z = 13:00+01:00 = 0700-0500"

  From the web summaries it is unclear whether appending the "Z" to
  a simple date string is permitted.  The ISO date "1996-07-07" refers
  explicitly to a local time zone.  I have no idea what ISO 8601 has
  to say about spacecraft time.  (Is UT "local" to a spacecraft?)

- ISO's idea of universal time may well not be an astronomer's.

Bill Pence's observation that a single keyword string can support
multiple formats (distinguished by length or some other property) is
quite provocative.  Perhaps this will prove of use with other FITS
keywords.  A little bit of this goes a long way, of course.

I agree with Bill's suggestion that the new full precision DATE-OBS
format use ISO conventions, e.g., DATE-OBS='2076-07-04'.  (Note that
trouble in the year 10000 will be avoided by simply adding a fifth
digit to the year field.)  DATE-OBS should not include ISO time
information.

The new FITS date format should, however, part ways with ISO and
be explicitly interpreted as a UT date (without a "Z").  This also
strengthens a weakness in the wording of the current standard:
"Specification of the date using Universal Time is recommended."
Change "recommended" to "required" for the new format.

The DD/MM/YY format will continue to indicate twentieth century dates.
Other DATExxxx keywords will be handled similarly.

If the community wants to establish an unsegmented format (e.g., MJD)
or a combined date/time format (e.g., ISO 8601), these should result
from entirely separate discussions.  Perhaps at some later date MJD-OBS
(and the associated TIMESYS, TIMEREF, etc.) will take precedence over
ISO-OBS, which will in turn take precedence over DATE-OBS and UT (not
to mention LST, HA, and all the other time-like keywords we use).  Do
these sound like negotiations we will finish in 3-1/2 years?  And then
implement?  Will the results of such negotiations be any easier to deal
with for those poor astronomers stuck with unmaintainable code?

Let's just fix the clear and present danger before adding new features,
no matter how attractive, to the standard.

Rob

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