date: width prefix in %N format specifier is ignored ( %3N, %6N always output full 9 nanosecond digits)

[danielzgtg]

From https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2150342 . One can make GNU Coreutils limit the output to 3 digits but uutils fails. Tested with rust-coreutils=0.8.0-0ubuntu3 and 26223ad.

The downstream bug report follows:

This is difference about gnudate/date command behaviour about nanosecond syntax.

The date format specifier "%N" supports an optional decimal-width prefix with gnudate (e.g. %3N for milliseconds, %6N for microseconds) that truncates the nanosecond string to the first N characters.

However uutils date ignores this prefix and always outputs all 9 digits without warnings, it might break backward compatibility that rely on date +%s%3N to obtain millisecond-resolution epoch timestamps.

Steps to reproduce

date +%3N # expected: 3 digits; actual: 9 digits
date +%6N # expected: 6 digits; actual: 9 digits
date +%s%3N # expected: 13-digit epoch-ms; actual: 19-digit epoch-ns

Expected (gnudate)

$ gnudate +%3N
111
$ gnudate +%6N
111935
$ gnudate +%T.%3N
10:00:39.110
$ gnudate +%s%3N
1777165239109

Actual (uutils date 0.8.0)

$ date +%3N
100952336
$ date +%6N
103515189
$ date +%T.%3N
10:00:39.97839160
$ date +%s%3N
177716523994933752

Assumption

GNU coreutils documents %N as:

%N — nanoseconds (000000000..999999999)
A leading decimal number specifies left-justified field width; e.g. %3N yields the first 3 digits (milliseconds).

uutils outputs 9 digits regardless of the width prefix. The width value appears to be parsed and then discarded.

Note that %9N (full nanoseconds, no truncation needed) produces correct output in both implementations.

Typical workaround

Replace date +%s%3N with date +%s%N and divide the difference by 1000000, like:

start=$(date +%s%N)
# ... work ...
elapsed=$(( ($(date +%s%N) - start) / 1000000 )) # milliseconds