Convertir un timestamp Unix

Un timestamp Unix est un compte de secondes depuis le 1er janvier 1970 UTC. JavaScript, Java et la plupart des chaînes de journalisation comptent en millisecondes. Les mêmes chiffres désignent donc deux instants qui peuvent être séparés par des décennies, et rien dans le nombre lui-même ne dit quelle convention l’a produit.

La taille tranche en pratique. Une valeur à dix chiffres est en secondes jusqu’en 2286 ; une valeur à treize chiffres est en millisecondes depuis 1973. Cette page choisit sur cette base puis vous dit ce qu’elle a choisi, ce que la plupart des convertisseurs omettent — celui qui devine en silence et se trompe affiche une date de janvier 1970 sans aucune explication.

L’UTC est le timestamp lui-même : une valeur epoch ne porte aucun fuseau, la lecture en UTC est donc un fait et non un choix. La ligne locale vient du réglage de votre appareil, et le décalage est imprimé à côté pour qu’il ne reste jamais implicite.

Cette distinction pèse plus qu’il n’y paraît quand le nombre vient d’ailleurs. Un timestamp sorti d’un journal de production désigne un instant, et cet instant est le même partout — mais l’heure au mur que votre collègue cite depuis le même journal est dans son fuseau, et comparer les deux à l’œil est l’endroit où une heure disparaît. Comparez la ligne UTC, ou comparez le nombre.

Paris est à UTC+1 en hiver et UTC+2 en été, et le basculement a lieu le dernier dimanche de mars et le dernier dimanche d’octobre. Un timestamp ne change pas de valeur ce jour-là : ce qui change, c’est la ligne locale que cette page affiche, parce que le décalage appliqué n’est plus le même.

C’est la source d’erreur la plus fréquente sur des journaux français. Deux événements séparés d’une heure au mur peuvent être séparés de deux heures réelles s’ils encadrent le basculement d’octobre, où l’heure de 2 h à 3 h est jouée deux fois. Le timestamp, lui, reste strictement croissant : c’est pour cela qu’il faut trier sur le nombre et n’afficher l’heure locale qu’à la fin.

ISO 8601 avec un `Z` final ne prête pas à confusion : elle nomme l’instant, le fuseau et la précision dans une seule chaîne, et tous les langages la lisent. `2023-11-14T22:13:20.000Z` ne peut pas être pris pour un jour-mois-année ni pour un mois-jour-année, ce que la même date écrite avec des barres obliques peut parfaitement être.

Cette ambiguïté n’est pas théorique et elle mord ici en particulier. `03/04/2024` est le 3 avril en France et le 4 mars aux États-Unis, et un tableur l’interprétera silencieusement selon sa propre locale. Si une date part dans un ticket, un message ou un autre système, la forme ISO est celle qui survit au voyage.

Les semaines ISO 8601 commencent le lundi, et la semaine 1 est celle qui contient le premier jeudi de l’année. Le 1er janvier peut donc appartenir à la semaine 52 ou 53 de l’année *précédente* — le 1er janvier 2021 est en 2020-S53 — et une année peut compter 53 semaines.

L’implémentation évidente, diviser le quantième par sept, s’en écarte une quinzaine de jours chaque année. Cela compte parce que la semaine ISO est ce qu’emploient les outils de reporting, la paie et l’essentiel de l’administration en France : un rapport intitulé « semaine 1 » peut couvrir des jours situés dans deux années différentes et être parfaitement correct.

Un entier signé de 32 bits qui compte des secondes déborde le 19 janvier 2038. Les systèmes qui utilisent encore un `time_t` de 32 bits repartiront en 1901 — la même forme de problème que l’an 2000, avec un rayon d’action plus étroit et une correction plus difficile, puisqu’il s’agit de firmware embarqué et de vieux formats de fichiers plutôt que de logiciels de gestion.

Cela ne concerne ni cette page ni rien qui ait été écrit ces dix dernières années dans un langage courant. JavaScript utilise un double, qui tient les millisecondes exactement jusqu’en 275760. Un `time_t` de 64 bits couvre plus longtemps que l’univers n’existe. Si vous regardez un timestamp dans un navigateur, 2038 est le problème de quelqu’un d’autre.

Une date en 1970 veut presque toujours dire que des millisecondes ont été lues comme des secondes — ou que la valeur était zéro ou vide et que quelque chose l’a convertie en zéro, ce qui est l’epoch lui-même. Une date dans un futur lointain signifie en général l’inverse : des secondes lues comme des millisecondes, ou un timestamp en microsecondes ou en nanosecondes, ce que certaines bases et certains systèmes de traçage émettent.

Les microsecondes font seize chiffres et les nanosecondes dix-neuf. Ni les unes ni les autres ne sont traitées automatiquement ici, parce qu’elles sont assez rares pour que les deviner dégraderait la déduction courante. Divisez par mille ou par un million d’abord, et la valeur retombe dans une plage que cette page lit correctement.

Le temps Unix fait comme si chaque journée comptait exactement 86 400 secondes, ce qui est faux : des secondes intercalaires ont été ajoutées à l’UTC une trentaine de fois depuis 1972. Le compteur epoch les ignore en répétant ou en étirant une seconde, selon le système.

La conséquence pratique est qu’un timestamp Unix n’est pas un compte exact de secondes écoulées depuis 1970, mais un compte de jours convertis en secondes. L’écart est de quelques dizaines de secondes au total et n’intéresse que la métrologie et certains protocoles de synchronisation ; pour lire un journal, il est sans effet.

La ligne « il y a huit mois » est calculée par rapport à l’horloge de votre appareil, et elle est volontairement grossière : au-delà de quelques jours, la précision à la minute n’aide personne et donne une fausse impression d’exactitude. Ce qu’on cherche à savoir, c’est si l’événement date de ce matin, de la semaine dernière ou de l’an dernier.

Cela veut dire que la ligne dépend d’une horloge que cette page ne contrôle pas. Sur une machine dont la date est fausse, l’UTC et la chaîne ISO restent justes tandis que le temps écoulé ne l’est pas — et c’est justement ainsi qu’on découvre qu’une horloge dérive.