Le temps Unix en une phrase
Le temps Unix, aussi appelé temps epoch ou temps POSIX, est un simple nombre entier qui compte les secondes depuis l'epoch, 1970-01-01T00:00:00Z. Il ne contient ni fuseau horaire, ni heure d'été, ni calendrier, et c'est justement pour cela que les bases de données, les fichiers de log, les API, les jetons JWT et les systèmes de fichiers l'utilisent : deux serveurs sur deux continents écrivent le même nombre pour le même instant.
Les dates antérieures à 1970 sont des nombres négatifs : -1 correspond au 31 décembre 1969 à 23:59:59 UTC. La valeur actuelle est un peu inférieure à deux milliards, et elle augmente de 86 400 chaque jour.
Essayez ici : Convertisseur de timestamp Unix
Ouvrir la page complète de l'outilSecondes, millisecondes, microsecondes
La définition parle de secondes, mais beaucoup de systèmes stockent des unités plus fines tout en parlant de timestamp Unix. En 2026, le moyen le plus rapide de les distinguer est le nombre de chiffres, et c'est aussi ainsi que le convertisseur de cette page détecte l'unité.
Les confondre est le bug le plus courant : lisez une valeur en millisecondes comme des secondes et vous obtenez une date environ 54 000 ans dans le futur ; lisez des secondes comme des millisecondes et vous atterrissez en janvier 1970. Si une date convertie affiche 1970, multipliez par 1 000. Si elle affiche une année très lointaine, divisez par 1 000.
| Unité | Chiffres aujourd'hui | Exemple pour le même instant | Sources typiques |
|---|---|---|---|
| Secondes | 10 | 1700000000 | Unix et Linux, PHP time(), MySQL UNIX_TIMESTAMP(), exp et iat des JWT |
| Millisecondes | 13 | 1700000000000 | JavaScript Date.now(), Java System.currentTimeMillis(), beaucoup d'API JSON |
| Microsecondes | 16 | 1700000000000000 | Fonctionnement interne de PostgreSQL, certains outils Python et de bases de données |
| Nanosecondes | 19 | 1700000000000000000 | Go time.UnixNano(), traçage haute résolution |
Fuseaux horaires et UTC
Un timestamp est toujours fondé sur l'UTC ; les fuseaux horaires n'interviennent qu'au moment de le transformer en date lisible par une personne. La même valeur 1700000000 correspond à 23:13 à Paris, 22:13 à Londres, 17:13 à New York et 01:13 le lendemain à Istanbul. Le nombre ne change pas, seul l'affichage change.
C'est pourquoi la bonne pratique consiste à stocker des timestamps (ou des dates UTC) et à convertir en heure locale tout à la fin, dans l'interface. Stocker des heures locales provoque des heures en double ou manquantes lors des changements d'heure. Le convertisseur affiche chaque timestamp dans votre heure locale, en UTC et dans un fuseau supplémentaire de votre choix sous Afficher aussi en, ainsi qu'au format ISO 8601 (2023-11-14T22:13:20.000Z) pour les API et RFC 2822 pour les en-têtes d'e-mail.
Un détail : le temps Unix ignore les secondes intercalaires. Chaque jour dure exactement 86 400 secondes, si bien qu'un timestamp se convertit en date par simple calcul. Les secondes intercalaires sont absorbées par les horloges, pas comptées dans le nombre.
Convertir dans Excel et Google Sheets
Les tableurs comptent des jours depuis 1900 au lieu de secondes depuis 1970 : on divise donc par le nombre de secondes dans une journée et on ajoute la date de l'epoch. Mettez la cellule résultat au format Date ou Date et heure, sinon vous verrez un nombre décimal comme 45244,93. Dans Excel et Google Sheets en français, les arguments sont séparés par un point-virgule, comme dans les formules ci-dessous ; avec une version anglaise, remplacez-le par une virgule.
Le résultat est en UTC. Pour afficher l'heure locale, ajoutez le décalage en heures divisé par 24, par exemple +1/24 pour Paris en hiver, +3/24 pour Istanbul ou -5/24 pour New York en hiver. Excel ne connaît pas l'heure d'été : un décalage fixe est donc faux la moitié de l'année dans beaucoup de pays ; pour de gros fichiers de log, utilisez plutôt la conversion en lot du convertisseur.
| Opération | Formule (timestamp en A2) |
|---|---|
| Secondes vers date (UTC) | =A2/86400+DATE(1970;1;1) |
| Millisecondes vers date (UTC) | =A2/86400000+DATE(1970;1;1) |
| Date en A2 vers secondes | =(A2-DATE(1970;1;1))*86400 |
| Secondes vers heure d'Istanbul (UTC+3) | =A2/86400+DATE(1970;1;1)+3/24 |
Convertir en JavaScript, Python et SQL
Tous les grands langages et bases de données ont des fonctions intégrées. Faites attention à l'unité attendue par chacune : JavaScript travaille en millisecondes, la plupart des autres en secondes.
| Environnement | Timestamp actuel | Timestamp vers date |
|---|---|---|
| JavaScript | Math.floor(Date.now() / 1000) | new Date(ts * 1000).toISOString() |
| Python | int(time.time()) | datetime.fromtimestamp(ts, tz=timezone.utc) |
| PHP | time() | gmdate('Y-m-d H:i:s', $ts) |
| MySQL | UNIX_TIMESTAMP() | FROM_UNIXTIME(ts) |
| PostgreSQL | extract(epoch from now()) | to_timestamp(ts) |
| SQL Server | DATEDIFF_BIG(SECOND, '1970-01-01', SYSUTCDATETIME()) | DATEADD(SECOND, ts, '1970-01-01') |
| SQLite | strftime('%s', 'now') | datetime(ts, 'unixepoch') |
Le problème de l'an 2038
Beaucoup de systèmes anciens stockent le temps Unix dans un entier signé de 32 bits. Sa valeur maximale, 2 147 483 647, est atteinte le 19 janvier 2038 à 03:14:07 UTC. Une seconde plus tard, le nombre déborde vers une grande valeur négative et la date revient en décembre 1901. Tout ce qui calcule des dates dans le futur, comme des prêts sur 20 ans, des certificats ou des tâches planifiées, peut rencontrer le problème plus tôt.
Les systèmes d'exploitation, langages et bases de données modernes utilisent un temps sur 64 bits, qui tient des milliards d'années. Le risque se trouve dans les vieux systèmes embarqués, les formats de fichiers et les colonnes de bases de données. Dans MySQL, par exemple, le type de colonne TIMESTAMP s'arrête toujours en janvier 2038 : les données appelées à durer sont plus sûres dans des colonnes DATETIME ou BIGINT. Si vous maintenez du code ancien, cherchez les champs de temps sur 32 bits et les colonnes int qui contiennent des timestamps.
Valeurs de référence utiles
- 0 = 1970-01-01 00:00:00 UTC, l'epoch elle-même.
- 1000000000 = 2001-09-09 01:46:40 UTC, le premier timestamp à dix chiffres.
- 1700000000 = 2023-11-14 22:13:20 UTC.
- 2000000000 = 2033-05-18 03:33:20 UTC.
- 2147483647 = 2038-01-19 03:14:07 UTC, la limite des 32 bits.
- 86400 = un jour, 604800 = une semaine, 3600 = une heure.