[fitswcs] FITS WCS Time Paper

[Lucio Chiappetti]

I apologize for the delay in sending these comments (possibly I will put 
my own in a separate e-mail, and give here only a few counter-comments).

I fully appreciate the effort and expertise put in the Time Paper, for 
which the authors shall be thanked, and I think it should be published 
rapidly. However I share (with some nuances) some of the concerns 
expressed by Tom McGlynn and reported below.


On Thu, 22 Mar 2012, Tom McGlynn wrote (later)

> I'm looking at this document in the same light as the earlier WCS papers 
> which were published in the same fashion.  I do not believe this current 
> draft addresses the mechanics of generating/reading FITS data with the 
> same level of rigor as they did.

This is important since the previous WCS papers 'have been formally 
approved by the IAUFWG and therefore are incorporated by reference as an 
official part of this Standard.' (section 8 of the standard)

On Thu, 22 Mar 2012, Tom McGlynn wrote (earlier)

> It seems to me that this document combines a standard definition, 
> recommendations for usage, aspirations for general changes to FITS that 
> might be useful, and operational considerations. Of these I believe only 
> the first two should have any place in the document and even they must 
> be carefully distinguished.

I agree with the need of a distinction, although I am not sure the latter 
two points shall be eliminated from the paper. I believe that the "general 
changes" either find their way in the standard NOW, contextually to the 
issue of the Time Paper, or "forever hold their peace".

> In section 4.1 a number of header keywords are specified as being 
> 'high-precision floating valued' following a discussion that says that 
> double precision may not be adequate for these numbers.  So is
>
>   MJD-OBS   = 50000   // MJD of observation.
>
> legal?  The document makes one wonder.  It's an integer, not even single 
> precision! The problem here is that precision is a usage issue [...] The 
> FITS standard already allows for very high precision floats in the 
> header so that this should not be mixed in with the normative elements 
> of the standard.

   We all know that data types in FITS headers are sort of heuristically
   defined, and their ASCII representation does not necessarily match
   computer storage data types.

   The indication of a "data type" in square brackets after the kwd name
   is (already) used in the WCS chapter of the standard (e.g. 8.2) which
   however seems limited to the "typical" (integer, character, floating
   point).

   The introduction of the term "datetime-valued" indicates a particular
   format of a character string, and is fully legitimate.

   The term "high-precision floating valued" coincides with what the
   standard calls "real floating-point number" (4.2.4), which does not
   discriminate at all between REAL*4 and REAL*8. In this respect your
   example of a dot-less value MJD=50000 is a legitimate float ("If the
   fractional part is present, the decimal point must also be present. If
   only the integer part is present, the decimal point may be omitted ...")

   In this respect "high-precision floating valued" is just adding emphasis
   on the fact that the PROBABILITY for time values (written in ASCII in
   the headers) to exceed the precision of a REAL*8 is higher than for
   other floating values.

   Possibly this emphasis can be given otherwise (e.g. slight rewording
   of the sentence at the end of section 4 (pag. 3) ?)

> - Including aspirations:
> Section 3.5 is entirely out of place in this document -- maybe it could 
> be included as a non-normative appendix.  This is a request for a new 
> datatype in FITS which is operationally entirely distinct from the time 
> standard.

   Yes, the issue of 128-bit reals is delicate and should be tackled by
   the IAUFWG (and FITS community) considering also issues like support
   of such data type by major language compilers.

   Also, an alternative could be integers. After all spacecraft clocks are
   usually arbitrary n-bits integer with LSB of 2**-p sec, as I pointed
   out in my comments to the earlier issue. Arnold Rots however thinks
   that "a floating type will be more intuitive to users"

   But if any alternative will request a special coding in software, it
   might be easier to choose one for which there are already
   implementations. I assume the doublet vectors are one such
   implementation (RXTE ? what does the radio pulsar community use ?)

> Conversely, the standard seems incomplete as to how the doublet vector 
> discussed in section 3.4 is used operationally.  Suppose I have a binary 
> table which has one or more columns which have TFORMn='2D'.

   I wonder it, provided a more unambiguous definition is used (see below)
   one could define a T datatype (T for time) which equates to 2D (same
   storage space as it, or as double precision complex M). This will allow
   it to be not limited to scalars, but to have "depth" (nT).

> table which has one or more columns which have TFORMn='2D'. How do I 
> know which are time doublets and which aren't? I'm guessing that 
> TTYPEn='TIME' is supposed to indicate a time column, but I'm not sure I 
> found a normative statement to that effect.

   This is true, and applies in general to other places too. I will raise
   some comments on my own in the next message.

> Is it legal to have TTYPEn='TIME' and TFORMn='2F'?  The standard seems 
> silent on these issues.

   By "the standard" you mean "the Time Paper" don't you ? which is NOT
   YET the standard !

> The standard is even silent on a the very basic issue of how elements in 
> a doublet are to be combined.  It talks about separating the number into 
> a integer and fractional part. [...] Should -3.5 be represented at (-3, 
> 0.5), (-3, -0.5), or (-4, 0.5)? A rigorous statement of how data are to 
> be combined should be given

   True.
   Unless one forbids times in the past (negative, before reference).

   Also integer and fractional part IN WHICH UNITS ? days ? seconds ?
   TIMEUNIT ?


> - Operational concerns:

> Section 4.6 is an example of where the standard goes well beyond its 
> avowed purpose of describing how to represent times into how to use 
> them.  While good time intervals are a very valid use of times within 
> FITS, they should be seen as an application of the time standard and not 
> a part of it.

   Indeed, section 4.6 on GTIs is a "convention" in common usage, and
   in fact 4.5 (a few lines above the end of the first column at pag. 9)
   says "these are excellent candidates for definition through an
   appropriate formally approved FITS convention rather than an inclusion
   in this standard" !!!

   Very true, except that there are no such thing as "formally approved"
   but just "formally registered" conventions.

I will now try to write down my other comments in a separate message.
Please stand by.