Add as_millis function to std::time::Duration

[paezao]

Hello,

It's funny because there's a from_millis function but not an as_millis one.

What do you guys think? It's a simple change.

Cheers

[nagisa]

You cannot convert duration to milliseconds losslessly whereas you can do that in the other direction.

[ticki]

@nagisa of course not, but it would still be very useful, nonetheless. An as_nanos would be very useful too.

[gkoz]

The duration RFC explicitly mentions acceptable losses:

In general, this proposal considers it acceptable to reduce the granularity of timeouts (eliminating nanosecond granularity if only milliseconds are supported) and to truncate very large timeouts.

So it is surprising that everyone has to implement the reductions manually.

[ticki]

Yes, this patttern is virtually everywhere.

[ticki]

See #1547

[robinst]

Looks like with rust-lang/rust#35118 (u128) landing, this would be possible without having to truncate large values.

[kornelski]

The rounding problem is silly. .as_millis() can express 584.9 million years in u64.

What is a realistic use case for needing millisecond precision on a duration longer than half a billion years? (but also doesn't need duration longer than 500 billion years)

[clarfonthey]

Perhaps we could offer subsec_millis and subsec_micros instead? It'd be nice to have something like that.

[lolgesten]

I think the time handling in rust a pretty serious ergonomic issue. To easily do a System.currentTimeMillis() or Date.now(), you have to pull in 3rd party crates or write several lines of code.

So whilst I agree rust std should stop short of full blown chronos time handling/formatting, milliseconds (and epoch) are so common they ought to be there.

[idubrov]

Totally agree. It's an ergonomic issue. Call me stupid, but this is the code I had to fix today:

let sec = (elapsed.as_secs() as f64) + f64::from(elapsed.subsec_nanos()) / 1000_000.0;

See the issue? It worked fine until our queries became too long. 🤥

[praetp]

Any progress on this ?