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.bar...@noaa.gov> 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 _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata