URL: <https://savannah.gnu.org/bugs/?68745>
Summary: Bug in rounding logic in time command
Group: The GNU Bourne-Again SHell
Submitter: None
Submitted: Wed 07 Oct 2026 12:27:26 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
Item Group: None
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Unlocked
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Wed 07 Oct 2026 12:27:26 PM UTC By: Anonymous
== Bug description and steps to reproduce ==
When running _time_ on a command that takes just under a whole amount of
seconds (the _sec_fraction_ argument of _mkfmt_ is >= 999500), the output
displays a colon (:, just after 9 in ASCII) instead of the correct most
significant digit after the decimal point.
Tested on:
- Arch Linux package -- GNU bash, version 5.3.20(1)-release
(x86_64-pc-linux-gnu)
- Arch Linux with bash built from source
(https://git.savannah.gnu.org/git/bash.git @
9c465866b7d849378369ef700cbe2965aa9691e3)
== Reproduction with the default Bash format ==
$ time sleep .9945
real 0m0.:00s
user 0m0.001s
sys 0m0.004s
$ time sleep 1.9975
real 0m1.:00s
user 0m0.001s
sys 0m0.001s
You might not get it on the first try. If the reported real time is less that
than the whole-second boundary, slightly increase the sleep duration. If it's
greater than or equal to the boundary, try a slightly shorter duration.
== Reproduction with a custom time format (easier) ==
$ TIMEFORMAT=%1R
$ time sleep .95
0.:
$ time sleep 1.95
1.:
== Bug cause ==
The bug is caused by the rounding-up logic in _mkfmt_ of _execute_cmd.c_;
these two lines in particular (1307-1308 on 9c465866):
if (rest >= maxval/2)
frac++;
== Possible solutions ==
(sorted from easiest to hardest)
1. Delete those two lines. The simplest solution, but results in a floored
value (would not be a problem for me at all, but others might have a different
opinion).
2. Handle this as a special case, i.e., don't round up if the result would
exceed .9. This seems to me even worse than 1. since .0 corresponds to
[.00,.05) (half of the size of the ranges of other digits) but .9 corresponds
to [.85,1.00) (1.5 as large as for other digits, 3 times as large as the range
of .0).
3. Move the rounding logic elsewhere, where it can properly affect higher
units (seconds, minutes).
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68745>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
