[fitswcs] FITS WCS Time Paper

[Rob Seaman]

On Mar 22, 2012, at 8:33 AM, Tom McGlynn wrote:

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

The document is a manuscript for submission to a scientific journal.  The latter aspects that motivate the standard and its usage are key elements of the paper from my point of view.  Presumably the FITS TARDIS user's manual will come later.

That said, the next draft could perhaps be edited to make it more accessible to users wanting to improve the usage of time elements in their FITS files and libraries.  Some comments along these lines:

1) I'm a big Doctor Who fan, but the subtitle may be a distraction from the seriousness of the topic.

2) That said, the Intro is a bit dry.  Perhaps the TARDIS jape could be moved here into a new topic paragraph motivating the importance of timekeeping to the science and practice of astronomy?

3) Aside: in table 2 the example leap second should be updated to June 2012.

4) Section four is the heart of the exercise and could be moved to directory follow the intro, referencing (the current) sections 2 and 3 as needed.  The point being that readers are likely to jump forward to the part they think they need (keyword semantics) and skip over the important caveats in sections 2 and 3 anyway.

5) Section four (that is, "Components of the Standard" that would become section two), should emphasize the normative statements in some way.  Perhaps a much briefer section on components of the standard followed by a separate commentary?  Or maybe surround normative statements in boxes or highlight them in bold?

6) Dozens of keywords are described in section four.  Just this fact will confuse programmers and astronomers attempting to use them.  Whatever the normative interrelationships, surely there is a notion of a minimal set, of a recommended set for some typical purpose(s), and of a (for want of a better word) maximal set?  These are discussions for section 5 on usage (or for a separate users guide), but the normative discussion should also be structured in some way to encourage good usage to those who never see anything other than section four.  Conceptually (not typographically) something like red text for keywords everybody MUST use, green for keywords everybody SHOULD use, and yellow for keywords you'd like all projects to aspire to use.

7) Proper (sorry, "Good" :-) handling of FITS time coordinates implies that a particular project has deployed and manages a timekeeping infrastructure and procedures appropriate to some scientific program.  As with other empirical dependent and independent variables marshaled in the service of instrumentation, telescopes, and data handling, what's necessary for one purpose may be insufficient for others.  This is more than a question of precision, but that may be the only handle archivists later have on the metadata.

Not to put too fine a point on it, but in my role as archive gatekeeper to large numbers of instruments of diverse origins, I've seen a lot of "interesting" metadata - and timekeeping issues are far and away the most frequent.  Whatever else is true of FITS time WCS metadata, its success in the community will depend on a certain flexibility and robustness.

This establishes an orthogonal axis to the minimal <--> maximal axis.  A project will aspire to comply with recommendations from this standard, perhaps quite detailed recommendations.  But it will fall short in entertaining ways when, for instance, the host country reschedules DST at the last minute, or an instrument's clock overflows if it isn't reset every three days, or NTP fails to sync to a local server because the client was booted first, or calibration data are taken with the telescope systems powered down, or - yes - UTC is redefined to no longer approximate UT1.

A standards document represents something of a Platonic ideal, but in this case that implies some sort of built-in Platonic notion of quality assurance.  Perhaps this is a discussion for future FITS BoFs and the ongoing time wars, but a way to paraphrase Tom's comments is that the standard is going to be confronted by real world issues and the document should be prepared for the blowback.

That said, the content of the document is quite mature and any such issues of phraseology should not delay its publication.

Rob