Benno,

So are you suggesting that CF should allow "years since" for 360, 365, and 
366-day calendars and "months since" for 360 day calendars (and continue to 
deprecate both of these for other systems)?

If so, I can see how this would be convenient, but it means that effectively 
we're not using UDUNITS to define the unit string in these special cases.

I can also see the benefit in disassociating the time units string from 
UDUNITS, which was one of John's suggestions, but I would worry about backward 
compatibility (haven't thought this through).

Jon

From: [email protected] [mailto:[email protected]] On Behalf Of 
Benno Blumenthal
Sent: 15 March 2011 15:20
To: Jon Blower
Cc: John Caron; [email protected]
Subject: Re: [CF-metadata] udunits handling of fuzzy time units

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]<mailto:[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]> 
[mailto:[email protected]<mailto:[email protected]>]
 On Behalf Of John Caron
Sent: 15 March 2011 13:02
To: [email protected]<mailto:[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]<mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]<mailto:[email protected]>
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata



--
Dr. M. Benno Blumenthal          
[email protected]<mailto:[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

Reply via email to