[fitswcs] [fitsbits] FITS WCS Paper V: Time - Draft for Review

[Lucio Chiappetti]

On Fri, 14 Oct 2011, Arnold Rots wrote:

> Version 0.90 of the FITS WCS Paper V on Time is now available for 
> review: [...] We request that comments be directed to the FITSWCS 
> discussion list: fitswcs at nrao.edu

I had Paper V for review on my desk awaiting for a quiet time like this 
semi-holiday week, and I see now the topic is getting reactivated, so 
perhaps I'm not too late, for what my 0.02 euro are worth :-)

I had a quick check in the archives, and I found a reply of mine dated 
2009-April-07. Some of the comments I raised at the time are possibly 
still valid.

(section 3 pag. 2 bottom of 1st column)

  Why would we need a 128-bit FLOATING data type in preference e.g. to
  a 128-bit INTEGER one ? Integers are usually better/simpler in keeping
  precision (spacecraft clocks are usually arbitrary n-bits integer)
  alhtough perhaps less handy.

  What is the situation for what compiler support in major programming
  languages is concerned ?

  I am also still not fully convinced that data in any single FITS file may
  really require such high precision. After all, if one is doing pulsar
  studies, the file will require very high resolution, but relative from an
  established time reference value. And surely one won't go back for
  centuries. On the other hand whoever studies things like epochs of Sun
  eclipses may go back for centuries or millennia, but is not likely to
  require sub-second precision.


(3.1/ 3.4 / 3.5 / the datetime data type)

  In principle I agree that a "datetime" data type would be useful, as
  it is present e.g. in SQL (at least mysql), but a proper data type is
  something that has a BINARY representation, not an ASCII one.

  But on the other hand, FITS header keywords are (unfortunately, but
  that's the way it is, and "once FITS forever FITS") "typeless". One
  could (talking in general) imagine that a user, in one's FITS reader,
  assigns an integer or float datatype to a keyword heuristically, but
  keywords remain typeless.

  So all what is said about the ISO-8601 datetime strings remain valid,
  for header keywords, which are typeless and expressed in ASCII, but
  it is not a "data type" and should not be used as such in the data
  part of an HDU.

  This is actually re-inforced by what you say in section 5.2.3 !!

(3.1 last bullet)

  "time zones are explicitly not supported"
  I'd add explicitly also that "daylight saving time (DST) conventions
  and alike are not supported"

(3.5 S data type)

  I repeat the formal argument. The WCS timing paper is likely to be
  incorporated by reference in the FITS standard (as other WCS papers)
  and as such it cannot "anticipate" additions and updates to the standard.

  We cannot hide it under the carpet ... should we discuss it now ?
  (The answer at the question about compiler support made above will be
  useful)

(3.6 last sentence "Caution")

  Does a reference exist for the convention described ?

(4. first para)

  Any reference for Greenbank convention (currently under review in the
  convention registry) ?

(4.1 at the end)

  Why are JEPOCH and BEPOCH "to be used with great caution" ?
  Please motivate in text

(4.2.1 pag. 4 end 1st column)

  "Any other time scale ... not listed on Table I are instrinsically
   unreliable ..."

   Can we draw the conclusion AND THEREFORE THEIR USAGE IN FITS FILES IS
   FORBIDDEN ?

(4.2.2 title)

  mention kwd TREFPOS explicitly in the title section !
  Or anticipate the "Keyword" \paragraph (is that's it in latex parliance)
  close to the beginning of the section, to give more emphasis to this
  rather important kwd,

(4.2.2 last sentence)

  any reference for the IAU ellipsoid ?

(4.2.4 keywords, typo)

  obviously the sentence in the "Keyword" \paragraph shall mention the
  time reference DIRECTION not position

(4.4)

  what is the "prevailing time unit" ? the one in the TIMEUNIT kwd ?
  Please define explicitly.

(5.2.1)

  There is a prohibition of multiple time reference positions etc.

  However there is a useful case in which one could have two "parallel"
  axes of time and PHASE (given an ephemeris) which could reside one
  along the other, and would benefit of being defined and regulated in
  this paper.

  (I'm thinking both of phase 0.0-1.0 for folded light curves as well
  as of an "unfolded" phase (where the bin after 1.0 could be 1.01,
  and which could go on for an undefined number of cycles)

(5.2.2)

  reference to Lorentz transformations etc. ... is it worth reporting
  some formulae in the paper ?

(References)

  - the latest reference to the FITS standard (IAUFWG 2008)
    should be replaced by the journal-published reference
    2010A&A...524A..42P i.e.

    \bibitem[Pence et al.(2010)]{2010A&A...524A..42P} Pence, W.~D.,
    Chiappetti, L., Page, C.~G., Shaw, R.~A., \& Stobie, E.\ 2010, \aap,
    524, A42

  - although not advocating "Boncompagni 1582" I'm still wondering
    whether the quotation of the papal bull is respecting the format
    used e.g. by science historians (surely the first author should
    be able to ask "in house" to Owen Gingerich for example)

(table 4)

   Title should be "RESERVED time scale keywords"

(table 6 and 7)

   do not really understand these tables with a degenerate time axis

(appendix A)

  In particular A.5; an "authority within IAU" on these matters should
  be identified and mentioned explicitly

  Entire appendix could be reformatted "graphically" as a clearer table
  with acronym, acronym expansion and textual explanation

And ... best wishes for the New Year to everybody

-- 
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html