[fitswcs] FITS WCS Time Paper

[Tom McGlynn]

Since I don't pretend to be cognizant of the subtle issues involved in 
time systems, I won't comment on the how those complexities are 
handled.  However, at the risk of stirring up issues that were thought 
addressed long ago, I do have a number of comments on the standard as 
a guide for someone trying to write or read FITS files containing 
times. 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.

According to the abstract the aim of this paper is:
    Time on all scales and precision known in astronomical datasets
    shall be described by extending the established FITS standard.
Why we need a particular time is not relevant to the standard though 
it may have some role when we illustrate the standard using typical usage.

Given that here are some (not all) examples of where I think the 
document says too much or mixes the standard specification and usage 
discussion:

- Mixing the standard and usage recommendations:
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 
and we should not be mixing it in with the standard definition of what 
MJD-OBS is.  The way it is described the precision seems normative. 
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.  Concerns that standard libraries may not provide 
sufficient precision should be in clearly non-normative parts of the 
standard.

- 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.  The time document should talk about how we use the 
FITS standard to specify times.  A new data type should be in an 
entirely different document -- where the need to use this type for 
times is one of the justifications.   If and when a new datatype were 
available, it would naturally become available for use in times 
without any change to the time standard.

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'. 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.  So do 
I have a time doublet anytime I see TTYPEn='TIME' and TFORMn='2D'. 
What about columns (as in the examples) with TTYPEn='BARYTIME'?  Are 
those time columns? The examples seem to indicate so.  Are there other 
values for TTYPE that indicate time columns? Should I be looking to 
TUNITn='s' instead?

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

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.  What happens if we have a doublet 
that violates the rule?  How are the two elements combined?  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 and 
at least recommendations for handling data that break the rules 
suggested.


- 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.  My understanding of the coordinate and spectral 
standards is that they do not include masks (to which GTIs 
correspond).  We might well want a standard to describes masks in 
general or GTIs in particular, but it shouldn't be this one.

		Regards,
		Tom McGlynn