I think one the important factors, implied if not stated is what is meant by accuracy. One approach is to set all non specified values to 0, such that: 1930-01-01 == 1930-01-01T00:00:00Z
Another appraoch is to take the accuracy to be encompassing, such that: 1930-01-01 == 1930-01-01T00:00:00Z to 1930-01-01T23:59:59Z 1930-01 == 1930-01-01T00:00:00Z to 1930-01-31T23:59:59Z (I have assumed a gregorian calendar and that seconds provide sufficient accuracy, whilst sub-seconds are merely optional) to my mind 1930-01 and 1920-01-01 are implicitly bounded quantities, not instants in time, January 2003 is the whole of the month, no more, no less. The second appraoch would then give: 1 months since 1930-01-01 == 1930-02-01 All this becomes very calendar dependent, which I think the calculations need to be. > 'udunits converts units like months and years to a fixed number of seconds' This seems to me to be an issue, something which needs addressing, either by changing the behaviour or deprecating it. mark -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Nan Galbraith Sent: 16 March 2011 13:33 To: [email protected] Subject: Re: [CF-metadata] udunits handling of fuzzy time units Is the whole problem just that when udunits calculates ISO string dates, it doesn't use the resolution implicit in the reference date and units? That seems like an easy problem to solve, without throwing out udunits. > 1 months since 1930-01-01 == 1930-02-01 The argument that months & years are inappropriate units for time delta is, sorry, wrong. They'd obviously only be used where the data was on a per-month or per-year basis, and the variation in the actual length of a month or year were either taken into account (i.e. by averaging different length time bins) or was unimportant (as in some models). The current system provides the flexibility to handle lots of different models of data time. What would be very useful would be to have a well defined method to describe the resolution of the time coordinate, which is missing in CF; we use a "resolution" attribute, but it's not a standard, so has limited value. We also use the old "fortran_format" attribute, and that (or something like it) should be used in udunits for converting calculated times to ISO strings. Nan > because udunits converts units like months and years to > a fixed number of seconds, one cant really use things like > months and years as units, since you get things like this: > 0 months since 1930-01-01 == 1930-01-01T00:00:00Z > 1 months since 1930-01-01 == 1930-01-31T10:29:03Z > 2 months since 1930-01-01 == 1930-03-02T20:58:07Z > 3 months since 1930-01-01 == 1930-04-02T07:27:11Z > -- ******************************************************* * Nan Galbraith (508) 289-2444 * * Upper Ocean Processes Group Mail Stop 29 * * Woods Hole Oceanographic Institution * * Woods Hole, MA 02543 * ******************************************************* _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
