date: Improve nanosecond support

[des]

Summary

Add support for a field width, which defaults to 9 if unspecified or
zero. If the width is not exactly 9, we have to either cut off digits
or append zeroes to make up the difference. This brings us in line
with GNU coreutils, minus the %-N case which we do not handle.

PR: 287080
MFC after: 1 week

[0mp]

Thanks!

Could you also add a note to date.1 saying that %XN is now supported? A note in CAVEATS or BUGS that %-N is not supported would also be good.

[des]

add %-N, update documentation

[des]

pass resolution through printisodate just in case

[0mp]

The manual page changes and the code changes look OK. Thanks!

I've added a couple of comments you about things you may want to consider before pushing the change.

bin/date/date.1

349

1. Li is deprecated, so no need to use it here.
2. Since "-" is effectively a constant here, I'd just go with Cm \&%-N

350

Nit pick: you start here with upper-case "As above" even though in the previous point it's lower-case "where n is". If you care, you may choose to address it.

651–657

You may consider:

Support for
.Ql \&%-N
and custom precision of
.Ql \&%N
was added in
.Fx 16.0 .

bin/date/tests/format_string_test.sh

136

I suspect that adding a test case for -N is a bit annoying as it depends on the host's clock resolution.

[des]

bin/date/tests/format_string_test.sh

136

Yes, and that can even change at runtime. You _can_ in theory detect it:

tc=$(sysctl -n kern.timecounter.hardware)
freq=$(sysctl -n kern.timecounter.tc.$tc.frequency)
width=$(bc -le "min(l10($freq), 9)$")

but the test script uses the -r option, which forces nsec to 0 and res to 9, so %-N is indistinguishable from %N in testing; they both produce exactly 000000000.

[des]

further refinement

[0mp]

Thank you for addressing the nit picks :)