Estoy usando OpenWRT en Arduino YUN y estoy tratando de obtener la fecha exacta en milisegundos (DD/MM/YYYY h:min:sec:ms) obteniendo la hora de un servidor de hora.
Desafortunadamente date +%N simplemente devuelve %N , pero no los nanosegundos. Escuché +%N no está incluido en la fecha de OpenWRT.
Entonces, ¿hay alguna forma de obtener la fecha (incluidos los milisegundos) como la quiero?
Respuesta aceptada:
En OpenWRT, date es busybox , que tiene limitaciones, pero esta no es estrictamente una de ellas. El problema subyacente es que libc (uClibc) no es compatible con esta extensión GNU strftime. (Aunque tampoco glibc, más sobre eso a continuación).
Deberías tener lua por defecto, pero eso no ayudará sin otros módulos no predeterminados.
hwclock llama a gettimeofday() para comparar/configurar el RTC (reloj de hardware), pero no generará una resolución inferior a un segundo (el acceso a los RTC puede ser lo suficientemente lento como para que no sea útil de todos modos). Aparte de eso, OpenWRT solo proporciona la antigua rdate , que solo tiene una resolución de segundos enteros.
Parece que no hay una forma sencilla de obtener una marca de tiempo precisa directamente desde /proc , la marca de tiempo más útil está en /proc/timer_list (tercera línea) que es el tiempo de actividad en nanosegundos (la resolución dependerá de la plataforma).
Si su busybox fue construido con CONFIG_BUSYBOX_CONFIG_ADJTIMEX establecido, entonces debería poder usar adjtimex para leer el reloj del núcleo (aunque tenga en cuenta que la versión de busybox tiene ambos diferentes argumentos y salida diferente al estándar adjtimex.
Versión normal, adjtimex -p , última línea de salida:
raw time: 1416419719s 146628us = 1416419719.146628
Versión Busybox, adjtimex (sin -p !), últimas 3 líneas:
[...]
time.tv_sec: 1416420386
time.tv_usec: 732653
return value: 0 (clock synchronized)
Goldilocks es una buena solución, suponiendo que tenga su configuración de compilación cruzada OpenWRT (¡muy recomendable!).
Su coreutils-date La solución funciona porque aunque coreutils es compatible con glibc, no es exclusivamente glibc. Viene con su propia implementación independiente de strftime (derivado de glibc), y lo usa para concluir (a través de strftime_case() ) el strftime subyacente para admitir varias extensiones (y, de lo contrario, recurre a la versión uClibc).
Incluso glibc (hasta la versión 2.23 actual) no es compatible con %N , los coreutils strftime() derivado de la versión canónica de glibc agrega %N y %:z y algunos otros cambios. Variaciones y versiones parcheadas de strftime() abundan (incluyendo versiones en bash y gawk).