While expressing precision in CF is an interesting issue, in this case
the Wikipedia quote is using the term in a different sense than I
(hopefully we) usually mean -- ISO8601 lets one express time intervals
succinctly in a single string, e.g. 2010-09 to mean all of september
2010, which is not an accuracy issue, it is a precise specification of
a larger interval. It lets you write 2010-09-01/10-05 as well, i.e.
it is not limited to intervals that involve special notational
boundaries. As Steve points out CF expresses this using a bounds
coordinate, i.e. giving the precise edges of each interval. Of
course, how the data is actually related to that interval is where the
notion of precision might come in, which cell methods/measures
addresses, perhaps inadequately for the purpose at hand.
ISO8601 is quite neat in the sense that it forces one to always
specify an interval, and CF software reading time bounds data and
rendering ISO8601 strings would do us all a lot of good.
Benno
On Wed, Oct 20, 2010 at 6:34 PM, Steve Hankin <Steven.C.Hankin at noaa.gov> wrote:
> Hi Jon,
>
> Why do you see this as an issue of date-times as ISO strings in particular?
> The same issues of precision are found in longitudes expressed as a
> degrees-minutes-seconds string compared to a floating point.? Or indeed to a
> depth expressed as a decimal string of known numbers of digits.? ("100.00"
> communicates different precision than "100" though both a represented by the
> same binary value.)
>
> CF provides the bounds attribute and the cell methods/measures to clarify
> (somewhat) these points.? What is your proposal for improved representation
> of precisions?? And wouldn't a general improvement in how to specify
> coordinate precision be preferable to a solution that applies to time, only?
>
> ??? - Steve
>
> =============================
>
>
> On 10/20/2010 9:41 AM, Jon Blower wrote:
>
> Hi all,
>
> I haven't followed this debate closely, but I've had cause to do a fair
> amount of thinking (outside the CF context) on the pros and cons of
> identifying date/times as strings or numbers. I could probably write a
> very boring essay on this but in summary, they are not exactly
> equivalent ways of representing the same information.
>
> 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".)
>
> >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.
>
> -----Original Message-----
> From: cf-metadata-bounces at cgd.ucar.edu
> [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Ben Hetland
> Sent: 20 October 2010 09:14
> To: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] New standard names for satellite obs data
>
> On 19.10.2010 16:27, Seth McGinnis wrote:
>
> What about using 'date' for string-valued times? That was my homebrew
> solution when I was considering a similar problem.
>
> If I may butt in and contribute here, I usually prefer names like
> 'datetime' or 'timestamp' in cases like this, because 'date' is
> potentially confusing. It may not be immediately obvious to a future
> reader (or programmer) that a variable called 'date' supports points in
> time down to for example seconds of accuracy.
>
>
> (Note that string data is a big pain to deal with in NetCDF-3, because
> you're limited to fixed-length character arrays. You need to use
> NetCDF-4 / HDF5 to get Strings as a data type.)
>
> (It may not be such a practical issue with ISO 8601 strings, as a
> reasonable max. length can be determined, I presume.)
>
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
--
Dr. M. Benno Blumenthal? ? ? ? ? benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000?? (845) 680-4450
Received on Thu Oct 21 2010 - 08:43:29 BST
