Autore: PUOJACKZ Data: 2006-01-12 Modificato: Documento non modificato Letture: 570 Torna indietro

Il problema dell'anno 2000 (anche conosciuto come problema Y2K o Millennium Bug) è stato comportato da una pratica comune (e non ad un errore di programmazione) nella progettazione delle funzioni da implementare nei software.
Nello specifico, le routine di gestione delle date, generavano degli errori, qualora l'applicativo venisse eseguito dopo il 1 Gennaio del 2000.
Occorre, però, analizzare i fatti storici che condussero l'inserimento, indiretto, di questo genere di problema, per poter comprendere, con sufficiente esattezza, la realtà dei fatti.
Negli anni 60, le memorie degli elaboratori e i sistemi di storaging erano alquanto costosi e poco estesi. Molte gestioni dei dati venivano effettuate tramite schede perforate, le quali rappresentavano le informazioni, in modalità testuale, su un sistema a griglia composto da 80 colonne. I linguaggi di programmazione, a quei tempi, come il COBOL o l'RPG, trattavano i numeri secondo le loro rappresentazioni ASCII o EBCDIC. Solo occasionalmente venivano utilizzati dei bit extra, chiamati "Zone Punch", per conservare un carattere per il simbolo - (Meno), oppure, per un numero negativo, altrimenti venivano compresse 2 cifre, in un solo byte, secondo una formattazione definita "binary-coded decimal" (abbreviato in BCD, oggi usato in orologi elettronici, calcolatrici ecc.), gestendo i numeri come del testo normale.
Col tempo, il sistema a schede perforate venne sostuito con quello a nastri magnetici, a dischi e, successivamente, con dei database (come l'ISAM). Tuttavia, però, la struttura dei programmi, col passare del tempo, non è cambiata di molto. Oggi giorno, programmi popolari come "dBase", continuano a conservare i dati, in modalità testuale.
Impiegare 2 caratteri per ogni campo dati era, negli anni 60, un fattore significativo. Siccome, a quei tempi, la programmazione si basava sulla risoluzione di problemi specifici (es. risolvere logicamente un problema, oppure, gestire un profilo hardware particolare), gli applicativi creati non godevano di un utilizzo protratto nel tempo. I programmatori di quegli anni, non credevano che le loro soluzioni, a certe situazioni, sarebbero giunte fino ai giorni nostri.
L'idea che i database fossero un implementazione importante, nella programmazione degli anni seguenti, non era molto diffusa, pertanto, nessuno prese in considerazione, con sufficiente serietà, la necessità di risolvere il problema legato alle 2 cifre della data.
Negli anni seguenti, questo problema venne alla luce in maniera chiara. I creatori del COBOL decisero, quindi, di notificare il bisogno di specificare delle date a 4 cifre, prassi attuata da tutti i programmatori, fin dalla prima Release del compilatore, in COBOL, nel 1961.
La conservazione delle date e del tempo, tramite un campo binario fisso, è considerata, spesso, una buona soluzione, ma questo può comportare dei problemi d'interpretazione nei software, in quanto, la rappresentazione, in questo caso, dev'essere in relazione ad un origine definita. Infatti esistono vari metodi d'implementazione.

- Il sistema di TimeStamping, utilizzato in Unix, conserva le date e il tempo in un area di memoria (un Integer con segno a 32-bit), rappresentandolo come numero dei secondi trascorsi dal momento attuale, rispetto il 00:00 del 1 Gennaio del 1970.
Questa tecnica, però, è limitata e soggetta al "2038 Bug", a causa del limite posto dal range degli Integer, in un ambiente a 32-bit.

- Microsoft Excel conserva le date a seconda del numero di giorni trascorsi da un origine predefinita (spesso, erroneamente detta "Julian Date"). Quest'ultima viene conservata in un Integer a 16-bit, il quale è soggetto ad un overflow dopo 65,536 giorni (approssimativamente dopo 179 anni). Sfortunatamente, alcune release del programma hanno, come punto d'origine, l'anno 1900, mentre altri, il 1904.
Inoltre, l'Excel è affetto da un problema Y2K molto elementare: l'anno 1900 (così come anche il 2000, il 2100, il 2200 ecc.), è considerato, erroneamente, bisestile. Tale errore è stato corretto nelle versioni successive del programma, sebbene, per una questione di compatibilità retroattiva, sia ancora mantenuto.

- Nel linguaggio di programmazione C, la funzione della libreria standard per ottenere l'anno corrente era affetta da un problema, il quale permetteva l'elaborazione di una risposta solo se l'anno era presente nel 20esimo secolo. Altri linguaggi di coding, contenenti delle funzioni in C (come il Perl o il JavaScript), gestivano erroneamente questo valore.
In ambito Web, il bug era alquanto innocuo, anche se nei casi di visualizzazione di certe particolari date, es. 1 Gennaio 2000, si otteneva, come risultato, "1/1/19100", "1/1/100", o altre varianti a seconda della formattazione utilizzata.
Anche quando si manifestò la data 9 Settembre 1999, vi furono delle preoccupazioni. Sì pensò ad una rappresentazione, in formato numerico, stile 9/9/99, cifra simile al codice EOF (End Of File, 9999), nei vecchi linguaggi di programmazione.
Ciò condusse nel credere che alcuni programmi potessero auto-terminarsi inaspettatamente. Tale pericolo, però, era immotivato, in quanto, il computer non conserva l'ora e la data con tale formato, bensì in 090999 o 9/9/99, proprio per evitare eventuali confusioni tra il confine Giorno/Mese.

- Altri problemi legati all'anno 2000 erano a riguardo del fattore "bisestile" (cioè se è divisibile per 4, senza che sia divisibile per 100 e non per 400), cosa alquanto insolita (gli anni che finiscono per "00" non lo sono mai). Fortunatamente, molti programmi vennero corretti in tempo.

Il problema dell'anno 2038

In informatica, i progettisti di ambienti operativi e di software hanno già calcolato il prossimo grosso problema legato alle date. L'anno 2038 sarà il 2° sparti-acque che renderà obsoleto (e non più utilizzabile) un gran numero di software presenti, oggi giorno.
Più in specifico, i programmi che sfruttano una rappresentazione del tempo in POSIX sono affetti da questo problema. Tale tipo di formattazione rappresenta i numeri in secondi (ignorando quelli di Leap), partendo, come origine, dal 1 Gennaio del 1970. Il POSIX è presente negli OS UNIX e *nix-Like, includendo, inoltre, tutti quei software per altri ambienti operativi, scritti utilizzando il linguaggio di programmazione C. Nella maggior parte dei sistemi a 32-bit, il tipo di dati "time_t" viene utilizzato per conservare il contatore dei secondi, presso un Integer con segno (anch'esso a 32-bit). Seguendo lo standard POSIX, l'ultima ora che può essere rappresentata, da questo formato, è il 03:14:08 UTC del 19 Gennaio, 2038.
Oltre questo valore, viene visualizzato un numero negativo, causando il malfunzionamento di tutti i programmi che necessitano delle funzioni di data ed ora, per l'elaborazione dei dati. Tale gestione erronea è dovuta, in quanto, le routine identificano, come anno, il 1970 o il 1901, invece che il 2038 (a seconda del tipo d'implementazione effettuato). Ovviamente, ciò provoca, di conseguenza, un errore a catena in tutti i calcoli ed in tutte le decisioni logiche gestite dalle funzioni presenti nel programma.
Non esistono delle correzioni semplici, per questo tipo di problema, nei combinati CPU/OS esistenti oggigiorno. La modifica della definizione del "time_t", in modo da forzare l'utilizzo di un tipo di dato a 64-bit, causerebbe una mancata compatibilità binaria con il software, il sistema di conservazione dei dati e, generalmente, in tutto ciò che impiega una rappresentazione binaria delle date e delle ore. Inoltre, impostare il "time_t", perchè impieghi un Integer, sempre a 32-bit, però senza segno, andrebbe ad incidere negativamente su tutti quei programmi che includono anche i fusi orari.
Molti OS, per architetture a 64-bit, impiegano già degli Integer di stessa lunghezza, nelle loro versioni di "time_t". Si suppone, pertanto, che il passaggio a questo genere di sistema possa essere completato entro il 2038. Tuttavia, occorre tener in considerazione che, oggi giorno, nel 2006, vi sono molti computer dedicati in certi dispositivi (alcuni presenti in ambienti critici), di cui, non si può stabilire, a priori, riguardo l'ipotetica sostituzione, con un architettura più avanzata, entro la data limite.
Utilizzando dei valori a 64-bit, il problema dell'ipotetico overflow verrà ritardato di 290 miliardi d'anni.
In via più specifica, il successivo "sparti-acque" scadrà il 4 Dicembre (Domenica), dell'anno 292.277.026.596, alle ore 15:30:08 UTC).