Dear All,
I totally agree with Heiko's words of caution. In my experience (over 30 years of oceanographic data management) duplicated information inevitably leads to inconsistent information.
Cheers, Roy.
Please note that I now work part-time from Tuesday to Thursday. E-mail response on other days is possible but not guaranteed!
-----Original Message-----
From: CF-metadata [mailto:cf-metadata-bounces at cgd.ucar.edu] On Behalf Of Heiko Klein
Sent: 15 January 2013 09:09
To: Aleksandar Jelenak - NOAA Affiliate
Cc: cf-metadata at cgd.ucar.edu
Subject: Re: [CF-metadata] New standard name: datetime_iso8601
Hello Aleksandar,
I've seen some files which did such duplication, even if they haven't been CF-compliant. If it doesn't need to be machine-readable, you can put that information where-ever you want and you don't need a standard_name for that.
But I can only give a warning for duplication: The worst file I've got had the time in the filename, time in an attribute and time as a
coordinate-axis: None of the three matched.
Heiko
On 2013-01-15 04:54, Aleksandar Jelenak - NOAA Affiliate wrote:
> Hello Nan, Chris:
>
> I am not proposing that time coordinate variables can also be ISO 8601
> datetime strings. The description for this standard name clearly
> states:
>
> "
> Variables with this standard name cannot serve as coordinate variables.
> "
>
> I am merely proposing a standard name for those who are willing to
> spend a few more kilobytes of their CF-netCDF files on duplicating
> time data as ISO 8601 strings.
>
> -Aleksandar
>
>
> On Fri, Jan 11, 2013 at 4:37 PM, Chris Barker - NOAA Federal
> <chris.barker at noaa.gov> wrote:
>> On Fri, Jan 11, 2013 at 9:00 AM, Aleksandar Jelenak - NOAA Affiliate
>> <aleksandar.jelenak at noaa.gov> wrote:
>>
>>> Here's the modified proposal for the datetime_iso8601 standard name:
>> ...
>>> String representing date-time information according to the ISO
>>> 8601:2004(E) standard.
>>
>> I think we should NOT adopt a string option for datetime variables.
>>
>> To quote Jonathan Gregory:
>>
>> """
>> In CF we have always applied the
>> principle that we only add to CF when there is a need to do so, i.e.
>> there is a use-case for something which cannot already be represented
>> in CF """
>>
>> We already have a way to encode datetimes in CF-netcdf.
>>
>> I believe this proposal resulted from the discussion about adding a
>> more flexible approach to datetimes in the CF Data Model. I think
>> that's a good idea, but separate from what encoding is used in
>> CF-netcdf. ( see my recent note for more detail about the difference
>> between and encoding and a data model ).
>>
>> 1) Having multiple ways to encode the same data in file format adds
>> complication to all client code -- client code would need a way to
>> process both ISO strings and "time_unit since datetime"
>>
>> 2) Any client code that can process ISO strings is likely to need to
>> convert them to a client-specific datetime representation anyway, in
>> order to plot, calculate with, etc them.
>>
>> 3) Any client library that can process ISO strings is very likely to
>> be able to also work with "time_unit since datetime" encoded data
>> anyway -- and it had better, as that encoding is part of the standard
>> anyway.
>>
>> As a result, we would be complicating client code, and getting no new
>> functionality.
>>
>> The one advantage I can see at the moment is that simple,
>> non-CF-aware clients, like ncdump, could easily present a nice
>> human-readable format. But I don't think that is worth the additional complication.
>>
>> -Chris
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
Dr. Heiko Klein Tel. + 47 22 96 32 58
Development Section / IT Department Fax. + 47 22 69 63 55
Norwegian Meteorological Institute http://www.met.no
P.O. Box 43 Blindern 0313 Oslo NORWAY
_______________________________________________
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.
Received on Tue Jan 15 2013 - 02:13:34 GMT
