diff options
| author | bors <bors@rust-lang.org> | 2014-08-28 22:11:18 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2014-08-28 22:11:18 +0000 |
| commit | 1a33d7a54170cd2904cebc7a6fd2d1da471ff64e (patch) | |
| tree | 19443a53e9632978ba4db74ed71b931e3f370975 /src/libcore/iter.rs | |
| parent | ba39b50943aa55790f79ccdebc446b0f7e6d0d3f (diff) | |
| parent | 447b64ebc28b0104a8121b4318bbd2970de2cc56 (diff) | |
| download | rust-1a33d7a54170cd2904cebc7a6fd2d1da471ff64e.tar.gz rust-1a33d7a54170cd2904cebc7a6fd2d1da471ff64e.zip | |
auto merge of #16626 : ruud-v-a/rust/duration-reform, r=brson
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.
Diffstat (limited to 'src/libcore/iter.rs')
0 files changed, 0 insertions, 0 deletions
