I am attaching a patch that implements Mark's timedelta_arith.py algorithms in C.

With rounding well defined, I am close to withdrawing my opposition to supporting mixed timedelta with float operations.  There is still one issue that I believe is worth discussing before this feature is accepted.  Time, unlike most other physical quantities has a non-arbitrary notion of direction.  Therefore, in many applications, rounding towards past or towards future may be preferable to rounding to nearest.

For example, one of the likely applications of floating point division would be to construct time series from continuous or differently sampled functions.  If such series are used to measure correlations between cause and effect, it is important that effect is measured at a time following the cause and not at an early or the same moment.

As Mark noted in private correspondence, this issue is mitigated by the fact that "with correct rounding, for timedeltas t and s, and a positive float x, it is guaranteed that t <= s implies t op x <= s op x" (where op is either * or /).  It is still possible however, that even the case of t < s and t op x == s op x present a problem in some applications.

Despite this issue, I would support round to nearest even choice over round to past or to future mainly because it is less likely to lead to surprises where (d1/d2) * d2 != d1.  This choice also conforms with the round() builtin definition and is somewhat more difficult to implement right using existing means.

Daniel, would you like to chime in on the questions of how the results of these operations should be rounded?

If I don't hear principle objections from the "nosy" list, I'll add a documentation patch.