Date in milliseconds on OpenWRT on Arduino YUN

On OpenWRT, date is 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.

hwclock calls 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.

Normal version, adjtimex -p, last line of output:

   raw time:  1416419719s 146628us = 1416419719.146628

Busybox version, adjtimex (without -p !), last 3 lines:

   [...]
   time.tv_sec:  1416420386
   time.tv_usec: 732653
   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 %N and %:z and a few other changes. Variations and patched versions of strftime() abound (including versions in bash and gawk).

If you have a C compiler on it and can't find anything else, this will report, e.g.

> millitime && sleep 1 && millitime
14/11/2014 9:39:49:364
14/11/2014 9:39:50:368

#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <sys/time.h>
#include <time.h>

int main (void) {
    struct timeval now;
    struct tm *parsed;

    if (gettimeofday(&now, NULL) == -1) {
        fprintf (
            stderr,
            "gettimeofday() failed: %s\n",
            strerror(errno)
        );
        return 1;
    }

    parsed = localtime((const time_t*)&now.tv_sec);
    if (!parsed) {
        fprintf (
            stderr,
            "localtime() failed: %s\n",
            strerror(errno)
        );
        return 1;
    }

    printf (
        "%d/%d/%d %d:%02d:%02d:%03d\n",
        parsed->tm_mday,
        parsed->tm_mon + 1,
        parsed->tm_year + 1900,
        parsed->tm_hour,
        parsed->tm_min,
        parsed->tm_sec,
        now.tv_usec / 1000
    );

    return 0;
}  

With gcc, just compile it gcc whatever.c -o millitime. If there's an error (which would be very weird), it reports to stderr and exits with a status of 1. Otherwise it reports to stdout and exits 0.

The milliseconds are rounded down from microseconds.

Actually there is also a package called coreutils-date! Didn't know about it! There all standard functionality is included!