DATE-OBS='31/12/99'

[Lucio Chiappetti]

On 7 Jul 1996, Rob Seaman wrote:

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

  yes

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

  yes, perhaps

> We also continue to discuss apples and oranges.  MJD clearly addresses
> a different need than a human readable (and writable) date.  I would

  Yes, I like (and use) dates in the readable form
  YYYY-MON-DD HH:MM:SS.FF  with MON=Jan,Feb etc.

  Incidentally when I defined such form I was inspired by some mail
  quoting some of the ISO formats (which I cannot trace now). I recall
  that the only difference was the presence of a blank between date and
  time instead of a letter (I favoured the blank because of human
  readability ...)

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

  otherwise said, applying Ockham's razor. one should use a subset composed 
  of a SINGLE case !

> - Why should the FITS date keyword (whatever it is) be required to
>   include a time, anyway?  

  Personally I believe that a date without a time is no use. In fact
  I've never used something like DATE-OBS (which is just a reserved
  keyword, not a mandatory one ...). I think there is no interest in
  knowing that a given measurement was done on a given date, if one
  cannot know the time !  
  Unless one does a measurement which is more than one day long ...

  We'd been recently designing a format for
  the archiving of XMM EPIC calibrations, and we were planning to use
  a DATE-OBS (because it was a "reserved" keyword) together with a  
  TIME-OBS  ... assuming that was the start of a measurement, and
  also a DATE-END and TIME-END ... Most of this was driven by a
  requirement to have an output file in FITS.
  Since I generally use another format as working format, I've used
  (or am planning to use) a different approach there. The idea is that
  keywords are stored in native binary representation (they can be
  written in ASCII when presented to the user or converted to FITS).
  Besides the "standard" types (I2 I4 R4 R8 CHARACTER) there are some
  "composite" types like dates, angular quantities etc. (they use a
  particular native binary representation, e.g. I4 or R8, but are
  DISPLAYED in an human legible form like   YYYY-MON-DD HH:MM:SS.FF  or
  +dd:mm:ss).
  For dates (intended as date-times for which not excessive precision
  is required) the native format is the Unix time (I4 number of sec since
  1970), and this requires just three routines :

      1 - to convert from "Unix time" to a "time array" (yy mm dd hh mm ss)
      2 - to convert from time array to Unix time
      3 - to format Unix time into ASCII human readable form (this calls
          number 1 and does an internal write)

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR     | Ma te' vugl' da' quost avis a ti' Orsign 
via Bassini 15 - I-20133 Milano  | Buttet rabios intant te se' pisnign      
Internet: LUCIO at IFCTR.MI.CNR.IT  |             (Rabisch, II 46, 119-120)    
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------