The "beaty" of date arithmetic

Tim Peters tim.one at comcast.net
Fri Jan 24 11:53:22 EST 2003


[Hans-Joachim Widmaier]
> I've considered using mxDateTime, but from looking at the docs, I
> haven't found anything that seemed to make it much easier. The
> problems start as soon as you're going from fixed units like hour, day
> to somewhat fuzzier like month.

Note that 2.3's datetime doesn't support fuzzy cases directly:  a timedelta
can only be given "crisp" units, like microseconds, seconds, minutes, hours,
days and weeks.  If you want "a month", you have to figure out for yourself
you want it to mean.

> What date is "T - 1 month - 1 day"?  What date is "2000-02-29 + 1 year"?
> Date arithmetic *is* complex.

Fuzzy date arithmetic is complicated, and so is datetime arithmetic
involving time zones.  For example, if you add "a day" to some datetime in
the day before a daylight saving time transition, "should" the hour member
of the result be the same, or off by one to reflect 24 real-life hours
difference?

It's actually easy to supply answers to all such puzzles, but they're more
arbitrary than compelling, and one size doesn't fit anyone.

> ...
> I already compiled 2.3a1 but didn't install it as it didn't pass the
> tests.

Which OS, which tests, etc -- if problems aren't reported, they won't get
fixed.  That's pretty much the point of an alpha release <wink>.






More information about the Python-list mailing list