[CF-metadata] date and time

From: Jonathan Gregory <j.m.gregory>
Date: Fri, 24 Oct 2008 08:37:36 +0100

Dear John

I generally agree with your summary.

> I think it's fair to say that the Standard Name only implies a format
> restriction in the context of a COARDS/CF file.
Yes.

> 'time' is a representation of any chronological parameter, even if
> just a day or a year; typically it represents a system time.'
I would use the standard_name "time" for the geophysical parameter of time in
the real world, the temporal coordinate of the geophysical parameters that
are being reported. This quantity, like other geophysical parameters, may have
to be obtained by processing or correcting various measurements.

I would advocate introducing other standard names with "time" in them, such
as forecast_reference_time, for quantities which have the form of time but
are not the actual time coordinate of the data.

> 'sensor_time' is any chronological parameter produced by a sensor;
> with similar constraints in a netCDF COARDS/CF file. (I guess
> sensor_time is a type of time.)
Exactly. It doesn't have to be "sensor_time". It depends what you and others
think is the right name.

> In a netCDF COARDS/CF file, a 'time' value must be be expressed as a
> "period of time since an epoch".
Yes. That's the convention we have adopted.

> The following variables are not fit for COARDS/CF, and thus can not
> have a CF standard name in that context:
> - Any time parameter that is expressed using the Gregorian calendar
> (because these are in a new format)
You mean expressed in components year, month, date etc. Yes, that's right,
but they can always be encoded as time-since-ref format.

> - Any time parameter whose reference epoch changes over the course
> of the data set (e.g., yearly, or daily)
I think we could define other standard_names for such time-like quantities
of the form time_since_EVENT if they are needed.

Cheers

Jonathan
Received on Fri Oct 24 2008 - 01:37:36 BST