Il bug off-by-1000: quando una data mostra gennaio 1970 o l'anno 56000

Tutti gli utenti si sono iscritti il ​​1 gennaio 1970: la schermata che rivela il bug e il backend che era perfettamente corretto

Una pagina del profilo che mostra tutti gli account vicino a gennaio 1970 è un sintomo di forte portata. Il backend potrebbe aver restituito i secondi epoch corretti mentre il codice frontend li ha passati direttamente a un costruttore Date che interpreta i millisecondi. Un conteggio attuale si riduce quindi di un fattore mille sull'asse del calendario.

Non modificare il display aggiungendo un anno costante o sostituendo la data. Cattura il campo grezzo, il suo contratto API e l'esatta chiamata del costruttore. ToolAcre consente di forzare entrambe le unità, in modo che un valore possa essere testato senza modificare i dati di produzione. La lettura che corrisponde a un altro evento noto identifica il probabile errore di confine.

I due sintomi: i secondi dati a un millisecondo API che arrivano a gennaio 1970 e i millisecondi dati a un secondo API che arrivano a decine di migliaia di anni

I secondi interpretati come millisecondi si avvicinano all'epoca perché un miliardo di millisecondi è solo una piccola frazione di secolo. L'errore inverso espande il valore di un trilione di millisecondi in un trilione di secondi, spesso al di fuori dei normali intervalli di applicazione. Entrambi i fallimenti preservano le cifre modificandone la scala.

L’articolo pubblicato a dieci contro tredici cifre spiega già l’euristica visiva contemporanea e i suoi limiti. Questo articolo si concentra invece sulla diagnosi e sulla prevenzione: selezione esplicita delle unità, prove indipendenti degli eventi e una conversione nell’interfaccia in cui la rappresentanza del produttore incontra il contratto del consumatore.

Poiché entrambi i rami sono deterministici, il sintomo può essere riprodotto con un dispositivo. Ciò rende più semplice dimostrare la mancata corrispondenza delle unità rispetto alla deriva intermittente dell'orologio o al comportamento di formattazione locale.

Dove di solito il confine è: JavaScript e Java in millisecondi, strumenti Unix, Python e la maggior parte dei database in secondi e il payload JSON tra di loro

Questo repository dimostra che JavaScript Date consuma millisecondi e che ToolAcre moltiplica i secondi prima di costruirne uno. Non stabilisce le impostazioni predefinite di ogni Java, Python, shell o database API nominato nella cartella di lavoro. Tali contratti devono essere controllati laddove vengono utilizzati.

Un numero JSON non contiene metadati dell'unità. Denominare un campo `created_at` trasferisce l'ambiguità tra i servizi; nominarlo `created_at_s` o documentare una stringa ISO rende il contratto rivedibile. L'adattatore ricevente dovrebbe convertirsi una volta nella sua rappresentazione interna anziché spargere moltiplicazioni tra le viste.

Scrivi la conversione accanto alla definizione del limite, non all'interno di un helper di visualizzazione riutilizzabile. L'adattatore conosce il contratto del produttore; un formattatore generico dovrebbe ricevere un istante già normalizzato.

Il confine dell'unità è API-specifico; questo repository dimostra che JavaScript La data utilizza i millisecondi

Un dispositivo debole come `0` non è in grado di rilevare il bug perché zero secondi e zero millisecondi denominano entrambi l'epoca. Piccoli valori inventati possono anche sembrare date 1970 plausibili. Una simulazione che restituisce la stessa scala attesa dal consumatore non esercita mai un vero disallineamento di integrazione.

Scegli un istante noto diverso da zero e rendi le due interpretazioni osservabilmente diverse. Dichiara il risultato canonico ISO al limite, non semplicemente che esiste un oggetto Date. Includere una cassa dei millisecondi e una cassa dei secondi; I test di ToolAcre confrontano 1,000,000 sotto ciascuna unità proprio per questo motivo.

I bug unitari sopravvivono ogni volta che i test non riescono a distinguere le due scale

Considera `created_at: 1738578000`. Forzato in secondi, diventa `2025-02-03T10:20:00.000Z`; forzato in millisecondi, diventa `1970-01-21T02:56:18.000Z`. Un record di distribuzione noto per essere stato creato a febbraio 2025 risolve l'ambiguità senza fare affidamento esclusivamente sul conteggio delle cifre.

Mantieni JSON non elaborato accanto all'evento noto mentre ripari l'adattatore. Se il campo fosse `1738578000000`, l'interpretazione in millisecondi identificherebbe lo stesso istante. I due valori non dovrebbero mai essere accettati in modo intercambiabile all'interno di uno schema, anche se un convertitore può dimostrare la loro equivalenza dopo aver applicato la scala corretta.

La data di distribuzione nota costituisce una prova indipendente. Senza di essa, la scelta del risultato più plausibile può codificare le aspettative di un ricercatore piuttosto che stabilire ciò che il produttore intendeva.

Esempio realizzato: testare un valore create_at in entrambe le unità esplicite

La riparazione duratura inizia al confine: analizza l'unità di origine documentata, convertila esattamente una volta ed esponi un valore interno digitato o denominato chiaramente. Le descrizioni degli schemi, gli esempi e i client generati devono preservare il suffisso o il formato data-ora. Un revisore può quindi individuare una moltiplicazione aggiuntiva prima della fase di esecuzione.

Aggiungi un dispositivo di regressione con la scala reale e un'aspettativa ISO fissa. Evita il rilevamento automatico nel codice dell'applicazione quando il produttore ha un contratto; le euristiche servono per indagare su dati legacy incerti. ToolAcre etichetta la scelta rilevata in modo preciso in modo che l'ipotesi non possa mascherarsi da metadati garantiti.

Ciò che questo non copre sono gli errori di fuso orario, che spostano una data di ore anziché di decenni

Un errore di fuso orario in genere sposta la visualizzazione di ore e può attraversare un giorno di calendario. Un errore di un fattore di1,000 sposta decenni o millenni. Mescolare le diagnosi incoraggia aggiustamenti di compensazione attorno a un valore la cui scala è già sbagliata. Verificare l'unità prima di controllare la formattazione locale.

Allo stesso modo, un'origine epocale errata può rimanere priva di senso sia nei secondi che nei millisecondi. Se nessuna delle due interpretazioni corrisponde a un evento noto, interrompi la commutazione e indaga sul produttore. Un convertitore restringe le ipotesi; non dimostra che ogni intero grande sia il tempo di Unix.

Se l'anno è plausibile ma l'ora è costantemente spostata, esamina la presentazione delle zone. Mantenere separate queste scale di sintomi riduce il percorso dallo screenshot alla causa principale.

Conclusione: un'unità sbagliata è un secolo sbagliato e come l'unità dichiarata del convertitore timestamp Unix ti consente di testare entrambe le letture in un momento

Un'unità sbagliata non è un metadato cosmetico: cambia l'istante. Considera gli 1970-schermi pesanti e anni incredibilmente distanti come segnali per ispezionare il legame produttore-consumatore. Il valore, il contratto unitario e l'evento noto costituiscono una prova in tre parti più forte di una data apparentemente ragionevole.

Utilizza il convertitore per confrontare letture esplicite, quindi codifica la scala scelta in nomi, tipi e test. L’obiettivo non è insegnare al software a indovinare in modo più intelligente. Serve per rimuovere l'ipotesi dal percorso che crea le date per gli utenti.

Una revisione del codice può quindi porre una domanda precisa ad ogni confine: quale unità entra e quale unità esce? Questo è più affidabile del riconoscimento di un particolare numero di cifre.