>> DateTime (ISO8601), Elapsed Mission Time (seconds), Sensor Time
>> (ISO8601), Sensor Date (ISO8601), Day-of-Year
>> Data Record:
>> 2008-08-18T18:57:55.79, 8403.33, 12:12:11,2008-08-18,262
>>
There's a fairly complete (maybe too complete) discussion of CF time at
http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.3/cf-conventions.html.
John's raised a couple of separate questions, one on time storage and
one or more on names for secondary time parameters.
ISO8601 times/dates are not numeric fields, and would have to be
stored as strings in NetCDF. It's easy enough to translate them into
and out of the ISO format if you want to display them, plus you can
actually *use* them if they've been converted to numbers in your
NetCDF file.
We're using ISO8601dates/times for global attributes in the oceansites
project, the idea being that we can easily generate a catalog using the
header fields. If you're talking about something like that, a metadata
field rather than a variable that has time as one of its dimensions,
that's
a bit different. Maybe those attributes should have standard names, in
the long run - there are not too many standard names for global attributes
in CF yet.
The 'elapsed mission time' and 'day of year' fields look like redundant
parameters, since they can easily be gotten from the time word, although
you'd need a 'mission start time' as a global parameter to get the elapsed
time. The need for 'day of year' disappears as soon as you store your
dates
and times as CF time - it's so easily extracted.
I agree that it would be useful to have a standard name to indicate a
sensor time, but it would be a good idea to discuss the purpose a little
more. Is it going to be used to indicate a clock drift, i.e. that the time
in 'DateTime' (or, in CF, time) is an absolute, or at least a 'corrected'
time, and this sensor_time is an indication of clock drift in an instrument?
Or would it be used for data where there's a nominal time base and multiple
sensors that actually have a separate, valid sample time? Does one
standard
name cover both of those cases?
Cheers -
Nan
> ...
>
> Could the third and fourth fields (sensor date and time) be combined and
> encoded as a single time-since-ref variable? We could give it a new standard
> name e.g. sensor_time. I'd prefer that to adopting ISO8601 as a completely
> different way of encoding time in CF.
>
>
>> The fifth field is at least a 'days since' format, though the
>> reference point will have discontinuities every new year. I'm a little
>> at sea as to whether this can be called 'time' or not.
>>
>
> Yes, I think it would be a time - but what is it? Is just repeating the
> sensor date, in effect?
>
Received on Thu Oct 23 2008 - 18:32:08 BST
