Hi all -
> One way in which they are different is precision. A value of "x seconds
> since y" has no implied precision - typically in programs we take the
> precision to be milliseconds, but there's nothing to suggest this in the
> actual metadata (anyone who tries to populate a GUI from CF metadata
> struggles with this). Semantically it's a time instant; i.e. an
> infinitesimal position in a temporal coordinate reference system.
> However, an ISO8601 string can have various precisions. (The string
> "2009-10" is not considered equivalent to "2009-10-01T00:00:00.000Z".)
The precision in "x units since y" relies on the units and on the
format of y; there seems to me to be plenty of implicit information
about the precision of "days since 1990-01-01" , vs "seconds
since 1990-01-01 00:00:00.00".
I'm not sure if UDUNITS allows the short format for the reference date,
and I haven't been able to find a description of the permitted formats in
the UDUNITS docs; there's not much in the CF docs about it either, beyond
some examples (which all use a complete date/time).
Does anyone know what formats UDUNITS allows in this field? It
seems likely that Unidata would want to follow ISO in this convention,
but maybe not.
Maybe we're all using "seconds since" a reference date, but
there's nothing to prevent us from indicating lower resolution
by using "minutes since" or "hours since" instead (other than,
in my own case, sloppy programming habits). The CF docs warn
against using month or year in this field, but it's not illegal and,
in some cases, it would probably give a more accurate reflection
of the true meaning of the time word than "seconds since" does.
Either of these seems more useful than storing time as a string.
Although I always use "seconds since", I do write both precision and
accuracy as attributes of the time variable in our NetCDF files, mainly
to document instrument clock characteristics. If that's not legal in
CF, I'm very surprised. We also use the Fortran_format attribute,
although I have no idea if that's still used in ncdump.
Cheers -
Nan
> > From Wikipedia (http://en.wikipedia.org/wiki/ISO_8601):
>
> "For reduced accuracy, any number of values may be dropped from any of
> the date and time representations, but in the order from the least to
> the most significant. For example, "2004-05" is a valid ISO 8601 date,
> which indicates May (the fifth month) 2004. This format will never
> represent the 5th day of an unspecified month in 2004, nor will it
> represent a time-span extending from 2004 into 2005."
>
> I've argued before in a previous thread on this list that it would be
> good to be able to specify the precision of time coordinates in terms of
> calendar date/time fields (which isn't the same thing as providing a
> tolerance value on the numeric coordinate value of a time axis).
>
> I'm not saying that we should definitely allow time strings in CF, just
> pointing out that they have some use cases we currently can't fulfil.
> I'm not sure they are definitively "bad practice" in all cases.
>
> (Regarding a technical point raised below, yes, it's a pain to represent
> variable length strings in NetCDF, but there is a maximum length for
> ISO8601 strings.)
>
> Hope this helps,
> Jon
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Lowry, Roy K
> Sent: 20 October 2010 10:00
> To: Ben Hetland; cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for satellite obs data
>
> Dear All,
>
> As others have said, I think this debate is irrelevant as there should
> be no need for string timestamps in NetCDF. Providing a Standard Name
> only encourages what I consider to be bad practice.
>
> Cheers, Roy.
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Wed Oct 20 2010 - 13:55:01 BST
