On 3/31/11 10:18 AM, Seth McGinnis wrote:
For those who have never encountered a non-standard calendar in the wild,
here's one place they show up:
Thanks for the clarification.
I draw the following conclusions:
1) converting between Calendars is ripe for error/mis-interpretation,
and probably shouldn't be attempted.
2) "months" and "year" really should be considered a calendar concept,
NOT a unit of time, like "seconds" and "hours", and thus should only be
used in the context of calendar-specific calculation and specification.
I don't know about "days" and "weeks".
The point of storing the data using the 360-day calendar is that it faithfully
reflects the structure of the model output.
I totally agree -- and further processing should respect that calendar, too.
I'm wondering what essential methods a calendar library needs to have to
support, eg 360 day calendars? The only one that comes to mind is to
calculate the difference between two dates in, say, seconds? What else?
I think using a data type that represents a date-time and another one
for a time-delta, and system to work with them is really helpful.
a time-delta is a span of time, which could be expresses in seconds,
hour, etc. However, when you pick a unit (like seconds) you are
specifying a resolution and range, so it's kind of nice to have a
universal one -- for instance, Python's timedelta stores days, seconds
and microseconds internall to get a good range and microsecond
resolution -- of course microsecond resolution isn't adequate for all
use, so that may not be ideal. Perhaps udinits's time functionality is
already good for this.
A date-time represents a particular point in time (rather than a span),
and must be tied to a given calendar.
So:
The difference between two date-times is a time-delta.
You can add a time-delta to a date-time to get another date-time.
etc.
With date-times, and good calender support, you could express things like:
x calendar months from a given date-time.
next thursday from a given date-time
and all sorts of nifty things like that, but they are distinctly
different operations from:
date_time + 45 hours.
The mxDateTime package:
http://www.egenix.com/products/python/mxBase/mxDateTime/doc/
provides a "RelativeDateTime" object to handle that kind of calendar
concepts/calculsations. That's a pretty nice approach.
HTH,
-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
