Comment utiliser cet outil ?
- Saisir un Unix Timestamp en secondes dans le champ de saisie.
- Le résultat en millisecondes apparaît immédiatement — pas de clic nécessaire.
- Copier le résultat au presse-papiers via le bouton Copier.
Que fait le convertisseur ?
Un Unix Timestamp compte les secondes depuis le 1er janvier 1970 00:00:00 UTC — la fameuse Epoch. Les systèmes POSIX, C et Python utilisent les secondes (10 chiffres). JavaScript, Java et Kafka utilisent les millisecondes (13 chiffres). Le convertisseur convertit entre les deux représentations : secondes × 1000 = millisecondes, millisecondes ÷ 1000 = secondes.
La conversion paraît triviale mais est l’une des sources d’erreur les plus fréquentes dans l’échange de données entre backend et frontend. Qui colle un timestamp à 10 chiffres dans new Date() atterrit en janvier 1970 au lieu de l’année actuelle.
Quelle est la formule de conversion ?
La formule est exacte, sans arrondi :
Secondes (s) × 1000 = millisecondes (ms)
Millisecondes (ms) ÷ 1000 = secondes (s)
Exemple : le Unix Timestamp 1745230000 (secondes) correspond à 1745230000000 (millisecondes). En JavaScript : new Date(1745230000000) donne le 21 avril 2025, 12:26:40 UTC.
Quels exemples d’usage existe-t-il ?
Valeurs courantes et leur conversion :
| Secondes (POSIX) | Millisecondes (JS) | Signification |
|---|---|---|
| 0 | 0 | Epoch : 1er janv. 1970 00:00:00 UTC |
| 86 400 | 86 400 000 | Exactement un jour (24 × 60 × 60) |
| 604 800 | 604 800 000 | Exactement une semaine |
| 2 629 746 | 2 629 746 000 | Mois moyen (30,44 jours) |
| 31 556 952 | 31 556 952 000 | Année moyenne (365,2425 jours) |
| 1 745 230 000 | 1 745 230 000 000 | Avril 2025 (valeur de référence) |
| 2 147 483 647 | 2 147 483 647 000 | Limite Y2038 (maximum 32 bits) |
À retenir : un jour fait exactement 86 400 secondes, une semaine 604 800. Ces valeurs sont constantes car les Unix Timestamps ne comptent pas les secondes intercalaires.
Quels domaines d’usage existe-t-il ?
Analyse de log et débogage : logs serveur, événements Kafka et entrées de base de données stockent les moments comme Unix Timestamps. Lors de la comparaison entre backend Python (secondes) et frontend JavaScript (millisecondes), le facteur 1000 est décisif. Sans conversion correcte, les dashboards affichent des moments en 1970 au lieu du mois en cours.
Développement d’API : les REST-APIs et webhooks transportent les timestamps en différentes précisions. Stripe utilise les secondes, Discord les millisecondes, InfluxDB les nanosecondes. Qui intègre des APIs a besoin de la conversion régulièrement — pas comme calcul mental mais comme outil fiable.
Migration de données : à l’import de données CSV ou JSON dans une nouvelle base, la précision du timestamp doit correspondre. PostgreSQL attend des microsecondes, MongoDB des millisecondes. Une mauvaise conversion mène à des séries temporelles cassées.
Évaluation Y2038 : les entreprises avec systèmes legacy vérifient actuellement quels composants utilisent encore des timestamps 32 bits. La valeur maximum 2 147 483 647 (19 janvier 2038, 03:14:07 UTC) est la limite dure.
Variantes de précision en un coup d’œil
Outre secondes et millisecondes existent deux autres niveaux de précision :
| Unité | Chiffres | Exemple | Diffusion |
|---|---|---|---|
| Secondes (s) | 10 | 1745230000 | POSIX, C, Python, Unix |
| Millisecondes (ms) | 13 | 1745230000000 | JavaScript, Java, Kafka |
| Microsecondes (µs) | 16 | 1745230000000000 | PostgreSQL, Python time.time_ns() |
| Nanosecondes (ns) | 19 | 1745230000000000000 | Go, Rust, Temporal.Instant |
Le nombre de chiffres est le moyen de reconnaissance le plus fiable : 10 = secondes, 13 = millisecondes, 16 = microsecondes, 19 = nanosecondes.
Le problème Y2038
Le 19 janvier 2038 à 03:14:07 UTC, la valeur 2147483647 atteint le maximum d’un entier signé 32 bits. Les systèmes qui stockent les timestamps en 32 bits interprètent la valeur suivante comme −2 147 483 648 — un saut en arrière à 1901.
Les timestamps 64 bits résolvent le problème : ils vont jusqu’à environ l’an 292 milliards. Tous les OS modernes et langages de programmation utilisent 64 bits. Sont menacés les systèmes embarqués, schémas de base de données anciens et firmware non mis à jour depuis des décennies.
L’API Temporal (ES2026, Stage 4 depuis mars 2026) utilise en interne des nanosecondes comme BigInt — le problème Y2038 n’existe pas là.
Questions fréquentes
Les réponses aux questions principales se trouvent dans le bloc FAQ ci-dessus — elles sont émises en JSON-LD structuré (FAQPage) pour les moteurs de recherche.
Quels outils de temps sont apparentés ?
Autres outils de l’écosystème convertisseur qui conviennent au sujet :
- Formateur JSON — formater lisible les réponses d’API avec timestamps et repérer les erreurs de syntaxe.
- Compteur de caractères — vérifier le nombre de chiffres des timestamps pour distinguer secondes de millisecondes.
- Text-Diff — comparer deux fichiers log avec timestamps et mettre en évidence les différences.
Dernière mise à jour :