Italiano

Strumenti per sviluppatori · Convertitore di timestamp Unix

Non tutte le epoche sono 1970: NTP, Windows FILETIME, GPS ed Excel date

· Sfondo

timestamp formati di dati debug

Diverse linee temporali con diversi punti zero convergenti in un istante
Illustrazione vettoriale originale ToolAcre

L'origine 1970 di Unix è solo una delle tante. Questo post esamina le epoche che incontrerai nei file e nei protocolli (1900, 1601, 1904, 1980, 2001) e mostra come riconoscere un valore che non è mai stato il tempo di Unix.

Il timestamp che è arrivato in 1900: un valore da un'acquisizione di rete che nessuna scelta di unità potrebbe rendere sensata

Un numero derivante dall'acquisizione di un pacchetto può produrre sciocchezze sia in secondi che in millisecondi perché l'unità non è l'unico parametro nascosto. Epoca significa un punto zero scelto; Unix utilizza 1970, mentre un altro protocollo può contare da qualche altra parte. Il ridimensionamento non può riparare l'origine sbagliata.

Quando entrambe le letture ToolAcre sono in conflitto con l'ora dell'evento noto, interrompi la commutazione. Identificare il nome del campo, il produttore, la versione del protocollo e l'origine documentata. Tagliare ripetutamente le cifre finché non appare un anno plausibile trasforma l'indagine in una coincidenza.

La stessa diagnosi si applica quando appare una data sensata ma è in conflitto con gli eventi circostanti. La plausibilità è un controllo debole; la provenienza e un evento di riferimento noto sono più forti.

NTP e 1900: secondi da 1900-01-01 con una frazione di 32 bit e il rollover di 2036 che ne deriva

La cartella di lavoro ha fornito l'origine, il layout frazionario e la data di rollover di NTP. Nessuno è implementato o testato nel convertitore Unix, quindi questo articolo non certifica tali specifiche. Un'acquisizione di rete deve essere decodificata in base alla documentazione del protocollo utilizzata dal mittente e dal parser.

Solo dopo aver derivato i secondi Unix il valore dovrebbe entrare in questo strumento. Mantieni l'era o il contesto di rollover perché un campo a larghezza fissa potrebbe non identificarlo da solo. Un risultato UTC raffinato di un'era presunta può essere internamente coerente ed esternamente sbagliato.

I campi del protocollo possono anche dividere componenti interi e frazionari. Concatenarli o decimalizzarli senza la scala specificata crea un nuovo numero che nessun decodificatore conforme intendeva.

I dettagli sulla conversione di NTP e il comportamento di rollover richiedono la documentazione di origine non presente qui

Allo stesso modo, i contatori Windows e .NET non sono modalità accettate. Il repository non contiene costanti per le loro origini o scale di graduazione. I loro grandi valori decimali possono superare l'intervallo intero esatto di JavaScript prima che uno sviluppatore tenti la conversione.

Utilizza una libreria sicura per numeri interi basata sulla definizione documentata della piattaforma, preserva l'originale come testo o intero ampio e quindi emetti un valore Unix. Non sottrarre un offset ricordato in virgola mobile. La precisione nella fascia bassa è importante quando la risoluzione della sorgente è inferiore ai millisecondi.

Un test di andata e ritorno dovrebbe includere un valore con cifre inferiori a zero. Le apparecchiature da un secondo intero non possono indicare se il resto in 100-nanosecondi o millisecondi è stato conservato correttamente.

Le definizioni FILETIME e .NET non sono implementate da ToolAcre e non vengono asserite dalla memoria

Le date del foglio di calcolo introducono una rappresentazione diversa: un seriale numerico interpretato dalle impostazioni del sistema di data della cartella di lavoro. Il problema 1900 della cartella di lavoro e le affermazioni sui vecchi Mac richiedono fonti di fogli di calcolo e non sono stabilite qui. ToolAcre non legge i metadati della cartella di lavoro.

Esamina il file con strumenti compatibili con i fogli di calcolo, determina il sistema di data configurato e preserva la precisione delle frazioni di giorno utilizzando quella libreria. Trattare un seriale come Unix secondi può produrre una data anticipata-1970 che assomiglia a un normale bug di scala mentre il problema reale è l'origine e l'unità insieme.

Le impostazioni della cartella di lavoro possono viaggiare con un file, quindi due periodici visivamente simili possono utilizzare origini diverse. La conversione appartiene al confine del documento in cui sono disponibili i metadati.

I sistemi seriali e le stranezze dei fogli di calcolo richiedono prove specifiche del foglio di calcolo

Anche GPS e le epoche relative ad Apple indicate nella struttura non sono incluse nell'implementazione. Le loro relazioni possono implicare convenzioni di scala oltre un costante spostamento dell'origine. Nessuna formula di compensazione o conversione attuale viene pubblicata qui senza prove autorevoli.

La diagnostica generale trasferisce ancora: identificazione zero, durata tick e convenzione di salto dal produttore. Quindi convertire con una libreria appropriata e verificare rispetto a un timestamp noto dello stesso set di dati. Tre fatti indipendenti sono più sicuri di un'ipotesi sulla larghezza decimale.

Questa cautela è particolarmente importante per quanto riguarda le convenzioni di salto. Una costante che funziona per una scala e una data potrebbe non essere una relazione senza tempo tra ogni coppia di sistemi.

Le relazioni GPS e Apple Epoch richiedono fonti autorevoli esterne a questo modulo

Un metodo funzionante difendibile inizia con un istante noto, ad esempio `2025-02-03T10:23:00.000Z` verificato di ToolAcre, pari a 1,738,578,180 secondi Unix. Per un'altra epoca documentata, calcola il suo valore utilizzando l'origine ufficiale di quel sistema e scalalo con l'aritmetica dei numeri interi, quindi riconvertilo utilizzando la stessa definizione.

Confronta il viaggio di andata e ritorno con la stringa Unix ISO e conserva la derivazione. Questo articolo non riempie intenzionalmente una tabella di cinque epoche con costanti che non sono state lette. Il metodo espone ogni presupposto e può essere esaminato rispetto a qualsiasi protocollo o formato di file abbia effettivamente prodotto i dati.

Metodo funzionante: derivare un istante attraverso epoche documentate anziché pubblicare costanti non verificate

ToolAcre non riconosce o converte automaticamente le epoche straniere. Il suo menu unità dice secondi e millisecondi, entrambi sotto la definizione Unix nella configurazione. Il rilevamento automatico sceglie solo tra quelle scale alla magnitudo 10¹¹; non cambia mai il punto zero.

Questo contratto ristretto impedisce la falsa fiducia. Se un conteggio straniero coincide con una data Unix plausibile, il convertitore non può avvisare che l'origine era sbagliata. La provenienza deve entrare prima dell'aritmetica. Documenta la trasformazione nel codice anziché fare affidamento su un runbook manuale.

L'etichetta automatica visibile riporta solo secondi o millisecondi. Non dovrebbe mai essere citato come prova che si sia verificato il rilevamento dell'origine, poiché tale ramo non esiste nell'origine.

Conclusione: scopri da quale zero stai contando e come il convertitore di timestamp Unix ti dice chiaramente che legge secondi o millisecondi Unix

Scopri da quale zero stai contando, quanto è grande un tick e come la sorgente gestisce la sua scala temporale. Un convertitore Unix risponde solo dopo che tali domande si sono risolte in secondi o millisecondi da 1970 UTC. Non può dedurre la semantica da un numero intero.

Utilizzare doppie letture non plausibili come segnale per indagare sull'origine, non come permesso per continuare a provare i divisori. Una volta che una conversione di origine produce un valore Unix, ToolAcre fornisce un utile UTC indipendente e un controllo di integrità locale mantenendo visibile il proprio presupposto.

Un buon adattatore nomina il tipo esterno, esegue una trasformazione di origine ed emette un valore Unix con marchio. Questa progettazione impedisce ai contatori non elaborati di penetrare nei costruttori di date generici.