DATE-OBS='31/12/99'

[Preben Grosbol]

Peter Bunclark wrote:

>In conclusion, we all agree there is a problem to be fixed, but not on
>much else.  I would like to add some further points:
>
>1) PAPER ONE did contain a few howlers (EPOCH being the most celebrated),
>   and so cannot be considered inviolate.  The phrase "the form 'dd/mm/yy'
>   (which is as good a system as any of the others)" is not only incredibly
>   flippant in the context, but quite inaccurate.  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.
>
>2) I would deprecate DATE-OBS from 1/1/2000; if FITS writers leave it out,
>   then old FITS readers won't misinterpret it.
>
>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...
>
>4) I feel strongly the proposed new format should be most-significant
>   first;  it is convenient in many situations to be able to do a 
>   meaningful sort on the ascii collating sequence.
>
>5) I feel strongly about the FITS standard, despite its various shortcomings
>   (8-character keywords is my favourite, right up there with the lack
>   of an unsigned data-type).  However, we're about to write a new
>   FITS writer for a major observatory (ING La Palma) and will not 
>   let it out with the century ambiguity outstanding; any chance
>   of reaching a consensus here?

 I generally agree with these conclusions.  To narrow down the
options, the two main ones are:

 1) Patch up the 'DATExxxx' keyword definition in some way e.g. redefine
    the date value string, add extra keyword, ...

 2) Deprecate the usage of 'DATExxxx' after 1/1/2000 (Peter's #2)
    and replace it e.g. use 'MJD-xxxx' or a new set of keywords.

 Whatever 'patch up' one proposes there will be lots of problems.
Thus, I would favor the cleaner option namely #2. For readability,
I still support to have something else than 'MJD-xxxx'. Jonathen
suggested 'CALEN-' which unfortunately is at least one character
too long and 'CAL-xxxx'/'CALE-xxx' do not look as nice.  As one
more probably would use UT as reference, a 'UTC-xxxx' set of
keywords could be considered using the complete extended date/time
format of ISO 8601 for the date value string.

 I finally got the ISO8601:1988/1991 standard document. It defines
several formats but the most relevant is the 'Calendar date' 
(ref. 5.2.1) and the 'Combibations of date and time of day
representations' (ref.5.4.1). The complete representations are:

                            Basic               Extended
   Date format             ccyymmdd            ccyy-mm-dd
   date example            20100213            2010-02-13

   Date/time (UTC)format   ccyymmddThhmmss.sZ  ccyy-mm-ddThh:mm:ss.sZ
   date/time example       20100213T135310.3Z  2010-02-13T13:53:10.3Z

(Actually comma (,) is prefered by ISO but full stop (.) is allowed).
Due to readability the extended format would be prefered.  The
ISO standard also define formats for local time and periods of time.

 On the MJD-OBS issue, the latest WCS proposal I have seen specifies
TAI but leaves the definition of start/mean/end/... open since WCS
only need a mean epoch.  Partly due to the year 2000 issue, ESO is
internally using MJD-OBS instead of DATE-OBS.
 At the IAU I understood (maybe wrongly) that the main reason to deprecate
the MJD was that a number of variable star people did (could) not
read the definition of MJD and therefore sometimes forgot to correct
for the half day offset with respect to JD.  The proposed usage of
MJD in FITS is well defined and in agreement with the IAU definition.
One reason to use MJD rather than JD is the two extra digits it gives
which translates to an accuracy better than a millisecond for a 64-bit
IEEE floating point number.

Preben Grosbol