Just a very quick comment: > Could the software be ported to other languages in which the netCDF lib > exists?
The good news is that the "non-standard" calendars (360_day etc) are easier to program in libraries than the standard Gregorian since the years (and sometimes months) are often fixed-length. Most languages will provide code that handles Gregorian dates and I don't think it's too hard to implement the others. > In order to do calculations with times, which are often necessary, we need to > be able to convert them into > a form which has a fixed-length unit since a reference time (like udunits), > even though that isn't the most > convenient way to express them. Yes - I think the "engine" of this is a routine that subtracts two times in a given calendar system and expresses the result as a certain number of, say, seconds. Again, not too hard in the "non-standard" calendars and usually implemented already for the Gregorian system in standard libs. Jon -----Original Message----- From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Jonathan Gregory Sent: 18 August 2011 16:42 To: cf-metadata@cgd.ucar.edu Subject: Re: [CF-metadata] CDM calendar date handling Dear John > http://www.unidata.ucar.edu/software/netcdf-java/CDM/DateTime.html > > If there's interest, I can propose as a CF convention. Otherwise it > can remain a CDM extension. Thank you for doing this. I think it's an attractive idea to have calendar handling in CF time coordinates. One issue to be dealt with would be the need to be able to process these strings using any programming language which might be used to process CF-netCDF data. Could the software be ported to other languages in which the netCDF lib exists? In order to do calculations with times, which are often necessary, we need to be able to convert them into a form which has a fixed-length unit since a reference time (like udunits), even though that isn't the most convenient way to express them. What you have proposed for the syntax looks very sensible to me. I have some minor points: * A bit related to Don's: it would be good to allow SI prefixes, like udunits does. For instance, ms is the usual SI symbol for millisecond. * What happens if n months or n years since a certain date is not a valid date in the calendar? You probably have a rule to resolve that. Most safely, it should be an error to encode such a time, I suppose (e.g. 1 year since 29 Feb 2008). Do you insist that the ref data is valid in the calendar? * The udunits ref time implies missing components e.g. 1 hour since 2011-1-1 means 1 hour since 00:00 on 2001-1-1. What do missing components of ISO strings imply in your implementation? I think it has got to imply something, because these datetimes are still complete time specifications, aren't they. * For further udunits compatibility, it would be convenient to be able to omit the time zone, which would imply Z. All global model data is in UTC, I should think, and I suppose it must be the obvious choice for all global datasets. I think that we should use standard_names of time for datetimes only, and other words, such as period, for intervals of time in standard_names. Then we can give them different sorts of units. Best wishes and thanks Jonathan _______________________________________________ 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
