Utilisation des timestamps Unix dans les systèmes embarqués, API et bases de données
Concevez l’horodatage de capteurs : RTC, NTP, horloges monotones, JSON et SQL, avec un exemple de synchronisation ESP32.
Une mesure de capteur exploitable associe une valeur, une référence temporelle et une indication de confiance. Unix time facilite les échanges, sans garantir à lui seul l’exactitude ou l’ordre des événements. Inspectez vos valeurs avec Convertisseur Unix Timestamp / Epoch et consultez Comprendre les timestamps Unix et l’Epoch Time pour les bases numériques.
RTC et horloge système
Une RTC matérielle maintient un calendrier ou un compteur pendant la veille du processeur, souvent avec une alimentation de secours. Elle n’est pas forcément configurée en UTC ni synchronisée. L’horloge système relie une base matérielle à une époque. Après perte d’alimentation, vérifiez la validité de la RTC : sa date par défaut n’est pas une mesure réelle.
STM32, ESP32 et Linux embarqué
Sur STM32, les domaines de sauvegarde, sous-secondes et fonctions RTC dépendent de la famille : consultez son manuel et AN4759. Il n’existe pas un registre Unix universel à lire sur tous les STM32. ESP-IDF combine des moyens RTC et haute résolution selon la configuration. Linux distingue CLOCK_REALTIME des horloges monotones. Contrôlez aussi libc et ABI, au-delà de l’architecture du CPU.
Synchronisation NTP et SNTP
NTP estime le décalage d’horloge et le délai réseau par échanges de paquets ; SNTP adopte une approche client simplifiée. Aucun ne supprime l’asymétrie réseau. Les champs d’époque et d’ère NTP ne sont pas des secondes Unix : laissez la pile les interpréter. Conservez état, ancienneté et incertitude de synchronisation. Un saut corrige brutalement l’heure ; un ajustement progressif modifie temporairement sa vitesse.
Horloge civile et horloge monotone
L’horloge civile indique une date UTC et peut sauter après une correction. Une horloge monotone mesure une durée depuis une origine arbitraire : elle ne représente pas directement une date UTC, et peut repartir à zéro au démarrage. Le comportement en veille dépend de l’horloge choisie. Utilisez-la pour délais et temporisations ; associez une référence UTC pour corréler plusieurs appareils.
Horodater l’acquisition des capteurs
Prenez l’horodatage près de l’échantillon ADC ou de l’interruption pertinente. L’heure d’envoi inclut files d’attente, radio et retransmissions ; conservez séparément l’heure de réception serveur. Pour un bloc de mesures, enregistrez origine, période et séquence en tenant compte de la dérive. Le guide sur l’échantillonnage complète cette distinction.
Journalisation et télémétrie
Ajoutez identité de l’appareil, identité de démarrage et numéro de séquence. Une correction vers le passé peut répéter une heure UTC sans désigner le même événement. Distinguez une heure mesurée d’une heure reconstruite. Trier uniquement sur UTC ne garantit pas l’ordre causal entre appareils dont les incertitudes se chevauchent.
Choisir l’unité selon le besoin
| Unité du timestamp | 1 s | 1700000000 s |
|---|---|---|
| Secondes (s) | 1 | 1700000000 |
| Millisecondes (ms) | 1000 | 1700000000000 |
| Microsecondes (µs) | 1000000 | 1700000000000000 |
| Nanosecondes (ns) | 1000000000 | 1700000000000000000 |
Les secondes conviennent aux échéances grossières, les millisecondes à de nombreuses télémétries, les microsecondes à certaines acquisitions et les nanosecondes à l’horodatage matériel adapté. La résolution est le pas représentable ; la répétabilité et l’exactitude sont d’autres propriétés. Une dérive libre de 20 ppm représente environ 1,728 s par 24 heures nominales, avec des variations possibles dues à la température et au vieillissement.
API REST et JSON
{
"timestamp_ns": "1700000000123456789",
"captured_at": "2023-11-14T22:13:20.123456789Z",
"time_quality": "synced",
"uncertainty_ms": 20,
"boot_id": "device-session-42",
"sequence": 17
}
Documentez époque, unité, signe et plage. Pour des clients utilisant binary64, transmettez les grandes valeurs en chaînes décimales. JSON.stringify n’accepte pas directement BigInt. Le nom timestamp_ns évite de deviner l’unité. Une date inconnue doit être null avec un état de qualité, plutôt qu’une fausse date plausible en 1970.
ISO 8601 et RFC 3339
RFC 3339 propose un profil pratique pour les échanges Internet. Incluez Z ou un décalage numérique et précisez la fraction de seconde. 2023-11-14T22:13:20Z et 2023-11-14T23:13:20+01:00 désignent le même instant. Une heure sans suffixe ne définit pas l’UTC. Un décalage seul ne conserve pas les règles futures de Europe/Paris.
Stockage SQL
CREATE TABLE sensor_measurement (
device_id text NOT NULL,
boot_id text NOT NULL,
sequence bigint NOT NULL,
captured_at timestamptz,
monotonic_us bigint NOT NULL,
time_quality text NOT NULL,
temperature_c double precision NOT NULL,
PRIMARY KEY (device_id, boot_id, sequence)
);
INSERT INTO sensor_measurement VALUES ('sensor-1', 'boot-42', 17,
TIMESTAMPTZ '2023-11-14T22:13:20.123456Z', 9812370, 'synced', 23.625);
Cet exemple cible PostgreSQL. timestamptz stocke un instant, affiché selon le fuseau de la session, et ne conserve pas l’identifiant IANA d’origine. Stockez celui-ci séparément si nécessaire. La précision des timestamps PostgreSQL est la microseconde ; conservez un champ numérique supplémentaire pour des nanosecondes exactes. Les autres moteurs SQL ont leurs propres limites. L’identité appareil/démarrage/séquence et l’indexation temporelle ont des rôles distincts.
UTC et planification locale
Stockez les événements en UTC. Une consigne quotidienne à 08:00 à Paris exige aussi sa règle locale et son fuseau IANA : l’heure UTC correspondante varie avec la saison. Définissez le comportement pour les heures sautées ou répétées. Ajouter 86400 secondes Unix n’assure pas la même heure locale le lendemain.
Limites de time_t et pérennité
Ne déduisez pas time_t de sizeof(void*). Un champ signé 32 bits en secondes rencontre 2038 même dans un produit partiellement 64 bits. ESP-IDF utilise time_t signé 64 bits depuis la version 5.0 ; anciens micrologiciels et protocoles peuvent rester étroits. Auditez formats printf, colonnes SQL, chargeurs de démarrage, pilotes RTC et migrations OTA.
Exemple ESP32 : capteur synchronisé par NTP
Ce code ESP-IDF 5.x/6.x est appelé une seule fois après initialisation d’esp-netif et connexion Wi-Fi ou Ethernet. Le pilote propre à la carte transmet à log_sensor une température finie. L’attente initiale est limitée à 15 secondes et chaque acquisition produit un enregistrement JSON.
#include <stdbool.h>
#include <stdint.h>
#include <inttypes.h>
#include <stdio.h>
#include <sys/time.h>
#include "freertos/FreeRTOS.h"
#include "esp_netif_sntp.h"
#include "esp_timer.h"
#include "esp_random.h"
static bool clock_synced;
static int64_t last_sync_us;
static uint32_t boot_id;
static uint64_t sequence;
void ntp_after_network_ready(void) {
boot_id = esp_random();
esp_sntp_config_t config = ESP_NETIF_SNTP_DEFAULT_CONFIG("pool.ntp.org");
esp_netif_sntp_init(&config);
clock_synced = esp_netif_sntp_sync_wait(pdMS_TO_TICKS(15000)) == ESP_OK;
if (clock_synced) last_sync_us = esp_timer_get_time();
}
void log_sensor(double temperature_c) {
int64_t monotonic_us = esp_timer_get_time();
struct timeval tv;
bool valid = clock_synced && monotonic_us - last_sync_us < INT64_C(3600000000)
&& gettimeofday(&tv, NULL) == 0;
printf("{\"boot_id\":\"%08" PRIx32 "\",\"sequence\":%" PRIu64
",\"monotonic_us\":\"%" PRId64 "\",\"timestamp_us\":",
boot_id, sequence++, monotonic_us);
if (valid) {
int64_t utc_us = (int64_t)tv.tv_sec * INT64_C(1000000) + tv.tv_usec;
printf("\"%" PRId64 "\"", utc_us);
} else printf("null");
printf(",\"time_quality\":\"%s\",\"temperature_c\":%.3f}\n",
valid ? "synced" : "unsynced", temperature_c);
}
timestamp_us et monotonic_us sont des chaînes décimales. Sans synchronisation, l’UTC devient null et l’ordre reste disponible. La validité d’une heure est une politique d’exemple, pas une garantie métrologique. Le code ne renouvelle pas automatiquement sa confiance : en production, mettez à jour last_sync_us depuis une notification de synchronisation, protégez l’état partagé et gérez reconnexion et incertitude. L’identifiant aléatoire 32 bits est illustratif ; préférez un compteur persistant ou un identifiant suffisamment robuste si les collisions sont critiques.
Redémarrages, dérive et perte de référence
Un redémarrage crée une nouvelle chronologie monotone. Conservez une identité de démarrage et n’assemblez pas aveuglément deux compteurs. Hors réseau, augmentez l’incertitude selon l’oscillateur et le temps depuis la dernière référence fiable. Une RTC secourue peut aider, avec un état de qualité adapté. Signalez les corrections importantes sans réécrire silencieusement les mesures passées.
Bonnes pratiques et validation
- Rendre explicites époque, unité et signe sur chaque interface.
- Utiliser UTC pour les événements et une horloge monotone pour les délais.
- Conserver séquence et qualité de synchronisation.
- Tester démarrage hors réseau, pile RTC vide, correction vers le passé, transitions DST et bornes entières.
- Maintenir les données de fuseaux pour la planification civile future.
FAQ technique
Une synchronisation NTP réussie garantit-elle la microseconde ?
Non. Asymétrie réseau, ordonnancement, oscillateur et latence d’acquisition subsistent. Mesurez la chaîne complète et annoncez une incertitude adaptée.
Peut-on déduire l’UTC du seul compteur monotone ?
Non. Il faut une correspondance avec une référence UTC et un modèle de dérive, avec âge et incertitude. Cette correspondance ne se prolonge pas sur un redémarrage indépendant.
Faut-il stocker les dates locales ?
Conservez les instants UTC, puis convertissez à l’affichage. Ajoutez le fuseau si la planification ou le contexte civil d’origine l’exige.
Outils et références techniques
Convertisseur Unix Timestamp / Epoch · Comprendre les timestamps Unix et l’Epoch Time · Tolérance des oscillateurs.
- IETF · RFC 3339
- IETF · RFC 5905 (NTP)
- IETF · RFC 8259 (JSON)
- Python · PEP 418
- Espressif · ESP-IDF
- STMicroelectronics · AN4759
- PostgreSQL · SQL
Outils et guides associés
Calculateur de condensateurs de charge de quartz · Lire le guide de conception complet