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
Received on Tue Jan 15 2013 - 02:09:17 GMT
