Better Display implementation for Duration
Nobody has claimed this yet.
- Dominant language
- Markdown
- Stars
- 6.6k
- Forks
- 1.7k
- Avg merge
- 16h 14m
- Merged PRs (30d)
- 1
Description
The brand new time::Duration type has a rather odd choice for its Display. It's attempting to show the smallest unit that doesn't lose any precision, unless the duration is at least 1 second, at which point it discards all sub-second precision. This is very odd, because it means that round numbers change units, so e.g. 252999ns, 253000ns, and 253001ns display respectively as 252999ns, 253µs, and 253001ns.
I would suggest that it should display using the largest unit that is <= the duration, in a floating-point format with zero to three decimals of precision (with rounding). This would mean that 2000ns would display as 2µs, 2001ns would display as 2.001µs, and 2100ns would display as 2.1µs. The cap of 3 decimal places of precision is because anything beyond that is likely to be irrelevant, and humans don't really like reading long numbers without grouping separators, and we especially don't like trying to compare two numbers that have significantly different amounts of precision.
Examples
| Duration | Display |
|---|---|
| 1ns | 1ns |
| 1_000ns | 1µs |
| 1_000_000ns | 1ms |
| 1_000_000_000ns | 1s |
| 999ns | 999ns |
| 1_001ns | 1.001µs |
| 1_100ns | 1.1µs |
| 1_234_567ns | 1.235ms |
| 1_234_567_890ns | 1.235s |
| 1_000_000_001ns | 1s |
| 1_000_999_999ns | 1.001s |
We might also want to support the precision flag, so you can say e.g. {:.3} to always force 3 digits of precision.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by locating the time::Duration implementation and its current Display behavior; no file or test path is named in the issue. Compare the existing output with the examples, then define and test the proposed unit selection, rounding, precision, and optional precision-flag behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100