J'utilise OpenWRT sur l'Arduino YUN et j'essaie d'obtenir la date exacte en millisecondes (JJ/MM/AAAA h:min:sec:ms) en obtenant l'heure par un serveur de temps.
Malheureusement date +%N renvoie simplement %N , mais pas les nanosecondes. J'ai entendu +%N n'est pas inclus dans la date OpenWRT.
Existe-t-il un moyen d'obtenir la date (y compris les millisecondes) comme je le souhaite ?
Réponse acceptée :
Sur OpenWRT, date est busybox , qui a ses limites, mais ce n'en est pas strictement une. Le problème sous-jacent est que la libc (uClibc) ne prend pas en charge cette extension GNU strftime. (Bien que glibc non plus, plus d'informations ci-dessous.)
Vous devriez avoir lua par défaut, mais cela n'aidera pas sans d'autres modules non par défaut.
hwclock appelle gettimeofday() pour comparer/régler le RTC (horloge matérielle), mais il ne produira pas une résolution inférieure à la seconde (l'accès aux RTC peut être suffisamment lent pour ne pas être utile de toute façon). En dehors de cela, OpenWRT ne fournit que l'ancien rdate , qui n'a qu'une résolution d'une seconde entière.
Il semble n'y avoir aucun moyen simple d'obtenir un horodatage précis directement à partir de /proc , l'horodatage le plus utile se trouve dans /proc/timer_list (3ème ligne) qui est le temps de disponibilité en nanosecondes (la résolution dépendra de la plate-forme).
Si votre busybox a été construite avec CONFIG_BUSYBOX_CONFIG_ADJTIMEX set, alors vous devriez pouvoir utiliser adjtimex pour lire l'horloge du noyau (notez cependant que la version busybox a les deux différents arguments et une sortie différente de l'adjtimex standard.
Version normale, adjtimex -p , dernière ligne de sortie :
raw time: 1416419719s 146628us = 1416419719.146628
Version Busybox, adjtimex (sans -p !), 3 dernières lignes :
[...]
time.tv_sec: 1416420386
time.tv_usec: 732653
return value: 0 (clock synchronized)
Goldilocks est une bonne solution, en supposant que vous ayez votre configuration de construction croisée OpenWRT (fortement recommandé !).
Votre coreutils-date La solution fonctionne car bien que coreutils soit conscient de glibc, ce n'est pas exclusivement glibc. Il est livré avec sa propre implémentation autonome de strftime (dérivé de glibc), et l'utilise pour conclure (via strftime_case() ) le strftime sous-jacent afin de prendre en charge diverses extensions (et revient à la version uClibc dans le cas contraire).
Même la glibc (jusqu'à la version 2.23 actuelle) ne prend pas en charge %N , les coreutils strftime() dérivé de la version canonique de la glibc ajoute %N et %:z et quelques autres changements. Variations et versions corrigées de strftime() abondent (y compris les versions en bash et gawk).