Le bug off-by-1000 : lorsqu'une date indique janvier 1970 ou l'année 56000

Chaque utilisateur a rejoint le 1 janvier 1970 — l'écran qui révèle le bug et le backend qui était parfaitement correct

Une page de profil affichant tous les comptes vers le 1970 janvier est un symptôme important. Le backend peut avoir renvoyé des secondes d'époque correctes tandis que le code frontend les a transmises directement à un constructeur Date qui interprète les millisecondes. Un décompte actuel est alors réduit d'un facteur mille sur l'axe du calendrier.

Ne modifiez pas l'affichage en ajoutant une année constante ou en remplaçant la date. Capturez le champ brut, son contrat API et l'appel exact du constructeur. ToolAcre vous permet de forcer les deux unités, afin qu'une valeur puisse être testée sans modifier les données de production. La lecture correspondant à un autre événement connu identifie l'erreur de limite probable.

Les deux symptômes : les secondes injectées dans un atterrissage d'API en millisecondes en janvier 1970 et les millisecondes alimentées par un atterrissage d'API en secondes il y a des dizaines de milliers d'années.

Les secondes interprétées comme des millisecondes se rapprochent de l'époque car un milliard de millisecondes ne représente qu'une petite fraction d'un siècle. L’erreur inverse transforme une valeur d’un billion de millisecondes en un billion de secondes, souvent en dehors des plages d’application ordinaires. Les deux échecs préservent les chiffres tout en changeant leur échelle.

L'article publié à dix contre treize chiffres explique déjà l'heuristique visuelle contemporaine et ses limites. Cet article se concentre plutôt sur le diagnostic et la prévention : sélection explicite d’unités, preuves d’événements indépendants et conversion à l’interface où la représentation d’un producteur rencontre le contrat d’un consommateur.

Étant donné que les deux branches sont déterministes, le symptôme peut être reproduit avec un seul appareil. Cela rend l'inadéquation des unités plus facile à prouver que la dérive intermittente de l'horloge ou le comportement de formatage des paramètres régionaux.

Là où se situe habituellement la frontière : JavaScript et Java en millisecondes, les outils Unix, Python et la plupart des bases de données en secondes, et la charge utile JSON entre eux

Ce référentiel prouve que JavaScript Date consomme des millisecondes et que ToolAcre multiplie les secondes avant d'en construire une. Il n'établit pas les valeurs par défaut de chaque API Java, Python, shell ou base de données nommée dans le classeur. Ces contrats doivent être vérifiés là où ils sont utilisés.

Un numéro JSON ne contient aucune métadonnée d'unité. Nommer un champ `created_at` transfère l'ambiguïté entre les services ; le nommer `created_at_s` ou documenter une chaîne ISO rend le contrat révisable. L'adaptateur de réception doit se convertir une fois en sa représentation interne plutôt que de disperser les multiplications entre les vues.

Écrivez la conversion à côté de la définition de la limite, et non dans un assistant d'affichage réutilisable. L'adaptateur connaît le contrat du producteur ; un formateur générique devrait recevoir un instant déjà normalisé.

La limite de l'unité est spécifique à l'API ; ce référentiel prouve que JavaScript Date utilise des millisecondes

Un appareil faible tel que `0` ne peut pas détecter le bug car zéro seconde et zéro milliseconde nomment tous deux l'époque. De petites valeurs fabriquées peuvent également ressembler à des dates 1970 plausibles. Une simulation qui renvoie la même échelle attendue par son consommateur n'entraîne jamais de véritable décalage d'intégration.

Choisissez un instant connu non nul et faites en sorte que les deux interprétations soient visiblement différentes. Affirmez le résultat ISO canonique à la limite, pas seulement l'existence d'un objet Date. Incluez un cas de millisecondes et un cas de secondes ; Les propres tests de ToolAcre comparent 1,000,000 sous chaque unité exactement pour cette raison.

Les bogues unitaires survivent chaque fois que les tests ne parviennent pas à distinguer les deux échelles

Considérez `created_at: 1738578000`. Forcé en secondes, il devient `2025-02-03T10:20:00.000Z` ; forcé en millisecondes, il devient `1970-01-21T02:56:18.000Z`. Un enregistrement de déploiement connu pour avoir été créé en février 2025 résout l'ambiguïté sans s'appuyer uniquement sur le nombre de chiffres.

Conservez le JSON brut à côté de cet événement connu lors de la réparation de l'adaptateur. Si le champ était `1738578000000`, l'interprétation en millisecondes identifierait le même instant. Les deux valeurs ne doivent jamais être acceptées de manière interchangeable dans un même schéma, même si un convertisseur peut démontrer leur équivalence après avoir appliqué l'échelle correcte.

La date de déploiement connue est une preuve indépendante. Sans cela, le choix du résultat le plus plausible peut coder les attentes d’un enquêteur plutôt que d’établir ce que le producteur voulait dire.

Exemple concret : tester une valeur create_at sous les deux unités explicites

La réparation durable commence à la limite : analysez l'unité source documentée, convertissez exactement une fois et exposez une valeur interne tapée ou clairement nommée. Les descriptions de schéma, les exemples et les clients générés doivent conserver le suffixe ou le format date-heure. Un réviseur peut alors repérer une multiplication supplémentaire avant l'exécution.

Ajoutez un dispositif de régression avec l'échelle réelle et une attente ISO fixe. Éviter la détection automatique dans le code de l'application lorsque le producteur a un contrat ; les heuristiques servent à enquêter sur des données héritées incertaines. ToolAcre étiquette précisément son choix détecté afin que la supposition ne puisse pas se faire passer pour des métadonnées garanties.

Ce que cela ne couvre pas : les erreurs de fuseau horaire, qui décalent une date en heures plutôt qu'en décennies

Une erreur de fuseau horaire décale généralement un affichage d'heures et peut s'étendre sur un jour calendaire. Un facteur d'erreur 1,000 décale des décennies ou des millénaires. Le mélange des diagnostics favorise des ajustements de décalage autour d'une valeur dont l'échelle est déjà fausse. Vérifiez l’unité avant d’inspecter le formatage local.

De même, une mauvaise origine d'époque peut rester absurde en secondes et en millisecondes. Si aucune des deux interprétations ne correspond à un événement connu, arrêtez de basculer et enquêtez sur le producteur. Un convertisseur restreint les hypothèses ; cela ne prouve pas que chaque grand entier correspond à l'heure Unix.

Si l'année est plausible mais que l'heure est constamment décalée, étudiez la présentation de la zone. Garder ces échelles de symptômes séparées raccourcit le chemin entre la capture d’écran et la cause première.

À retenir : une mauvaise unité est un mauvais siècle - et comment l'unité déclarée du convertisseur d'horodatage Unix vous permet de tester les deux lectures en un instant

Une mauvaise unité n'est pas une métadonnée cosmétique : elle change l'instant. Traitez les écrans 1970-lourds et les années invraisemblablement lointaines comme des signaux pour inspecter la couture producteur-consommateur. La valeur, le contrat unitaire et l'événement connu forment une preuve en trois parties plus solide qu'une date apparemment raisonnable.

Utilisez le convertisseur pour comparer les lectures explicites, puis encodez l'échelle choisie en noms, types et tests. Le but n’est pas d’apprendre aux logiciels à deviner plus intelligemment. Il s'agit de supprimer les suppositions du chemin qui crée des dates pour les utilisateurs.

Une révision du code peut alors poser une question précise à chaque frontière : quelle unité entre et quelle unité sort ? C'est plus fiable que de reconnaître un nombre particulier de chiffres.