[Python-Dev] datetime.timedelta total_microseconds

Fred Drake fred at fdrake.net
Wed Feb 27 00:57:08 EST 2019

On Tue, Feb 26, 2019 at 10:20 PM Terry Reedy <tjreedy at udel.edu> wrote:
> To me, total_x implies that there is a summation of multiple timedeltas,
> and there is not.

Do you believe this is a particularly dominant perception?  I don't,
but specific backgrounds probably play into this heavily.

I'd expect to total a bunch of timedelta values using sum([d0, d1, ..., dn]).

Given we already have total_seconds(), it's not clear avoiding
additional methods is meaningful, unless we're going to deprecate
total_seconds().  Not really a win in my book.

I'd rather stick with the existing pattern, if anything even needs to
be done.  I'm quite happy to use d.total_seconds() * 1000000 as long
as the accuracy is sufficient.  Someone with more floating point
expertise can probably think of a reason that's not good enough, in
which case... an appropriate method wouldn't be poorly named as

> I might prefer one method, .convert? with an argument
> specifying the conversion unit, 'microseconds', 'seconds', ... .

Using a function that takes a units indicator (as
d.convert(units='microseconds')) seems like a poor choice; most uses
will hard-code exactly one value for the units, rather than passing in
a variable.  Getting a more specific name seems reasonable.

> It is also not obvious is answer is rounded to nearest second
> or not.

No, but that's a problem we have now with total_seconds().  Best
handled by maintaining the pattern and documenting the behavior.
While fractional microseconds aren't a thing with timedelta values now
(and probably not in any near future), it seems good to keep these
floats so things stay consistent if we can ever get better clocks.


Fred L. Drake, Jr.    <fred at fdrake.net>
"A storm broke loose in my mind."  --Albert Einstein

More information about the Python-Dev mailing list