Un collegue m a envoye ce nombre : 1752345678, et m a demande quelle date c etait. J y ai jete un oeil et j ai dit : aux alentours du 2025-07-12. Quelques secondes plus tard il a relance — attends, c etait celui a 13 chiffres 1752345678901 ou celui a 10 chiffres 1752345678 ? C est l etat quotidien de la plupart des gens avec les timestamps UNIX : on les reconnait a l oeil, on ne sait pas les lire.

Ce guide existe pour que la prochaine fois que vous verrez une chaine de 10, 13, 16 ou 19 chiffres, vous puissiez dire tout de suite quel jour, heure et seconde elle pointe — et pour comprendre pourquoi l epoque se trouve etre 1970-01-01.

Vue d ensemble en 30 secondes

  • 1970-01-01 00:00:00 UTC a ete choisi comme epoque UNIX pour trois raisons : UNIX lui-meme etait en train de naitre a cette periode ; un entier signe 32 bits stocke le temps de la facon la plus commode en partant de la ; et choisir un moment fixe dans le passe simplifie l alignement entre systemes.
  • Un timestamp UNIX est le nombre de secondes depuis ce moment (avec decimales pour la precision sub-seconde). En pratique vous rencontrez quatre precisions courantes : secondes, millisecondes, microsecondes et nanosecondes.
  • Le nombre de chiffres lui-meme indique la precision : 10 chiffres sont des secondes, 13 des millisecondes, 16 des microsecondes, 19 des nanosecondes. Avec cette seule regle vous tombez juste 90% du temps.
  • Pour basculer a la demande entre secondes, millisecondes, microsecondes, nanosecondes et dates lisibles, ajoutez a vos favoris notre Convertisseur de timestamp UNIX.

5 scenarios reels : ou apparaissent les timestamps

Scenario 1 : un nombre a 13 chiffres dans un log serveur

Vous voyez une ligne type 1752345678901 INFO request completed dans un log backend. Ce nombre est presque surement en millisecondes, pas en secondes.

Pourquoi : les langages backend les plus utilises renvoient par defaut Date.now() (JavaScript), System.currentTimeMillis() (Java) ou time.time() * 1000 (Python), tous des millisecondes a 13 chiffres.

Solution : collez 1752345678901 dans notre Convertisseur de timestamp UNIX. Il detecte la precision automatiquement et affiche l heure UTC et l heure locale. Sans l outil, rappelez-vous que 13 chiffres divises par 1000 donnent a peu pres 10 chiffres, et que 1752345678 correspond a environ 2025-07-12.

Scenario 2 : un nombre a 10 chiffres dans une reponse API

Une API REST renvoie du JSON comme {"created_at": 1752345678, "expires_at": 1752346400}. C est presque surement des secondes.

Pourquoi : certaines API anciennes (surtout de l ere PHP et certains outils Unix) utilisent encore les secondes, et plusieurs API publiques de temps emettent directement en secondes.

Solution : regardez le nom du champ. S il s appelle unix_timestamp ou epoch_seconds, ce sont des secondes. S il s appelle created_time_ms ou timestamp_ms, ce sont des millisecondes. Notre Convertisseur de timestamp UNIX affiche les quatre precisions d un coup, donc vous pouvez verifier a l oeil.

Scenario 3 : les claims iat et exp dans un JWT

Le payload d un JWT contient souvent iat: 1752345678 et exp: 1752349278. Les deux sont en secondes, pas en millisecondes.

Pourquoi : le RFC 7519 (la spec JWT) definit NumericDate comme le nombre de secondes depuis l epoque (avec decimales facultatives). Toutes les bibliotheques JWT conformes utilisent les secondes.

Solution : decodez le token avec notre Decodeur JWT. iat et exp sont affiches en secondes par defaut. Si vous voyez un iat a 13 chiffres, c est un signal d alarme — soit la bibliotheque a injecte des millisecondes par erreur, soit une implementation non standard est en jeu.

Scenario 4 : ISO 8601 et epoch melanges dans la base de donnees

Un piege classique : une colonne stocke une chaine ISO 8601 (2025-07-12T10:30:00Z), une autre stocke un entier epoch (1752345678). Les JOIN qui oublient d unifier les unites deviennent lents, et les comparaisons qui ignorent le fuseau renvoient de mauvaises lignes.

Pourquoi : c est un residu d une decennie de scripts de migration et d ORMs. Equipes differentes et eres de code differentes laissent les deux formats cohabiter dans le meme schema.

Solution : les nouvelles tables stockent un seul format de temps absolu. Preferez les millisecondes epoch (13 chiffres) ou l ISO 8601 avec fuseau (2025-07-12T10:30:00+08:00). Ne melangez pas.

Scenario 5 : trois ingenieurs sur trois fuseaux

Quelqu un poste dans le chat une heure comme 2025-07-12 10:30:00. Un collegue la lit comme heure de Pekin, un autre comme UTC, un troisieme comme heure du Pacifique US. La reunion decale de huit heures et quelqu un se connecte a minuit.

Pourquoi : une chaine d heure locale sans fuseau est une mine dans la collaboration entre fuseaux.

Solution : en travail entre fuseaux n utilisez que l ISO 8601 avec fuseau (2025-07-12T10:30:00+08:00) ou l epoch (10 ou 13 chiffres). Les deux sont absolus et ne dependent pas de la position du lecteur. Comme standard d equipe, preferez l epoch ms — un nombre, un format, sans ambiguite pour celui qui colle.

4 pieges courants

Piege 1 : secondes contre millisecondes (l histoire Y2K : 2000-01-01 = 946684800 secondes, pas 946684800000)

Le piege classique : le 2000-01-01, une partie du code a traite l epoque comme des millisecondes et a calcule 946684800000. En reconvertissant en date, cela debordait l entier signe 32 bits, faisant planter des pans de certains systemes et renvoyant d autres dates en 1970.

Solution : le nombre de chiffres est votre premier indice. 10 chiffres sont des secondes ; 13 chiffres sont des millisecondes. Si votre code melange les unites, definissez des constantes comme SECOND = 1 et MILLISECOND = 1000 et faites passer toutes les conversions par elles. Pas de nombres bruts.

Piege 2 : comparer deux epoch entre fuseaux est sur ; comparer deux chaines locales naive ne l est pas

Deux epoch soustraits donnent toujours une vraie difference en secondes, independante du fuseau. Deux chaines locales naive comme 2025-07-12 10:30:00 soustraites donnent une soustraction litterale, pas une vraie difference de temps, quand les lecteurs sont sur des fuseaux differents.

Solution : persistance et comparaison entre fuseaux n utilisent que l epoch ou l ISO 8601 avec fuseau. Les chaines locales naive vivent uniquement dans la couche UI — jamais pour le stockage, jamais pour la comparaison.

Piege 3 : perte de precision — les microsecondes a 16 chiffres et les nanosecondes a 19 chiffres perdent de la precision en JavaScript

Number en JavaScript est double precision IEEE 754. Le plafond d entier sur est Number.MAX_SAFE_INTEGER = 2^53 - 1 ≈ 9.007 × 10^15. Une microseconde a 16 chiffres (jusqu a ~10^16) et une nanoseconde a 19 chiffres (jusqu a ~10^19) depassent cette limite, donc les stocker dans un number JS fait perdre de la precision.

Solution : les langages backend comme Go, Rust et les entiers Python preservent la precision nativement. Le frontend peut afficher, mais pour persister cote serveur passez en chaines ("1752345678901234567"). Les soustractions et comparaisons se font cote backend avec bigint ou une bibliotheque de dates.

Piege 4 : overflow 32 bits — apres le 2038-01-19 03:14:07 UTC, l entier signe 32 bits boucle

Un entier signe 32 bits monte jusqu a 2^31 - 1 = 2147483647 secondes, ce qui est exactement le 2038-01-19 03:14:07 UTC. Au-dela, un time_t 32 bits repasse en negatif et la date du systeme saute en 1901. C est Y2K38.

Solution : les langages modernes (Go, Rust, Python 3, Node.js, Java) utilisent tous des entiers 64 bits ou une precision superieure et ne sont pas concernes. Mais les systemes embarques, les mainframes COBOL heritage, certains dispositifs IoT et certains drivers de base de donnees utilisent encore un time_t 32 bits. Auditez ces chemins avant 2038 sinon ils repeteront le drame Y2K a leur maniere.

Pratiques recommandees

  1. Dans votre code, utilisez des chaines ISO 8601 avec fuseau pour le temps absolu — par exemple 2025-07-12T10:30:00+08:00. Les humains lisent, les machines parsent, pas d ambiguite de fuseau.
  2. En transit et en stockage, utilisez les millisecondes epoch (13 chiffres) pour le temps absolu. Un nombre, un format, sans ambiguite entre langages. Ca marche dans les payloads JSON, les logs, les colonnes de base et les parametres d URL.
  3. Devant l utilisateur, convertissez en chaines d heure locale. Utilisez Intl.DateTimeFormat ou une bibliotheque equivalente pour localiser le temps absolu — ne faites jamais calculer le fuseau a la main par l utilisateur.
  4. Pour le debug et la verification, ajoutez a vos favoris notre Convertisseur de timestamp UNIX. Collez un nombre, voyez UTC, heure locale, ISO 8601, RFC 2822 et quatre precisions epoch en une seconde. Combinez avec notre Decodeur JWT pour inspecter iat/exp et avec notre Generateur d expressions cron pour lire l epoch des next-run — la boucle de gestion du temps est fermee.
  5. Quand les timestamps arrivent encodes en URL ou en Base64 (etat OAuth, URLs signees, tokens avec horodatage), decodez d abord avec notre Encodeur de texte puis collez le resultat dans le Convertisseur de timestamp UNIX pour voir l heure lisible.

La difficulte avec les timestamps n est pas l arithmetique — c est le melange des precisions et des fuseaux. Quand votre equipe se cale sur le duo epoch ms + ISO 8601, 90% des incidents de fuseau disparaissent.

Faut-il encore s inquieter de 2038 ?

Ca depend ou vous regardez.

Bureaux, serveurs, mobiles, fonctions cloud — le time_t 64 bits est la norme partout, et Y2K38 n est pas un probleme sur ces plateformes. Linux, macOS, Windows, Go, Rust, Python 3, Node.js et Java sont tous en 64 bits. Le 2038-01-19, rien de visible ne se passera.

Le vrai risque vit dans les systemes embarques, les mainframes COBOL heritage, certains dispositifs IoT et certains drivers de base ou systemes de fichiers qui utilisent encore des entiers signes 32 bits pour time_t. Ces equipements ont des cycles lents de mise a jour firmware — cameras de surveillance, routeurs, PLCs industriels, ECU automobiles sont les categories a haut risque.

Solution : si votre business depend de dispositifs ou bibliotheques tierces, auditez maintenant votre chaine de dependances. Cherchez time_t, int32_t stockant des secondes, vieux schemas MySQL, code C embarque. Mettez a jour ce que vous pouvez, ecrivez des workarounds la ou vous ne pouvez pas, et remplacez le reste avant 2038.

Comme dans les annees qui ont precede Y2K, le monde de l ingenierie corrigera par lots dans une fenetre. Y2K38 a sa propre fenetre — plus courte que celle de Y2K parce que les equipements 32 bits sont desormais disperses chez de nombreux fabricants — et le travail commence aujourd hui.

Ouvrez le Convertisseur de timestamp UNIX, collez une valeur en millisecondes a 13 chiffres et regardez l outil detecter automatiquement la precision et fournir les quatre precisions plus UTC, heure locale, ISO 8601 et RFC 2822 d un coup. Un clic dans les favoris ; une reponse en une seconde. La prochaine fois que quelqu un colle 1752345678, vous aurez la reponse.