Come un software capisce se 03/04 è il 3 aprile o il 4 marzo
Le date ambigue non si risolvono indovinando la lingua del dispositivo. Ecco la strategia reale: campionare un blocco, fissare una configurazione, poi scandire tutto il file cercando un giorno maggiore di 12 per confermarla o ribaltarla.
L'ambiguità è più stretta di quanto sembri
03/04 preso da solo è indecidibile. Ma un export di chat non contiene una data: ne contiene migliaia, e l'ambiguità sopravvive soltanto se *tutte* hanno entrambi i numeri pari o inferiori a 12. È qui che sta il meccanismo, ed è il motivo per cui nella pratica il problema si risolve senza chiedere niente all'utente.
Qualsiasi data in cui un componente supera 12 si risolve da sola. 25/12 può essere solo giorno-prima. 12/25 può essere solo mese-prima. Un file che contiene un solo messaggio inviato dal 13 in poi porta con sé la propria risposta. Il caso critico non è "il software non può saperlo", è "questo file specifico non contiene prove", che è una situazione molto più rara e molto più circoscritta.
Quasi tutte le spiegazioni si fermano a "dipende dalla lingua del dispositivo". La locale è un'ipotesi di partenza, non una risposta: dice cosa provare per primo, non se hai indovinato.
Perché la locale da sola non basta
Il dispositivo che ha generato l'export non è necessariamente quello che lo legge. Un export scritto su un telefono italiano (giorno-prima) viene aperto in un browser che dichiara inglese americano. Un telefono comprato all'estero conserva un formato regionale a cui il proprietario non pensa mai. Una chat archiviata anni fa su un altro apparecchio porta il formato di quell'apparecchio, non quello di oggi.
Anche dentro la stessa piattaforma il formato varia. iOS e Android scrivono la riga di timestamp in modo diverso: parentesi, separatori, anno a due o quattro cifre, orologio a 12 ore con AM/PM oppure a 24 ore. Due export della stessa conversazione fatti da due telefoni possono differire a livello di caratteri pur descrivendo messaggi identici.
Un parser che legge la locale del browser e si ferma lì ha costruito un lancio di monetina con passaggi in più. E quando sbaglia, il danno non è estetico: ogni numero calcolato a valle eredita l'errore.
Primo passaggio: campionare, non leggere tutto
Il nostro parser legge un campione di 300 righe dall'inizio dell'export e da lì ricava le proprietà strutturali del file: quale piattaforma l'ha scritto, l'ordine della data, se l'anno ha due o quattro cifre, quale separatore divide i componenti, se l'orologio è a 12 o 24 ore, e la lingua dei messaggi di sistema.
Si usa un campione perché queste proprietà sono strutturali: WhatsApp non cambia separatore a metà conversazione. Trecento righe bastano a stabilire la forma di tutte le righe successive, e restano veloci anche su file con centinaia di migliaia di messaggi.
Alla fine di questo passaggio il parser ha una sola configurazione fissata. Non un insieme di candidati, non un'ipotesi riga per riga. Una configurazione, applicata in modo uniforme. Indovinare il formato riga per riga è il modo tipico di ritrovarsi con gennaio letto giorno-prima e febbraio letto mese-prima, e una cronologia incoerente senza che nulla segnali il problema.
Secondo passaggio: verificare l'ordine su tutto il file
L'ordine della data è l'unica proprietà che il campione non chiude, perché il campione può non contenere la prova. Le prime 300 righe di una conversazione possono facilmente essere una settimana di inizio marzo in cui ogni data è ambigua.
Per questo il parser scandisce l'intero file cercando il caso che squalifica un'ipotesi: una data in cui il componente in posizione giorno supera 12. Trovarne uno coerente con l'assunzione corrente la conferma. Trovarne uno impossibile sotto quell'assunzione la ribalta. Il campione fornisce l'ipotesi, il file intero fornisce il test.
È anche il motivo per cui il controllo deve girare su tutto e non su una porzione. La prova sta dove sta: in una chat di due anni il valore decisivo può essere un 28 sepolto novemila righe più in basso, e fermarsi prima per guadagnare tempo è esattamente il modo di perderlo.
Terzo passaggio: il file sfortunato in cui nessuna data decide
Alcuni file davvero non contengono prove. Una chat breve, distribuita su pochi giorni tutti compresi nei primi dodici del mese, è indecidibile a partire dalle sue date. Non resta nessuna inferenza intelligente da fare: l'informazione non c'è.
In quei casi rimane l'ipotesi basata sulla locale, e va usata per quello che è: un valore predefinito, non una conclusione. In pratica il rischio si restringe insieme al file. Un file senza date squalificanti è per definizione confinato ai primi dodici giorni di ogni mese che tocca, quindi la lettura errata resta limitata invece di propagarsi.
Quello che conta è la direzione. Se una serie di date viene letta nell'ordine sbagliato, la sequenza dei giorni può risultare rimescolata. Ed è precisamente per questo che vale la pena far girare la verifica su tutto il file invece di accontentarsi della locale.
Cosa rompe davvero un ordine sbagliato
Un ordine di data letto male non corrompe il testo dei messaggi, e le metriche che ignorano il tempo sopravvivono: il totale dei messaggi e il conteggio delle parole restano gli stessi.
Salta tutto ciò che ha una forma temporale. I confini dei giorni si spostano, quindi l'attività quotidiana viene attribuita alle date sbagliate e i messaggi per giorno attivo cambiano. Le serie consecutive dipendono da giorni di calendario contigui: una sequenza rimescolata spezza serie reali o inventa adiacenze mai esistite. La finestra temporale del recap, cioè la prima e l'ultima data della conversazione, può finire su giorni sbagliati. Anche i silenzi e le pause tra conversazioni si calcolano sull'ordinamento, quindi si deformano.
Un'eccezione utile da segnalare: le statistiche sull'ora del giorno, tipo i pattern notturni, derivano dal componente orario e non dall'ordine della data, quindi tengono. Dipendono però dal rilevamento 12 ore contro 24 ore, ed è per questo che fa parte della stessa configurazione fissata e non di un controllo aggiunto dopo.
Come si testa una strategia del genere
Una logica di rilevamento come questa fallisce in silenzio, quindi le fixture sono l'unica difesa reale. Le nostre coprono le combinazioni che si incontrano davvero: formati di export iOS e Android, messaggi di sistema in inglese e in italiano, orologio a 12 e a 24 ore, e sia DD/MM sia MM/DD.
Conta la copertura combinatoria più del numero di casi. Un parser può gestire perfettamente Android più italiano più 24 ore più giorno-prima e comunque sbagliare iOS più inglese più 12 ore più mese-prima, perché le proprietà interagiscono. I marcatori AM/PM cambiano la forma della riga di timestamp, che cambia dove finisce la ricerca del separatore, che cambia cosa sta leggendo il controllo sull'ordine della data.
Se stai indagando su un altro strumento che ti ha letto le date al contrario, l'ordine delle domande è questo: quale formato ha scritto il dispositivo di origine, lo strumento fissa una configurazione o rindovina riga per riga, e verifica la propria assunzione su tutto il file o solo sulle righe iniziali. La risposta sta quasi sempre nella terza domanda.
Domande frequenti
Perché il mio export mostra le date nell'ordine sbagliato?+
Di solito perché lo strumento ha dedotto il formato dalla locale del browser o del sistema invece di verificarlo sul file. Il dispositivo che ha generato l'export può usare un ordine diverso da quello che lo legge, e uno strumento che non verifica mai la propria ipotesi sulle date reali non se ne accorge.
Un software può risolvere DD/MM e MM/DD con certezza?+
Sì, ogni volta che il file contiene almeno una data con un giorno superiore a 12, perché in quel caso una sola lettura è possibile. Se tutte le date hanno entrambi i componenti pari o inferiori a 12, nessuna analisi può deciderlo e lo strumento deve ricorrere a un valore predefinito.
Perché campionare solo 300 righe invece di leggere tutto il file?+
Perché piattaforma, separatore, larghezza dell'anno, orologio e lingua sono proprietà strutturali che non cambiano a metà file, quindi una finestra breve basta a determinarle. L'ordine della data è diverso: viene risolto sull'intero file, perché la data decisiva può trovarsi in qualsiasi punto.
Quali statistiche vengono compromesse se l'ordine della data è sbagliato?+
Tutto ciò che si basa sui giorni di calendario: attività quotidiana, messaggi per giorno attivo, serie consecutive, pause e silenzi, e la prima e l'ultima data della finestra del recap. I totali semplici come messaggi e parole non cambiano, e i pattern per ora del giorno dipendono dall'orologio, non dall'ordine della data.