Improve precision of Duration-float operations by eggyal · Pull Request #150933 · rust-lang/rust

eggyal · 2026-01-10T17:52:10Z

Rather than convert Duration to a float in order to multiply or divide by a floating point number, which entails a loss of precision, we instead represent both operands as u128 nanoseconds and perform integer arithmetic thereupon.

This improvement in precision affects some of the documented examples.

Given that these methods have been stabilised, is it a breaking change to affect their output? If so, this PR obviously cannot be merged as-is: we might instead need to create new methods for this more precise calculation (and possibly deprecate the existing ones).

Fixes #149794
r? libs-api

rustbot · 2026-01-11T03:09:46Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

eggyal · 2026-01-12T03:22:52Z

@rustbot ready

eggyal · 2026-01-12T14:27:30Z

No, some corner cases are not quite right here. I'll add some more tests and push a fix.

@rustbot author

eggyal · 2026-01-12T18:35:41Z

@rustbot ready

tgross35 · 2026-03-04T06:43:33Z

@craterbot run mode=build-and-test

craterbot · 2026-03-04T06:43:55Z

👌 Experiment pr-150933 created and queued.
🤖 Automatically detected try build 8da2082
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

eggyal · 2026-03-04T11:17:40Z

Should we run crater while our own tests are failing? Surely I should fix that first!

tgross35 · 2026-03-04T11:33:47Z

The failure is just a changed panic string right? I don't expect anyone to be checking that

eggyal · 2026-03-04T13:45:28Z

We also were introducing new panics for some negative factors that previously yielded zero, which has been corrected in my latest push.

@rustbot ready

Rather than convert Duration to a float in order to multiply or divide by a floating point number, which entails a loss of precision, we instead represent both operands as u128 nanoseconds and perform integer arithmetic thereupon.

Amanieu · 2026-03-04T17:17:38Z

Once you get into floating-point arithmetic, some amount of precision loss is to be expected. I actually don't find it too surprising that multiplying by 1.0 would result in precision loss for very large durations. The main problem with the code in this PR is that it adds a huge amount of complexity for what is really an edge case. It would be more appropriate to just have a warning in the documentation which explains that this method may cause precision loss due to the use of floating-point arithmetic, even when multiplying with 1.0.

@rfcbot close libs

rust-rfcbot · 2026-03-04T17:17:41Z

Team member @Amanieu has proposed to close this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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 this document for info about what commands tagged team members can give me.

craterbot · 2026-03-05T18:04:49Z

🚧 Experiment pr-150933 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2026-03-08T01:27:46Z

🎉 Experiment pr-150933 is completed!
📊 358 regressed and 300 fixed (837236 total)
📊 3182 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-150933/retry-regressed-list.txt ↩

quaternic · 2026-03-18T17:31:53Z

@Amanieu

The main problem with the code in this PR is that it adds a huge amount of complexity for what is really an edge case.

I agree on the complexity, but I do still think the issue needs fixing. The current implementation doesn't follow the basic principle of floating point arithmetic: Compute the exact result and round to the output type. It doesn't make sense that Duration can represent aeons with nanosecond precision, but the rounding error of these operations can be thousands of years. Duration::MAX.div_f32(3.0) and Duration::MAX / 3 differ by ~5800 years.

The complexity of this PR is unfortunate, but it's mostly due to the ad hoc implementation of scaling an integer by a float. It could be significantly cleaned up with a hypothetical u128::checked_mul_f64(u128, f64) -> Option<u128>. In fact, f128::mul could be used for this as well; map the count of nanoseconds to the subnormal range of f128, do floating point multiplication (which does the proper rounding), and map back to an integer with a range check.

cuviper · 2026-03-19T17:35:49Z

If we want to keep the full Duration precision, then I think f128 is a much better way to manage the complexity -- see #154107.

A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like rust-lang#150933 or rust-lang#154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.

Document precision considerations of `Duration`-float methods A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like rust-lang#150933 or rust-lang#154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.

Rollup merge of #155133 - cuviper:duration_fp_docs, r=the8472 Document precision considerations of `Duration`-float methods A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like #150933 or #154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.

rust-bors · 2026-04-22T22:33:33Z

☔ The latest upstream changes (presumably #155655) made this pull request unmergeable. Please resolve the merge conflicts.

tgross35 · 2026-04-23T07:17:00Z

If the libs team would rather not take the complexity / slowdown here, then I think a good solution could be adding mul_f128 and div_f128, making sure that those are precise. Then in the {mul,div}_{f32,f64} docs make it clear that they might not be precise and to use *_f128 if you need it.

Document precision considerations of `Duration`-float methods A `Duration` is essentially a 94-bit value (64-bit sec and ~30-bit ns), so there's some inherent loss when converting to floating-point for `mul_f64` and `div_f64`. We could go to greater lengths to compute these with more accuracy, like rust-lang/rust#150933 or rust-lang/rust#154107, but it's not clear that it's worth the effort. The least we can do is document that some rounding is to be expected, which this commit does with simple examples that only multiply or divide by `1.0`. This also changes the `f32` methods to just forward to `f64`, so we keep more of that duration precision, as the range is otherwise much more limited there.

rustbot assigned BurntSushi Jan 10, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 10, 2026

eggyal commented Jan 10, 2026

View reviewed changes

Comment thread library/core/src/time.rs Outdated

quaternic reviewed Jan 10, 2026

View reviewed changes

Comment thread library/core/src/time.rs Outdated

quaternic reviewed Jan 10, 2026

View reviewed changes

Comment thread library/core/src/time.rs Outdated

eggyal marked this pull request as draft January 11, 2026 03:09

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 11, 2026

eggyal force-pushed the issue-149794 branch 2 times, most recently from 5844308 to adc30ec Compare January 11, 2026 15:14

This comment has been minimized.

Sign in to view

eggyal force-pushed the issue-149794 branch from adc30ec to 3caa936 Compare January 11, 2026 20:19

eggyal commented Jan 11, 2026

View reviewed changes

Comment thread library/core/src/time.rs Outdated

This comment has been minimized.

Sign in to view

eggyal force-pushed the issue-149794 branch from 3caa936 to a2e75b5 Compare January 12, 2026 03:21

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 12, 2026

eggyal marked this pull request as ready for review January 12, 2026 03:23

eggyal requested a review from quaternic January 12, 2026 03:23

eggyal force-pushed the issue-149794 branch 2 times, most recently from cf585ba to c7098b3 Compare January 12, 2026 10:48

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 12, 2026

eggyal marked this pull request as draft January 12, 2026 14:27

eggyal force-pushed the issue-149794 branch from c7098b3 to da6a534 Compare January 12, 2026 18:34

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 4, 2026

eggyal force-pushed the issue-149794 branch from 0138103 to df001fb Compare March 4, 2026 13:43

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 4, 2026

eggyal force-pushed the issue-149794 branch from df001fb to 8b98e60 Compare March 4, 2026 13:55

Improve precision of Duration-float operations

48a261c

Rather than convert Duration to a float in order to multiply or divide by a floating point number, which entails a loss of precision, we instead represent both operands as u128 nanoseconds and perform integer arithmetic thereupon.

eggyal force-pushed the issue-149794 branch from 8b98e60 to 48a261c Compare March 4, 2026 13:56

rust-rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 4, 2026

Amanieu removed the I-libs-nominated Nominated for discussion during a libs team meeting. label Mar 4, 2026

rust-rfcbot added the disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. label Mar 4, 2026

craterbot removed the S-waiting-on-crater Status: Waiting on a crater run to be completed. label Mar 8, 2026

cuviper mentioned this pull request Mar 19, 2026

Use f128 internally for Duration-float methods #154107

Closed

cuviper mentioned this pull request Apr 10, 2026

Document precision considerations of Duration-float methods #155133

Merged

Uh oh!

Conversation

eggyal commented Jan 10, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Jan 11, 2026

Uh oh!

This comment has been minimized.

Uh oh!

This comment has been minimized.

eggyal commented Jan 12, 2026

Uh oh!

eggyal commented Jan 12, 2026

Uh oh!

eggyal commented Jan 12, 2026

Uh oh!

tgross35 commented Mar 4, 2026

Uh oh!

craterbot commented Mar 4, 2026

Uh oh!

eggyal commented Mar 4, 2026

Uh oh!

tgross35 commented Mar 4, 2026

Uh oh!

eggyal commented Mar 4, 2026

Uh oh!

Amanieu commented Mar 4, 2026

Uh oh!

rust-rfcbot commented Mar 4, 2026 • edited by cuviper Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

craterbot commented Mar 5, 2026

Uh oh!

craterbot commented Mar 8, 2026

Footnotes

Uh oh!

quaternic commented Mar 18, 2026

Uh oh!

cuviper commented Mar 19, 2026

Uh oh!

rust-bors Bot commented Apr 22, 2026

Uh oh!

tgross35 commented Apr 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

eggyal commented Jan 10, 2026 •

edited by rustbot

Loading

rust-rfcbot commented Mar 4, 2026 •

edited by cuviper

Loading