Skip to content

stat: truncate fractional pre-epoch timestamps toward zero - #14975

Open
mattsu2020 wants to merge 2 commits into
uutils:mainfrom
mattsu2020:stat-nanoseconds.sh
Open

mattsu2020 wants to merge 2 commits into
uutils:mainfrom
mattsu2020:stat-nanoseconds.sh

Conversation

@mattsu2020

@mattsu2020 mattsu2020 commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor

Fractional pre-epoch timestamps round away from zero when reducing precision, so %.3Y prints -0.877 instead of -0.876. Truncate fractional output toward zero while preserving floor-based integer seconds and the sign of negative values truncated to zero. Add Rust regression tests.

Refs #14705 (stat/stat-nanoseconds.sh).

Validated with 10 stat unit tests, 39 stat integration tests, rustfmt, and clippy.
close #14976

@mattsu2020
mattsu2020 marked this pull request as draft September 30, 2026 09:32
@xtqqczze

This comment was marked as resolved.

@github-actions

github-actions Bot commented Sep 30, 2026 •

Copy link
Copy Markdown

GNU testsuite comparison:

Congrats! The gnu test tests/stat/stat-nanoseconds is no longer failing!

@mattsu2020
mattsu2020 marked this pull request as ready for review September 30, 2026 10:21
@xtqqczze

Copy link
Copy Markdown
Collaborator

Should we fix format_scaled_decimal instead?

@mattsu2020

mattsu2020 commented Sep 30, 2026 •

Copy link
Copy Markdown
Contributor Author

Should we fix format_scaled_decimal instead?

Should we pass the original sign to format_scaled_decimal?
once the value is truncated to zero,
format_scaled_decimal no longer knows whether the original value was negative

@xtqqczze

Copy link
Copy Markdown
Collaborator

I’m not particularly fond of the existing approach. It might be worth considering whether we should use a crate that explicitly supports rounding, such as rust_decimal.

Comment thread src/uu/stat/src/stat.rs
Comment thread src/uu/stat/src/stat.rs Outdated
@mattsu2020

Copy link
Copy Markdown
Contributor Author

I’m not particularly fond of the existing approach. It might be worth considering whether we should use a crate that explicitly supports rounding, such as rust_decimal.

rust_decimal makes sense if we want to share rounding behavior across utilities like stat, printf, numfmt, and seq.
For stat alone, keeping the current integer-based approach may be simpler.
I wonder if this will affect performance.

@codspeed

codspeed Bot commented Sep 30, 2026

Copy link
Copy Markdown

Merging this PR will degrade performance by 2.31%

⚡ 2 improved benchmarks
❌ 1 regressed benchmark
✅ 390 untouched benchmarks
⏩ 54 skipped benchmarks1

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

Mode Benchmark BASE HEAD Efficiency
❌ Simulation three_39_bit_primes 346.9 ms 415.8 ms -16.57%
⚡ Simulation five_38_bit_primes 1.8 s 1.7 s +6.11%
⚡ Simulation thirteen_39_bit_primes 9.4 s 8.9 s +5.32%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.


Comparing mattsu2020:stat-nanoseconds.sh (6d18249) with main (cacdd8d)

Open in CodSpeed

Footnotes

  1. 54 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

@xtqqczze

Copy link
Copy Markdown
Collaborator

Benchmark variance tracked by #14921.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

stat: incorrect rounding of fractional pre-epoch timestamps with precision

3 participants