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: ngalbraith at whoi.edu
> Cc: cf-metadata at 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.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=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 at cgd.ucar.edu
> > http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
Received on Fri Jan 18 2013 - 06:59:39 GMT
