On Tue, Mar 15, 2011 at 12:45 PM, Jon Blower <j.d.blower at reading.ac.uk>wrote:
> 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
>
Since the standard supports calendars and udunits does not, we have very
nearly already disassociated the time units string from udunits for most
calendars (and if udunits is "fixed" w.r.t. calendars, we are OK there as
well). There is not really a backwards compatibility problem if months and
years are restricted to the explicit calendars for which they are
meaningful.
As for the comment that
There are various date-time libraries that will let you do math like:
>
> a_date_time + 3 months.
>
> But in that case, the actual length of "3 months" depends on the date-time
> it is being added to.
>
That is the whole point of calendars -- by converting from standard_calendar
to 360, added 3 months, and converting back to the standard calendar, you do
in-fact get months that depend on the date-time being added to. Those
calendar-to-calendar conversions need to be done carefully, we do it by
matching up the edges of each time interval, e.g. [ 0000 1 Jan 1960, 0000 1
Feb 1960) corresponds to Jan 1960 in all three calendars. But it is not
sloppy per se.
Steve's point about sloppy science is well taken, but I am not sure we can
solve that by pretending that we cannot understand months when we can handle
them fairly precisely.
Personally I am more upset about the year 0000 meaning climatology, always a
bad idea, but a particularly bad choice now that proleptic-gregorian is the
ISO8601 standard calendar. In fact, the only systematic way to represent a
monthly climatology (average year) is calendar or 360/365 with a modulus
360 or 365 -- days and standard calendar just do not cut it. In this
context in particular months/years make a lot of sense, and I am not going
to be able to persuade my uses that monthly climatologies should not be
used. And sooner-or-later we are going to get into trouble for saving
climatologies without the target period, anyway (1981-2010 anyone?).
>
>
> *From:* bennoblumenthal at gmail.com [mailto:bennoblumenthal at gmail.com] *On
> Behalf Of *Benno Blumenthal
> *Sent:* 15 March 2011 15:20
> *To:* Jon Blower
> *Cc:* John Caron; cf-metadata at cgd.ucar.edu
>
> *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 <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
>
--
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/d8920837/attachment-0001.html>
Received on Tue Mar 15 2011 - 12:54:28 GMT
