Nan and Chris, > 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.
Yes, since version 4.2, ncdump has supported the "-t" and "-T" options for showing dates and times in human-readable and ISO-compliant format, respecting the "calendar" attribute for interpreting dates. Thanks to an idea from Phil Bentley and some code contributed by Dave Allured, those options also work for bounds attributes that are times. --Russ > 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.jele...@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 * > ******************************************************* > > > > _______________________________________________ > CF-metadata mailing list > CF-metadata@cgd.ucar.edu > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
