Repository navigation
Tracking Issue: Duration::{as_nanos, as_micros, as_millis} #50202
Description
Activity
- changed the title
[-]Duration should have an as_nanos function[/-][+]Tracking Issue: Duration::as_nanos[/+]on May 27, 2018 - changed the title
[-]Tracking Issue: Duration::as_nanos[/-][+]Tracking Issue: Duration::{as_nanos, as_micros, as_millis}[/+]on Jun 2, 2018 I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Error> and returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
Reacted by Josh Huber, Artyom Pavlov, Oleg Eterevsky, kryptan, Félix, Mitsutoshi Aoe, Benjamin Levy, Kevin Cox, Kyle J Strand, Joshua Dawson and 4 more@gbutler69 I think it's about the way you think of
Duration. If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative.You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Reacted by Florian Gilcher, Liigo Zhuang, Rob Watson, Joshua Dawson, Robin Brown and EntyIf it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative.
Here is what I take issue with:
let t1 = std:time:SystemTime.now(); // ....long running computation happening... // System Clock Time changed back 5 hours (because it was wrong to begin with) outside the program // ....long running computation completed... let t2 = std:time:SystemTime.now(); let clock_time_between_events = t2.duration_since( t1 ); // returns an error instead of negative duration, so I must do... let ( clock_time_between_events, neg_duration ) = match ( clock_time_between_events ) { Some(duration) => ( duration, false ) _ => ( t1.duration_since( t2 ).unwrap(), true ) }
And....DING! DING! DING! ....you know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
Reacted by Laurențiu Nicola, Jesse Wright, Martin Pool, Tux3, Joshua Dawson, Anders Musikka and Robin BrownYou can use https://doc.rust-lang.org/std/time/struct.Instant.html if you want to measure a duration.
You can use https://doc.rust-lang.org/std/time/struct.Instant.html if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error>, but, instead return ClockTimeDifference. It could be as simple as:
struct ClockTimeDifference { duration : Duration, is_negative : bool }
It can, but the return type of
duration_sincewill never change, so it's up to you (or a crate) to implement that.@gbutler69 @lnicola This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the internals.rust-lang.org site.
Reacted by Laurențiu Nicola and Jack O'ConnorWhy can't as_millis return an i64?
Pardon my ignorance, but why is this unstable? For my usecase, I probably don't need more than a
u32, and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have au128, but I'm just not sure what to do here for my code which I'm trying to keep as close to fully stable as possible (I want it to be as portable and safe as I can make it).I know (I think?) I can use
d.as_secs() * 1_000_000u64 + d.subsec_micros() as u64, but I'd rather not lose the precision and I think I can always useu128for all my platforms.Reacted by Keziah Biermann and PSeitz4 remaining items
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
pub fn as_millis(&self) -> u128 {…} pub fn as_micros(&self) -> u128 {…} pub fn as_nanos(&self) -> u128 {…}
This may be a stupid question, but is
u128available on all platforms that Rust supports?Reacted by Ben Berman🔔 This is now entering its final comment period, as per the review above. 🔔
The final comment period, with a disposition to merge, as per the review above, is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
- added a commit that references this issue
on Dec 26, 2018
Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability.
CC: #50167