Yes, I read the conventions section 4.4, including a few times while
preparing the question. Not too complicated, and helpful; it just
didn't address my problem, that I could see.
A point I found useful to consider is the idea that these are
secondary time parameters. When the netCDF file gets created, I
appreciate that it has a coordinate called time, which is presumably
the primary parameter. But in the original data (from which the netCDF
file is generated), it may or may not be the case that the 'primary
time' exists. (Maybe the system time becomes the primary time; maybe
some GPS sensor produces a timestamp that becomes primary time; maybe
something else will provide the key information from which time can be
established.) So is it the case that the Standard Name 'time' is
always assigned to the primary time? Or can 'time' be assigned to any
and all time parameters?
The two cases you outline seem pretty similar to me, but maybe I'm
missing something. As a general observation, the question 'how are you
going to use this' reflects an assumption that the only (or primary)
use of the netCDF files and the standard names is purposeful and
anticipatory. In fact, especially if you are dealing with observation
data, both can be strictly documentary; and of course the data can be
used in unintended ways. So it shouldn't matter how the data will be
used; I just want to know how to document what I have. (There are
reasons the different time parameters are not duplicates, which I
won't go into here; I just wanted to know how to label them, such that
generating a netCDF COARDS/CF file using those names won't bring the
wrath of CF down upon me.)
John
On Oct 23, 2008, at 5:32 PM, Nan Galbraith wrote:
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?
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:[EMAIL PROTECTED]> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project: http://marinemetadata.org
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
