Re: [Libguestfs] [hivex][PATCH] Increase filetime printing resolution to sub-second
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.
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.
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.
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