Timestamp Unix : pourquoi des secondes ou millisecondes donnent-elles 1970 ?

Si un horodatage récent devient une date de janvier 1970, je vérifierais d'abord si des secondes ont été interprétées comme des millisecondes. Les deux représentations peuvent partir de la même origine, mais une seconde contient mille millisecondes. Se tromper d'unité change donc radicalement la date affichée. Une valeur absente remplacée par zéro peut également produire 1970 : c'est un indice à examiner, pas une explication automatique.

Prenons une enquête de support fictive. Je reçois un petit export d'événements avec la valeur `1704067200`. Un autre fichier contient `1704067200000`. On me demande si ces deux lignes parlent du même moment. Avant de corriger le fichier ou de signaler une panne, je veux comprendre ce que chaque colonne représente. Les fichiers et l'échange sont inventés ; les calculs sont reproductibles.

Deux nombres différents pour le même instant

Interprété en secondes depuis l'origine Unix, `1704067200` correspond au 1er janvier 2024 à 00:00:00 UTC. Le même instant exprimé en millisecondes devient `1704067200000`. Multiplier par mille change ici l'unité, pas l'événement.

En revanche, si un logiciel lit `1704067200` comme un nombre de millisecondes, il obtient le 20 janvier 1970 à 17:21:07,200 UTC. Cette date très ancienne est bien le résultat de l'interprétation erronée. Elle ne dit rien de l'année pendant laquelle l'événement d'origine s'est produit.

La explication POSIX de l’époque situe l'origine Unix/POSIX au 1er janvier 1970 à minuit UTC. L'objet `Date` classique de JavaScript utilise des millisecondes depuis cette origine, comme l'explique la référence MDN.

Dans mes notes, je conserverais toujours le nombre avec son unité déclarée. Un grand entier, pris isolément, reste ambigu. Le nom de la colonne, la documentation de l'export ou le système qui produit la valeur doit expliquer son sens.

Je compare une ligne avant de toucher au fichier entier

Pour commencer, je choisirais une copie d'exemple sans donnée personnelle. Inutile de transmettre un fichier clients complet si la question porte uniquement sur la représentation d'un nombre. Une ligne minimale facilite aussi la recherche du problème.

La dernière ligne est importante. Zéro représente un instant valide. Il ne devrait pas signifier implicitement « inconnu », « pas encore reçu » ou « aucun rendez-vous ». Le système qui produit le fichier doit distinguer ces situations.

Je garde aussi le texte original de la valeur. Si un tableur a déjà arrondi le nombre ou l'affiche en notation scientifique, la cellule visible ne suffit pas forcément à reconstituer l'export. Ma première référence reste ce qui a effectivement été enregistré par la source.

Retrouver les opérations utiles dans Convertix Online

L'interface publique de Convertix Online propose Texte & données, avec les opérations Timestamp → date et Date → timestamp. Ces libellés et leur fonctionnement public ont été vérifiés le 14 septembre 2026. Le parcours décrit ici concerne le navigateur.

Pour la première opération, je saisirais une valeur de l'exemple sans espace de regroupement ni séparateur de milliers. Les deux nombres correctement interprétés correspondent à la même date UTC. L'outil actuel déduit secondes ou millisecondes de la grandeur du nombre, ce qui facilite le traitement des valeurs récentes courantes. Cette déduction ne remplace pas la définition d'une colonne inconnue.

Dans l'autre sens, j'utiliserais une date explicite comme `2024-01-01T00:00:00Z`. L'opération Date → timestamp renvoie actuellement des secondes entières. Il faut le savoir avant de comparer ce résultat à un logiciel qui attend des millisecondes ou conserve des fractions de seconde.

Les résultats attendus de cet article reposent sur les calculs et sur le fonctionnement public examiné ; ce ne sont pas les résultats d'un essai interactif réalisé pour ce récit. Avant de réutiliser une sortie, je la vérifierais, surtout pour une date ancienne, une valeur inhabituelle ou un format provenant d'un autre système.

Dix ou treize chiffres : un repère, pas une preuve

Pour les dates de la période actuelle, les secondes Unix apparaissent souvent sous la forme d'un entier à dix chiffres, les millisecondes sous la forme d'un entier à treize chiffres. Ce repère aide à reconnaître les deux valeurs du tableau. Il n'est pas une règle universelle applicable à tous les horodatages.

Les dates plus anciennes peuvent comporter moins de chiffres. Une date antérieure à l'origine peut donner une valeur négative. D'autres systèmes comptent des microsecondes, des nanosecondes, des jours ou une durée depuis une autre origine. Un identifiant peut également posséder dix chiffres sans représenter une date.

Je chercherais donc d'abord le producteur du champ. Un nom comme `created_at` indique l'événement visé, mais ne précise pas nécessairement son unité. Une documentation disant « entier en secondes Unix » apporte une information plus solide.

Dans notre enquête imaginaire, je noterais provisoirement `created_at_seconds` et `created_at_milliseconds` pour comparer les sources. Je ne renommerais pas une colonne de production et je ne multiplierais pas toutes ses valeurs sur la seule base de leur apparence. La correction doit suivre l'explication, pas la précéder.

UTC et heure locale peuvent changer le jour affiché

Une fois l'unité comprise, deux affichages peuvent encore sembler différents parce qu'ils utilisent des fuseaux horaires différents. Cette question est indépendante du choix entre secondes et millisecondes.

Dans un exemple à décalage fixe, `2024-01-01T00:00:00Z` et `2023-12-31T19:00:00-05:00` désignent le même instant. La deuxième horloge affiche encore le 31 décembre. L'événement n'a pas reculé dans le temps : nous lisons deux présentations différentes par rapport à UTC.

Le `Z` final désigne UTC dans ce format de date et d'heure. Un décalage explicite comme `-05:00` permet aussi de situer l'heure affichée. Une chaîne contenant seulement `2024-01-01 00:00` n'apporte pas la même précision. La spécification ECMAScript du format date-heure définit le format interopérable employé par JavaScript.

Je comparerais d'abord les instants UTC, puis je choisirais un affichage lisible pour la personne concernée. Un écran en heure locale et un export en UTC peuvent être tous les deux corrects. Leurs indications doivent rendre cette différence visible sans obliger à deviner l'origine d'un écart de plusieurs heures.

Le fuseau d'une région n'est pas un décalage figé

Un décalage indique la différence avec UTC à un instant donné. Un fuseau identifié par une région peut contenir des règles qui font évoluer ce décalage selon la date. Les deux informations répondent à des besoins proches, mais différents.

Pour un événement passé, conserver un instant explicite aide les systèmes à s'accorder sur la chronologie. Pour une consigne récurrente, comme « chaque matin à neuf heures dans cette ville », les règles du fuseau peuvent aussi être nécessaires. Ajouter toujours le même nombre de secondes ne décrit pas automatiquement la même consigne qu'une répétition à heure locale constante.

Le guide MDN des formats de date et d'heure distingue les valeurs locales et celles qui comprennent un décalage. Dans mon dossier, je séparerais « quand cela s'est produit » de « comment l'heure doit être présentée ».

Convertix traduit une entrée prise en charge. Il ne connaît pas la signification de ma colonne fictive : événement unique, calendrier récurrent ou simple date sans heure. Je dois comprendre ce contexte avant de choisir une représentation. Sinon, une conversion techniquement valable peut répondre à une autre question que la mienne.

Une fraction de seconde reste une information

Imaginons maintenant l'entrée `2024-01-01T00:00:00.250Z`. La partie `.250` représente 250 millisecondes après minuit. Si le format de destination ne conserve que des secondes entières, cette précision ne peut pas rester dans l'entier renvoyé.

Cela concerne l'opération inverse actuelle de Convertix, qui retourne des secondes Unix entières. Un aller-retour par cette représentation ne prouve donc pas que les millisecondes ont été conservées. Je peux retrouver la bonne seconde tout en ayant perdu ce qui distinguait deux événements à l'intérieur de celle-ci.

Pour une note lisible destinée à une personne, la seconde entière peut suffire. Pour comparer des événements très rapprochés, je vérifierais d'abord la précision attendue par la source et la destination. La décision dépend de l'usage, pas du nombre de chiffres le plus agréable à afficher.

Je distinguerais également précision d'écriture et exactitude de l'horloge. Trois chiffres après la seconde permettent d'exprimer des millisecondes ; ils ne prouvent pas que l'appareil connaissait l'heure avec cette exactitude. Ajouter des décimales n'améliore pas l'horloge qui a produit la donnée.

Quand 1970 vient plutôt d'une valeur vide

L'enquête change si la ligne d'origine ne contient aucune date. Un programme situé plus loin dans la chaîne peut remplacer cette absence par zéro, volontairement ou non. L'affichage final présente alors une date valide alors que la source n'avait fourni aucun instant.

Je suivrais la valeur dans une chaîne aussi courte que possible : champ original, valeur interprétée, entrée du convertisseur, résultat affiché. À chaque étape, je vérifierais si l'absence est restée une absence. Cette démarche apprend davantage que convertir plusieurs fois le même zéro.

Une information inconnue ne doit pas devenir silencieusement minuit à l'origine Unix. Inversement, je ne supprimerais pas un véritable zéro uniquement parce que sa date paraît inhabituelle. La distinction dépend du format et du sens du champ.

La question pratique est donc : le système a-t-il reçu une date, ou une valeur par défaut en a-t-elle créé une ? Convertix peut expliquer un nombre fourni ; il ne peut pas retrouver l'heure d'un événement que la source n'a jamais enregistrée.

L'horodatage ne dit pas tout de l'événement

Deux instants correctement convertis peuvent désigner deux étapes différentes. L'un correspond à la création sur un appareil, l'autre à la réception sur un serveur, un troisième à la génération de l'export. Leur écart ne prouve pas automatiquement un problème d'horloge.

Dans ma note de support, je garderais les noms des champs à côté des résultats. « Créé » et « reçu » méritent deux lignes tant que leurs définitions ne disent pas autre chose. Si la transmission a été retardée, les deux dates peuvent décrire correctement leurs événements respectifs.

Une date plausible ne certifie pas non plus l'authenticité du fichier. Comprendre sa représentation ne prouve ni l'identité de son auteur ni l'absence de modification. Ce sont d'autres vérifications, avec d'autres éléments.

Enfin, le temps Unix/POSIX suit une convention concernant les secondes intercalaires : elles ne sont pas appliquées à ce décompte, comme l'explique la justification du standard POSIX. Il faut donc éviter de présenter tout timestamp comme un chronomètre physique exact de chaque seconde écoulée depuis 1970.

La conclusion que je préparerais pour le support

Une réponse utile pourrait tenir en trois phrases : « Le premier fichier exprime des secondes, le second des millisecondes. Les deux valeurs de l'exemple correspondent au 1er janvier 2024 à minuit UTC. L'affichage de 1970 provient de la lecture des secondes comme des millisecondes. » Chaque affirmation peut être vérifiée séparément.

Si l'unité de départ reste inconnue, je le précise : « L'interprétation en secondes donne une période plausible, mais la documentation de l'export reste à confirmer. » Un résultat vraisemblable soutient une hypothèse ; il ne remplace pas la définition de la source.

Je joins la valeur d'exemple sans information privée, ses unités, la représentation UTC attendue et la signification des colonnes. Une autre personne peut alors refaire la comparaison sans recevoir tout le fichier initial.

Pour examiner une valeur prise en charge, ouvrez Convertix Online, puis Texte & données. Le guide général de Convertix présente les autres outils. Pour cette enquête, un nombre correctement défini vaut mieux qu'une transformation immédiate de tout l'export.