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