Un formato per misurare il tempo

 A volte, mi verrebbe da dire spesso, ci complichiamo inutilmente la vita.

 Nei primi anni '70 furono inventati il linguaggio C e il sistema operativo Unix, sul quale si basa il moderno Linux. All'epoca i processori più avanzati usavano al massimo parole di 32 bit e quindi si decise di implementare una misura del tempo basata sul formato "Integer-32". Tuttavia, chi fece quella scelta non fu molto lungimirante oppure riteneva che, nell'arco di 50-60 anni, questi standards sarebbero stati ampiamente superati e dimenticati e non avrebbero avuto più alcun impatto sulla società. Purtroppo, le cose sono andate un po' diversamente e adesso il mondo dell'informatica e dell'automazione si trova a dover combattere con un "baco" o una "sindrome", quella dell'anno 2038, che ha preso il posto del famigerato "millenium bug" del 2000.

 Se utilizziamo una parola di 32 bit, essa può generare 2³² diverse combinazioni, cioè quasi 4,3 miliardi (4294967296 precisamente). All'epoca, si decise di esprimere il tempo con una risoluzione di 1 secondo a partire dalla data "primordiale" del 1 gennaio 1970; una scelta semplice e apparentemente ragionevole poiché, essendoci mediamente in un anno 31,56 milioni di secondi, si otterrebbe un intervallo temporale di 4,295·10⁹ /  3,156·10⁶ = 136,1 anni e si sarebbe potuti arrivare ad esprimere data e ora fino all'inizio del 2106. Purtroppo le cose non sono andate esattamente così perchè, per rispetto alla regola di programmazione secondo cui "non bisogna inventare daccapo la ruota", si è deciso di utilizzare lo standard già esistente "Integer-32", usato per esprimere numeri algebrici con uno dei 32 bit esprime in realtà il segno. Dato però che per esprimere una data/ora con il segno non ha molto senso (a meno di non voler esprimere in tal modo date antecedenti al 1/1/1970), si è finiti per dimezzare l'intervallo disponibile ed ecco che dopo la fatidica data del 19/1/2038 il sistema va in crisi e non riesce a fornire risultati affidabili; curiosamente, peraltro, l'ora fatidica cadrà alle 3:14, ovvero π... una vera cabala numerica! Questa data doveva apparire sufficientemente remota all'epoca ma non lo è certo per noi; essa è già più vicina rispetto al fatidico anno 2000 e, probabilmente, la maggior parte delle persone che leggono questo articolo saranno ancora vive in quella data!

 Qualcuno potrebbe dire che si tratta di un problema inesistente, dato che ormai i computers e i sistemi operativi si sono evoluti e l'utilizzo di parole di 64 bit è divenuto universale; questa è probabilmente la stessa considerazione che fecero gli ingegneri programmatori che realizzarono Unix. Purtroppo non è così in tutti i settori! Alcune vecchie routines software, i cosiddetti "sistemi integrati" in macchinari più o meno obsoleti come pure i nomi di molti files, utilizzano ancora il vecchio standard ed è per questo che, nel settore, il "baco del 2038" fa più paura di quello del 2000. Gli effetti si cominciano già a far sentire, infatti negli ultimi anni i database di diverse aziende sono andati in crisi calcolando date di scadenza o interessi bancari a lungo termine!  E tutto questo si sarebbe potuto evitare (o meglio, rimandare al 22° secolo) semplicemente sfruttando quel fatidico bit del segno!

 Naturalmente, i recenti sistemi operativi si sono adeguati e, facendo tesoro della lezione, hanno enormemente ampliato l'intervallo temporale abbracciato. Anzi, in realtà si è sovra-reagito, anche perchè un intero di 64 bit è davvero sovrabbondante a questo scopo: con 2⁶⁴ = 1,845·10¹⁹ combinazioni e una risoluzione di 1 secondo, si arriverebbe a codificare qualsiasi data in un intervallo abnorme, 282 o 584 miliardi di anni a seconda se si usa o no il segno; questo corrisponde a 21 o 42 volte l'età dell'Universo! Anche volendo aumentare la risoluzione a 1 millisecondo, come fanno alcuni, si tratterebbe di un intervallo di ampissimo, pari a oltre 2-4 volte il tempo trascorso dalla scomparsa dei dinosauri. In realtà, se volessimo adottare questa risoluzione di 1 ms, basterebbe un intero "signed" di 48 bit per spaziare dal 4459 aC al 4459 dC; questa è già, per molti versi, una soluzione ottimale in termini di precisione e di intervallo, a conferma che, anche in questo campo, le parole di 48 bit sono già sufficienti a risolvere brillantemente le limitazioni dei 32 bit senza gli eccessi dei 64 bit.

 Con 64 bit ci si potrebbe spingere a risoluzioni temporali ancora maggiori, fino a 1 μs o addirittura 1 ns. Nel primo caso, l'intervallo abbracciato sarebbe di 584000 anni, nel secondo 548 anni. Quest'ultima mi pare l'opzione più ragionevole perchè, anche anticipando la data iniziale al 1900, ci si spingerebbe fino a metà del 25° secolo con una precisione a prova di sistema GPS!*

 In alternativa, ci sarebbe una soluzione "ibrida" che unisce i pregi di una risoluzione elevata e di un intervallo pressoché "infinito", sulla falsariga dei formati modificati da me proposti in più occasioni per il "calcolo floating". In pratica, si utilizzerebbe un intero "signed", dove il primo bit ha un significato diverso dal segno. Se esso vale zero, allora abbiamo un tempo espresso con risoluzione di 1 ns (ad esempio, dal 1/1/1970 a inizio aprile 2262, in piena epoca di Star Trek!). Quando invece il primo bit vale 1, allora si potrebbe adottare una risoluzione più bassa (1 secondo o 1 millisecondo), dividendo equamente l'intervallo risultante nel passato e nel futuro (di fatto significa dedicare un altro bit allo scopo). Al limite, anche se per certi aspetti appare assurdo, invece di un "integer-64" si potrebbe utilizzare direttamente il formato "floating-64" per esprimere le date con una precisione elevata intorno alle date odierne e più bassa su date remote, in un intervallo ampissimo, qualcosa come 10³⁰⁰ anni, adottando il secondo come unità!

 Effettivamente, nel linguaggio Java di Oracle esiste un formato detto "nanoTime" che utilizza la risoluzione di 1 ns per descrivere lassi temporali di durata massima pari a 292 anni (64bit  integer signed) ma non per indicare una data vera e propria, dato che il momento di inizio è indefinito e dipende dalla particolare applicazione.

 Un'ultima considerazione: volendo adottare una misura del tempo decimale più razionale, basata sui "Cronos" che sono la centomillesima parte del giorno (descritta in un altro mio articolo di 5 anni fa), il sistema ibrido andrebbe dal 1970 a metà 2222 con una risoluzione di 1 nCronos (8,46·10^-10 s)* e ±126 miliardi di anni con una risoluzione di 1 Cronos.

* Nota a piè pagina: proprio come avviene nella determinazione della posizione tramite GPS, una simile precisione richiederebbe il dover specificare il sistema di riferimento e il luogo esatto in cui è valida, per non incorrere nei problemi relativistici legati alle differenze nello scorrere del tempo a causa del moto relativo e a causa dei campi gravitazionali! Per fare un esempio, una ipotetica persona che trascorresse la sua vita di 80 anni in cima al monte Everest, vivrebbe 25 millisecondi di meno rispetto al suo gemello al livello del mare; una differenza impercettibile per noi ma che diventa importante per la precisione esibita nei nuovi sistemi proposti. Naturalmente, questo complicherebbe parecchio le cose, infatti, per effettuare calcoli orbitali precisi, il JPL adotta il Barycentric Dynamical Time, riferito ad un ipotetico sistema di riferimento solidale con il baricentro del sistema solare ma al di fuori di campi gravitazionali significativi. Del resto, lo stesso concetto di "misura del tempo" si fonda sull'idea classica di "simultaneità" che è stata messa in crisi da Einstein!