[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