[fitsbits] 64-bit integers

[William Thompson]

I was asked to document the application which requested the 64-bit integers. 
Here's the response that was sent to me.

> the time values that I am using range between few microseconds up to about
> 109-1010 microseconds (approximately the number of microseconds in one day).
> With such a range, using a double precision float variable that has a
> total number of 8 digits, I will lose the microsecond resolution after
> about one hour (3.6*109 microseconds).
> 
> Since the long64 variables are not yet introduced in the FITS standard, I
> am switching into splitting the long64 into a second and a microsecond counter.

I also have some thoughts of my own on encoding time values, which I previously 
sent to one person, and now want to share with the whole group.

I've worked with similar applications where numbers representing time needed to 
be decoded from spacecraft telemetry.  Typically, these are stored in a certain 
number of bits within the telemetry stream, e.g. 40 or 48 bits.  Usually, the 
first 32 bits represent the number of seconds from some reference epoch (often 
from 1-Jan-1958), while the remaining bits represent the fractional time.  The 
spacecraft I've worked with only digitize their time to about ~1 millisecond 
accuracy, which requires about 10 additional bits.  To get to microsecond 
accuracy requires 20 additional bits, for a total of 52 bits.

I've always considered such bit patterns to be fixed point arithmetic, and 
convert them into floating point numbers with units of seconds.  An IEEE 
floating point number has 52 bits for the mantissa, which is just barely enough 
to encode a TAI time value to microsecond accuracy.  Since I've only ever had to 
worry about it to millisecond accuracy, this tight fit has never worried me.  I 
would worry, though, if I had to depend on all 52 bits being maintained in the 
conversion between integer and floating point.

William Thompson