date: strftime ignores flags and widths on %N (nanoseconds)

[sylvestre]

Summary

GNU date honours strftime flags and widths on %N (nanoseconds). uutils ignores or mishandles them: %_3N should space-pad to width 3, and %-N should still emit the full 9-digit default, but uutils emits a single 0.

Found by a fuzz_date run.

Reproduction

$ LC_ALL=C TZ=UTC /usr/bin/date -d '@0' '+%_3N' | od -c | head -1
0000000   0                \n

$ LC_ALL=C TZ=UTC target/debug/coreutils date -d '@0' '+%_3N' | od -c | head -1
0000000   0  \n

$ LC_ALL=C TZ=UTC /usr/bin/date -d '@0' '+%-N'
000000000

$ LC_ALL=C TZ=UTC target/debug/coreutils date -d '@0' '+%-N'
0

Test

#[test]
fn test_date_strftime_n_width_and_flags() {
    new_ucmd!()
        .env("LC_ALL", "C")
        .env("TZ", "UTC")
        .arg("-d")
        .arg("@0")
        .arg("+%_3N")
        .succeeds()
        .stdout_is("0  \n");

    new_ucmd!()
        .env("LC_ALL", "C")
        .env("TZ", "UTC")
        .arg("-d")
        .arg("@0")
        .arg("+%-N")
        .succeeds()
        .stdout_is("000000000\n");
}

[dragutreis]

Hello, I've been looking into this issue and put together a fix that properly handles %N precision (width) and flags like _ for space-padding and - for no-padding, matching how GNU date behaves. I've also added unit tests to confirm the fix and tested it against GNU coreutils 9.10. Could I submit a pull request with these changes?