On Fri, Oct 17, 2025, 13:08 Chet Ramey <[email protected]> wrote:
>
> On 10/14/25 10:19 PM, Grisha Levit wrote:
> > Also, I'm assuming it was not intentional that values with a precision
> > of 0 were being truncated while all other precisions were rounded (but
> > maybe it was?).
>
> A zero precision just cuts the decimal point and everything following it.
> This is what ksh93 does, and consistent with what POSIX interp 267
> specified (the TIMEFORMAT part never actually made it into the standard).
I read that but didn't find anything that suggested a precision of 0 be
treated specially w.r.t. rounding. I think this is the relevant part of
the proposed text:
The optional p is a decimal digit specifying
the precision, the number of digits after the
decimal point. A value of 0 shall not display
the decimal point.
[...]
In the following three formats, <time> is the
<real time>, <user time>, or <system time> for
%R, %U, or %S, respectively.
For %R, %U, and %S, if l is not specified, the
output format shall be:
"%.<i>p</i>f", <time>
In the above three formats, <i>p</i> in the output
format represents the optional p specified
after the % in TIMEFORMAT.
>From which I would expect %0R to just behave like printf("%.0f", ...),
i.e., still round, rather than truncate, to an integer.
As for ksh93, AFAICT it truncates for all precision values, not just
for 0:
$ TIMEFORMAT='%0R %1R %2R %3R' ksh93 -c 'time sleep 0.993'
0 0.9 0.99 0.996
