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
Chris.Barker at noaa.gov
Received on Mon Apr 04 2011 - 12:36:11 BST
