Hi Mark, > Do the time parsing and string output options include appreciation of > the CF calendars such as 360 day? > > will a 360 day calendar enable a string of > 2012-02-30 > to be printed > while a gregorian calendar will not?
Yes. You can verify this by saving the following in caltest.cdl: netcdf caltest { dimensions: time = 1; variables: double t1(time); t1:units = "days since 2013-01-01"; t1:calendar = "gregorian"; double t1_360(time); t1_360:calendar = "360_day" ; t1_360:units = "days since 2013-01-01"; data: t1 = 59; t1_360 = 59; } Then create the corresponding binary netCDF file using ncgen, and run "ncdump -t" on it: $ ncgen -b caltest.cdl $ ncdump -t caltest.nc If you don't get output that includes t1 = "2013-03-01" ; t1_360 = "2013-02-30" ; it's time (using *any* calendar) to update your netCDF software :-). --Russ > -----Original Message----- > From: CF-metadata on behalf of Russ Rew > Sent: Mon 14/01/2013 15:56 > To: ngalbra...@whoi.edu > Cc: cf-metadata@cgd.ucar.edu > Subject: Re: [CF-metadata] New standard name: datetime_iso8601 > =20 > Nan and Chris, > > > I agree with Chris. > >=20 > > 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. > >=20 > > Thanks - Nan > >=20 > > 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=20 > > 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 > > > > > > > >=20 > >=20 > > --=20 > > ******************************************************* > > * Nan Galbraith (508) 289-2444 * > > * Upper Ocean Processes Group Mail Stop 29 * > > * Woods Hole Oceanographic Institution * > > * Woods Hole, MA 02543 * > > ******************************************************* > >=20 > >=20 > >=20 > > _______________________________________________ > > 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 > > _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata