Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add as_millis function to std::time::Duration #1545

Closed
paezao opened this Issue Mar 16, 2016 · 14 comments

Comments

Projects
None yet
@paezao
Copy link

paezao commented Mar 16, 2016

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

This comment has been minimized.

Copy link
Contributor

nagisa commented Mar 16, 2016

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

@ticki

This comment has been minimized.

Copy link
Contributor

ticki commented Mar 16, 2016

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

@gkoz

This comment has been minimized.

Copy link

gkoz commented Mar 16, 2016

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

This comment has been minimized.

Copy link
Contributor

ticki commented Mar 16, 2016

Yes, this patttern is virtually everywhere.

@ticki

This comment has been minimized.

Copy link
Contributor

ticki commented Mar 17, 2016

See #1547

@robinst

This comment has been minimized.

Copy link
Contributor

robinst commented Jan 4, 2017

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

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented Feb 7, 2017

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)

@clarfon

This comment has been minimized.

Copy link
Contributor

clarfon commented Feb 21, 2017

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

@lolgesten

This comment has been minimized.

Copy link

lolgesten commented Nov 19, 2017

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

This comment has been minimized.

Copy link

idubrov commented Jan 31, 2018

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

This comment has been minimized.

Copy link

praetp commented May 21, 2018

Any progress on this ?

@kornelski

This comment has been minimized.

Copy link
Contributor

kornelski commented May 21, 2018

@lolgesten

This comment has been minimized.

Copy link

lolgesten commented May 21, 2018

And there is this: rust-lang/rust#50167

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Oct 7, 2018

Closing in favor of rust-lang/rust#50202.

@Centril Centril closed this Oct 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.