Convertisseur d'horodatage

Un horodatage Unix est simplement le nombre de secondes écoulées depuis minuit UTC le 1er janvier 1970 — un point de référence arbitraire choisi il y a des décennies et devenu depuis la valeur par défaut quasi universelle pour représenter un instant dans un système informatique. L'attrait est qu'il réduit une date et une heure à un seul entier facile à comparer et stocker : vérifier si un instant précède un autre est une simple comparaison numérique plutôt qu'un calcul de calendrier, et le stocker occupe une quantité fixe et prévisible d'espace quel que soit le siècle où tombe la date. C'est pourquoi cela sous-tend tout, des colonnes d'horodatage dans les bases de données aux réponses d'API et entrées de fichiers journaux, même si le nombre brut n'a aucun sens pour une personne qui le regarde directement — c'est la raison même de l'existence d'un convertisseur comme celui-ci.

Un horodatage Unix représentant l'instant présent en secondes fait dix chiffres de long, et le même instant exprimé en millisecondes en fait treize — trois chiffres supplémentaires pour la précision au millième. Cette différence de longueur est le moyen rapide et fiable d'identifier dans quelle unité se trouve un nombre donné, et explique aussi les deux modes d'échec les plus courants et déroutants quand la mauvaise hypothèse est faite. Passer une valeur en millisecondes à du code attendant des secondes multiplie la date apparente par environ mille, tombant quelque part vers l'an 55000 — spectaculairement et manifestement faux. Passer une valeur en secondes à du code attendant des millisecondes fait l'inverse : divise le temps écoulé réel par environ mille, faisant tomber la date interprétée quelque part en 1970, assez proche d'une date plausible pour parfois être confondue avec une vraie erreur ailleurs plutôt qu'un décalage d'unités.

Un horodatage Unix brut ne porte aucune information de fuseau horaire — c'est simplement un compte de secondes écoulées, identique partout sur Terre à un instant donné — et le moment de le convertir en date lisible est là où un fuseau horaire doit être choisi à des fins d'affichage. Stocker et journaliser des événements en UTC (ou l'horodatage brut lui-même, indépendant du fuseau horaire par définition) signifie que chaque enregistrement d'un système représente exactement le même instant quel que soit le fuseau horaire du serveur, de la base de données, ou de la personne lisant le journal. Convertir en heure locale est une décision de la couche d'affichage prise seulement quand un humain regarde réellement la valeur, c'est pourquoi cet outil sépare clairement les deux : UTC et ISO 8601 comme valeurs à stocker et comparer, heure locale comme version à lire.

Une quantité significative d'infrastructure plus ancienne — ancien code C, certains systèmes embarqués, certains types de colonnes de bases de données plus anciennes — stocke un horodatage Unix dans un entier signé de 32 bits, qui a un plafond ferme : il déborde à 03:14:07 UTC le 19 janvier 2038 et revient à une date de 1901, une erreur de même forme sous-jacente que le bug de l'an 2000 mais enracinée dans les limites d'entiers binaires plutôt que dans des années à deux chiffres. JavaScript représente les nombres en valeurs à virgule flottante 64 bits, qui ont bien plus de marge et ne sont pas sujettes à ce débordement précis, donc un horodatage calculé dans cet outil n'est pas affecté — le souci s'applique à tout système ayant produit à l'origine l'horodatage en cours de conversion, pas à la conversion qui se produit ici.