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 <j.d.blower at reading.ac.uk>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: cf-metadata-bounces at cgd.ucar.edu [mailto:
> cf-metadata-bounces at cgd.ucar.edu] On Behalf Of John Caron
> Sent: 15 March 2011 13:02
> To: cf-metadata at cgd.ucar.edu
> 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
> 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
>
--
Dr. M. Benno Blumenthal benno at iri.columbia.edu
International Research Institute for climate and society
The Earth Institute at Columbia University
Lamont Campus, Palisades NY 10964-8000 (845) 680-4450
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20110315/b9e46f85/attachment-0001.html>
Received on Tue Mar 15 2011 - 09:19:31 GMT
