Hi Jon, I prefer handling the precision issue through a format mask attribute. I usually hit this problem in Oracle with the 'date' data type (in say column X), whose format I control by also storing an Oracle date/time format string (say in column Y). Formatted date/time to the appropriate precision is then obtained using the function to_date (X,Y).
Something similar should surely be possible in CF with a binary time channel, an ISO-8601 template (parameter attribute?) and an interface function. Cheers, Roy. ________________________________________ From: cf-metadata-boun...@cgd.ucar.edu [cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jon Blower [j.d.blo...@reading.ac.uk] Sent: 20 October 2010 14:41 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] New standard names for satellite obs data 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-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Lowry, Roy K Sent: 20 October 2010 10:00 To: Ben Hetland; cf-metadata@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-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Ben Hetland Sent: 20 October 2010 09:14 To: cf-metadata@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.) -- Regards, -+-Ben-+- _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata