[Python-Dev] datetime.timedelta total_microseconds

[Fred Drake]

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
total_microseconds.

> 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

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