Repository navigation
Allow Division of datetime.timedelta Objects #48541
Description
| BPO | 4291 |
|---|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2009-04-15.06:19:30.572>
created_at = <Date 2008-11-09.23:57:54.484>
labels = ['type-feature', 'library']
title = 'Allow Division of datetime.timedelta Objects'
updated_at = <Date 2009-04-15.06:19:30.480>
user = 'https://bugs.python.org/JeremyBanks'bugs.python.org fields:
activity = <Date 2009-04-15.06:19:30.480>
actor = 'Jeremy Banks'
assignee = 'none'
closed = True
closed_date = <Date 2009-04-15.06:19:30.572>
closer = 'Jeremy Banks'
components = ['Library (Lib)']
creation = <Date 2008-11-09.23:57:54.484>
creator = 'Jeremy Banks'
dependencies = []
files = []
hgrepos = []
issue_num = 4291
keywords = []
message_count = 10.0
messages = ['75670', '75671', '75672', '75673', '75678', '75679', '75910', '75919', '78186', '85982']
nosy_count = 1.0
nosy_names = ['Jeremy Banks']
pr_nums = []
priority = 'low'
resolution = None
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue4291'
versions = []
Activity
JeremyBanks commentedon Nov 9, 2008
It would be convenient if it were possible to divide one
datetime.timedelta object by another to determine their relative durations.
Were the datetime module pure Python a crude solution would just be to
add two methods like this:
However, I don't understand know the Python C API well enough to know
how to patch the C module.
tiran commentedon Nov 10, 2008
That's just too weird. A long time ago I suggested to implement __int__
and __float__ on timedelta objects: int(timedelta) -> seconds,
float(timedelta) -> seconds.micros. Then your use case could be written
as float(td1) / float(td2) which is far more obvious than td1 / td2.
Unfortunately I wasn't a core developer back in those days.
vstinner commentedon Nov 10, 2008
I don't understand what do you expect with the divison. Can you give an
use case and/or examples?
JeremyBanks commentedon Nov 10, 2008
Sorry, allowing for conversion to int/float is probably a more sensible
solution.
This idea was brought to my mind when I was making a very very simple
script for a friend to display how far through a time range we currently
are. For example:
In my case, precision wasn't important so I just divided elapsed.days by
duration.days, but it would be continent to have an accurate result by
just writing what I did above.
vstinner commentedon Nov 10, 2008
The issue bpo-1673409 may help: delta1.toseconds() / delta2.toseconds().
JeremyBanks commentedon Nov 10, 2008
Thanks, I should have paid more attention to the results when I searched
for duplicates. I think that Christian's suggestion of enabling float()
and int() for timedeltas is worth having here, though.
mdickinson commentedon Nov 15, 2008
[Christian]
To me, td1/td2 is more obvious that float(td1)/float(td2).
float(td) involves an arbitrary choice, to return time in *seconds*
(rather than days, or milliseconds, or ...); I think this violates
EIBTI. To me, the obvious and easy-to-read way to get the number
of seconds is to do the division:
abalkin commentedon Nov 16, 2008
@christian
Adding a __float__ method to datetime was entertained back in 2003, but
was rejected. The same reasons apply to timedelta:
"""
A C double doesn't have enough precision for roundtrip guarantees.
Does it really need to be automatic? I.e., does it really need to
be __float__()? I'd be less against this if it was an explicit
method, e.g. dt.asposixtime().
--Guido van Rossum (home page: http://www.python.org/~guido/)
"""
http://mail.python.org/pipermail/python-dev/2003-January/032166.html
vstinner commentedon Dec 22, 2008
See related issues: bpo-1289118 and bpo-2706.
JeremyBanks commentedon Apr 15, 2009
Redundant with bpo-2706 and others.