[Libguestfs] [hivex][PATCH] Increase filetime printing resolution to sub-second

[Alex Nelson]

On Dec 13, 2011, at 02:04 , Jim Meyering wrote:

> Alex Nelson wrote:
> 
>> I tried using the nstrftime function instead of strftime; strftime
>> didn't seem to recognize %N, even when I included gnulib's strftime.h
>> header.  Then the %N format added trailing zeroes I wasn't expecting.
>> Unfortunately, the test-strftime.c file didn't include a test for
>> nanosecond-resolution display, so I wasn't sure if this was a problem
>> with my call or the %N specification.
>> 
>> I've produced a patch for gnulib to demonstrate what I was missing,
>> attached.  Jim, should I submit it to the bug-gnulib mailing list?  It
> 
> Hi Alex,
> 
> Yes, the test case addition would be welcome on bug-gnulib.
Thanks, I've submitted it.
> 
>> 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?

> 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 producing the trailing 0's at all.  I take it there is no similar nanosecond % directive that prints down to the most significant digit?
> 
>> The second attached patch uses nstrftime, and gives funny-looking
>> results.  For example, here are the first two mtimes of hivexml's
>> output on hivex/images/large, line 1 for the first version of this
>> patch, line 2 using nstrftime:
>> 
>> <hive><mtime>2010-02-02T13:42:52.27Z</mtime><node name="$$$PROTO.HIV"
>> root="1"><mtime>2010-02-02T13:42:44.626Z</mtime>
>> <hive><mtime>2010-02-02T13:42:52.270000000Z</mtime><node
>> name="$$$PROTO.HIV"
>> root="1"><mtime>2010-02-02T13:42:44.626000000Z</mtime>
>> 
>> I'm partial to the first version's output.
> 
> 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.

Thanks, Jim!

--Alex