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

[Jim Meyering]

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