Add something like `Duration::as_fractional_secs`

[luser]

I've found myself wanting to format a Duration as a human-readable number of seconds with a fractional portion. Of course I screwed up the conversion when I wrote that code, thankfully someone sent me a PR to fix it:
mozilla/sccache#52

It would be nice if this was a built-in API. Ideally we'd have pub fn as_fractional_secs(&self) -> f64, but maybe that'd lose too much precision? I suppose we could alternately do something like pub fn as_fractional_secs(&self) -> (u64, f32), where it returns (self.as_secs(), self.subsec_nanos() as f32 / 1000_000f32). That's a bit less ergonomic, but not awful.

Alternately, since it's already easy to do arithmetic on Durations, another take on this would be to implement Display for Duration, which could write the value as seconds, and support the floating-point precision format field for fractional seconds.

[michaelwoerister]

👍 I've found myself wanting something like this too quite a bit in the past.

[clarfonthey]

I'd recommend rewording to this as as_float, because as_fractional makes me think that it's going to be some sort of reduced fraction type.

[sfackler]

There are a bunch of convenience accessors/constructors that would be great to add to Duration, including this one, milliseconds, etc. There are some slightly nontrivial API design decisions here around return types, so an RFC is probably warranted but I don't think it'd need to be too complex.

[matklad]

A somewhat orthogonal use case to keep in mind: I often add ad-hoc time measurements to my code as a difference between two Instant::now. In this circumstances, it would be really helpful to have as_fractional_[secs|millis|micros|nanos]. And for this particular purpose I wish I could format!("{:?}", duration) and get human friendly "100 ms" or "1.5 sec" or "42 ns" automatically based on the duration length.

[luser]

I looked around, and chrono::Duration implements Display:
https://docs.rs/chrono/0.2.25/chrono/struct.Duration.html

but it's just re-exporting time::Duration. The Display implementation is here:
https://github.com/rust-lang-deprecated/time/blob/8d7d141fe91ea936b952376b36e50ad861f01e16/src/duration.rs#L363

It outputs in ISO 8601 format, which looks like PxDyS, where x is the number of days and y is the number of seconds including the fractional component. Either part can be omitted if it would be zero. I didn't actually know ISO 8601 specified a duration format, so TIL. That doesn't seem incredibly useful, although having methods that accept and produce ISO-standard formats is often helpful for datetime handling, so I could see an argument for having an as_iso_8601 method.

There's a chrono-humanize crate, which has a HumanTime type that you can instantiate based on a chrono::Duration or chrono::DateTime, and a Humanize trait that is implemented for the same types, both of which allow you to get a human-friendly summary of a time period, but it's very human-centric, in that it prints things like "in 3 minutes" and "3 minutes ago", and it simply prints "now" for durations shorter than some arbitrary amount (10 seconds?). This looks useful, but doesn't solve my use case.

I couldn't find any other relevant existing crates, if someone knows about something I'd be interested to hear!

Python's datetime.timedelta type has a total_seconds method that returns the total number of seconds it represents in floating point. The documentation there notes that for large time intervals it will lose accuracy.

I'm not familiar enough with datetime handling in other languages to come up with other examples without a lot of digging, and I've already spent longer writing this comment than I intended. :)

[arthurprs]

Related rust-lang/rfcs#1545 and #35868

[torkleyy]

If you are interested, I just released floating-duration (very basic).

[clarfonthey]

Also: shouldn't this thread be moved to the RFC repo?

[dtolnay]

The Duration API has been explored from a few different perspectives in rust-lang/rfcs#1545, rust-lang/rfcs#1547, #35868, #41328, rust-lang/rfcs#1917, and #38475. At this point I believe an RFC is going to be required. It should summarize the key use cases from each of those discussions and propose a coherent API for Duration to address the use cases that are deemed important.