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-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Jon Blower [j.d.blower at reading.ac.uk]
Sent: 20 October 2010 14:41
To: cf-metadata at 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-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.)
--
Regards,
-+-Ben-+-
_______________________________________________
CF-metadata mailing list
CF-metadata at 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 at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
Received on Wed Oct 20 2010 - 14:50:06 BST
