DATE-OBS='31/12/99'

[Peter Bunclark]

Rob Seaman wrote:
> 
> 
> If, for some reason, FITS readers cannot be updated - isn't it also
> likely that the corresponding FITS writers can't be updated either?
Yes, but the point of FITS is that readers and writers don't correspond to 
each other, rather both correspond to the standard.  Sadly, readers get left
behind in the process.

> 
> 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.
Part of my argument is, I would rather it failed completely with `KEYWORD
NOT PRESENT' than fail quietly having secretly got the century wrong.  I bet
if you were using this to compute airmasses at time of observation, for example,
you may well not check manually.


> Should a fundamental decision be driven by unmaintainable software?
No, not really.  I just include that problem as a factor in optimising the
solution.

> 
> 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.
Still disagree, this time because of current software, much of which will
parse DD/MM/YYYY without calling an error, and thus not alerting its maintainer
to the need for an update.  (Dates will all apparently be in 1919).


> - 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.
> 
All your points about MJD and about ISO full-format dates makes a lot of sense.

> 
> 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.
But could make reader-writing very complex!

> 
> 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.
> 
> 
> Rob
> 
So is there any chance we could agree on the following:
1) Clarify DD/MM/YY to be 20th century
2) allow alternative DATE-OBS= '1996-07-08'

   The User Guide should advise stopping use of DD/MM/YY; and to use the `-' as
   a field-separator, not to use FORMAT(i4,1x,i2,1x,2i2) so that the year 10000
   will work.  We'll ignore it, of course.
   The format DD/MM/YYYY is NOT allowed.

Please note the climb-down!! Personally, I would still choose a new keyword;
telling a reader to search for a different keyword is greatly simpler than writing
a new date-string parsing algorithm.  However, I believe this is so important I'd
really like to kick it into action.   What's the procedure to declare a standard
extension?