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
Closed

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

paezao opened this issue Mar 16, 2016 · 14 comments
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.

Comments

@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
Copy link
Member

nagisa commented Mar 16, 2016

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

@ticki
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
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
Copy link
Contributor

ticki commented Mar 16, 2016

Yes, this patttern is virtually everywhere.

@ticki
Copy link
Contributor

ticki commented Mar 17, 2016

See #1547

@nrc nrc added the T-libs-api Relevant to the library API team, which will review and decide on the RFC. label Aug 18, 2016
@robinst
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
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)

@clarfonthey
Copy link
Contributor

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

@lolgesten
Copy link

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
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
Copy link

praetp commented May 21, 2018

Any progress on this ?

@kornelski
Copy link
Contributor

I've created a poll about it https://internals.rust-lang.org/t/duration-as-milliseconds/7605

@lolgesten
Copy link

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

@Centril
Copy link
Contributor

Centril commented Oct 7, 2018

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

@Centril Centril closed this as completed Oct 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-libs-api Relevant to the library API team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests