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.)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20101020/5e85bbd9/attachment-0001.html>
Received on Wed Oct 20 2010 - 16:34:55 BST
