Secondes ou millisecondes
1777118400
1777118400000
Les deux valeurs désignent le même instant si la première est lue comme des secondes et la seconde comme des millisecondes. Confondre les deux est *le* bug de timestamp le plus fréquent.
Convertissez entre timestamps Unix, ISO 8601, UTC et heure locale.
Dernière mise à jour
177723989317772398930002026-04-26T21:44:53.000Z2026-04-26 21:44:53Sun, 26 Apr 2026 21:44:53 GMTUn convertisseur Unix timestamp transforme l'*epoch time* — un seul nombre qui représente un instant précis — en date lisible, et fait l'inverse à la demande. En tant que dev, on croise des timestamps partout : colonnes de base de données, lignes de logs, réponses d'API, événements analytics, claim exp d'un JWT, déclencheurs de tâches planifiées ou en-têtes d'expiration de cache.
Le principe est simple : les machines stockent le temps sous forme de nombre (secondes ou millisecondes écoulées depuis le 1970-01-01 00:00:00 UTC), mais nous, humains, on a besoin de calendriers, de fuseaux horaires et de formats lisibles. Passer de l'un à l'autre fait partie des tâches de debug les plus fréquentes dans n'importe quelle appli web ou mobile.
Le piège classique, c'est l'*unité*. POSIX et la plupart des langages côté backend travaillent en secondes. JavaScript, Java et beaucoup de brokers de messages travaillent en millisecondes. Certains systèmes de métriques montent en microsecondes ou nanosecondes. Règle pratique : un nombre à 10 chiffres, c'est presque toujours des secondes ; à 13 chiffres, c'est presque toujours des millisecondes.
1970-01-01 00:00:00 UTC).2026-04-25T12:00:00Z) est un format texte portable. Le Z final (ou +00:00) signifie UTC ; un décalage comme +02:00 indique une heure locale en avance de 2 heures sur UTC.Collez un nombre (secondes ou millisecondes) ou une chaîne de date. Le convertisseur détecte automatiquement le format en se basant sur sa longueur et sa forme.
Si la détection automatique se trompe, basculez manuellement entre secondes et millisecondes — 10 chiffres = secondes, 13 chiffres = millisecondes.
Le résultat affiche l'ISO 8601 en UTC, votre heure locale, ainsi qu'une formulation relative lisible (il y a 3 heures, dans 2 jours).
Copiez directement le timestamp, la chaîne ISO ou l'heure locale. Pratique pour remplir un exp de JWT, une ligne en base ou une requête sur des logs.
Les formats que vous croiserez le plus souvent en manipulant des dates et des heures dans du code. ISO 8601 est aussi normalisé par l'IETF sous le nom de RFC 3339 pour son usage dans les protocoles.
| Format | Exemple | Où on le rencontre |
|---|---|---|
| Unix secondes | 1777118400 | Logs backend, exp d'un JWT, time() POSIX, Redis |
| Unix millisecondes | 1777118400000 | Date.now() en JavaScript, System.currentTimeMillis() en Java |
| ISO 8601 UTC | 2026-04-25T12:00:00Z | API REST, JSON, GraphQL, fichiers de logs |
| ISO 8601 avec décalage | 2026-04-25T14:00:00+02:00 | Planification côté utilisateur, invitations de calendrier |
| RFC 2822 | Sat, 25 Apr 2026 12:00:00 GMT | En-têtes d'e-mails, en-têtes HTTP Date et Last-Modified |
| Date seule | 2026-04-25 | Anniversaires, jours fériés — sans notion de fuseau horaire |
1777118400
1777118400000
Les deux valeurs désignent le même instant si la première est lue comme des secondes et la seconde comme des millisecondes. Confondre les deux est *le* bug de timestamp le plus fréquent.
{ "id": 42, "createdAt": 1777118400, "expiresAt": 1777204800}Convertissez chaque valeur avant de supposer qu'elle est dans le passé ou le futur. La plupart des API JSON utilisent des secondes Unix, mais vérifiez toujours la doc — les backends à dominante JavaScript renvoient souvent des millisecondes.
2026-04-25T12:00:00Z
2026-04-25T14:00:00+02:00
Ces deux chaînes représentent *le même instant*. Stockez toujours les moments en UTC ; ne les formatez en heure locale qu'au moment de l'affichage.
1700000000 lu en secondes donne novembre 2023, mais lu en millisecondes ça tombe en janvier 1970.'2026-04-25') au lieu de comparer des timestamps. Deux chaînes ISO valides peuvent décrire le même instant sous des formes différentes.1970-01-01 00:00:00 UTC. C'est un nombre unique qui désigne un instant précis, indépendamment de tout fuseau horaire.Date.now() en JavaScript renvoie des millisecondes ; la majorité des backends renvoient des secondes.Date de JavaScript stocke les timestamps en millisecondes depuis l'epoch Unix — c'est ce que renvoient Date.now() et new Date().getTime(). Cela offre plus de précision que la seconde, mais c'est une source classique de bugs « facteur 1000 » quand on dialogue avec d'autres langages.new Date(...) en JavaScript, ou utilisez datetime.fromtimestamp(...) en Python. Ou collez-le dans un convertisseur Unix timestamp pour avoir le résultat en un clic.2038-01-19 — c'est le fameux bug de l'an 2038. Les langages et bases de données modernes stockent désormais les timestamps sur 64 bits, ce qui repousse la plage utilisable de plusieurs centaines de milliards d'années.