[Python-Dev] datetime.timedelta total_microseconds

Henry Chen tahafut at gmail.com
Fri Feb 15 17:50:42 EST 2019


Indeed there is a potential loss of precision:

_timedelta_to_microseconds(timedelta(0, 1, 1)) returns 1000000

where conversion function is defined according to the initial message in
this thread

On Fri, Feb 15, 2019 at 2:29 PM Paul Ganssle <paul at ganssle.io> wrote:

> I'm still with Alexander on this. I see functions like total_X as
> basically putting one of the arguments directly in the function name - it
> should be `total_duration(units)`, not `total_units()`, because all of
> those functions do the same thing and only differ in the units they use.
>
> But Alexander's approach of "divide it by the base unit" is *even more
> general* than this, because it allows you to use non-traditional units
> like weeks (timedelta(days=7)) or "two-day periods" or whatever you want.
> If you use this idiom a lot and want a simple "calculate the total"
> function, this should suffice:
>
> def total_duration(td, *args, **kwargs):
>     return td / timedelta(*args, **kwargs)
>
> Then you can spell "x.total_microseconds()" as:
>
> total_duration(x, microseconds=1)
>
> Or you can write it like this:
>
> def total_duration(td, units='seconds'):
>     return td / timedelta(**{units: 1})
>
> In which case it would be spelled:
>
> total_duration(x, units='microseconds')
>
> I don't see there being any compelling reason to add a bunch of methods
> for a marginal (and I'd say arguable) gain in aesthetics.
> On 2/15/19 4:48 PM, Chris Barker via Python-Dev wrote:
>
> On Fri, Feb 15, 2019 at 11:58 AM Rob Cliffe via Python-Dev <
> python-dev at python.org> wrote:
>
>> A function with "microseconds" in the name IMO misleadingly suggests that
>> it has something closer to microsecond accuracy than a 1-second granularity.
>>
>
> it sure does, but `delta.total_seconds()` is a float, so ms accuracy is
> preserved.
>
> However, if you DO want a "timedelta_to_microseconds" function, it really
> should use the microseconds field in the timedelta object. I haven't
> thought it through, but it makes me nervous to convert to floating point,
> and then back again -- for some large values of timedelta some precision
> may be lost.
>
> Also:
>
> _MICROSECONDS_PER_SECOND = 1000000
>
>
> really? why in the world would you define a constant for something that
> simple that can never change? (and probably isn't used in more than one
> place anyway
>
> As Alexander pointed out the canonical way to spell this would be:
>
> delta / timedelta(microseconds=1)
>
> but I think that is less than obvious to the usual user, so I think a:
>
> delta.total_microseconds()
>
> would be a reasonable addition.
>
> I know I use .totalseconds() quite a bit, and would not want to have to
> spell it:
>
> delta / timedelta(seconds=1)
>
> (and can't do that in py2 anyway)
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
>
> _______________________________________________
> Python-Dev mailing listPython-Dev at python.orghttps://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/paul%40ganssle.io
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/tahafut%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190215/2367ddce/attachment.html>


More information about the Python-Dev mailing list