[fitswcs] [fitsbits] Version 0.981 of the WCS Time Standard Draft
Lucio Chiappetti
lucio at lambrate.inaf.it
Wed Feb 13 10:12:16 EST 2013
It is my turn to comment on the latest draft of the WCS Time paper. I
agree with most of the comments made recently, in particular the typos and
formal matters which have been spotted.
I'll intervene only about a few (most already mentioned), starting from
the less important. The first two are my own, the other depend on comments
from Mark and/or Bill.
--------------------------------------------------------------------
*) abstract and section 1
the issue of the "four" WCS papers of which this is the "fifth" has
already been addressed. The papers "incorporated by reference" are
indeed four (section 8 of the standard), however the HEALPIX paper
has never been formally numbered as "WCS Paper IV" ... but it looks
like the numbering has been de facto abandoned.
--------------------------------------------------------------------
*) (status of) section 4.7
the GTI "convention" is a sensible and widely used one. However it
belongs more to the "convention registry" than to the standard itself
(if we keep to the practice followed so far ... if there are good
reasons to deviate, and make it a convention "more equal" than the
other, please talk now ... otherwise I'm afraid it should be moved
to the non-prescriptive part of the paper)
--------------------------------------------------------------------
On Fri, 8 Feb 2013, William Pence wrote: (marked WP)
On Fri, 8 Feb 2013, Mark Calabretta wrote: (marked MC)
*) formalities about which parts of the standard
MC> Sect. 1:
MC> "The prescriptive part of this standard is contained in Sections 2,
MC> 3, 4, and Appendix A."
MC>
MC> Section 2 only contains the terms of reference which are not
MC> prescriptive.
MC>
MC> Conversely, Sect. 6.2.1 is prescriptive, but probably should be
MC> moved somewhere into Sect. 4.
section 2 is however necessary for the understanding of the truly
prescriptive sections, so fits nicely "in the standard".
I interpreted 6.2.1 as a mere summary of statements made previously,
but if not then should be moved
--------------------------------------------------------------------
*) Sect. 4.1.3:
MC> The values defined for TREFPOS in Table 3 vary from those defined
MC> for SPECSYS and SSYSOBS in Paper III and use US spelling.
MC>
MC> By the simple expedient of ignoring all but the first 3 characters,
[...]
WP> I like this idea of only treating the first 3 characters as significant
WP> and ignoring any optional trailing characters. [...]
I like the three-letter coding too.
BTW, should we make them case-insensitive ?
--------------------------------------------------------------------
*) Sect. 3.4:
MC> The requirements (a) for doublet time values to be split into
MC> integer and fractional parts, and (b) for them to be of the same
MC> sign, seem unnecessary and unwarranted to me. I expect they will
MC> be the first parts of this proposal to be violated in practice.
I'm quite surprised by this statement
WP> I suggest changing the text so that it merely *recommends* that both
WP> have the same sign to avoid ambiguities. It is just common sense to
WP> represent the value -3.123456789 as -3.0 plus -0.123456789 rather than
WP> -4.0 plus +0.87654321,
It is like the case of declination ... 5:59:59 = 5.9997(2) deg
and -5:59:59 = -5.9997(2) deg
Since all times are *relative* to MJDREF/JDREF/DATEREF, they can in
principle be either on the positive or on the negative side of the
reference time (as the CRPIX CRVAL may even be outside an image),
although I'd personally chosen a more restrictive way (like having the
reference time equal to 0 UT of the same day of the first time bin in
a light curve, so that all relative times were on the positive side).
But making the integer and fractional parts with different signs
seems just confusing to me.
The fact that two elements of a doublet are the integer and fractional
parts (*in the chosen unit*) is a different story. Personally I would
have considered times as integer counters with 2**-n s resolution on
the LSB ... but I would have split them so that the most significant
element had 2**0 = 1 s resolution, i.e. effectively integer seconds
and fractions of seconds. Having an arbitrary split elsewhere will be
... just arbitrary !
I am NOT asking to reconsider (from pair of doubles to pair of
integers). I am just noticing there are many possible ways of
handling times (and possibly different ones have actually been
used in the past) ... but the purpose of defining a standard
(badly needed since a long time !) should be a way of cutting
down the possibilities and TAKING A CHOICE. So I am contented
with 0.981 as it stands.
Then there is the issue of "Once FITS forever FITS" ... but
defining the (new) standard will not invalidate existing files
*as FITS files* ... simply they would not be consistent with
FITS time files created after acceptance of the standard.
--------------------------------------------------------------------
*) Sect. 4.1.2:
MC> The handling of MJDREF and JDREF could be improved significantly by
MC> relaxing the current requirement that the high-precision forms be
MC> split into integer and fractional parts.
[...]
MC> If this conflicts with current usage then the keywords can easily
MC> be renamed.
WP> The X-Ray community has used this FITS convention for a couple
WP> decades, so it would be dangerous to reuse [M]JDREFI or [M]JDREFF with
WP> a different meaning.
In principle Mark is correct. The "loosely-typed" nature of FITS
keywords, which are not linked to a strict association to a REAL*4
or REAL*8 should allow to define a date of arbitrary precision e.g.
JDREF = 2456337.126527778
In practice however the reader should probably parse the value
into integer and fractional parts before using it. So both ways
(JDREF vs JDREFI/JDREFF) are ultimately equivalent.
It might be the case to force one among many possibilities, as
said above, but one has to consider whether this violates the
OFAF principle, or simply if this might be an inconvenient for
a large number of existing files ...
--------------------------------------------------------------------
*) Sect. 4.3.1:
MC> "It is sometimes convenient to be able to apply a uniform clock
MC> correction in bulk by just putting that number in a single
MC> keyword."
MC>
MC> A global time reference point is already defined, and in
MC> triplicate for good measure: MJDREF, JDREF, and DATEREF.
[...]
MC> This multiplicity of ways of doing what are essentially trivial
MC> operations just makes it easier to get things wrong.
I tend to agree with Mark ... but I'm sorry this is not of much use
for the paper :-)
--------------------------------------------------------------------
*) Sect. 3.1:
two different sorts of argument under this heading ...
... the first is about a "datetime" type per se
... the second about "if and when" statements
MC> "In this paper we will use datetime as a pseudo data type to
MC> indicate its use. Following the current FITS standard (Pence et
MC> al., 2010) its values must be written as a character string in A
MC> format, but if and when an ISO-8601 data type is adopted, it
MC> should be used in table columns, rather than the string type."
MC> If an ISO-8601 data type is ever going to be defined (by and for
MC> FITS) then this paper is the place to do it.
[then continues proposing examples like array of 6 reals, or 5
integers and 1 real]
I've used myself 7-integer arrays y m d h m s f (with fraction
in 1/100 s) as a form of time *representation* but I would not
have considered them as a way of "internal representation" or
"binary representation", not more than I would consider BCD
instead of IEEE floats :-)
My own internal choice at the time was "Unix 1970" (Posix)
time (which has the known shortcomings described in 4.1.1
of the paper), as reference times. And elapsed 2**-n s from
the reference for individual times.
A running (unsegmented ?) sequence of seconds is a suitable binary
representation for "datetimes" for purposes not requiring
sub-second resolution (timestamps in databases).
So in principle in FITS we would have needed only one new
(binary) data type, i.e. "time", a running (unsegmented)
sequence of seconds (as floats with arbitrary resolutions).
The closest approximation to it (given all "external" constraints)
is what proposed in 3.4 i.e. 2D doublets of relative times
with respect to a reference.
We could as well call these 2D (with the *fixed* split at
integer/fraction, see discussion above) as the "time data type".
And the reference time, due to the foresight of the FITS fathers
(:-) smile but not ironic) is stored as an ASCII string in a
loosely-typed, arbitrary resolution header kwd, either as [M]JDREF
or DATEREF.
Which is *correctly* referred to as a "pseudo data type".
For me, ISO-8601 strings pertain correctly to header keywords (for
which all types are "pseudo"). If one thinks of a binary table
then I would never consider storing individual times as 19-char or
longer ISO-8601 strings, so for me it is not a TFORM but a TDISP,
a format for display !
However, even I would probably never use an ASCII table instead
of a binary table, ASCII tables are not ruled out, nor 20A
columns in binary tables are ruled out.
That is, even if I'd done perhaps differently, I could be
contented with the current wording of 3.1 and 3.4 (but for
the 'if and when' portions, see below).
WP> I think these "if and when" type statements have no place in a
WP> reference standards document. [...] I think the presence of these "if
WP> and when" statements in the paper serve no useful purpose and will
WP> lead to continued diversionary debate as we proceed through the formal
WP> approval process of this FITS paper, and therefore should be deleted.
The same applies to the other "if and when" at the end of section 3
(about 128-byte floats).
I tend to agree with Bill.
(although to be honest there have been cases, e.g. in the BINTABLE
paper, of features present in the paper and not part of the standard,
or which only later became part of the standard)
WP> If one wants to propose a new datetime data format for FITS, then I
WP> think this should be done separately so as to not further delay the
WP> completion of this Time WCS paper.
The argument in favour of prompt publication (and standard
endorsement) of this paper is indeed strong.
However, to be realistic, one shall say that, if we have to define
a time data type ... either we do it now or we postpone it to a
far future.
As said above, I do not consider we need a "datetime" type (which is a
TDISP for me). We might need a "time" type (or "high resolution
time"), and that could simply be the 3.4 2D case with strict rules on
it, cutting out variants and possible choices.
Let's look forward to a prompt freezing and submission of the paper !
--
------------------------------------------------------------------------
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
------------------------------------------------------------------------
Italian Research STILL at risk. La Ricerca italiana TUTTORA a rischio !
see http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/nobrain3.html cfr
More information about the fitswcs
mailing list