Time of course

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: Time of course
• From: ethan@xxxxxxxxxxxxxxxxxx (Ethan Alpert)
• Date: Wed, 12 Feb 1992 16:26:10 MST

I've been following this conversation very closely and I have a question for
the NC_DOUBLE time storage proponents. I agree that the time storage should
work for storing time, but what about accessing time? Can you provide some
examples of how an application would access this time data?

Just for reference. IEEE defines a 64 bit double to have one sign bit, 11 
exponent bits and 52 mantissa bits. There is also an implied "sticky bit"
which is always set to 1 and is assumed to be left of the decimal point. 
There are three special values of the exponent; all zeros represents exact 
zero and  all ones being used to represent +- infinity


My confusion stems from not understanding how you plan to use the 52 bit IEEE
mantissa as a 52 bit integer. I understand that you simply have to use the
LSB to advance the time counter but how are you going to disable the floating 
point of the machine, so as to prevent the machine from using the exponent part
of the IEEE double. 

For example what if I start at the base (I'm assuming the base will start with 
the mantissa set to all zeros and the exponent zeroed too). The decimal value 
of this number would be 0.0. When the exponent is all zeros then the number
represents exact zero.

Now lets say I'm creating the coordinate variable and I start with the above
conditions. The first element gets the 0.0 value. For the second value I add
the LSB value to it. Here is the first hint of the problem. When I perform
this addition the mantissa is UNCHANGED and the exponent represents 2^-52. This
could be 2^-53 I'm not certain but my point should be evident. In some cases
equal mantissas could represent different coordinate time values.

Is this clear? I think this is what concerns Dan. 

The answer is to start the base at 1.0 and add multiples of the LSB to it to 
compute the values to store in the coordinate variable. This works because 
IEEE has the "sticky bit" that is always set and the binary number would look
something like the following. 

1.0000000000....1
^               ^
Sticky bit      LSB


It is important to note that one can only add to and subtract from the base. 
Multiplication and Division must not be used because the CPU will use set the 
exponent of the double. Furthermore, when computing multiples of the LSB to
add to the base only integer mulipliers should be used. This seems like a lot
to require the average user to know, remember and think about.

Finally, if I want to select the first 10 milliseconds of June 1st for a ten
year period from within my own application how would I do this. The conversion
from the floating point representation would appear to be kind of mind twisting,
when taking into account leap years and irregular month spacing. How will 
generic applications handle this? More discussion is needed on accesing time
data once its stored in the NC_DOUBLE format? Can a conversion utility library 
be developed to handle this? 

        -ethan