En bref : un timestamp Unix est le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970. Logs et API l'utilisent car il est sans ambiguïté et indépendant du fuseau. Les deux pièges sont de distinguer les secondes des millisecondes, et de se rappeler que le nombre brut est toujours en UTC jusqu'à ce que vous le convertissiez dans un fuseau local.
Pour comparer des entrées entre serveurs, un simple entier se raisonne plus facilement qu'une date formatée : pas de fuseau, pas de locale, pas d'ambiguïté d'heure d'été. Mais cette même simplicité explique qu'un timestamp égaré puisse être mal lu.
Pourquoi les timestamps commencent en 1970
L'époque Unix est minuit UTC le 1er janvier 1970, choisie par les premiers développeurs Unix aux Bell Labs comme point de référence simple et fixe. Chaque timestamp Unix n'est que le compte des secondes depuis cet instant, ce qui fait de l'arithmétique — « combien de temps entre ces deux événements ? » — une simple soustraction.
Secondes ou millisecondes ?
C'est l'erreur la plus fréquente en lisant des logs. Règle empirique : si la valeur a plus de 11 chiffres (supérieure à environ 10¹¹), c'est presque sûrement des millisecondes. Un timestamp actuel en secondes vaut environ 1,7 milliard (dix chiffres) ; le même instant en millisecondes vaut environ 1,7 billion (treize chiffres). Donnez une valeur en millisecondes à un analyseur en secondes et vous atterrirez des dizaines de milliers d'années dans le futur.
Le timestamp est toujours en UTC
Un timestamp Unix encode un instant absolu, pas une heure locale d'horloge. Pour l'afficher à un humain, vous appliquez un fuseau : le même nombre est « 14 h 30 à Londres » et « 9 h 30 à New York ». Convertir proprement dans les deux sens, c'est être explicite sur le fuseau visé : un bon convertisseur utilise la base de fuseaux standard IANA et l'API Intl.DateTimeFormat pour que le décalage (heure d'été comprise) soit correct pour la date en question.
ISO 8601 pour tout ce que vous stockez ou partagez
Quand un timestamp doit être lisible par l'humain tout en restant sûr pour la machine, utilisez l'ISO 8601 : 2024-03-15T14:30:00.000Z. Le T sépare date et heure et le Z indique l'UTC. Il se trie correctement comme texte brut et supprime l'incertitude secondes-vs-millisecondes pour le prochain lecteur.
La note sur 2038
Les systèmes qui stockent le timestamp en entier signé 32 bits débordent le 19 janvier 2038. La plupart des plateformes modernes sont passées au temps 64 bits, mais il est utile de le savoir face à un vieux système ou une colonne de base de données à largeur fixe.
Un flux pratique
- Copiez la valeur brute depuis votre log ou la réponse de l'API.
- Collez-la dans le Convertisseur de Timestamp, qui détecte automatiquement secondes vs millisecondes et affiche la date dans le fuseau choisi.
- Convertissez les deux événements comparés dans le même fuseau (ou gardez-les en UTC) avant de soustraire.
- Stockez ou partagez le résultat en ISO 8601 pour éviter de réintroduire l'ambiguïté. Associez-le au Compteur de Caractères si vous nettoyez un extrait de log pour un ticket.
Erreurs courantes à éviter
- Mélanger secondes et millisecondes dans la même comparaison.
- Supposer qu'un timestamp brut est déjà en heure locale.
- Comparer deux événements rendus dans des fuseaux différents.
- Utiliser des champs de temps 32 bits à largeur fixe qui ne survivent pas à 2038.