I agree with Chris.
Having ncdump or other clients show dates in an ISO-compliant format
is a fine idea, as is using ISO strings for dates in attributes, but those
are completely different from storing date variables as strings.
NetCDF uses a binary storage format and is not meant to be human
readable.
Thanks - Nan
On 1/11/13 4:37 PM, Chris Barker - NOAA Federal 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
>
>
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Mon Jan 14 2013 - 07:08:39 GMT
