Why can't timedeltas be divided?

[Dan Bishop]

If I try to write something like:

num_weeks = time_diff / datetime.timedelta(days=7)

I get:

TypeError: unsupported operand type(s) for /: 'datetime.timedelta'
and 'datetime.timedelta'

Of course, one could extend the timedelta class to implement division,

def _microseconds(self):
return (self.days * 86400 + self.seconds) * 1000000 +
self.microseconds
def __truediv__(self, other):
if isinstance(other, datetime.timedelta):
return self._microseconds() / other._microseconds()
else:
return datetime.timedelta(0, 0, self._microseconds() /
other)
def __floordiv__(self, other):
if isinstance(other, datetime.timedelta):
return self._microseconds() // other._microseconds()
return NotImplemented

but why is a basic arithmetic operation missing from the standard
datetime module?

 

[Maric Michaud]

Le Jeudi 25 Mai 2006 00:07, Dan Bishop a écrit :

If I try to write something like:

    num_weeks = time_diff / datetime.timedelta(days=7)

because it has no meaning, what you want is :

num_weeks = time_diff.days / 7
or
num_weeks = (time_diff / 7).days


--
_____________

Maric Michaud
_____________

Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097

 

[John Machin]

Le Jeudi 25 Mai 2006 00:07, Dan Bishop a écrit :

because it has no meaning, what you want is :

num_weeks = time_diff.days / 7
or
num_weeks = (time_diff / 7).days

The ratio of two durations has no meaning???

 

[John Machin]

Le Jeudi 25 Mai 2006 00:07, Dan Bishop a écrit :

because it has no meaning, what you want is :

num_weeks = time_diff.days / 7
or
num_weeks = (time_diff / 7).days

The ratio of two durations has no meaning???

 

[Robert Kern]

Le Jeudi 25 Mai 2006 00:07, Dan Bishop a écrit :


because it has no meaning,

Yes, it does.

what you want is :

num_weeks = time_diff.days / 7
or
num_weeks = (time_diff / 7).days

Uh, no. Besides the integer division problem in your first line, keep in mind
that the .days attribute does not give you the time interval measured in days.
It gives you the number of *whole* days in the interval. The first method will
be incorrect if time_diff is not an even multiple of 1 day. The latter will be
incorrect if time_diff is not an even multiple of 7 days.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Maric Michaud]

oups ididn't post it to the good thread

Le Jeudi 25 Mai 2006 01:10, vous avez écrit :

The ratio of two durations has no meaning???

Oh, sorry, sure it has, I wanted to say "it has no meaning in timedelta
provided arithmetic".
It's a ratio (no dimension) not a duration. In that sense the expected result
should be a float, and the proposed operator will break the timedelta's
arithmetic consistence.

t, u, v <- timedeltas
t+u # valid
t / u # valid
t / u + v # invalid while all terms are valids

It's a big design flaw and I think it's the full answer to the original
question.

Le Jeudi 25 Mai 2006 02:26, Robert Kern a écrit :

Uh, no. Besides the integer division problem in your first line, keep in
mind that the .days attribute does not give you the time interval measured
in days. It gives you the number of *whole* days in the interval. The first
method will be incorrect if time_diff is not an even multiple of 1 day.
The latter will be incorrect if time_diff is not an even multiple of 7 days.

In fact i was computing the exact number of whole weeks in the delta. In
respect of that both expression are perfectly correct, but the second one
isn't clear IMO (why this "days" attribute should give me the number of
weeks ?).

This said it's not hard to figure out the correct expression of the decimal
value of weeks in deltas (discarding the microseconds which are not
relevant) :
num_weeks = (time_diff.days * 24* 3600 + time_diff.seconds) / (7.*24*3600)

If I need to do much of these in a piece of code I would probably define some
helper functions like this :

def tomicroseconds(td) :
        return td.days * 24* 3600 * 10**6 +
                   td.seconds * 10 ** 6 + td.microseconds

def toseconds(td) : return float(tomicroseonds(td)) / 10 ** 6
tominute, tohours, todays, toweeks, etc...

and use float and int / and % operators.
This is an easy and clean implementation IMHO.

--
_____________

Maric Michaud
_____________

Aristote - www.aristote.info
3 place des tapis
69004 Lyon
Tel: +33 426 880 097

 

[webograph]

Oh, sorry, sure it has, I wanted to say "it has no meaning in timedelta provided arithmetic".
It's a ratio (no dimension) not a duration. In that sense the expected result should be a float, and the proposed operator will break the timedelta's arithmetic consistence.

t, u, v <- timedeltas
t+u # valid
t / u # valid
t / u + v # invalid while all terms are valids

why is this a problem? not every structure has to form a closed
mathematical field, and there are other cases in which dividing similar
values yields another structure (think of calculating `factor =
speed2/speed1; distance2 = factor * distance1`)

is there any hope this can be fixed? defining timedelta/timedelta
division could not break existing code because no such division is
defined yet.

num_weeks = (time_diff.days * 24* 3600 + time_diff.seconds) / (7.*24*3600)

this requires domain knowledge i'd expect a time structure to provide!
as you can create a timedelta by timedelta(seconds=1234567), i think it
is not too much to ask to have some simple way to get back the 1234567
seconds without thinking about what intervals (currently days, seconds
and microseconds) are used internally.

sorry for bringing up such an old thread, but this seems important to me
-- up to now, there are thousands [1] of python programs that use
hardcoded time calculations.


regards
webograph


[1]
http://www.google.com/codesearch?q=60|3600+24+timedelta+lang:python
(gave me about 2000)

 

[Martin v. Löwis]

sorry for bringing up such an old thread, but this seems important to me

-- up to now, there are thousands [1] of python programs that use
hardcoded time calculations.

Would you like to work on a patch?

Regards,
Martin

 

[castironpi]

sorry for bringing up such an old thread, but this seems important to me
-- up to now, there are thousands [1] of python programs that use
hardcoded time calculations.

Would you like to work on a patch?

Last time I brought up this sort of thing, it seemed fairly unanimous
that the shortcomings of the datetime module were 'deliberate' and
would not be fixed, patch or no patch.

I wanted to format strings with them. How does modulo a datetime
sound?

 

[Martin v. Löwis]

Last time I brought up this sort of thing, it seemed fairly unanimous

that the shortcomings of the datetime module were 'deliberate' and
would not be fixed, patch or no patch.

Ok, so then if the answer to my question is "yes", the first step
should be to discuss it on python-dev.

Regards,
Martin

 

[webograph]

Ok, so then if the answer to my question is "yes", the first step
should be to discuss it on python-dev.

i've had a look at the source code and written a small patch (attached;
contains a case in classical/floor division as well as truediv).
is there a defined escalation procedure from python-list to python-dev
or should i just send the suggestion+patch there?

regards
webograph

ps: i hope the patch conforms to python c coding style (most of it is
just copy/pasted and modified).

 

[webograph]

Yes, that's where it was decided that the datetime module was fine
that way it is and must not be changed.

could you give me some pointers to that discussion?

i found some discussion about interpretation as intervals [1], casting
numbers to intervals [2] and vice versa (plus discussion of connection
to unix timestamps) [3], and arithmetics of time/datetime and timedelta
[4], on which i agree that those are problematic (some of those also
touch the problem of time zones).
nevertheless, i fail to see such problems when dividing timedeltas --
after all, `delta2 / 5 == delta1` works, so why should not `delta2 /
delta1 == 5`?

regards
webograph

[1] http://www.mail-archive.com/[email protected]/msg21629.html
[2] http://mail.python.org/pipermail/python-dev/2002-March/020604.html
[3] http://www.mailinglistarchive.com/[email protected]/msg12596.html
[4] http://bugs.python.org/issue1118748

 

[Martin v. Löwis]

Well, http://bugs.python.org/issue1673409 seems very closely related.

I can't see the relationship. This issue is about conversion methods,
not about arithmetic.

Regards,
Martin

 

[Martin v. Löwis]

i've had a look at the source code and written a small patch (attached;

contains a case in classical/floor division as well as truediv).
is there a defined escalation procedure from python-list to python-dev
or should i just send the suggestion+patch there?

Post a patch to bugs.python.org, optionally also post a message
referring to that patch to python-dev.

Regards,
Martin

 

[webograph]

Post a patch to bugs.python.org, optionally also post a message
referring to that patch to python-dev.

i've created an issue at [1]. let's hope for the best!

thanks for your support
webograph

[1] http://bugs.python.org/issue2706