# [issue2706] datetime: define division timedelta/timedelta

Tennessee Leeuwenburg report at bugs.python.org
Tue Mar 10 22:15:57 CET 2009

```Tennessee Leeuwenburg <tleeuwenburg at gmail.com> added the comment:

Hi all,

I'm trying to help out by reviewing issues in the tracker... so this is
just a first attempt and I hope it is somewhat useful. This issue covers
a number of discrete functional changes. I here review each in turn:

1) Allow truediv, the operator '/', to be applied to two timedeltas
(e.g. td1 / td2). The return value is a float representing the number of
times that td2 goes into td1.

Evaluation: Since both time deltas are quantitative values of the same
unit, it makes sense they should be able to support basic math
operations. In this case, operation to be added is '/' or truediv. I
would personally find this functionality useful, and believe it is a

Recommendation: That this functionality be recommended for development

2) Allow truediv to be applied to a timedelta and an int or float. The
return value is a timedelta representing the fractional proportion of
the original timedelta.

Evaluation: This makes total sense.
Recommendation: That this functionality be recommended for development

2) Allow divmod, the operator '%', to be applied to two timedeltas (e.g.
td1 % td2). I think there is some debate here about whether the return
value be an integer in microsends, or a timedelta. I personally believe
that a timedelta should be returned, representing the amount of time
remaining after (td1 // td2)  * td2 has been subtracted.

The alternative is an integer, but due to a lack of immediate clarity
over what time quanta this integer represents, I would suggest returning
a unit amount. There is also some discussion of returning (long,
timedelta), but I personally fail to see the merits of returning the
long without some unit attached.

3) Allow divmod, the operator '%', to be applied to a timedelta and an
integer or float. (e.g. <timedelta> % 3). I'm not quite as sold on this.
I suggest that more discussion is required to flesh this out further.

A patch has been attached which implements some of this behaviour. I
would suggest that it's valuable to start doing this work in discrete
chunks so that progress can be begun before the issues under debate are
resolved. I suggest that it would be appropriate to create three smaller
issues, each tackling just one piece of functionality. This should make
the changes more atomic and the code patch simpler.

-T

----------
message_count: 19.0 -> 20.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
_______________________________________
```