Subject: Re: WCS Proposal

From: Arnold Rots <arots at xebec.gsfc.nasa.gov>
Date: Wed, 15 Nov 1995 12:42:33 -0500 (EST)

The G&C WCS proposal pulls together many loose ends in FITS convention
land.  In the process it formalizes things that everybody has used;
unfortunately, the proposed conventions do not always coincide with the
various practices in different sectors of the astronomical community.
I am not talking about the coordinate systems themselves, but about the
auxiliary conventions - in particular the ones dealing with time.

I am sure not everybody is fully aware of these implications.  Since
the WCS proposal offers us a chance to set a number of things straight,
we should look very carefully at the conventions proposed by G&C: make
sure they follow common practice and, if there are differing practices,
define a way to specify these differences.

I recognize that G&C really address celestial coordinates and that
time only comes in because of the time variable aspects of this, such
as precesssion, nutation, etc.  However, whether we intend this or not,
sooner or later images that have a time stamp will be used by somebody
who is interested in time variable phenomena, such as supernovae or
proper motions.  That being the case, we should make a reasonable
effort to make it clear what we are talking about.  The problem is
that in this area there have been conflicting practices.  I feel that
we, therefore, should deal with these issues in a general way, trying
to conform as much as possible to existing practices.  Steve Allen has
voiced similar concerns on fitsbits.

Another way to put this is that time obviously is being dealt with
more systematically in conventions used for specific time series
data files.  At the very least, we should make sure that the conventions
are consistent.  As it stands, this is not the case.

Against this background, I would like to make two specific proposals.

1. As implied by G&C, the old DATE-OBS keyword does not allow enough
flexibility or precision.  We should be cognizant, though, that
certain sectors of the community have solved this by adding the
keywords TIME-OBS, DATE-END, and TIME-END, specifying that DATE-OBS
and TIME-OBS refer to the start of the observation(s).

1a. I think it would be good to recognize this practice as a valid
way of specifying the precise epoch.

1b. I also think that providing an MJD-based alternative is a good
idea, but in order to avoid any confusing as to whether the -OBS
appendix refers to the start, middle, or end of an observation, I
would propose to use the specific keywords MJD-BEG, MJD-AVG, and/or
MJD-END.

2. Mark wrote:
> G&C doesn't assume TAI, it prescribes it.
That's worse.  There are a lot of FITS files out in the community that
would otherwise be conforming with the WCS proposal, but on this
issue would be invalidated.  Besides, I would argue that, FITS being
an IAU-accepted standard, it should stick to the official IAU time
system: TT (:-).  And, as argued by Steve Allen, it would be unwise to
force TAI on older archival data.  There is also the issue of whether
any pathlength correction have been applied; i.e., the time reference
frame.

I propose that we add the following two keywords:

2a. TIMESYS
valid values: TT, TAI, UTC, UT1, ...
default:      UTC (this is a recommendation based on the suspicion
                  that UTC is the most ubiquitous system in existing
                  files that carry time with sufficient precision to
                  care about this)

2b. TIMEREF
valid values: LOCAL, GEOCENTRIC, BARYCENTRIC
default:      LOCAL (this is partly to make it very clear that there
                    is an important issue here; LOCAL means: at the
                    observatory, whether it is on the earth's surface
                    or meandering through other parts of the solar
                    system)

One might argue whether the TASSIGN keyword should be included in this.
For the uninitiated: this defines where the time tag is added to the
data.  It would, for instance, be significant for interplanetary probes:
was the time stamp attached by the spacecraft or at the time the telemetry
was received on the ground?  However, the exceptions to the usual case
(time stamps are attached at the observatory) are sufficiently rare that
we should not (have to) worry about this.

  - Arnold Rots

Mark Calabretta wrote:

> 
> 
> On Wed 1995/10/18 10:40:17 -0400, Arnold Rots wrote
> in a message to: fitsbits at fits.cv.nrao.edu
> 
> >b. What does "time of observation" mean?  The start, the middle, the
> >end, a weighted mean?
> 
> As stated in section 3, it's an average.
> 
> In the context of section 3, MJD-OBJ is provided as a timestamp for the
> observation as a whole, in particular for the calculation of proper motion in
> maps taken at two epochs.  Depending on the timescale of the observation, it
> could also be relevant to such effects as parallax, precession, nutation,
> aberration, and gravitational deflection.  As such the precision of MJD-OBS
> depends on the duration of the observation - if the observation lasted 1 sec
> then MJD-OBJ would have comparable precision.
> 
> Putting it another way, effects which vary significantly during the course
> of an observation (for example, a long exposure on a planet) should be
> accounted for in the observing process (sharp planet + smeared stars), or
> otherwise will result in some sort of blurring in the image (smeared planet +
> sharp stars).
> 
> I'm not arguing that start/stop times may not be needed (in the general case
> you could have multiple starts/stops), only that definition of the required
> keywords is outside the scope of the paper - that being the representation of
> celestial coordinates.
> 
> >c. It is unwise to implicitly assume a particular time system.  G&C
> >assume TAI; I am sure many would interpret it as UTC.  The point is
> 
> G&C doesn't assume TAI, it prescribes it.
>

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 16 Nov 1995 21:37:43 GMT

This is the way that the SOHO project uses time:

Calendar dates (segmented time):

	1.  Are always expressed in UTC

	2.  Uses the ISO 8601 format as endorsed by the Consultative Committee
	    for Space Data Systems.  For example, the current date/time would
	    be expressed as

		DATE_OBS = 1995-11-16T21:21:15.721Z

	3.  An underscore is used in the name DATE_OBS to distinguish it from
	    the standard DATE-OBS keyword.

	4.  Even when not using the CCSDS format, years are always given with
	    four digits to avoid confusion when the year 2000 rolls around.
	    Date formats with different interpretations in Europe and America,
	    such as 11/12/95, are avoided.

MJD numbers:

	1.  Are only used internally to the software.  They're never written
	    into the FITS header.

	2.  Are combined with a second number which is the number of
	    milliseconds into the day.  Thus, this is also a segmented time,
	    and is expressed in UTC.  This second time-of-day number has a
	    larger maximum value on days containing a leap second.

TAI time:

	1.  Is always unsegmented, i.e. a single number which is the number of
	    seconds since 1 Jan 1958 0h.  The above calendar time can be
	    expressed in TAI as

		OBT_TIME = 1195248104.721

	2.  Is the only unsegmented time used by us.

For either UTC or TAI time, we give both the start and end times of the
observation.

This is explained in more detail in

	http://orpheus.nascom.nasa.gov/cds/swnote/time_conversion.ps

(or .tex for the original LaTeX file).  The software refered to can be found in

	ftp://sohoftp.nascom.nasa.gov/pub/softops/cds/util/time/

William Thompson

---

From: sla at umbra.ucolick.org (Steve Allen)
Date: 18 Nov 1995 09:06:16 GMT

In article <48gav7$33t at post.gsfc.nasa.gov>,

>       1.  Are always expressed in UTC

This is not useful for data obtained prior to 1972 when UTC was
first deployed.

>           seconds since 1 Jan 1958 0h.  The above calendar time can be

It remains to be seen whether the enormous amount of archival astronomical
data stored in emulsion on glass plates will be deemed of sufficient value
to convert to digital form.  But for much of that data the specification
of either UTC or TAI as the time system is inappropriate.

Early in this century the San Jose railroad station set its clocks by
using signals telegraphed down from the Lick Observatory clock on
Mt. Hamilton.  For all plates taken during that era the observatory
was its own source of standard time.  Attempts to convert the times
of these plates to UTC or TAI for storage in FITS would not be reasonable.
--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW

---

From: Tim Pearson <tjp at solitaire.cv.nrao.edu>
Date: 21 Nov 1995 02:27:26 GMT

I have two comments on this thread:

(1) I agree that it is unreasonable to insist that all epochs (times)
in FITS files be referenced to a single system, e.g., UTC or TAI. In some
cases the conversion from the recorded time to the standard system may be
unknown (to be determineed from the data, for example). Thus we need a new
keyword, like TIMESYS, to specify the time system in cases where it matters.
'UTC' is a reasonable default.

(2) I like the use of Modified Julian Date for recording epoch. Unfortunately,
though, a large segment of the IAU does not. Here is an excerpt from
Resolution No. C3 of Commission 26, 27, 30, and 42 (IAU Information Bulletin
No.74, january 1995):

"Commissions 26, 27, 30, & 42 of the IAU ... do deplore the introduction
of the Modified Julian Day system ; ... recommend the rescinding of resolution
No.4 of the XVth general assembly of the IAU that established the Modified
Julian Day system,and recommend the continuing use of Julian Day Numbers...."

I do not know the background to this; but the argument against MJD seems to be
that the odd half-day difference between MJD and JD is "very confusing to
the users". This may be true, but it ignores the widespread use of MJD in
computer systems.  

I think that this resolution does not have the status of a resolution of the
General Assembly; but it may be brought up in the next General Assembly.

(Please, let's not discuss the merits of counting time from Greenwich noon
or from Greenwich midnight here!)

Tim Pearson, Astronomy Dept 105-24, Caltech, Pasadena, California 91125, USA
Internet:                  tjp at astro.caltech.edu, Pearson_T at caltech.edu
NSI-Decnet (SPAN):         Deimos::TJP or 15237::TJP
Telephone:                 +1 818 395-4980    FAX: +1 818 568-9352