Un résultat « 1er janvier 1970 » dans Excel ou Python après une conversion : c’est le symptôme le plus fréquent rencontré par les développeurs qui manipulent des timestamps Unix. La cause est presque toujours la même, une confusion entre secondes et millisecondes. Avant de choisir une formule, il faut compter les chiffres du timestamp. Cette page couvre les conversions pour Excel, Google Sheets, PHP, JavaScript, Python et MySQL, avec les pièges exacts à éviter dans chaque environnement.
Qu’est-ce qu’un timestamp Unix ?
Un timestamp Unix (appelé aussi « epoch time » ou « POSIX time ») est un entier représentant le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC. Cette date de référence a été choisie par les ingénieurs d’AT&T Bell Labs comme point de départ pratique. La première version du Unix Programmer’s Manual (novembre 1971) utilisait pourtant le 1er janvier 1971 comme epoch, mesuré en 60èmes de seconde. Après le passage aux secondes, les 136 années couvertes rendaient le déplacement à 1970 cohérent.
En mars 2026, la valeur courante tourne autour de 1 741 500 000. Ce nombre augmente d’une unité chaque seconde. On le retrouve dans les systèmes Unix/Linux, les bases de données (MySQL, PostgreSQL, MongoDB), Git pour dater les commits, les APIs web et les fichiers de log serveur.
10 ou 13 chiffres : le diagnostic que la plupart des tutoriels oublient
La longueur d’un timestamp détermine sa précision et donc la formule à lui appliquer. Appliquer une formule « secondes » à un timestamp en millisecondes produit une date en l’an 57 000. Appliquer une formule « millisecondes » à un timestamp en secondes produit une date en décembre 1970. Les deux erreurs sont aussi fréquentes l’une que l’autre.
| Nombre de chiffres | Précision | Exemple (mars 2026) | Environnements principaux |
|---|---|---|---|
| 10 | Secondes | 1741500000 | PHP, Python, Unix shell, MySQL |
| 13 | Millisecondes | 1741500000000 | JavaScript (Date.now()), Java, APIs REST modernes |
| 16 | Microsecondes | 1741500000000000 | Bases de données haute précision, C++ |
| 19 | Nanosecondes | 1741500000000000000 | Python time.time_ns(), systèmes temps réel |
JavaScript est la source principale de confusion dans les équipes mixtes front/back. Date.now() retourne des millisecondes, alors que time() en PHP ou time.time() en Python retournent des secondes. Un timestamp copié d’une console Node.js dans une requête MySQL ou une formule Excel produira un résultat faux sans message d’erreur. La règle pratique : si le timestamp a 13 chiffres, diviser par 1000 avant tout traitement.
Formules de conversion par environnement
Les syntaxes ci-dessous supposent un timestamp en secondes (10 chiffres). Pour les timestamps en millisecondes, diviser par 1000 au préalable, sauf mention contraire.
Excel et Google Sheets
Excel stocke les dates comme des nombres décimaux où 1 = un jour. Un timestamp Unix se convertit donc en divisant par 86 400 (secondes dans une journée) et en ajoutant la date du 1er janvier 1970, que Excel reconnaît via la fonction DATE(1970,1,1) :
=(A1/86400)+DATE(1970,1,1)
Après avoir entré cette formule, formater la cellule en « Date » ou « Date et heure » pour afficher le résultat. Google Sheets utilise la même formule. Pour un timestamp en millisecondes (13 chiffres) : =(A1/86400000)+DATE(1970,1,1).
PHP
La fonction date() de PHP accepte directement un timestamp en secondes en second argument :
date('Y-m-d H:i:s', $timestamp);
Pour un objet manipulable : DateTime::createFromFormat('U', $timestamp). L’opération inverse (date vers timestamp) utilise strtotime('2026-03-09').
JavaScript et Node.js
L’objet Date de JavaScript attend des millisecondes. Pour un timestamp en secondes, multiplier par 1000 :
const date = new Date(timestamp * 1000);
date.toISOString() retourne le format ISO 8601 (« 2026-03-09T12:00:00.000Z »). La bibliothèque Day.js, plus légère que Moment.js, simplifie le formatage : dayjs(timestamp * 1000).format('YYYY-MM-DD HH:mm:ss').
Python
Le module datetime de la bibliothèque standard gère la conversion :
from datetime import datetime, timezone
datetime.fromtimestamp(timestamp, tz=timezone.utc)
Sans le paramètre tz=timezone.utc, la fonction utilise le fuseau local de la machine, ce qui peut produire des résultats inattendus sur un serveur en UTC+0 ou UTC+2. Pour les timestamps en nanosecondes, Python 3.3 et versions ultérieures proposent time.time_ns() pour générer et datetime.fromtimestamp(ts_ns / 1e9) pour convertir.
MySQL
FROM_UNIXTIME() convertit un entier Unix en type DATETIME :
SELECT FROM_UNIXTIME(timestamp_column) FROM table;
UNIX_TIMESTAMP() effectue l’opération inverse. Pour stocker des données au-delà de 2038 (voir section suivante), préférer un BIGINT à la colonne native TIMESTAMP, dont la plage s’arrête au 19 janvier 2038.
Le problème de 2038 et pourquoi ça concerne encore des systèmes en production
Un timestamp Unix stocké dans un entier signé sur 32 bits peut représenter au maximum 2 147 483 647 secondes depuis l’epoch. Cette limite correspond exactement au 19 janvier 2038 à 03:14:07 UTC, selon la spécification POSIX. Dépassé d’une seconde, l’entier déborde (integer overflow) et bascule à -(2^31), ce que les systèmes interprètent comme le 13 décembre 1901.
Ce problème, connu sous les noms « Y2K38 » ou « bug de l’an 2038 », ne concerne pas les systèmes d’exploitation 64 bits modernes : Linux (depuis 2011 sur les architectures 64 bits), macOS et Windows 10/11 sont hors de danger. Les systèmes vulnérables sont les équipements embarqués (routeurs, automates industriels, certains appareils IoT) et les applications legacy compilées avec time_t en 32 bits et jamais mises à jour.
La migration vers des entiers signés sur 64 bits (int64_t) repousse la limite à environ 292 milliards d’années après l’epoch Unix, soit approximativement 21 fois l’âge estimé de l’univers. PostgreSQL utilise des timestamps 64 bits nativement depuis la version 7.3. MySQL requiert une migration explicite des colonnes TIMESTAMP vers BIGINT ou DATETIME pour les données post-2038.
Outils en ligne pour convertir sans écrire de code
Pour des conversions ponctuelles, epochconverter.com, unixtimestamp.com et timestamp.online permettent de convertir un timestamp sans code, dans les deux sens (timestamp vers date et date vers timestamp), avec support des fuseaux horaires (UTC, Paris, New York, Tokyo). Ils acceptent les formats secondes et millisecondes.
Ces outils sont pratiques pour vérifier une valeur manuellement. Pour des traitements en volume (exports CSV, logs API, pipelines analytics), une formule intégrée à l’outil de destination reste plus fiable qu’un copier-coller via un convertisseur.
La confusion entre secondes et millisecondes est la source de 90 % des bugs de conversion rencontrés en pratique. Compter les chiffres avant d’appliquer une formule prend deux secondes et évite des heures de débogage.
