🚀 go-pugleaf

In article <9210051405.AA21114@fits.cv.nrao.edu>, Lucio Chiappetti <lucio@ifctr.mi.cnr.it> writes...
>On Wed, 30 Sep 1992 17:15:10 GMT  <pence@heawk1.gsfc.nasa.gov> said:
>>
>>Here at the HEASARC we often need to express keyword values which have
>>more significant figures than can be stored in a double precision
> 
>  I actually wonder how this is SPECIFICALLY related to the example of
>  MJD discussed below, or is really general.
> 
>>A common example of this problem is the Modified Julian Date
>>which has a value something like 48043.8797453703700742
> 
>  I am inclined to think this is somehow related to the need of expressing
>  time quantities like this.
>  What I believe is needed is a way of defining some "compound" or "non-
>  primitive" data types. By non-primitive I mean they should go beyond the
>  usual CHARACTER, INTEGER, REAL and DOUBLE PRECISION supported by FITS.
>  I raised this point already in a previous posting.
>  In my view this concerns BOTH header keywords AS WELL AS data quantities
>  (e.g. columns in binary tables).
>  The sort of data types I am thinking of are quantities like :
> 

	(He goes on to describe suggested definitions of the quantities ANGLE,
	HANGLE, DATE, DATETIME, and TIME.  Definitions omitted to save space.)

I strongly suggest looking into the document "Time Code Formats" from the
Consultative Committee for Space Data Systems, CCSDS 301.0-B-2, April 1990.
This is available from

	CCSDS Secretariat
	Communications and Data Systems Division (Code-OS)
	National Aeronatuics and Space Administration
	Washington, DC 20546, USA

The topic of encoding date and time values into binary and ASCII values is
discussed there in some detail.  The suggested format for ASCII encoding is
briefly outlined below for the following example (5 Oct 1992 at 1:23:45 UT)

			   1992-10-05T01:23:45.000Z

The number of decimal places after the seconds field ("45") can be whatever is
appropriate, or can be omitted entirely.  Encoding only date, or only time,
values is also discussed.

It's always better to use a pre-existing standard than to reinvent the wheel.

On another note, I agree with Wayne Landsman that encoding the more-than-double
precision value as a character string, i.e.

	MJD     = '48043.8797453703700742'    /  MJD

is preferable to

	MJD     =      48043.8797453703700742 /  MJD

Bill Thompson