Change:
/// Multiplies `Duration` by `f32`. /// /// # Panics <del> /// This method will panic if result is not finite, negative or overflows `Duration`. </del> <ins> /// This method will panic if result is negative, overflows `Duration` or not finite. </ins> /// /// # Examples /// ``` /// use std::time::Duration; /// /// let dur = Duration::new(2, 700_000_000); <del> /// // note that due to rounding errors result is slightly different /// // from 8.478 and 847800.0 </del> /// assert_eq!(dur.mul_f32(3.14), Duration::new(8, 478_000_640)); <del> /// assert_eq!(dur.mul_f32(3.14e5), Duration::new(847799, 969_120_256)); </del> <ins> /// assert_eq!(dur.mul_f32(3.14e5), Duration::new(847800, 0)); </ins> /// ``` #[stable(feature = "duration_float", since = "1.38.0")] #[must_use = "this returns the result of the operation, 

Discussion:
Hello. I am diagnosing why I've got a wrong duration computed from Duration::fromsecsf32()... I tried this code: I expected to see an exact 30-second duration. Instead, I've got this: which is: 30 seconds and 1024 nanos. I dig deeper into rust code and I've prepared a sample code which is computing it based on the source code: As the result I've got: Instead of exact 30 seconds and 0 nanos.
?
Works on current stable and nightly: I mean, that this issue exist for that versions.
yep, I also confirmed on:
What is interesting the function: fromsecsf64 doesn't seem to have this problem... so a quick workaround would be use it and cast from f32 to f64
Extending(?) f32 to u128 gives this addition in 1024:
CC: CC: Adding authors ... guys please take a quick look if you have a time...
f32 will naturally have trouble representing all possible nanosecond values and so doing calculations in f64 may help here somewhat. However the most appropriate approach would be to decompose the float into the whole part and the fractional part and then operate on the two separately to produce the values necessary to create the . and may work sufficiently well for the purpose. EDIT: I think we would still need to be careful about how the nanosecond fraction is handled. We cannot simply multiply the number by and then convert to an integer, because is not capable of representing integers of such degree losslessly.
We cannot simply multiply the number by and then convert to an integer, because f32 is not capable of representing integers of such degree losslessly. Small correction: is represented exactly by , the problem is with . The closest float is , which results in the 1024 ns error. For example, would have produced an exact value. I would say such loss of precision is expected for and if you want exact values, you should use the integer based methods. So I don't think this issue should be marked as a bug. It could be worthwhile to improve the code by processing the fractional part separately, but note that it will not solve this issue fundamentally. We still have the issue of mapping at most 23 fractional bits into ~30 bits, e.g. calling would still result in an inexact result.

specifically may be representable exactly, but f32 cannot represent all integers exactly. Though maybe its not a huge deal if after we end up roundtripping back to the actual integer in all cases.
Argh, I forgot that the method is not available on , so the linked PR will not work out of box. UPD: I have implemented manual fraction/exponent splitting and their conversion to integers.