Hi Benno, all, > no one who uses "months since date-time" is using the udunits interpretation
I'm not sure how you can say this with certainty. CF deprecates, but does not ban, the use of "months since" in the udunits sense. Therefore, by a literal reading of CF, I think an interpretation of "udunits months since" would be allowable. > the calendar 360_day interpretation, which is part of the standard, and > beyond udunits. The 360_day calendar is part of CF, but nowhere in the standard can I find something that says that if you use the 360_day calendar the definition of the month somehow changes from the udunits definition, even if that is the intention. Is the definition of the day constant between calendars? If so, constant at what? 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. Jon From: cf-metadata-boun...@cgd.ucar.edu [mailto:cf-metadata-boun...@cgd.ucar.edu] On Behalf Of Benno Blumenthal Sent: 29 March 2011 20:25 To: Christopher Barker Cc: cf-metadata@cgd.ucar.edu 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 <chris.bar...@noaa.gov<mailto:chris.bar...@noaa.gov>> 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<tel:%28206%29%20526-6959> voice 7600 Sand Point Way NE (206) 526-6329<tel:%28206%29%20526-6329> fax Seattle, WA 98115 (206) 526-6317<tel:%28206%29%20526-6317> main reception chris.bar...@noaa.gov<mailto:chris.bar...@noaa.gov> _______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu<mailto:CF-metadata@cgd.ucar.edu> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata -- Dr. M. Benno Blumenthal be...@iri.columbia.edu<mailto:be...@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
_______________________________________________ CF-metadata mailing list CF-metadata@cgd.ucar.edu http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
