[Libguestfs] [hivex][PATCH] Increase filetime printing resolution to sub-second
Jim Meyering
jim at meyering.net
Wed Dec 14 11:39:36 UTC 2011
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.
More information about the Libguestfs
mailing list