-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
libstd: Refactor Duration. #16626
libstd: Refactor Duration. #16626
Conversation
This changes the internal representation of `Duration` from days: i32, secs: i32, nanos: u32 to secs: i64, nanos: i32 This resolves rust-lang#16466. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds.
2^63 milliseconds is just shy of 300 million years. Do we really need to support the full range that i64 seconds gives us? It might be a better API to just restrict |
We could restrict it to |
As I said on the previous PR, I think it's acceptable for |
This enables `num_milliseconds` to return an `i64` again instead of `Option<i64>`, because it is guaranteed not to overflow. The Duration range is now rougly 300e6 years (positive and negative), whereas it was 300e9 years previously. To put these numbers in perspective, 300e9 years is about 21 times the age of the universe (according to Wolfram|Alpha). 300e6 years is about 1/15 of the age of the earth (according to Wolfram|Alpha).
The failures don’t seem to be related to the changes ... is there something I should fix? |
assert!(Duration::days(MAX_DAYS).checked_add(&Duration::seconds(86400)).is_none()); | ||
assert_eq!(Duration::milliseconds(i64::MAX - 1).checked_add(&Duration::microseconds(999)), | ||
Some(Duration::milliseconds(i64::MAX - 2) + Duration::microseconds(1999))); | ||
assert!(Duration::milliseconds(i64::MAX).checked_add(&Duration::microseconds(1000)).is_none()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is too long, according to make tidy
.
The failure was
This is indeed something you need to fix. |
This changes the internal representation of `Duration` from days: i32, secs: i32, nanos: u32 to secs: i64, nanos: i32 This resolves #16466. Note that `nanos` is an `i32` and not `u32` as suggested, because `i32` is easier to deal with, and it is not exposed anyway. Some methods now take `i64` instead of `i32` due to the increased range. Some methods, like `num_milliseconds`, now return an `Option<i64>` instead of `i64`, because the range of `Duration` is now larger than e.g. 2^63 milliseconds. A few remarks: - Negating `MIN` is impossible. I chose to return `MAX` as `-MIN`, but it is one nanosecond less than the actual negation. Is this the desired behaviour? - In `std::io::timer`, some functions accept a `Duration`, which is internally converted into a number of milliseconds. However, the range of `Duration` is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds? - Negative durations are not formatted correctly, but they were not formatted correctly before either.
This changes the `Add` and `Sub` implementations for `Timespec` introduced in #16573 to use `Duration` as the time span type instead of `Timespec` itself, as [suggested](#16573 (comment)) by @sfackler. This depends on #16626, because is uses `Duration::seconds(i64)`, whereas currently `Duration::seconds` takes an `i32`.
This changes the internal representation of
Duration
fromto
This resolves #16466. Note that
nanos
is ani32
and notu32
as suggested, becausei32
is easier to deal with, and it is not exposed anyway. Some methods now takei64
instead ofi32
due to the increased range. Some methods, likenum_milliseconds
, now return anOption<i64>
instead ofi64
, because the range ofDuration
is now larger than e.g. 2^63 milliseconds.A few remarks:
MIN
is impossible. I chose to returnMAX
as-MIN
, but it is one nanosecond less than the actual negation. Is this the desired behaviour?std::io::timer
, some functions accept aDuration
, which is internally converted into a number of milliseconds. However, the range ofDuration
is now larger than 2^64 milliseconds. There is already a FIXME in the file that this should be addressed (without a ticket number though). I chose to silently use 0 ms if the duration is too long. Is that right, as long as the backend still uses milliseconds?