Toutes les époques ne sont pas 1970 : NTP, Windows FILETIME, GPS et dates Excel

L'horodatage qui a atterri dans 1900 — une valeur provenant d'une capture réseau qu'aucun choix d'unité ne pourrait rendre raisonnable

Un nombre issu d'une capture de paquet peut produire un non-sens en secondes et en millisecondes car l'unité n'est pas le seul paramètre caché. Époque signifie un point zéro choisi ; Unix utilise 1970, alors qu'un autre protocole peut compter ailleurs. Le redimensionnement ne peut pas réparer la mauvaise origine.

Lorsque les deux lectures de ToolAcre entrent en conflit avec l'heure de l'événement connue, arrêtez de basculer. Identifiez le nom du champ, le producteur, la version du protocole et l’origine documentée. En coupant les chiffres à plusieurs reprises jusqu'à ce qu'une année plausible apparaisse, l'enquête se transforme en coïncidence.

Le même diagnostic s'applique lorsqu'une date raisonnable apparaît mais entre en conflit avec les événements environnants. La plausibilité est un contrôle faible ; la provenance et un événement de référence connu sont plus forts.

NTP et 1900 — secondes depuis 1900-01-01 avec une fraction 32 bits, et le rollover 2036 qu'il apporte

Le classeur fournissait l'origine du NTP, la disposition fractionnaire et la date de basculement. Aucun n'est implémenté ou testé dans le convertisseur Unix, donc cet article ne certifie pas ces spécificités. Une capture réseau doit être décodée conformément à la documentation du protocole utilisée par l'expéditeur et l'analyseur.

Ce n'est qu'après avoir dérivé les secondes Unix que la valeur doit entrer dans cet outil. Conservez le contexte d’ère ou de survol, car un champ de largeur fixe peut ne pas l’identifier seul. Un résultat UTC raffiné d'une époque supposée peut être cohérent en interne et erroné en externe.

Les champs de protocole peuvent également diviser des composants entiers et fractionnaires. Les concaténer ou les décimaler sans l'échelle spécifiée crée un nouveau nombre qu'aucun décodeur conforme n'avait prévu.

Les détails de la conversion NTP et le comportement de basculement nécessitent une documentation source non présente ici

De même, les compteurs Windows et .NET nommés ne sont pas des modes acceptés. Le référentiel ne contient aucune constante pour leurs origines ou leurs échelles de ticks. Leurs valeurs décimales élevées peuvent dépasser la plage entière exacte de JavaScript avant qu'un développeur ne tente la conversion.

Utilisez une bibliothèque sécurisée pour les entiers fondée sur la définition documentée de la plate-forme, conservez l'original sous forme de texte ou d'entier large, puis émettez une valeur Unix. Ne soustrayez pas un décalage mémorisé en virgule flottante. La précision dans les basses fréquences est importante lorsque la résolution source est inférieure à quelques millisecondes.

Un test aller-retour doit inclure une valeur avec des chiffres inférieurs à la seconde différents de zéro. Les appareils d'une seconde entière ne peuvent pas révéler si le reste de 100-nanoseconde ou de milliseconde a été correctement préservé.

Les définitions FILETIME et .NET ne sont pas implémentées par ToolAcre et ne sont pas affirmées à partir de la mémoire

Les dates des feuilles de calcul introduisent une représentation différente : une série numérique interprétée par les paramètres du système de date du classeur. La bizarrerie 1900 du classeur et l'ancienne revendication Mac nécessitent des sources de feuilles de calcul et ne sont pas établies ici. ToolAcre ne lit pas les métadonnées du classeur.

Inspectez le fichier avec des outils compatibles avec les feuilles de calcul, déterminez le système de date configuré et préservez la précision en fractions de jour à l'aide de cette bibliothèque. Traiter une série comme des secondes Unix peut produire une date précoce 1970 qui ressemble à un bug d'échelle ordinaire alors que le problème réel est l'origine et l'unité ensemble.

Les paramètres du classeur peuvent voyager avec un fichier, de sorte que deux publications en série visuellement similaires peuvent utiliser des origines différentes. La conversion appartient à la limite du document où ces métadonnées sont disponibles.

Les systèmes en série et les bizarreries des feuilles de calcul nécessitent des preuves spécifiques à la feuille de calcul

Les époques liées au GPS et à Apple mentionnées dans le plan sont également en dehors de l'implémentation. Leurs relations peuvent impliquer des conventions d'échelle au-delà d'un changement d'origine constant. Aucune formule de compensation ou de conversion actuelle n'est publiée ici sans preuve faisant autorité.

Le diagnostic général transfère toujours : identifier le zéro, la durée du tick et la convention de saut du producteur. Convertissez ensuite avec une bibliothèque appropriée et vérifiez par rapport à un horodatage connu du même ensemble de données. Trois faits indépendants sont plus sûrs qu’une estimation en largeur décimale.

Cette prudence est particulièrement importante en ce qui concerne les conventions de saut. Une constante qui fonctionne pour une échelle et une date ne constitue peut-être pas une relation intemporelle entre chaque paire de systèmes.

Les relations d'époque GPS et Apple nécessitent des sources faisant autorité en dehors de ce module

Une méthode de travail défendable commence par un instant connu, par exemple le `2025-02-03T10:23:00.000Z` vérifié par ToolAcre, égal à 1,738,578,180 secondes Unix. Pour une autre époque documentée, calculez sa valeur en utilisant l’origine officielle et l’échelle de ce système avec l’arithmétique entière, puis reconvertissez-la en utilisant la même définition.

Comparez l'aller-retour à la chaîne ISO Unix et conservez la dérivation. Cet article ne remplit pas intentionnellement un tableau de cinq époques avec des constantes qui n'ont pas été lues. La méthode expose toutes les hypothèses et peut être examinée par rapport au protocole ou au format de fichier réellement produit les données.

Méthode de travail : dériver un instant à travers des époques documentées plutôt que de publier des constantes non vérifiées

ToolAcre ne reconnaît ni ne convertit automatiquement les époques étrangères. Son menu d'unité indique les secondes et les millisecondes, toutes deux sous la définition Unix dans la configuration. La détection automatique choisit uniquement entre ces échelles de magnitude 10¹¹ ; cela ne change jamais le point zéro.

Ce contrat étroit empêche les fausses confiances. Si un décompte étranger arrive à une date Unix plausible, le convertisseur ne peut pas avertir que l'origine était erronée. La provenance doit être entrée avant l’arithmétique. Documentez la transformation dans le code plutôt que de vous fier à un runbook manuel.

L'étiquette automatique visible n'indique que les secondes ou les millisecondes. Il ne doit jamais être cité comme preuve de la détection de l'origine, car aucune branche de ce type n'existe dans la source.

À retenir : sachez à partir de quel zéro vous comptez - et comment le convertisseur d'horodatage Unix vous indique clairement qu'il lit les secondes ou millisecondes Unix

Sachez à partir de quel zéro vous comptez, quelle est la taille d'un tick et comment la source gère son échelle de temps. Un convertisseur Unix ne répond qu'une fois que ces questions ont été résolues en secondes ou millisecondes depuis 1970 UTC. Il ne peut pas déduire la sémantique d’un seul entier.

Utilisez des lectures doubles invraisemblables comme signal pour enquêter sur l'origine, et non comme autorisation de continuer à essayer des diviseurs. Une fois qu'une conversion source produit une valeur Unix, ToolAcre fournit une vérification UTC indépendante et locale utile tout en gardant sa propre hypothèse visible.

Un bon adaptateur nomme le type étranger, effectue une transformation source et émet une valeur Unix de marque. Cette conception empêche les compteurs bruts de s'infiltrer dans les constructeurs de dates génériques.