On Tue, Mar 29, 2011 at 5:16 PM, Jon Blower <[email protected]>wrote:
> > I tend to agree with Chris’s points by the way – I am not sure that Benno’s > formulations make things clearer. If Chris has misunderstood the use of the > calendar attribute then so have I and so have many others – IMHO this points > to a lack of clarity in the standard rather than a failure of the community > to “get it”. Just my viewpoint. > > > I did not say that there was a failure of the community to "get it". What I meant was that the calendar attribute controls the interpretation of time, and many of the e-mails ignored it, making the conversation hard to understand. I'll not participate in this conversation again, Benno > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Benno Blumenthal > *Sent:* 29 March 2011 20:25 > *To:* Christopher Barker > *Cc:* [email protected] > *Subject:* Re: [CF-metadata] udunits time unit question > > > > Well I thought I was helping, but maybe not. > > > > > > On Tue, Mar 29, 2011 at 12:35 PM, Christopher Barker < > [email protected]> wrote: > > > > There are data sets that use "months since date-time" in existence. > However, anyone using those data sets with the udunits lib is interpreting > that data in a way that may not be what the data creator intended -- this is > simply broken, It can not be enshrined as a standard. > > > > > > and I agree. I would take it a bit farther -- no one who uses "months > since date-time" is using the udunits interpretation -- all of use who use > it are using the calendar 360_day interpretation, which is part of the > standard, and beyond udunits. > > > > Not to pick on Chris, but I think it is clear over the course of this > conversation that many of the participants do not understand the calendar > attribute, which is causing a great deal of pain (or at least conversation). > > > > My examples indirectly show how I handled the problem before the calendar > attribute existed -- I defined two fundamental time units within udunits > (seconds *and* years), and thus did not let udunits convert between them > (outside code, which understands "calendar", does convert between them). > This is not a major code change, but a configuration change (udunits.dat in > my day). Anyway, calendar is now part of the standard, which makes things > clearer (or so we would like to think). > > > > Anyway, we have a basic problem: while "since" seems to let us convert > between duration (which has physical units), and an instant in time, there > is a precision problem which calendar partly addresses/papers over: sometime > we just talk about years (or much much longer), sometimes we ignore the > variation in month length (calendar 360_days), sometimes we ignore the leap > years (calendar 365_days or calendar 366_days), and we almost always ignore > leap_seconds (at least I do, anyway). The standard has to come to grips > with this aspect of the conversion, which is always there, physical units > being what they are. > > > > And there is a lot of data out there with year being the right sense of > things -- the fuzziness is real -- tree ring data, coral data, ice cores, > all count years more-or-less, though one wonders if a year is catastrophic > enough whether it messes up the count. Not to mention the data where year > seems a bit small. Yes, we gave up on the passing of the seasons for > defining "time" a while ago, but many of us are modelling the earth, which > means that the earth-bound descriptions of time are what we need to > concisely describe what we are doing. > > > > Benno > > > > > > On 3/26/11 6:07 PM, Benno Blumenthal wrote: > > 1/365 years since 1960-01-01 calendar 365_days (equivalent to days in > 365_day calendar) > > > > Is it? what varies here, the length of the year or the length of the day? > if the length of the year is well defined (what is it here?), the 1/365 > years is well defined, and it very well may not be 24 hours. If if is, then > why the heck do you not use "days since"? > > > > 1/360 years since 1960-01-01 calendar 360_days (equivalent to days in > 360_day calendar) > 1/12 years since 1960-01-01 calendar 360_days (the much maligned months) > > > > but which month? one with a defined number of hours, all the same, or one > that varies depending on where in the calendar year the data is? > > As I read these, I'm quite confused -- I can certainly see why one might > what to collect or store data at such frequencies, but that's not what the > CF standard is about. It is about clearly defining the data when stored, > transmitted and shared -- ALL of the above examples are ripe for confusion, > and could just as easily be expressed as "hours since" or "days since". > > > > months since 1960-01-01 calendar 360_days > > > > what is a "calendar 360_day"? > > > > (just as a reminder -- it is > important to us, no matter how many people write to say months are > meaningless) > > > > I don't think any of us think months are meaningless -- simple that they > are not a good choice for well-defined time durations. > > It seems to me that there are two cases: > > 1) The data is defined on some kind of regular interval (or irregular, but > on clearly defined points in the time continuum) - in which case use an > appropriate unit: seconds, hours, days. (days is open to debate, I suppose) > > or > > 2) the data correspond to calendar months, i.e. monthly averaged data, etc > -- a way to specify "calendar unit" makes sense: "calendar months since > 1989-01" > > but using all these peculiar combination of units, so that the time > variable can be: (1,2,3,4), rather than say, (0, 5, 10, 15) makes no sense > to me. > > And is it used in any other context? If you have an instrument that is > gathering data at 1/2hz, would you do: > > "2 seconds since date-time" then have your time variable be: (0,1,2,2)? > > I think not, you'd do: > > "seconds since date-time" and have your time variable be: (1,2,4,6) > > > > However, then you lose the semantics of a 3 month interval. As Benno > (sorry for spelling > your name wrong last time) showed, the semantics of the qualifier for x > since have real > meaning in climate datasets. > > > > I am looking at how hard that would be to support, but it does add > perhaps unneeded complexity. > > > But it adds semantics of the time periods in question. > > > > The question is "is the added information worth the added complexity?". > Also, one of the goal of the CF standard is to make it easier to have client > software that can easily work with data from a variety of data sets -- this > kind of thing makes it harder, not easier. If you want to give the user some > information about the data collection interval, put it in optional > meta-data. > > > There is a lot of talk about udunits as the "reference library", and while > I do see the value of a reference library, I also think that we need to > remember that: > > 1) we can define a standard without a specific reference lib actually > existing. > > 2) not every one is going to use udunits -- which means that if we add all > this complexity to the standard, we need to not only add a bunch of code to > handle it in udunits, but also everyone else that uses other libraries for > units has to deal with it -- please don't make me write that code! > > I have no idea how anyone else handles time in their client code, but what > I do is: > > - first convert the time access to date-time objects > - second -- convert to whatever I need to do with it. > > I do this so that my client code can be all the same, I don't have to deal > with multiple units, reference dates, etc in most of my code. > > > > On 3/28/11 9:31 AM, Steve Hankin wrote: > > 1. the *use of "months" as a unit of measure*, with the intention > that this refer to calendar months of varying length ... not a > "unit of measure" by the normal meaning of that word > > > > It's not clear to me that that is the intention, actually -- I htink it > means that in some uses, and means "1/12 of a year" in others (even though > year isn't clearly defined, either!) > > In fact, since udunits is the official reference lib,and it does define a > month has being a specific length, I think current practice is the later > use. > > > > The question before us is, does the fact that there are some existing > "CF" files that utilize these encodings, require that those encodings be > formalized into CF? It is hard to say "no" in such cases, because doing > so creates inconvenience for our colleagues and their users. > > > > Sure, but a standrad is defeined as "everything in current use", there > isin't really much point in having it at all. > > I think my point above is relevant here: > > > > We should look at each of these questions from the point of view of the > complexity of the software *reading* the file. > > > > +1 > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > [email protected] > > > _______________________________________________ > 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 > -- 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
