Alex Nelson wrote:
On Dec 13, 2011, at 02:04 , Jim Meyering wrote:
> Alex Nelson wrote:
...
>> is an additional test that shows what the actual behavior of
nstrftime
>> is, though I don't know if that's what the expected behavior is. I
>> would expect 10 nanoseconds to be reported as "0.00000001" seconds,
>> not "0.000000010".
>
> The %N directive is defined to produce zero-padded nanoseconds.
Ok. I haven't been able to find this with Google; where is it documented?
date --help gives a clue:
%N nanoseconds (000000000..999999999)
> As such, it must represent 10 as 000000010, not 00000001.
> If you choose to put that string after a decimal point, you're
> changing the semantics to "fractional seconds", at which
> point you can safely post-process it to remove trailing '0's.
Post-processing to remove 0's seems less efficient to me than not
You're worried about run-time efficiency? If that's it, I suggest
that you measure first.
If you're worried about your coding efficiency, that would have
to be balanced against changing a long-established API that is
in use by everything from coreutils to emacs. (i.e., it won't change)
> producing the trailing 0's at all. I take it there is no
similar
> nanosecond % directive that prints down to the most significant
...
> If you can settle for less resolution, you may want to use e.g.,
%6N or %3N:
>
> $ date +%T.%3N
> 11:03:00.728
>
> $ date +%T.%6N
> 11:03:01.463570
It's my preference to not restrict the resolution. Come to
think
about it, this %nN directive could afford to go into that
test-strftime program, too. I'll submit another patch once the first
one goes through.
Please just combine them into one, since they're so small and similar.