Per questo articolo la prenderemo molto larga, per inquadrare bene il problema e poterlo rendere comprensibile a chiunque.

Il problema

Comininciamo con un’informazione di base: i computer usano dei numeri (in sistema binario) per rappresentare qualunque dato, e la base di tutto il software è l’interpretazione di questi numeri. Per esempio, sono memorizzati come numeri anche i singoli caratteri, compresi quelli che state leggendo – sono i vari strati di software a rendere un particolare numero uno specifico carattere.

Il discorso vale anche per la rappresentazione del tempo, in cui software ((e quindi anche sistemi operativi) diversi adottano metodi diversi. Talvolta con certi limiti…
Qualcuno potrebbe ricordarsi il problema del millennium bug: allo scoccare della mezzanotte del 31 dicembre 1999 tutti i computer sarebbero impazziti, non capendo più in che anno eravamo. Lo scenario prospettato al pubblico era più apocalittico di quanto realmente presente, principalmente grazie al fatto che il problema era specifico di sistemi MS-DOS mentre Unix (e Linux, che si era già diffuso nel parco server) erano immuni.
La differenza era che MS-DOS memorizzava l’anno come un numero da 0 a 99, dando per scontato che il secolo fosse sempre 1900. D’altronde, era prassi (e allontanandoci dall’anno 2000 sta ritornando) riferirsi ad un anno particolare senza citare il secolo.
Unix e (similmente) Linux usano lo unix time: contano i secondi trascorsi dalle ore 00:00 del 1 gennaio 1970. E lo fanno con un intero a 32 bit: sono capaci di contare circa 2 miliardi di secondi, che sono cira 68 anni, da sommare o sottrarre al 1 gennaio 1970.
In questa maniera è possibile rappresentare qualunque secondo dal 13 dicembre 1901 al 19 gennaio 2038. Ed è proprio lì il problema: quando si aggiungerà un secondo al conteggio più grande possibile, si avrà un errore (integer overflow per interi a complemento a 2) e si tornerà indietro di 136 anni.

La soluzione del sistema operativo

Come per il millennium bug, la soluzione è una modifica nella rappresentazione della data. Se per MS-DOS si è trattto di cambiare il punto di inizio (per esempio, considerando come del secolo 2000 tutti gli anni dallo 00 al 30), e per Windows NT usare quattro cifre per l’anno, per Linux si tratta di aumentare la capacità di conteggio, passando da 32 a 64 bit. Facciamo però notare un dettaglio: se il Kernel viene modificato devono essere modificati tutti i programmi che girano su quel Kernel per concordare sulla rappresentazione.

Avrete notato come il passaggio sia esattamente quello già avvenuto con l’architettura delle CPU. Non è un caso, nel senso che le potenze di 2 sono comuni nel mondo informatico, ma non è nemmeno una cosa necessaria: un sistema a 64 bit può usare interi a 32 bit per rappresentare un numero, e un sistema a 32 bit deve poter usare un intero a 64 bit per poter fare la stessa cosa. Giusto per esempio: quando fu stabilito lo unix time erano diffusi sistemi a 8 bit!

L’introduzione però di una nuova architettura ha permesso a chi ha scritto il Kernel per questa architettura di cambiare questo dettaglio: il software che doveva girare sarebbe stato adattato e ricompilato in ogni caso, quindi poteva usare una nuova rappresentazione.
I processori a 64 bit odierni sono compatibili col vecchio comportamento a 32 bit, per permettere al vecchio software di girare allo stesso modo – e il Kernel ne è consapevole, tanto da usare prorio con questo software la vecchia rappresentazione.

Per i sistemi a 32 bit, per retrocompatibilità, si è mantenuta la vecchia rappresentazione fino al Kernel 5.6, quando di default è stata adottata la nuova. Questo dettglio è importante perché ricadono in questa categoria non solo i vecchi PC x86, ma una gran moltitudine di apparecchi embedded o SoC. Due esempi: il Raspberry Pi (fino alla versione 2B) e la maggior parte degli smartphone in circolazione.

La soluzione non è l’unica possibile, soprattutto perché raddoppiando lo spazio (in bit) per memorizzare il numero, si espande enormente il conteggio massimo: con 64 bit si può contare ogni secondo dall’inizio dell’universo. Due volte (quasi meglio di Chuck Norris!). Pertanto sono fatte proposte come contare i millisecondi, o perfino i microsecondi, p cambiare il sistema per tenere conto di altre condizioni (come il secondo intercalare).

XFS e l’anno 2038

Come dicevamo, la modifica del Kernel è solo il primo passo: tutto il software deve capire (ma non per forza usare al suo interno) quella rappresentazione. Ma questo vale ancora di più per le componenti del sistema operativo.
Da molto tempo il filesystem XFS è integrato in Linux, ed è stato scelto come standard per i sistemi Red Hat (e molti derivati, specie CentOS). Come tutti i filesystem per Linux, la struttura dati che identifica un file memorizza l’orario di modifica in un campo apposito timestamp. Beh, in realtà i campi sono 3: uno per la modifica, uno per la creazione e un per l’accesso al file.
Finora questo campo era del tutto simile al formato usato dal Kernel: un numero intero a 32 bit. Ma nell’implementazione proposta per il Kernel 5.10 (tra le molte modifiche) è prevista l’opzione bigtime, che cambia il formato: un intero a 64 bit. E non più conteggiare i secondi, ma i nanosecondi passati dal 1 gennaio 1970.
Questa modifica permetterà di superare il problema dell’anno 2038, arrivando fino all’anno 2486, con anche una notevole precisione degli orari: il milionesimo di secondo. Si nota anche che la rappresentazione usata da XFS sarà diversa da quella usata dal Kernel: evidentemente la maggiore precisione è stata ritenuta di interesse superiore ad una rappresentazione immortale (almeno quanto l’universo).
L’opzione è facoltativa, e rimarrà tale per un po’ di tempo: l’attivazione di questa funzionalità renderebbe impossibile leggere i filesystem già esistenti creati senza l’opzione attiva, e la compatiblità continua ad essere importante. Possiamo anche credere che Red Hat e distribuzioni collegate non rendano attiva di default questa impostazione con le release attuali, aspettando almeno la prossima major release (un ipotetico Red Hat 9).

La notizia in sé è in realtà piccola, ma mostra molto chiaramente quanto i dettagli possano fare la differenza, e quanta cura e prudenza siano necessari a definirli – e modificarli.
Siamo certi che per il 2038 tutti i problemi saranno risolti, anche se è possibile che in tempo di IoT (ed Echo Dot, o Google Home…) alcuni dispositivi non verranno aggiornati e semplicemente smetteranno di funzionare. Ma chi tiene uno smartphone attuale per altri 18 anni?

Marco Bonfiglio

Ho coltivato la mia passione per l’informatica fin da bambino, coi primi programmi BASIC. In età adulta mi sono avvicinato a Linux ed alla programmazione C, per poi interessarmi di reti. Infine, il mio hobby è diventato anche il mio lavoro.
Per me il modo migliore di imparare è fare, e per questo devo utilizzare le tecnologie che ritengo interessanti; a questo scopo, il mondo opensource offre gli strumenti perfetti.