]> git.lizzy.rs Git - rust.git/commit
auto merge of #16626 : ruud-v-a/rust/duration-reform, r=brson
authorbors <bors@rust-lang.org>
Thu, 28 Aug 2014 22:11:18 +0000 (22:11 +0000)
committerbors <bors@rust-lang.org>
Thu, 28 Aug 2014 22:11:18 +0000 (22:11 +0000)
commit1a33d7a54170cd2904cebc7a6fd2d1da471ff64e
tree19443a53e9632978ba4db74ed71b931e3f370975
parentba39b50943aa55790f79ccdebc446b0f7e6d0d3f
parent447b64ebc28b0104a8121b4318bbd2970de2cc56
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.
src/libstd/io/net/tcp.rs
src/libstd/io/net/unix.rs