Format Unix Timestamp vs ISO 8601 : lequel tu devrais utiliser ?

Si tu as déjà intégré deux systèmes qui stockent les dates différemment, tu connais déjà la galère. Une API renvoie 1714521600, une autre renvoie 2024-05-01T00:00:00Z, et te voilà à écrire de la logique de conversion à minuit. Choisir dès le départ le bon format entre le timestamp Unix et l'ISO 8601 permet d'économiser des heures de débogage et d'éviter des bugs discrets en production. Les deux formats sont largement utilisés, chacun a de vraies forces, et aucun n'est universellement « meilleur ». Ce qui compte, c'est de comprendre précisément dans quel contexte chacun s'impose — et pourquoi un mauvais choix a un coût réel.

Qu'est-ce que le format timestamp Unix ?

Un timestamp Unix (aussi appelé Unix time ou epoch time) est un simple entier représentant le nombre de secondes écoulées depuis l'époque Unix : le 1er janvier 1970, 00:00:00 UTC. Le format Unix time est par définition indépendant du fuseau horaire, car il fait toujours référence à UTC. Il n'y a aucune ambiguïté liée à l'heure d'été ou aux décalages régionaux.

Par exemple, le timestamp Unix 1714521600 représente un instant précis et unique, peu importe où dans le monde tu le lis. Les systèmes modernes étendent souvent cette précision aux millisecondes (1714521600000) voire aux microsecondes. Tu peux en apprendre davantage sur ces variantes dans notre guide sur les secondes, millisecondes et microsecondes dans les timestamps Unix.

Techniquement, un timestamp Unix n'est qu'un nombre. Cette simplicité est à la fois sa plus grande force et la source de son principal problème de lisibilité.

Pour un historique approfondi de l'origine de ce concept, consulte notre article sur l'epoch time et ses fondements.

Qu'est-ce que le format de date ISO 8601 ?

L'ISO 8601 est une norme internationale publiée par l'Organisation internationale de normalisation qui définit comment représenter les dates et les heures sous forme de chaînes de caractères. Un datetime ISO 8601 typique ressemble à ceci : 2024-05-01T00:00:00Z.

Décomposons ce format :

• 2024-05-01 — la date au format YYYY-MM-DD
• T — un séparateur entre la date et l'heure
• 00:00:00 — l'heure au format HH:MM:SS
• Z — indique UTC (on peut aussi utiliser des décalages comme +05:30)

L'ISO 8601 constitue la base de la norme RFC 3339 largement utilisée dans les protocoles internet. Ce format est lisible par l'humain, triable sous forme de chaîne et sans ambiguïté selon les locales. Contrairement à l'écriture « 05/01/2024 » — qui signifie le 1er mai aux États-Unis mais le 5 janvier en Europe — l'ISO 8601 est universellement cohérent.

Différences clés en un coup d'œil

Quand utiliser le timestamp Unix ?

Le format Unix time excelle dans des situations précises et bien définies. Utilise-le quand :

1. Tu fais des calculs sur les dates

Calculer des durées est trivial avec des timestamps Unix. Pour savoir combien de secondes se sont écoulées, il suffit de soustraire un entier d'un autre. Avec des chaînes ISO 8601, tu dois d'abord parser les deux valeurs en objets datetime, puis calculer la différence. Pour des opérations à haute fréquence (imagine la journalisation de millions d'événements), ce surcoût de parsing s'accumule rapidement.

2. Tu stockes des dates en base de données

Les colonnes d'entiers sont plus rapides à indexer et à comparer que les colonnes de chaînes. Si tu exécutes des requêtes du type « donne-moi tous les événements des 7 derniers jours », comparer deux entiers est plus efficace que parser et comparer des chaînes. Notre guide détaillé sur les timestamps Unix en base de données couvre en profondeur les stratégies d'indexation et les patterns de requêtes.

3. Tu communiques entre services internes

Quand deux services backend que tu contrôles doivent s'échanger des timestamps, le format Unix réduit la complexité de parsing. Les deux côtés s'accordent sur un contrat entier, sans risque de mauvaise interprétation d'une chaîne de fuseau horaire.

4. Logique d'expiration et de TTL

Les tokens JWT, les entrées de cache et les expirations de session sont presque universellement exprimés en timestamps Unix. Le claim exp d'un JSON Web Token (JWT) est un timestamp Unix précisément pour cette raison : comparer exp > Date.now() / 1000 n'est qu'une seule comparaison d'entiers.

5. Éviter les bugs de fuseau horaire

Comme les timestamps Unix sont toujours en UTC, ils éliminent toute une catégorie de bugs liés à l'heure d'été. Si ton application sert des utilisateurs dans plusieurs fuseaux horaires, stocker des timestamps Unix et ne convertir en heure locale qu'au moment de l'affichage est un pattern architectural éprouvé.

Sois vigilant face au problème de l'an 2038 si tu utilises des entiers signés sur 32 bits pour stocker des timestamps Unix — utilise toujours des entiers 64 bits dans les systèmes modernes.

Quand utiliser le format de date ISO 8601 ?

Le format de date ISO 8601 s'impose dans les contextes où des humains ou des systèmes externes doivent lire, écrire ou valider des dates sans exécuter de code.

1. Réponses d'API consommées par des tiers

Si tu construis une API publique, renvoyer "created_at": "2024-05-01T12:30:00Z" est bien plus agréable pour les développeurs que "created_at": 1714562200. Les développeurs externes comprennent immédiatement la valeur sans avoir à la convertir. De nombreux guides de style d'API, dont ceux de Stripe et GitHub, utilisent l'ISO 8601 par défaut pour cette raison.

2. Fichiers de logs et pistes d'audit

Les logs sont lus par des humains lors d'incidents. Une ligne de log qui dit [2024-05-01T14:22:05Z] ERROR: payment failed est immédiatement exploitable. Un log avec [1714569725] ERROR: payment failed oblige le lecteur à convertir le timestamp avant même de commencer à déboguer.

3. Internationalisation et localisation

L'ISO 8601 inclut des informations explicites sur le décalage de fuseau horaire. Quand ton système doit préserver l'heure locale d'origine de l'utilisateur (par exemple, un événement de calendrier créé à 9h00 à Tokyo), l'ISO 8601 avec le bon décalage (2024-05-01T09:00:00+09:00) capture cette intention. Un timestamp Unix seul ne peut pas indiquer dans quel fuseau horaire se trouvait l'utilisateur au moment de la création.

4. Fichiers de configuration et formats d'échange de données

Les fichiers JSON, YAML et CSV que les humains éditent doivent utiliser l'ISO 8601. Si un développeur doit définir manuellement une date d'expiration dans un fichier de configuration, écrire 2025-01-01T00:00:00Z est bien moins risqué que de calculer et saisir un timestamp Unix à la main.

Exemples de code en JavaScript et Python

JavaScript : conversion entre les deux formats

// Obtenir le timestamp Unix actuel (en secondes)
const unixNow = Math.floor(Date.now() / 1000);
console.log(unixNow); // ex. 1714521600

// Convertir un timestamp Unix en chaîne ISO 8601
const isoString = new Date(unixNow * 1000).toISOString();
console.log(isoString); // "2024-05-01T00:00:00.000Z"

// Convertir une chaîne ISO 8601 en timestamp Unix
const parsed = new Date("2024-05-01T00:00:00Z");
const backToUnix = Math.floor(parsed.getTime() / 1000);
console.log(backToUnix); // 1714521600

// Calculer une durée entre deux timestamps Unix (aucun parsing nécessaire)
const start = 1714521600;
const end = 1714608000;
const durationSeconds = end - start;
console.log(`Duration: ${durationSeconds / 3600} hours`); // 24 hours

Python : travailler avec les deux formats

import time
from datetime import datetime, timezone

# Obtenir le timestamp Unix actuel
unix_now = int(time.time())
print(unix_now)  # ex. 1714521600

# Convertir un timestamp Unix en chaîne ISO 8601
dt = datetime.fromtimestamp(unix_now, tz=timezone.utc)
iso_string = dt.isoformat()
print(iso_string)  # "2024-05-01T00:00:00+00:00"

# Convertir une chaîne ISO 8601 en timestamp Unix
parsed_dt = datetime.fromisoformat("2024-05-01T00:00:00+00:00")
back_to_unix = int(parsed_dt.timestamp())
print(back_to_unix)  # 1714521600

# Calculer une durée - trivial avec des timestamps Unix
start = 1714521600
end = 1714608000
duration_hours = (end - start) / 3600
print(f"Duration: {duration_hours} hours")  # 24.0 hours

Exemple concret : système de réservation

Imagine que tu construises une API de réservation hôtelière. Un utilisateur à New York réserve une chambre avec un check-in prévu le 15 juin 2024 à 15h00, heure locale. Voici comment les deux formats se comportent différemment en pratique.

Stockage en timestamp Unix : Tu convertis l'heure locale de l'utilisateur en UTC et stockes 1718470800. C'est compact et rapide à requêter. Mais quand le personnel de l'hôtel à New York consulte l'enregistrement brut en base de données, il voit un nombre. Il a besoin d'un outil pour le déchiffrer. Pire encore, si tu oublies de convertir l'heure locale en UTC avant le stockage, tu introduis silencieusement un bug de 4 heures (New York est à UTC-4 en été).

Stockage en ISO 8601 : Tu stockes 2024-06-15T15:00:00-04:00. Le décalage est préservé. Le personnel peut lire l'enregistrement directement. L'intention de fuseau horaire d'origine n'est pas perdue. En revanche, les comparaisons de chaînes en SQL sont légèrement plus lentes, et calculer « dans combien d'heures est le check-in » nécessite de parser la chaîne au préalable.

La solution en production qu'adoptent la plupart des équipes : stocker le timestamp Unix en base de données pour les performances et la fiabilité, et retourner la chaîne ISO 8601 dans la réponse API pour la lisibilité. C'est le pattern utilisé par les grandes plateformes. Tu obtiens le meilleur des deux mondes.

Pour un guide complet des patterns de conversion, consulte notre guide complet de conversion de timestamp Unix en date.

Recommandation claire par cas d'usage

Sur la base de contraintes réelles, voici une recommandation directe pour chaque scénario :

• Stockage en base de données : utilise le timestamp Unix (entier). Indexation plus rapide, pas de parsing de fuseau horaire, empreinte mémoire réduite.
• Communication entre microservices internes : utilise le timestamp Unix. Les deux côtés maîtrisent le contrat et aucun humain ne lit le payload brut.
• Réponses d'API REST publiques : utilise l'ISO 8601. Les développeurs tiers ont besoin de valeurs lisibles et auto-documentées.
• Fichiers de logs et pistes d'audit : utilise l'ISO 8601. Les humains lisent les logs sous pression lors d'incidents.
• Expiration de JWT et de sessions : utilise le timestamp Unix. La spécification l'exige et les comparaisons se font en une seule opération.
• Fichiers de configuration et tâches planifiées : utilise l'ISO 8601. Les humains écrivent et éditent ces fichiers directement.
• Fonctionnalités de calendrier et de planification : utilise l'ISO 8601 avec un décalage de fuseau horaire explicite. Préserve l'intention de fuseau horaire d'origine de l'utilisateur.
• Arithmétique de dates dans la logique applicative : convertis d'abord en timestamp Unix, effectue les calculs, puis reconvertis si nécessaire.

Pour un ensemble plus large de bonnes pratiques autour de la manipulation des timestamps dans le code backend, notre tutoriel timestamp Unix pour développeurs couvre en détail les patterns de stockage, de formatage et de gestion des fuseaux horaires.

Conclusion

Le débat entre timestamp Unix et format de date ISO 8601 ne porte pas sur la supériorité de l'un sur l'autre. Il s'agit d'utiliser le bon outil pour le bon usage. Les timestamps Unix ont leur place dans tes colonnes de base de données, tes contrats de services internes et ta logique d'expiration. L'ISO 8601 appartient à tes réponses API, tes logs et tout fichier qu'un humain pourrait ouvrir. La plupart des systèmes en production robustes utilisent les deux : stocker en Unix time, exposer en ISO 8601. Si tu intègres ce seul pattern, tu éviteras les bugs de gestion des dates les plus courants avant même qu'ils n'atteignent la production.

Fini les doutes sur le format de date à utiliser

Essaie notre convertisseur de timestamp Unix gratuit sur unixtimestamp.app et convertis instantanément entre Unix time et ISO 8601 — sans écrire une seule ligne de code. Colle un timestamp, obtiens une date lisible en quelques secondes.

Essayer l'outil gratuit →