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

Tracking Issue: Duration::{as_nanos, as_micros, as_millis} #50202

Open
fintelia opened this Issue Apr 24, 2018 · 18 comments

Comments

Projects
None yet
9 participants
@fintelia
Contributor

fintelia commented Apr 24, 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

@Mark-Simulacrum Mark-Simulacrum changed the title from Duration should have an as_nanos function to Tracking Issue: Duration::as_nanos May 27, 2018

@sfackler sfackler added the B-unstable label Jun 2, 2018

@sfackler sfackler changed the title from Tracking Issue: Duration::as_nanos to Tracking Issue: Duration::{as_nanos, as_micros, as_millis} Jun 2, 2018

@gbutler69

This comment has been minimized.

gbutler69 commented Jul 4, 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.

@lnicola

This comment has been minimized.

Contributor

lnicola commented Jul 4, 2018

@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.

@gbutler69

This comment has been minimized.

gbutler69 commented Jul 4, 2018

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.

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).

@lnicola

This comment has been minimized.

Contributor

lnicola commented Jul 4, 2018

You can use https://doc.rust-lang.org/std/time/struct.Instant.html if you want to measure a duration.

@gbutler69

This comment has been minimized.

gbutler69 commented Jul 4, 2018

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
}
@lnicola

This comment has been minimized.

Contributor

lnicola commented Jul 4, 2018

It can, but the return type of duration_since will never change, so it's up to you (or a crate) to implement that.

@fintelia

This comment has been minimized.

Contributor

fintelia commented Jul 4, 2018

@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.

@NatTuck

This comment has been minimized.

NatTuck commented Jul 6, 2018

Why can't as_millis return an i64?

@sfackler

This comment has been minimized.

Member

sfackler commented Jul 7, 2018

@NatTuck large durations won't fit into that type.

@rivertam

This comment has been minimized.

Contributor

rivertam commented Nov 13, 2018

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 a u128, 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 use u128 for all my platforms.

@fintelia

This comment has been minimized.

Contributor

fintelia commented Nov 13, 2018

@sfackler is there any reason not to move forward with stabilization on this? @rivertam correctly observes that it has been unstable for quite a while

@sfackler

This comment has been minimized.

Member

sfackler commented Nov 13, 2018

The stability of u128 was the blocker previously, but that's now no longer a problem.

@rfcbot fcp merge

@rfcbot

This comment has been minimized.

rfcbot commented Nov 13, 2018

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@SimonSapin

This comment has been minimized.

Contributor

SimonSapin commented Nov 14, 2018

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 {…}
@lnicola

This comment has been minimized.

Contributor

lnicola commented Nov 14, 2018

This may be a stupid question, but is u128 available on all platforms that Rust supports?

@rfcbot

This comment has been minimized.

rfcbot commented Nov 14, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@sfackler

This comment has been minimized.

Member

sfackler commented Nov 14, 2018

@lnicola Yep, it should be available on all platforms.

@rfcbot

This comment has been minimized.

rfcbot commented Nov 24, 2018

The final comment period, with a disposition to merge, as per the review above, is now complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment