[CF-metadata] New standard name: datetime_iso8601

From: Aleksandar Jelenak - NOAA Affiliate <aleksandar.jelenak>
Date: Mon, 14 Jan 2013 22:54:48 -0500

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
Received on Mon Jan 14 2013 - 20:54:48 GMT