Timestamp Unix expliqué : qu'est-ce que l'heure Epoch et comment les développeurs l'utilisent

Timestamp Unix expliqué : qu'est-ce que l'heure Epoch et comment les développeurs l'utilisent

Les timestamps Unix font partie de ces notions présentes partout dans le développement logiciel mais rarement expliquées correctement. On les voit dans les colonnes de bases de données, les réponses d'API, les fichiers de logs, les jetons JWT, les systèmes de fichiers et les en-têtes HTTP. Une valeur comme 1710892800 peut ressembler à du bruit sans signification la première fois que vous la rencontrez, mais elle encode un instant précis que n'importe quel langage de programmation, sur n'importe quel système d'exploitation, peut interpréter sans ambiguïté.

Cet article explique ce que sont les timestamps Unix, pourquoi ils sont devenus la façon standard de représenter le temps en informatique et comment les manipuler dans sept langages de programmation. Que vous construisiez une API REST, déboguiez une tâche cron ou essayiez de comprendre un timestamp dans un dump de base de données, comprendre l'heure Epoch vous évitera des heures de confusion. Si vous devez convertir rapidement un timestamp Unix en date lisible, ou l'inverse, essayez notre convertisseur de timestamp Unix : il gère automatiquement les timestamps en secondes, millisecondes et microsecondes.

Qu'est-ce qu'un timestamp Unix ?

Un timestamp Unix est un entier unique qui représente un instant précis. Il compte le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00

Temps universel coordonné (UTC). Ce point de départ précis est appelé Epoch Unix, et la méthode de comptage est appelée temps Unix, temps POSIX ou simplement heure Epoch.

Par exemple, le timestamp Unix 1000000000 représente le 9 septembre 2001 à 01:46

UTC. Le timestamp 0 représente l'Epoch elle-même : minuit le 1er janvier 1970. Un timestamp de 86400 représente exactement un jour après l'Epoch, car une journée contient 86 400 secondes (60 secondes fois 60 minutes fois 24 heures).

Le choix du 1er janvier 1970 n'est pas arbitraire. Le système d'exploitation Unix était développé aux Bell Labs à la fin des années 1960 et au début des années 1970 par Ken Thompson, Dennis Ritchie et d'autres. Les premiers systèmes Unix avaient besoin d'une manière compacte de stocker les dates de modification des fichiers, et les ingénieurs ont choisi une date proche de la création du système. L'Epoch Unix originale était en réalité le 1er janvier 1971, mais elle a ensuite été reculée au 1er janvier 1970 pour donner au système un point de départ plus rond et plus de marge. Le compteur 32 bits qu'ils utilisaient pouvait représenter des dates jusqu'en 2038 avec un départ en 1970, ce qui paraissait alors une éternité.

Le terme "epoch" en informatique signifie simplement un point de référence fixe à partir duquel le temps est mesuré. Différents systèmes utilisent différentes epochs : Windows utilise le 1er janvier 1601 ; Mac OS Classic utilisait le 1er janvier 1904 ; NTP utilise le 1er janvier 1900. Mais l'Epoch Unix de 1970 est de loin la plus utilisée dans le développement logiciel moderne.

Pourquoi les développeurs utilisent les timestamps Unix

Les timestamps Unix sont devenus la représentation dominante du temps en logiciel pour plusieurs raisons pratiques qui résolvent de vrais problèmes d'ingénierie.

Indépendance vis-à-vis des fuseaux horaires. Un timestamp Unix est toujours en UTC. Lorsque votre API renvoie 1710892800, cette valeur signifie la même chose que le serveur soit à Tokyo, le client à Londres ou la base de données hébergée en Virginie. Il n'y a aucun décalage horaire à parser, aucune transition d'heure d'été à gérer, aucune ambiguïté sur le fait que "3

PM" signifie heure de l'Est ou du Pacifique. La conversion vers l'heure locale n'a lieu qu'au niveau de la présentation.

Arithmétique simple. Vous voulez savoir combien de secondes se sont écoulées entre deux événements ? Soustrayez un timestamp de l'autre. Vous devez planifier quelque chose dans 24 heures ? Ajoutez 86 400 au timestamp actuel. Vous devez vérifier si un jeton a expiré ? Comparez le timestamp d'expiration au temps actuel avec un simple opérateur inférieur. Aucune bibliothèque de parsing de dates n'est requise.

Indépendance du langage et de la plateforme. Tous les grands langages de programmation fournissent des fonctions intégrées pour travailler avec les timestamps Unix. Python a time.time(), JavaScript a Date.now(), PHP a time(), Java a System.currentTimeMillis(), Go a time.Now().Unix(), et les bases SQL ont UNIX_TIMESTAMP() ou EXTRACT(EPOCH FROM ...). Cette universalité fait des timestamps Unix un choix naturel pour l'échange de données entre systèmes écrits dans différents langages.

Stockage compact. Un timestamp Unix en secondes tient dans un entier 32 ou 64 bits. Cela représente 4 ou 8 octets, contre 19+ octets pour une chaîne ISO 8601 comme 2025-03-20T00:00:00Z. Dans des bases de données avec des millions de lignes, cette différence compte pour le stockage comme pour la performance des index.

Tri et comparaison sans ambiguïté. La comparaison d'entiers est plus rapide et plus simple que la comparaison de chaînes. Il n'y a aucun risque des bugs de tri qui touchent les chaînes de dates, où "03/04/2025" peut signifier le 4 mars ou le 3 avril selon la locale. Avec un calculateur de dates, vous pouvez vérifier n'importe quel calcul de date, mais les timestamps Unix rendent les maths trivialement correctes au niveau du code.

Comment fonctionne le temps Unix

Le temps Unix est un décompte linéaire et monotone croissant de secondes. À l'Epoch (1er janvier 1970, 00:00

UTC), le compteur valait zéro. Chaque seconde écoulée incrémente le compteur de un. Aujourd'hui, le timestamp Unix est d'environ 1,77 milliard, ce qui signifie qu'environ 1,77 milliard de secondes se sont écoulées depuis l'Epoch.

Le décompte est linéaire en ce sens que chaque seconde est traitée de la même manière. Il n'y a pas de trou pour les années bissextiles, pas d'ajustement pour l'heure d'été et, point controversé, aucune prise en compte des secondes intercalaires. Du point de vue du temps POSIX, chaque journée a exactement 86 400 secondes, chaque heure exactement 3 600 secondes et chaque minute exactement 60 secondes. C'est une simplification volontaire qui échange la précision astronomique contre la simplicité informatique.

Les timestamps négatifs représentent des instants avant l'Epoch. Le timestamp -86400 représente le 31 décembre 1969 à 00:00

UTC, exactement un jour avant l'Epoch. Le timestamp -2208988800 représente le 1er janvier 1900 à minuit UTC. Les timestamps négatifs sont parfaitement valides et pris en charge par la plupart des langages, même si certains anciens systèmes et bases de données les gèrent mal.

Vous pouvez voir le temps Unix comme une ligne numérique qui s'étend dans les deux directions depuis zéro :

... -86400 ─── 0 ─── 86400 ─── 172800 ...
    Dec 31     Jan 1   Jan 2    Jan 3
    1969       1970    1970     1970

Chaque graduation est séparée d'une seconde, et la ligne s'étend vers le passé pour représenter toute date historique et vers le futur jusqu'à ce que la taille d'entier du système soit épuisée. Pour les entiers signés 32 bits, la ligne s'arrête à 2 147 483 647 (19 janvier 2038). Pour les entiers signés 64 bits, elle s'étend sur environ 292 milliards d'années dans les deux directions, bien au-delà de l'âge de l'univers.

Secondes, millisecondes et microsecondes

Tous les "timestamps Unix" n'ont pas la même précision. Lorsque vous rencontrez un grand nombre qui représente un instant, le nombre de chiffres indique l'unité utilisée.

10 chiffres : secondes. C'est le timestamp Unix classique. Les valeurs actuelles ressemblent à 17xxxxxxxx. La plupart des appels système Unix/Linux, time() en PHP, int(time.time()) en Python, UNIX_TIMESTAMP() en MySQL et EXTRACT(EPOCH FROM ...) en PostgreSQL renvoient des timestamps en secondes. C'est le format le plus courant dans les bases de données et les API.

13 chiffres : millisecondes. Les valeurs actuelles ressemblent à 17xxxxxxxxxxx. Date.now() en JavaScript et System.currentTimeMillis() en Java renvoient des millisecondes par défaut. Beaucoup d'API modernes et de frameworks frontend utilisent des timestamps en millisecondes. Pour convertir en secondes, divisez par 1 000. Pour convertir des secondes en millisecondes, multipliez par 1 000.

16 chiffres : microsecondes. Les valeurs ressemblent à 17xxxxxxxxxxxxxx. time.time() en Python renvoie un flottant avec une précision en microsecondes. Certains systèmes de journalisation haute précision et applications scientifiques utilisent des timestamps en microsecondes. Pour convertir en secondes, divisez par 1 000 000.

19 chiffres : nanosecondes. Les valeurs ressemblent à 17xxxxxxxxxxxxxxxxx. time.Now().UnixNano() en Go renvoie des nanosecondes. La précision nanoseconde est utilisée dans le profilage de performance, les systèmes de traçage distribué et les plateformes de trading à haute fréquence. Pour convertir en secondes, divisez par 1 000 000 000.

Comment les distinguer automatiquement : comptez les chiffres. Si vous écrivez du code qui doit accepter des timestamps avec n'importe quelle précision, une heuristique simple fonctionne bien :

10 digits → seconds      (range: ~1973-2286 for positive values)
13 digits → milliseconds (range: ~1973-2286 for positive values)
16 digits → microseconds (range: ~1973-2286 for positive values)
19 digits → nanoseconds  (range: ~1973-2286 for positive values)

Si la valeur a 10 chiffres, traitez-la comme des secondes. Si elle en a 13, divisez par 1 000 pour la normaliser en secondes. Le motif est cohérent, car la plage de dates "intéressante" (passé récent à futur proche) tombe toujours dans ces plages de nombre de chiffres. Notre convertisseur de timestamp Unix détecte automatiquement la précision avec cette approche.

Timestamp Unix dans les langages de programmation

Voici des exemples pratiques pour les opérations de timestamp les plus courantes dans sept langages. Chaque section montre comment obtenir le timestamp actuel, convertir un timestamp en date lisible et convertir une date en timestamp.

Python

import time
from datetime import datetime, timezone

# Get current Unix timestamp (float with microsecond precision)
timestamp = time.time()            # e.g., 1710892800.123456
timestamp_int = int(time.time())   # e.g., 1710892800

# Timestamp to datetime (UTC)
dt = datetime.fromtimestamp(1710892800, tz=timezone.utc)
print(dt)  # 2024-03-20 00:00:00+00:00
print(dt.strftime('%Y-%m-%d %H:%M:%S'))  # 2024-03-20 00:00:00

# Datetime to timestamp
dt = datetime(2024, 3, 20, tzinfo=timezone.utc)
ts = int(dt.timestamp())  # 1710892800

# Parse a date string to timestamp
from datetime import datetime
dt = datetime.strptime("2024-03-20 15:30:00", "%Y-%m-%d %H:%M:%S")
dt = dt.replace(tzinfo=timezone.utc)
ts = int(dt.timestamp())

JavaScript

// Get current Unix timestamp in milliseconds
const nowMs = Date.now();             // e.g., 1710892800000

// Get current Unix timestamp in seconds
const nowSec = Math.floor(Date.now() / 1000);  // e.g., 1710892800

// Timestamp (seconds) to Date object
const date = new Date(1710892800 * 1000);  // Note: JS expects milliseconds
console.log(date.toISOString());           // "2024-03-20T00:00:00.000Z"
console.log(date.toLocaleString());        // Locale-dependent output

// Date to timestamp (seconds)
const ts = Math.floor(new Date('2024-03-20T00:00:00Z').getTime() / 1000);
// ts = 1710892800

// Timestamp to formatted string without libraries
const formatted = new Intl.DateTimeFormat('en-US', {
  dateStyle: 'full',
  timeStyle: 'long',
  timeZone: 'America/New_York'
}).format(new Date(1710892800 * 1000));

PHP

<?php
// Get current Unix timestamp
$timestamp = time();          // e.g., 1710892800
$microtime = microtime(true); // e.g., 1710892800.123456

// Timestamp to formatted date
echo date('Y-m-d H:i:s', 1710892800);    // "2024-03-20 00:00:00"
echo gmdate('Y-m-d H:i:s', 1710892800);  // UTC: "2024-03-20 00:00:00"

// Date string to timestamp
$ts = strtotime('2024-03-20 00:00:00 UTC');  // 1710892800

// Using DateTime object
$dt = new DateTime('2024-03-20', new DateTimeZone('UTC'));
$ts = $dt->getTimestamp();  // 1710892800

// Timestamp to DateTime
$dt = new DateTime();
$dt->setTimestamp(1710892800);
echo $dt->format('Y-m-d H:i:s T');

Java

import java.time.*;

// Get current Unix timestamp in seconds
long epochSecond = Instant.now().getEpochSecond();  // e.g., 1710892800

// Get current Unix timestamp in milliseconds
long epochMilli = System.currentTimeMillis();  // e.g., 1710892800000

// Timestamp to LocalDateTime (UTC)
LocalDateTime ldt = LocalDateTime.ofInstant(
    Instant.ofEpochSecond(1710892800), ZoneOffset.UTC
);
System.out.println(ldt);  // 2024-03-20T00:00

// Timestamp to ZonedDateTime (with timezone)
ZonedDateTime zdt = Instant.ofEpochSecond(1710892800)
    .atZone(ZoneId.of("America/New_York"));
System.out.println(zdt);  // 2024-03-19T20:00-04:00[America/New_York]

// Date to timestamp
long ts = LocalDateTime.of(2024, 3, 20, 0, 0, 0)
    .toEpochSecond(ZoneOffset.UTC);  // 1710892800

SQL (MySQL et PostgreSQL)

-- MySQL: Get current Unix timestamp
SELECT UNIX_TIMESTAMP();                          -- e.g., 1710892800
SELECT UNIX_TIMESTAMP('2024-03-20 00:00:00');     -- 1710892800

-- MySQL: Timestamp to datetime
SELECT FROM_UNIXTIME(1710892800);                 -- '2024-03-20 00:00:00'
SELECT FROM_UNIXTIME(1710892800, '%Y-%m-%d');     -- '2024-03-20'

-- PostgreSQL: Get current Unix timestamp
SELECT EXTRACT(EPOCH FROM NOW())::BIGINT;         -- e.g., 1710892800
SELECT EXTRACT(EPOCH FROM TIMESTAMP '2024-03-20 00:00:00')::BIGINT;

-- PostgreSQL: Timestamp to datetime
SELECT TO_TIMESTAMP(1710892800);                  -- '2024-03-20 00:00:00+00'
SELECT TO_TIMESTAMP(1710892800) AT TIME ZONE 'US/Eastern';

-- Filter rows from the last 24 hours (MySQL)
SELECT * FROM events
WHERE created_at >= UNIX_TIMESTAMP() - 86400;

-- Filter rows from the last 24 hours (PostgreSQL)
SELECT * FROM events
WHERE created_at >= EXTRACT(EPOCH FROM NOW()) - 86400;

Go

package main

import (
    "fmt"
    "time"
)

func main() {
    // Get current Unix timestamp
    sec := time.Now().Unix()        // seconds, e.g., 1710892800
    ms := time.Now().UnixMilli()    // milliseconds
    us := time.Now().UnixMicro()    // microseconds
    ns := time.Now().UnixNano()     // nanoseconds

    // Timestamp to time.Time
    t := time.Unix(1710892800, 0).UTC()
    fmt.Println(t)                                    // 2024-03-20 00:00:00 +0000 UTC
    fmt.Println(t.Format("2006-01-02 15:04:05"))     // 2024-03-20 00:00:00
    fmt.Println(t.Format(time.RFC3339))               // 2024-03-20T00:00:00Z

    // Date to timestamp
    t2 := time.Date(2024, 3, 20, 0, 0, 0, 0, time.UTC)
    ts := t2.Unix()  // 1710892800

    fmt.Println(sec, ms, us, ns, ts)
}

Bash / Shell

# Get current Unix timestamp
date +%s                          # e.g., 1710892800

# Timestamp to human-readable date (GNU/Linux)
date -d @1710892800               # Wed Mar 20 00:00:00 UTC 2024
date -d @1710892800 '+%Y-%m-%d %H:%M:%S'  # 2024-03-20 00:00:00

# Timestamp to human-readable date (macOS/BSD)
date -r 1710892800                # Wed Mar 20 00:00:00 UTC 2024
date -r 1710892800 '+%Y-%m-%d'   # 2024-03-20

# Date string to timestamp (GNU/Linux)
date -d '2024-03-20 00:00:00 UTC' +%s    # 1710892800

# Date string to timestamp (macOS/BSD)
date -j -f '%Y-%m-%d %H:%M:%S' '2024-03-20 00:00:00' +%s

# Calculate elapsed time
START=$(date +%s)
# ... some operation ...
END=$(date +%s)
ELAPSED=$((END - START))
echo "Operation took ${ELAPSED} seconds"

Timestamp Unix dans Excel et Google Sheets

Les tableurs utilisent leur propre système de numéros de série de dates, mais vous pouvez convertir les timestamps Unix avec des formules simples.

Timestamp Unix vers date dans Excel ou Google Sheets :

=(A1/86400)+DATE(1970,1,1)

Cette formule divise le timestamp par 86 400 (le nombre de secondes dans une journée) pour obtenir le nombre de jours depuis l'Epoch, puis l'ajoute à la date Epoch. Formatez la cellule résultat comme une date/heure pour voir une valeur lisible.

Date vers timestamp Unix :

=(A1-DATE(1970,1,1))*86400

Cela inverse le processus : calculer le nombre de jours entre la date et l'Epoch, puis multiplier par 86 400 pour obtenir des secondes.

Mise en garde importante sur les fuseaux horaires : Excel et Google Sheets ne comprennent pas intrinsèquement les fuseaux horaires. Les formules ci-dessus supposent que les timestamps sont en UTC. Si vos dates de tableur sont dans un fuseau horaire local, vous devez ajuster en ajoutant ou soustrayant le décalage UTC en secondes. Par exemple, pour US Eastern (UTC-5) :

=(A1/86400)+DATE(1970,1,1)-(5/24)

Gestion des timestamps en millisecondes : si vos données contiennent des timestamps à 13 chiffres en millisecondes, divisez par 86 400 000 au lieu de 86 400 :

=(A1/86400000)+DATE(1970,1,1)

Pour des conversions ponctuelles rapides sans créer de feuille de calcul, utilisez directement notre convertisseur de timestamp Unix dans votre navigateur.

Timestamps Unix remarquables

Certains timestamps Unix sont devenus des jalons mémorables dans l'histoire de l'informatique. Certains ont été célébrés par les programmeurs ; d'autres ont causé de vrais bugs.

Date (UTC)	Timestamp Unix	Importance
Jan 1, 1970 00:00	0	L'Epoch Unix, début du temps Unix
Jan 1, 2000 00:00	946,684,800	Y2K / passage à l'an 2000
Sep 9, 2001 01:46	1,000,000,000	Un milliard de secondes, célébré par les passionnés d'Unix
Jan 9, 2007 09:41	1,168,344,060	Steve Jobs annonce le premier iPhone
Mar 13, 2009 23:31	1,234,567,890	Chiffres séquentiels, fêtes "Unix time 1234567890"
Jul 14, 2017 02:40	1,500,000,000	1,5 milliard de secondes depuis l'Epoch
Jan 1, 2025 00:00	1,735,689,600	Début de l'année 2025
May 18, 2033 03:33	2,000,000,000	Deux milliards de secondes
Jan 19, 2038 03:14	2,147,483,647	Entier signé 32 bits maximum, échéance Y2K38

Le jalon du milliard de secondes en 2001 a été largement remarqué dans la communauté développeur. Certaines équipes ont organisé des fêtes "epoch second" similaires aux célébrations Y2K. Le timestamp à chiffres séquentiels 1234567890 en 2009 a suscité encore plus d'attention, avec des sites de compte à rebours et des rassemblements de passionnés Unix dans le monde entier.

Le problème de l'année 2038 (Y2K38)

Le problème de l'année 2038 est un bug réel et bien compris qui affecte tout système stockant les timestamps Unix dans des entiers signés 32 bits. On l'appelle parfois "bug Y2K38" ou "Unix Millennium Bug". Même s'il est moins spectaculaire que Y2K, il peut provoquer des perturbations importantes dans les systèmes non mis à jour.

Ce qui se passe

Un entier signé 32 bits peut représenter des valeurs de -2 147 483 648 à 2 147 483 647. La valeur positive maximale, 2 147 483 647, correspond au 19 janvier 2038 à 03:14

UTC. Une seconde plus tard, l'entier déborde. Au lieu de devenir 2 147 483 648, il revient à -2 147 483 648, que le système interprète comme le 13 décembre 1901 à 20:45

UTC.

Ce n'est pas un problème théorique. Tout logiciel qui compare des timestamps, calcule des durées ou planifie des événements futurs produira des résultats incorrects après le débordement. Un fichier créé en 2038 pourrait sembler plus ancien qu'un fichier créé en 2037. Un certificat SSL valide jusqu'en 2040 pourrait paraître expiré depuis plus d'un siècle. Une tâche planifiée pour mardi prochain pourrait s'exécuter immédiatement ou ne jamais s'exécuter.

Comparaison avec Y2K

Le bug Y2K venait du stockage des années sur deux chiffres, de sorte que l'an 2000 était indistinguable de 1900. Le bug Y2K38 est mécaniquement différent mais conceptuellement similaire : il est causé par un entier de taille fixe qui sort de sa plage. La correction Y2K portait surtout sur les formats de chaînes de dates. La correction Y2K38 exige de changer les types de données à un niveau plus profond, dans les appels système, formats de fichiers, schémas de bases de données et protocoles binaires.

La solution

Le correctif est simple en principe : utiliser des entiers 64 bits au lieu d'entiers 32 bits. Un entier signé 64 bits peut représenter des timestamps jusqu'à environ 292 milliards d'années depuis l'Epoch, ce qui devrait suffire. La plupart des systèmes d'exploitation 64 bits modernes, y compris Linux (depuis le noyau 5.6 pour toutes les interfaces internes), macOS et les versions modernes de Windows, ont déjà fait cette transition. Les langages de programmation exécutés sur des systèmes 64 bits utilisent généralement des valeurs temporelles 64 bits par défaut.

Systèmes encore à risque

Le danger se trouve dans les systèmes difficiles à mettre à jour :

• Appareils embarqués avec processeurs 32 bits (contrôleurs industriels, dispositifs médicaux, systèmes automobiles) qui pourraient encore fonctionner en 2038
• Bases de données héritées avec colonnes de timestamp en entier 32 bits (certaines tables MySQL utilisant INT au lieu de BIGINT)
• Formats de fichiers binaires qui codent en dur des timestamps 32 bits dans leurs en-têtes
• Appareils IoT avec de longues durées de déploiement et des mises à jour firmware rares
• Protocoles réseau qui spécifient des champs de timestamp 32 bits dans leurs standards

Si vous concevez un nouveau système aujourd'hui, utilisez toujours des entiers 64 bits pour les timestamps. Si vous travaillez sur un système existant, auditez votre stockage des timestamps : vérifiez les types de colonnes de base de données, les définitions de structures et les formats de sérialisation. Utilisez des convertisseurs comme hexadécimal vers décimal pour inspecter des données binaires brutes si vous devez vérifier comment les timestamps sont stockés au niveau des octets.

Secondes intercalaires et temps Unix

L'un des aspects les plus débattus du temps Unix est son traitement des secondes intercalaires. Réponse courte : le temps POSIX les ignore entièrement.

Dans le monde réel, la rotation de la Terre ralentit progressivement. Pour maintenir UTC synchronisé avec la rotation réelle de la planète, l'International Earth Rotation and Reference Systems Service (IERS) insère occasionnellement une seconde intercalaire. Entre 1972 et 2016, 27 secondes intercalaires ont été ajoutées. Pendant une seconde intercalaire, l'horloge UTC indique 23:59

avant de passer à 00:00, soit une minute de 61 secondes.

Le temps POSIX fait comme si cela n'existait pas. Chaque journée est définie comme exactement 86 400 secondes, chaque minute comme exactement 60 secondes. Lorsqu'une seconde intercalaire se produit dans la réalité, le temps POSIX répète une seconde (la même valeur de timestamp apparaît deux fois) ou étale l'ajustement sur les secondes voisines, selon l'implémentation. L'approche "leap smear" de Google répartit la seconde supplémentaire sur une fenêtre de 24 heures, de sorte que chaque seconde est très légèrement plus longue qu'une vraie seconde ce jour-là.

Pour la grande majorité des tâches de développement logiciel, cela n'a pas d'importance. La différence entre le temps Unix et l'UTC précis est au plus de quelques secondes sur toute l'Epoch, ce qui est négligeable pour les timestamps de logs, inscriptions d'utilisateurs, limites de débit API ou tâches planifiées. Si vous construisez des systèmes de navigation par satellite, des logiciels d'observation astronomique ou des plateformes de trading financier qui exigent une précision sub-seconde par rapport au TAI (Temps atomique international), vous avez besoin d'une représentation du temps différente des timestamps Unix.

Il est à noter que la Conférence générale des poids et mesures a voté en 2022 l'abolition des secondes intercalaires d'ici 2035, donc tout ce sujet pourrait devenir sans objet dans un avenir proche.

Foire aux questions

Les timestamps Unix peuvent-ils être négatifs ?

Oui. Les timestamps Unix négatifs représentent des dates antérieures au 1er janvier 1970. Par exemple, -1 correspond au 31 décembre 1969 à 23:59

UTC, et -86400 au 31 décembre 1969 à 00:00 UTC. La plupart des langages modernes gèrent correctement les timestamps négatifs, mais certains systèmes et bases de données ne les prennent pas en charge. La fonction FROM_UNIXTIME() de MySQL, par exemple, n'accepte que les valeurs non négatives. Si vous devez travailler avec des dates historiques avant 1970, testez le comportement de votre plateforme.

Quel est le timestamp Unix maximum ?

Sur un système 32 bits, le timestamp Unix maximum est 2 147 483 647 (19 janvier 2038 à 03:14

UTC). Sur un système 64 bits, le maximum est 9 223 372 036 854 775 807 (environ 292 milliards d'années à partir de maintenant). Les systèmes et langages modernes utilisent par défaut des valeurs temporelles 64 bits, donc la limite pratique est effectivement infinie. Vous pouvez vérifier de grands nombres avec un convertisseur binaire vers décimal pour voir comment la représentation binaire correspond à la valeur entière maximale.

Le temps Unix est-il la même chose que UTC ?

Pas exactement. Le temps Unix est basé sur UTC mais ignore volontairement les secondes intercalaires, il peut donc dériver de quelques secondes par rapport au vrai UTC. Pour tous les usages pratiques en développement d'applications, le temps Unix et UTC sont interchangeables. La distinction ne compte que dans les contextes scientifiques, militaires ou de timing haute précision. Le temps Unix est toujours référencé à UTC : il n'intègre jamais de décalage de fuseau horaire ni d'heure d'été.

Comment les fuseaux horaires affectent-ils les timestamps Unix ?

Ils ne les affectent pas, et c'est précisément l'intérêt. Un timestamp Unix est indépendant du fuseau horaire. La valeur 1710892800 représente le même instant partout dans le monde. Les fuseaux horaires n'interviennent que lorsque vous convertissez un timestamp Unix en format lisible. La fonction new Date(1710892800 * 1000) en JavaScript affichera des heures différentes selon le fuseau local du navigateur, mais l'instant sous-jacent est identique. Stockez et transmettez toujours les timestamps en UTC (ce que sont les timestamps Unix par définition), puis convertissez en heure locale seulement pour l'affichage.

Quelle est la différence entre temps Unix et ISO 8601 ?

Le temps Unix est une représentation numérique (un entier qui compte les secondes), tandis qu'ISO 8601 est un format de chaîne (comme 2024-03-20T00:00:00Z). Les deux peuvent représenter le même instant, mais ils ont des compromis différents. Les timestamps Unix sont plus compacts (4-8 octets contre 20+), plus rapides à comparer (comparaison d'entiers contre parsing de chaîne) et plus simples pour l'arithmétique. Les chaînes ISO 8601 sont lisibles sans conversion et auto-descriptives (elles incluent l'information de fuseau horaire). Les API acceptent souvent les deux formats ; les bases de données peuvent stocker l'un et exposer l'autre. Utilisez les timestamps Unix pour le stockage et le calcul, et ISO 8601 pour les sorties destinées aux utilisateurs et les échanges de données où la lisibilité compte.

Comment convertir un timestamp Unix dans un paramètre d'URL ?

Passez le timestamp comme un entier brut dans la chaîne de requête : https://example.com/api/events?since=1710892800. Aucun encodage n'est nécessaire, car les timestamps ne contiennent que des chiffres. Côté serveur, parsez-le comme un entier et validez la plage. Les validations courantes consistent à vérifier que la valeur est positive (sauf si vous supportez les dates avant 1970), qu'elle ne dépasse pas le maximum de votre système et qu'elle est dans la précision attendue (secondes ou millisecondes). Si votre API reçoit à la fois secondes et millisecondes, vérifiez le nombre de chiffres : 10 chiffres signifie secondes, 13 chiffres signifie millisecondes. Documentez la précision attendue par votre API pour éviter la confusion.

Conclusion

Les timestamps Unix sont un concept fondamental en ingénierie logicielle. Leur simplicité, un entier unique comptant les secondes depuis un point fixe, les rend idéaux pour stocker, comparer et transmettre des valeurs temporelles entre langages, plateformes et fuseaux horaires. Comprendre leur fonctionnement, la précision à utiliser et les pièges à surveiller (notamment le problème de 2038) fera de vous un développeur plus efficace.

Que vous déboguiez un timestamp dans un fichier de logs, conceviez un schéma de base de données ou construisiez une API servant des clients dans plusieurs fuseaux horaires, les timestamps Unix fournissent une base fiable et sans ambiguïté. Ajoutez notre convertisseur de timestamp Unix à vos favoris pour les conversions rapides, et retenez : en cas de doute, stockez le temps comme timestamp Unix 64 bits en UTC.