Change:
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:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand 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.
I think it's about the way you think of . 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.
Here is what I take issue with: And....DING! DING! DING! 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).
You can use 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:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
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 site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable? For my usecase, I probably don't need more than a , and I really only need millis (though the code I'm porting happens to use microseconds). I'd rather have a , 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 , but I'd rather not lose the precision and I think I can always use for all my platforms.
is there any reason not to move forward with stabilization on this? correctly observes that it has been unstable for quite a while
The stability of u128 was the blocker previously, but that's now no longer a problem. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [ ] 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 for info about what commands tagged team members can give me.
I couldn’t find all the details in this issue, grepping through the code shows that this tracking issue is for:
This may be a stupid question, but is available on all platforms that Rust supports?
:bell: This is now entering its final comment period, as per the . :bell:
Yep, it should be available on all platforms.
The final comment period, with a disposition to merge, as per the , is now complete.
Now that final comment period has ended, can these methods be stabilized?
Yes, the next step is a stabilization PR.
Awesome! I've made a PR for stabilization here: Please let me know if it needs any adjustments. I can't wait for this to land! :tada:

Discussion:
<del> #![feature(duration_as_u128)] </del> <ins> #![cfg_attr(stage0, feature(duration_as_u128))] </ins> use std::{collections::VecDeque, time::Instant}; const VECDEQUE_LEN: i32 = 100000;

/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_millis(), 5730); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_millis(&self) -> u128 { self.secs as u128 * MILLIS_PER_SEC as u128 + (self.nanos / NANOS_PER_MILLI) as u128

/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_micros(), 5730023); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_micros(&self) -> u128 { self.secs as u128 * MICROS_PER_SEC as u128 + (self.nanos / NANOS_PER_MICRO) as u128

/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_nanos(), 5730023852); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_nanos(&self) -> u128 { self.secs as u128 * NANOS_PER_SEC as u128 + self.nanos as u128

#![feature(const_cstr_unchecked)] #![feature(core_intrinsics)] #![feature(dropck_eyepatch)] <del> #![feature(duration_as_u128)] </del> <ins> #![cfg_attr(stage0, feature(duration_as_u128))] </ins> #![feature(exact_size_is_empty)] #![feature(external_doc)] #![feature(fixed_size_array)]