bug#34345: coreutils v.8.30 – Two fractional digits accuracy. Appropriate notation regarding time elapsed.

[Assaf Gordon]

severity 34345 wishlist
retitle 34345 dd: report elapsed time as HH:MM:SS.NNNNNNN
stop

Hello,

Ricky Tigg's original message was sent to address@hidden
(not to address@hidden), and did not create a new bug report:

   https://lists.gnu.org/r/coreutils/2019-02/msg00003.html

This is of course absolutely fine - but PLEASE keep the same mailing 
list when replying (e.g. don't reply to address@hidden if
the message was sent to address@hidden).

The original message said:

On 2019-02-06 2:36 a.m., Ricky Tigg wrote:
> Enhancements request
> Hi. Command executed:
>
> # dd if=/dev/zero of=/dev/sdc status=progress
> 8003555840 bytes (8.0 GB, 7.5 GiB) copied, 1994 s, 4.0 MB/s
> dd: writing to '/dev/sdc': No space left on device
> 15638481+0 records in
> 15638480+0 records out
> 8006901760 bytes (8.0 GB, 7.5 GiB) copied, 2014.25 s, 4.0 MB/s
>
>
>     - Could values reported at '(8.0 GB, 7.5 GiB)' be displayed using 
a two
>     fractional digits accuracy (model 1.23 GiB).

That is not likely to change.
The printing code uses a common function (human_readable) that is used
in several other coreutils programs, and the convention is to print up
to 3 digits (or 2 digits with one decimal point).
Examples:
   1.1 KB
    11 KB
   111 KB
    11 MB
   111 MB
   1.1 GB
    11 GB
   111 GB
   1.1 TB

The exact number of bytes is printed at the beginning of the line,
and you can use 'numfmt' to format it to your liking:

    $ dd if=/dev/zero of=/dev/zero bs=1M count=10 2>&1 \
          | tail -n1 | numfmt --to=si --format '%2.5f'
    10.48576M bytes (10 MB, 10 MiB) copied, 0.00315612 s, 3.3 GB/s


>     - Could values reported at '1994 s', '2014.25 s' to be displayed
>     according to notation <*hour*>*h*<*minutes*>*'*<*seconds*>*''*.

An interesting idea.
I couldn't find previous discussion about it, so I'll mark this item
as a "wishlist".

As always, patches are welcomed.

> Potential issue:
> Since values '1994 s', '2014.25 s' expressed here may in the present
> context cover nothing but a same object, non-identical values may be
> interpreted as a programming issue. Regards.

I don't understand the above - can you clarify ?

regards,
 - assaf