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. _______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
