On 3/29/11 12:24 PM, Benno Blumenthal wrote:
Well I thought I was helping, but maybe not.
you certainly are helping -- we all need to know what folks' use cases
are to determine a good solution.
-- no one who uses "months
since date-time" is using the udunits interpretation -- all of us who
use it are using the calendar 360_day interpretation, which is part of
the standard, and beyond udunits.
uhm, how can you be sure what "all of us" are doing?
Not to pick on Chris,
You aren't picking on me, you're picking on my understanding of the
situation -- which is fair game.
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).
yes, i think you are right. I just went to read the CF standard about
this again, and it helps, but I'm still confused about how Calendars
like "360_day" can be used in practice, and I don't see why anyone needs:
"5 days since 1960-01-01 calendar 365_days"
rather than:
"days since 1960-01-01 calendar 365_days"
and multiply the time variable by 5. So I think the use of units like "5
days", and use of various calendars are orthogonal.
on to my question about calenders. Form the docs:
360_day
All years are 360 days divided into 30 day months.
OK, so I take it that a day is 24 hours, so a year is 24 * 360 hours
long. I can see the utility in this, but then i guess 1960-01-31 is
illegal? And if you do "years since" or even "months since", the meaning
is going to get very offset after a few year from the "usual" calendar.
I'm also not sure what "1960-01-01" means in a 360_day calendar -- what
is year 0? Or do you use the Gregorian calendar for the "point in time"
part? Maybe that doesn't matter, as long as we aren't concerned about
absolute dates. This does satisfy Steve's point about having a
meaningful axis for doing math -- every month and year is the same length.
However, at the end of the day, I don't see the use -- you really can't
talk about dates in this calendar anyway, so why not pick an arbitrary
point in time and use hours? When if comes down to it, I can certainly
see why one might want to do calculations and plotting, etc, in those
calendars, but I don't see why your netcdf file has to store the data
that way.
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,
yup.
many of us are modeling
the earth, which means that the earth-bound descriptions of time are
what we need to concisely describe what we are doing.
right -- and I think that the calendar_year concept makes sense for this
-- but you'd better use something like the Gregorian calendar, or your
years won't line up with the seasons for long!
-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
