On 2007.11.01, Rich Signell wrote:
:
: CF-folk,
:
: I'd like to find out what the community thinks of adding a
: two-variable integer representation as an acceptable way of
: representing time in CF.
In reality, it is a three variable time storage method, You're stuffing
a reference value (we call it the 'epoch', here in RAL) into the units
string of 'time'.
All three values would be required to convert to a local time string
or to compute time differences.
I'm also puzzled by the use of a seemingly arbitrary
reference time of 1968-05-23 00:00 UTC.
The day offset integer allows for +/- 547,945 years from the reference
time. Why not use 1970-1-1 00:00 as an implied epoch? Since the standard year
part is only 4 digits, we can't really represent dates outside the range
-9999-01-01 to 9999-12-31 anyway.
This time storage method would be acceptable, in my opinion, only if
conversion and difference subroutines are published. All of our data
sets currently use Unix time(s) (seconds since 1970) and make extensive
use of these values to computing time differences, and user input and
labeling using existing (Unix,perl,python, etc) Locale infrastructures.
Note that MIT and NCAR/RAL are currently working on expanding the CF
standard to include a set of attributes in CF files which will record time
fields like validity start and end times, data collection start and end
times, forecast time and generated at time.
Currently, people are using the CF time string for any one of the time
fields I mentioned. So far, it is left unspecified as to what the time
value actually represents. The start?, the middle? the end?. In the
future, CF compliance should require the use of more than one, ambigious,
time stamp.
--
Frank Hage fhage at ucar.edu
National Center for Atmospheric Research
Received on Thu Nov 01 2007 - 17:06:51 GMT
