I am sorry, but this conversation is more confusing that it needs to be -- once calendar 360_day is chosen, there is nothing "fuzzy" about month or year, and once calendar 365_day or 366_day is chosen, there is nothing "fuzzy" about year. udunits does not support calendar, so its poor choice of month/year support is not an issue -- if it did support calendar (which is in the standard), then it would handle year/month correctly for these choices of calendar.
Benno On Tue, Mar 15, 2011 at 9:14 AM, Jon Blower <[email protected]>wrote: > I think it's good to remove the dependence on UDUNITS from the CDM for date > handling. > > However, although "date" is not a unit of measure, "seconds" is, and so is > "month" in the definition of UDUNITS. Since CF defines that we use the > UDUNITS interpretation of month/year, it would seem dangerous to change this > assumption for backward compatibility? > > (It's not just that months are of variable lengths within a year, but also > that there are different definitions of a "month". UDUNITS uses a fixed > year-length (not a calendar year length) and a month is year/12.) > > BTW, the various calendars are implemented in ncWMS at > http://www.resc.rdg.ac.uk/trac/ncWMS/browser/trunk/src/java/uk/ac/rdg/resc/edal/time > . > > I even wrote half-decent unit tests - aren't I a good boy? ;-) > > Jon > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of John Caron > Sent: 15 March 2011 13:02 > To: [email protected] > Subject: Re: [CF-metadata] udunits handling of fuzzy time units > > On 3/15/2011 5:03 AM, Karl Taylor wrote: > > I agree with Jon. > > > > By definition, I think, a "unit of measure" must not vary; hence month > > is not a proper unit and not only depends on month of year, but also > > on assumed calendar (and similarly for year). Therefore, I think > > "months since" and "years since" should not be allowed in CF. > > > > Karl > > Hi Karl: > > so if currently we cant actually use months and years, because of the > way udunits handles them, why not redefine how they should be understood > when you do use them, namely as setting the month or year field in a > date calculation. > > this eases the burden on data writers, and makes the metadata human > readable, at the cost of a small increase in the complexity of libraries > that read data. > > one more comment: a date is not a unit of measure, and therein lies all > the trouble. IMO, date handling should be removed from the udunits > package, which is what im doing now in the CDM (not removing date > handling from udunits, just not using udunits anymore to handle dates). > > John > _______________________________________________ > 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 > -- Dr. M. Benno Blumenthal [email protected] International Research Institute for climate and society The Earth Institute at Columbia University Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
_______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
