busybox, which has limitations, but this is not strictly one of them. The underlying problem is that the libc (uClibc) does not support this GNU strftime extension. (Though neither does glibc, more on that below.)
You should have
lua by default, but that won't help without some other non-default modules.
gettimeofday() for comparing/setting the RTC (hardware clock), but it won't output sub-second resolution (accessing RTCs can be sufficient slow that it might not be useful anyway). Other than that OpenWRT only provides the ancient
rdate, which only has whole-second resolution.
There appears to be no straightforward way to get an accurate time stamp directly from
/proc, the most useful time stamp is in
/proc/timer_list (3rd line) which is the uptime in nanoseconds (the resolution will depend on the platform).
If your busybox was built with
CONFIG_BUSYBOX_CONFIG_ADJTIMEX set, then you should be able to use
adjtimex to read the kernel clock (though note that the busybox version has both different arguments and different output to the standard adjtimex.
adjtimex -p, last line of output:
raw time: 1416419719s 146628us = 1416419719.146628
-p !), last 3 lines:
return value: 0 (clock synchronized)
Goldilocks's is a fine solution, assuming you have your OpenWRT cross build setup (highly recommended!).
Your coreutils-date solution works because while coreutils is glibc aware, it is not exclusively glibc. It comes with its own standalone implementation of
strftime (derived from glibc), and uses that to wrap up (via
strftime_case()) the underlying
strftime so as to support various extensions (and falls back to the uClibc version otherwise).
Even glibc (up to the current 2.23) doesn't support
%N, the coreutils
strftime() derived from the canonical glibc version adds
%:z and a few other changes. Variations and patched versions of
strftime() abound (including versions in bash and gawk).