Convertisseur de timestamp Linux

Un horodatage Unix (également appelé temps POSIX ou temps epoch) est le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC, en excluant les secondes intercalaires. C'est un simple entier qui représente le même instant à l'échelle mondiale, quel que soit le fuseau horaire.

Vous pouvez convertir un horodatage Unix de plusieurs manières : - En ligne : utilisez notre Convertisseur d'horodatage Unix pour une conversion instantanée - Terminal Linux : exécutez date -d @1785292800 (sur GNU Linux) ou date -r 1785292800 (sur macOS) - JavaScript : new Date(timestamp * 1000).toISOString() - Python : datetime.utcfromtimestamp(1785292800) - PHP : date("Y-m-d H:i:s", 1785292800)

Un horodatage en secondes a 10 chiffres (par ex. 1785292800). Un horodatage en millisecondes a 13 chiffres (par ex. 1785292800000) car il multiplie la valeur en secondes par 1000. Date.now() de JavaScript renvoie des millisecondes, tandis que la plupart des autres systèmes et API utilisent des secondes. Les mélanger accidentellement produit des dates complètement fausses — utiliser des millisecondes là où des secondes sont attendues donne une date d'environ 56 000 ans dans le futur. Vérifiez toujours la résolution de votre source de données avant de convertir. En cas de doute, comptez les chiffres : 10 chiffres = secondes, 13 chiffres = millisecondes.

Oui. Les dates antérieures au 1er janvier 1970 sont représentées par des nombres négatifs. Par exemple, l'horodatage -3600 correspond au 31 décembre 1969 à 23:00:00 UTC. Tous les outils de conversion ne gèrent pas correctement les horodatages négatifs, mais notre convertisseur en ligne le fait. Les langages de programmation les prennent en charge universellement.

Le problème de l'an 2038 (également appelé Y2K38) est un problème de représentation du temps qui affecte les systèmes stockant les horodatages sous forme d'entiers signés 32 bits. La valeur maximale est 2147483647, ce qui correspond au 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, la valeur déborde vers -2147483648, interprétée comme le 13 décembre 1901. La plupart des systèmes 64 bits modernes ne sont pas affectés, mais les appareils embarqués, les bases de données héritées et certains systèmes 32 bits restent vulnérables. La solution consiste à migrer vers des représentations temporelles 64 bits, qui offrent une plage d'environ 292 milliards d'années.

Non. Les horodatages Unix ignorent intentionnellement les secondes intercalaires. Chaque jour est traité comme exactement 86 400 secondes, même lorsqu'une seconde intercalaire est ajoutée à l'UTC. Lors d'une insertion de seconde intercalaire, l'horodatage Unix n'avance pas pendant une seconde, sautant effectivement la seconde intercalaire. Cela signifie que les horodatages Unix divergent du temps atomique d'une quantité faible (actuellement environ 27 secondes) mais croissante.

Un horodatage Unix représente le même instant partout. Le fuseau horaire n'a d'importance que lorsque vous l'affichez sous forme de date lisible par un humain. Stockez toujours les horodatages sous leur forme entière brute et convertissez en heure locale uniquement pour l'affichage. Utilisez des noms de fuseaux horaires IANA comme America/New_York plutôt que des abréviations comme EST ou PST, car les abréviations ne tiennent pas compte de l'heure d'été. Notre Convertisseur d'horodatage Unix affiche les résultats dans plusieurs fuseaux horaires simultanément.

Le maximum dépend de la taille d'entier utilisée pour le stockage : - Entier signé 32 bits : 2147483647 (19 janvier 2038 à 03:14:07 UTC) - Entier non signé 32 bits : 4294967295 (7 février 2106 à 06:28:15 UTC) - Entier signé 64 bits : 9223372036854775807 (environ 292 milliards d'années à partir de maintenant) La plupart des systèmes modernes utilisent des entiers 64 bits, offrant une plage pratiquement infinie. La pratique courante consistant à stocker les horodatages dans des colonnes de base de données ou des structures de données sous forme de type 64 bits (BIGINT en SQL) est pérenne.