Why can't timedeltas be divided?

Discussion in 'Python' started by Dan Bishop, May 24, 2006.

  1. Dan Bishop

    Dan Bishop Guest

    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?
    Dan Bishop, May 24, 2006
    #1
    1. Advertising

  2. 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
    Maric Michaud, May 24, 2006
    #2
    1. Advertising

  3. Dan Bishop

    John Machin Guest

    On 25/05/2006 8:25 AM, Maric Michaud wrote:
    > 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
    >
    >


    The ratio of two durations has no meaning???
    John Machin, May 25, 2006
    #3
  4. Dan Bishop

    John Machin Guest

    On 25/05/2006 8:25 AM, Maric Michaud wrote:
    > 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
    >
    >


    The ratio of two durations has no meaning???
    John Machin, May 25, 2006
    #4
  5. Dan Bishop

    Robert Kern Guest

    Maric Michaud wrote:
    > 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,


    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
    Robert Kern, May 25, 2006
    #5
  6. 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 :
    > > 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.

    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
    Maric Michaud, May 25, 2006
    #6
  7. Dan Bishop

    webograph Guest

    On Thu, 25 May 2006, maric wrote:
    > > 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
    >

    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%3Apython
    (gave me about 2000)
    webograph, Apr 27, 2008
    #7
  8. > 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
    Martin v. Löwis, Apr 27, 2008
    #8
  9. Dan Bishop

    Guest

    On Apr 26, 10:27 pm, Jon Ribbens <> wrote:
    > On 2008-04-27, Martin v. Löwis <> wrote:
    >
    > >> 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?
    , Apr 27, 2008
    #9
  10. > 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
    Martin v. Löwis, Apr 27, 2008
    #10
  11. Dan Bishop

    webograph Guest

    On 2008-04-27 09:12, Martin v. Löwis wrote:
    >> 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.

    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, Apr 27, 2008
    #11
  12. Dan Bishop

    webograph Guest

    On 2008-04-27 14:18, Jon Ribbens wrote:
    > 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//msg21629.html
    [2] http://mail.python.org/pipermail/python-dev/2002-March/020604.html
    [3] http://www.mailinglistarchive.com//msg12596.html
    [4] http://bugs.python.org/issue1118748
    webograph, Apr 27, 2008
    #12
  13. > 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, Apr 27, 2008
    #13
  14. > 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
    Martin v. Löwis, Apr 27, 2008
    #14
  15. Dan Bishop

    webograph Guest

    On 2008-04-27 19:28, Martin v. Löwis wrote:
    > 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
    webograph, Apr 27, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,252
    louis lin
    Oct 28, 2003
  2. Metin Yerlikaya

    an alternative method to do divided clocks

    Metin Yerlikaya, Feb 15, 2005, in forum: VHDL
    Replies:
    4
    Views:
    625
    John_H
    Feb 15, 2005
  3. Dos-Man
    Replies:
    5
    Views:
    1,237
    Augustus
    Mar 4, 2004
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,762
    Smokey Grindel
    Dec 2, 2006
  5. Perry Loh
    Replies:
    0
    Views:
    289
    Perry Loh
    Mar 24, 2006
Loading...

Share This Page