Horodatages Unix How to Convert and Why They’re Everywhere
Un référentiel pratique pour travailler avec les timestamps Unix : secondes versus millisecondes, conversion en JavaScript, Python, SQL et bash, pièges liés aux fuseaux horaires à éviter, et savoir quand utiliser les timestamps au lieu des chaînes ISO 86-01.
Une date Unix est le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC — également appelée l'époque Unix. Cette date n'a pas été choisie pour une raison technique ; elle correspondait simplement à l'année en cours lors de la conception de Unix. L'époque est toujours en UTC, ce qui signifie qu'une date comme 1712800000 signifie le même instant partout sur Terre, indépendamment du fuseau horaire.
Les dates Unix sont utilisées partout : en-têtes HTTP, tokens JWT, enregistrements de bases de données, fichiers de journaux, files de messages et réponses API. Si vous développez ou déboguez quelque chose impliquant le temps, vous rencontrerez ces dates fréquemment. Le Convertisseur de date Unix IO Tools est pratique pour des recherches rapides, mais vous devez aussi savoir comment les gérer dans le code.
Secondes vs Millisècondes : L'erreur courante qui affecte tout le monde
L'erreur de date Unix la plus fréquente en production : confondre les secondes et les millisècondes. La norme Unix utilise des secondes. JavaScript’s Date.now() retourne des millisècondes. Java fait de même avec System.currentTimeMillis().
Une date Unix de 1712800000 correspond au 20 avril 2024. Une date Unix de 1712800000000 (millisècondes) correspond à une année vers 56 000. Si vos calculs de date produisent des dates dans le futur ou affichent 1970-01-01, c'est presque toujours pour cette raison.
Règle de base : si le timestamp a 13 chiffres, c'est en millisècondes. Si c'est 10 chiffres, c'est en secondes. En doute, divisez par 1000 et vérifiez si le résultat est sensé.
Conversion des dates Unix par langage
Voici les modèles que vous utiliserez effectivement :
JavaScript
// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now(); // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000
// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000); // must multiply by 1000
console.log(date.toISOString()); // "2024-04-11T02:13:20.000Z"
// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);
Python
from datetime import datetime, timezone
# Get current timestamp (seconds)
import time
ts = int(time.time()) # e.g. 1712800000
# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat()) # 2024-04-11T02:13:20+00:00
# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())
SQL (MySQL / MariaDB)
-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)
-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();
-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');
Bash
# Get current timestamp
date +%s
# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024
# macOS (BSD date)
date -r 1712800000
Tableau de référence rapide
| Langue | Obtenir la date actuelle (en secondes) | Date → timestamp | Date → timestamp |
|---|---|---|---|
| JavaScript | Math.floor(Date.now()/1000) | new Date(ts * 1000) | Math.floor(d.getTime()/1000) |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) | int(dt.timestamp()) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) | UNIX_TIMESTAMP(datetime_str) |
| Bash | date +%s | date -d @ts | date -d "2024-04-11" +%s |
Les pièges des fuseaux horaires
Les dates Unix sont toujours en UTC. Toujours. Le nombre 1712800000 n'a pas de fuseau horaire — il compte simplement les secondes depuis l'époque. Le fuseau horaire est une question de présentation, pas de stockage.
Où les développeurs se font prendre :
- Python’s
datetime.fromtimestamp(ts)sanstz=timezone.utc— utilise le fuseau horaire local du serveur, sans le signaler. Utilisezfromtimestamp(ts, tz=timezone.utc)plutôt. - MySQL’s
FROM_UNIXTIME()— convertit en fonction du paramètre de fuseau horaire du serveur MySQL (@@session.time_zone). Si votre serveur est en UTC+8, le résultat est décalé de 8 heures. - Stocker
datetimedans MySQL sans normalisation en UTC — si votre serveur d'application et votre serveur de base de données sont dans des fuseaux horaires différents, chaque insertion ou lecture devient une erreur potentiellement déclenchée.
Le modèle qui évite tout cela : stocker les dates Unix dans la base de données, convertir en format lisible par l'humain au moment de l'affichage dans la couche d'application, en utilisant le fuseau horaire préféré de l'utilisateur.
Dates Unix vs chaînes ISO 8601 : Quel format stocker
Les deux formats sont valides pour le stockage. Les avantages et inconvénients :
- Date Unix (entier): compacte, rapide pour les comparaisons et les calculs, sans ambiguïté de fuseau horaire, fonctionne sur tous les moteurs de base de données. Inconvénient : non lisible par l'humain sans outil.
- Chaîne ISO 8601 (par exemple,
2024-04-11T02:13:20Z) : lisible par l'humain dans la base de données, auto-documentée. Inconvénient : plus lente pour les requêtes de plage, le fuseau horaire peut être omis ou incorrectement spécifié.
Pour la plupart des applications : stocker les dates comme entiers. Utiliser les chaînes ISO 8601 dans les API et les journaux où la lisibilité humaine est importante. Si vous devez stocker une chaîne ISO 8601, inclure toujours le Z ou l'offset explicite — une chaîne sans fuseau horaire est un désastre dans les systèmes distribués. 2024-04-11 02:13:20 sans fuseau horaire est une catastrophe dans les systèmes distribués.
Le problème de 2038
Les entiers signés de 32 bits peuvent stocker une valeur maximale de 2147483647, ce qui correspond au 1er janvier 2038 à 03:14:07 UTC. Les systèmes qui stockent des dates Unix dans un entier de 32 bits int vont déborder à ce moment-là — en revenant à 1901 ou en s'arrêtant.
Dois-je m'inquiéter ? Si vous écrivez du nouveau code, non — utilisez des entiers de 64 bits. Si vous maintenez du code C ancien, des logiciels embarqués ou des schémas MySQL anciens utilisant INT(11) pour les dates Unix, il est utile de les vérifier. Le type TIMESTAMP de MySQL est également affecté ; DATETIME n'est pas affecté. Les systèmes modernes utilisant des entiers de 64 bits sont sûrs jusqu'à l'année 292 milliards.
Avez-vous besoin de convertir rapidement des dates sans écrire de code ? Le Convertisseur de date Unix sur IO Tools gère les secondes et les millisècondes, affiche simultanément la date UTC et la date locale, et vous permet de coller une date pour obtenir le timestamp.
Vous aimerez peut-être aussi
Installez nos extensions
Ajoutez des outils IO à votre navigateur préféré pour un accès instantané et une recherche plus rapide
恵 Le Tableau de Bord Est Arrivé !
Tableau de Bord est une façon amusante de suivre vos jeux, toutes les données sont stockées dans votre navigateur. D'autres fonctionnalités arrivent bientôt !
Outils essentiels
Tout voir Nouveautés
Tout voirMise à jour: Notre dernier outil was added on Avr 19, 2026
