Subject: Question about a fits header

From: alspehr at mhd3.uchicago.edu (Alanna Spehr)
Date: Wed, 4 Sep 1996 19:00:58 GMT

I have fits files that have:

OBS_TIME=                52917

in their header. (Along with OBS_DATE and DATE, if it matters.)
Can somebody tell me what the 52917 is, and how I can change it
to something more useful? Or, is there someplace that would 
document things like this?

Thanks

Als

---

From: sla at umbra.ucolick.org (Steve Allen)
Date: 5 Sep 1996 07:31:55 GMT

In article <Dx825M.3vy at midway.uchicago.edu>,
>document things like this?

Not having an answer to this question, I pose another:

Documenting the semantics and syntax of all FITS keywords would
require a community-wide effort involving every site which has written
a FITS file.  Let us assume that it be possible to gather FITS keyword
characteristics (semantics, format, units, defining authority, dates
of use, etc.)  into a database which be globally updatable and
queryable via the WWW.

How valuable might such a database be?
--
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: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 4 Sep 1996 20:06:40 GMT

>document things like this?

Just as a guess, the number of seconds into the day?  That would work out to
14:41:57.  This sort of convention should be explained as a comment, e.g.

	OBS_TIME=                52917	/Seconds into the day (UTC)

Note, by the way that there isn't any ambiguity about an ISO-8601 entry such as

	DATE_OBS= "1996-09-04T14:41:57.000Z"

Bill Thompson

---

From: Patrick Wallace <ptw at star.rl.ac.uk>
Date: Fri, 6 Sep 1996 10:16:38 +0100 (BST)

On Wed, 4 Sep 1996, Alanna Spehr wrote:

> to something more useful?

My guess is it's a Modified Julian Date (JD-2400000.5).  A procedure
for turning an MJD into year, month, day is appended.  There are
other ways of doing it (see the Explanatory Supplement to the
Astronomical Almanac).

Patrick Wallace
____________________________________________________________________________
Starlink Project Manager                        Internet:  ptw at star.rl.ac.uk
Rutherford Appleton Laboratory                       Tel:    +44-1235-445372
Chilton, Didcot, Oxon OX11 0QX, UK                   Fax:    +44-1235-445848
____________________________________________________________________________

      SUBROUTINE sla_DJCL (DJM, IY, IM, ID, FD, J)
*+
*     - - - - -
*      D J C L
*     - - - - -
*
*  Modified Julian Date to Gregorian year, month, day,
*  and fraction of a day.
*
*  Given:
*     DJM      dp     modified Julian Date (JD-2400000.5)
*
*  Returned:
*     IY       int    year
*     IM       int    month
*     ID       int    day
*     FD       dp     fraction of day
*     J        int    status:
*                       0 = OK
*                      -1 = unacceptable date (before 4701BC March 1)
*
*  The algorithm is derived from that of Hatcher 1984
*  (QJRAS 25, 53-55).
*
*  P.T.Wallace   Starlink   23 November 1994
*
*  Copyright (C) 1995 Rutherford Appleton Laboratory
*-

      IMPLICIT NONE

      DOUBLE PRECISION DJM
      INTEGER IY,IM,ID
      DOUBLE PRECISION FD
      INTEGER J

      DOUBLE PRECISION F,D
      INTEGER JD,N4,ND10

*  Check if date is acceptable
      IF (DJM.LE.-2395522D0.OR.DJM.GE.1D9) THEN
         J=-1
      ELSE
         J=0

*     Separate day and fraction
         F=MOD(DJM,1D0)
         IF (F.LT.0D0) F=F+1D0
         D=NINT(DJM-F)

*     Express day in Gregorian calendar
         JD=NINT(D)+2400001

         N4=4*(JD+((6*((4*JD-17918)/146097))/4+1)/2-37)
         ND10=10*(MOD(N4-237,1461)/4)+5

         IY=N4/1461-4712
         IM=MOD(ND10/306+2,12)+1
         ID=MOD(ND10,306)/10+1
         FD=F

         J=0

      END IF

      END

---

From: "Thomas A. McGlynn" <tam at silk.gsfc.nasa.gov>
Date: Mon, 09 Sep 1996 10:59:47 -0400

> other ways of doing it (see the Explanatory Supplement to the
Alas, MJD 52917 is about 7 years in the future.  I think
you need to get in touch with whoever wrote the FITS file
to find out what it means.
		Tom McGlynn

---

From: seaman at noao.edu (Rob Seaman)
Date: 10 Sep 1996 17:30:07 GMT

Bill Wyatt (wyatt at cfahub.harvard.edu) writes:

> Since there are 86,400 seconds in a day, and there was a DATE keyword,
> 52917 is surely is the second of the indicated day.

But is it UT or local time?  This corresponds to 14:41:57 or ~ 2:42 PM
if it's local time.  One can probably safely assume standard rather than
daylight savings time.

Note, however, that "52917" can also be interpreted as a legal ISO 8601
time string, representing ~ 5:30 AM, local time (no "Z", so not UT).
I don't know what ISO 8601 says about daylight time.

At least, as best I can tell it's legal to omit the leading zero for
the hours field.  The only constraint I see in the web summaries of the
standard is that the time cannot be truncated from the left - but only
when the combined date/time format is used, otherwise hyphens are used
as place keepers for missing fields.  The "T" is optional if the usage
is clear from the context (the name of the keyword is "OBS_TIME").

Does anybody have an official copy of the ISO 8601 standard that they
can bring to the ADASS meeting?  We may want to consult it before we adopt
it into FITS...  Hopefully the standard itself is more clear about issues
like omitting leading zeroes than the summaries are.

One concern I have about the ISO standards is that it is rather hard to 
find a copy without buying one yourself.  For instance, the University
of Arizona library doesn't appear to have a copy.  There may not be a
copy anywhere in Tucson - or Arizona, for that matter.  On the other
hand, the FITS standard has been propagated around the world wherever
there are copies of the A&A Supplements - or you can just get the
documents off the web.

The answer to the original question, by the way, is that only the authors
of this particular FITS file (or of the software that produced it) will
be able to reliably define what "OBS_TIME" means, since this is not a
standard FITS keyword.  If the authors can't be consulted, then reality
checks such as that optical/near IR data (not calibrations) must have
been acquired during local nighttime are about all you have to go on.
An hour angle or airmass keyword can be converted back into a sidereal
time if you have the telescope coordinates (celestial and geographic).

Rob Seaman
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B

---

From: wyatt at cfahub.harvard.edu (Bill Wyatt)
Date: Tue, 10 Sep 1996 15:21:07 GMT

Thomas A. McGlynn (tam at silk.gsfc.nasa.gov) wrote:
: >Patrick Wallace wrote:
: >> 
: >> On Wed, 4 Sep 1996, Alanna Spehr wrote:
: >> 
: >> > I have fits files that have:
: >> >
: >> > OBS_TIME=                52917
: >> >
: >> > in their header. (Along with OBS_DATE and DATE, if it matters.)
: >> > Can somebody tell me what the 52917 is, and how I can change it
: >> > to something more useful?
: >> 
: >> My guess is it's a Modified Julian Date (JD-2400000.5).  A procedure
: >> for turning an MJD into year, month, day is appended.  There are
: >> other ways of doing it (see the Explanatory Supplement to the
: >> Astronomical Almanac).
: >> 
: >> Patrick Wallace
: >> 
: >Alas, MJD 52917 is about 7 years in the future.  I think
: >you need to get in touch with whoever wrote the FITS file
: >to find out what it means.
: >		Tom McGlynn

--
Bill Wyatt  (wyatt at cfa.harvard.edu)
   Smithsonian Astrophysical Observatory  (Cambridge, MA, USA)

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 10 Sep 1996 23:06:08 GMT

>Bill Wyatt (wyatt at cfahub.harvard.edu) writes:

	(stuff deleted)

>there are copies of the A&A Supplements - or you can just get the

Yes, the ISO-8601 standard costs money, but I believe that the CCSDS
recommendation, which is a restricted subset of ISO-8601, is free.  I've posted
that recommendation in the past.  In any case, it's probably better to restrict
the ISO-8601 standard to a sane subset, rather than try to implement
everything.

Bill Thompson