Il Bug Dell'Anno 10.000 Sui Software (Y10K)

E' vero, sicuramente noi, non saremo ancora in vita per documentarlo inoltre le tendenze tecnologiche suggeriscono che entro l'anno 10.000, è altamente improbabile che una qualsiasi delle tecnologie o software di elaborazione dati siano ancora in uso, tuttavia rimane un problema che oggi presenta delle criticità ed ha risvolti interessanti dal punto di vista informatico.

Vi siete mai chiesti, a livello di software e sistemi, cosa succederà nell'anno 10.000?
In primis va sottolineato che è molto plausibile che i calendari attualmente in uso siano sostituiti da qualcos'altro. Tuttavia, va detto che gli anni a cinque cifre sono già oggi un problema per molti programmi di analisi lungimirante (ad esempio software che esaminano la gestione a lungo termine delle scorie nucleari). Il problema dell'Anno 10.000 (noto anche come problema Y10K) riguarda bug di formattazione e archiviazione del tempo che emergerebbero allo scoccare dell'anno 10.000 (in quanto a cinque cifre). Questo problema può essere visualizzato in Microsoft Excel dalla versione di Office 2013 in poi, che memorizza le date come il numero di giorni dal 31 dicembre 1899 (il giorno 1 è il 1900-01-01). Allo stesso modo, Microsoft Access memorizza le date come il numero di giorni dal 30 dicembre 1899 (il giorno 1 è il 1899-12-31). In entrambe le applicazioni, un valore di 2958465 verrebbe formattato correttamente come "31 dicembre 9999", ma aggiungendo 1 per passare alla data prevista del "1 gennaio 10000" si causerebbe un errore di formattazione; in Excel, ad esempio, verrebbe visualizzato nella cella come una serie di #characters. Inoltre, Excel non può convertire automaticamente stringhe con formato data "12/12/2007" in date, se l'anno supera il 9999.
La Long Now Foundation si è imbattuta in questa limitazione di Excel durante la progettazione dell'orologio da 10.000 anni (la società sta tentando di promuovere l'abitudine nello scrivere anni con 5 cifre: tipo 02018. Ci sarebbe però un discreto problema con l'anno 100.000...).
Il programma open source OpenOffice Calc è in grado di visualizzare correttamente le date oltre l'anno 9999 con anni a cinque cifre, ma almeno dalla versione 2.4 cade vittima del problema dell'Anno 32.768: il "31 dicembre 32.767" è la data più alta disponibile.
Il 32767 è il numero positivo più alto che può essere rappresentato usando un intero con segno a 16 bit, aggiungendo uno a questo valore si provoca l' overflow e Calc interpreta l'anno come un numero negativo grande ovvero il "1 gennaio - 32.768" . Anche Python supporta date da 1 cifra a 4.


DIFFERENZE CON IL MILLENNIUM BUG
A differenza del problema dell'anno 2000, in cui le cifre significative sono state omesse, la risoluzione del problema dell'anno 10.000 non richiede l'aggiornamento dei vecchi record, poiché sono presenti tutte e quattro le cifre significative. Richiederebbe solo che la memorizzazione dei record in decimali sia in grado di memorizzare cinque o più cifre.
Esiste, tuttavia, un potenziale problema con i set di record che fanno uso dell'ordinamento lessicale. Ad esempio, le rappresentazioni di date nell'intervallo 10.000-19.999 apparirebbero interlacciate con le date nell'intervallo 1000-1999 anziché successive all'anno 9999.

Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Nel 1999 non si fece altro che parlare del tanto temuto Millennium Bug che sarebbe accorso allo scoccare della mezzanotte, con l'entrata quindi del nuovo millennio.
TG, film, serie TV, giornali, riviste e qualsiasi mezzo di comunicazione dedicava sempre uno spazio più o meno ampio a questo evento.
L’allarmismo era davvero ai massimi livelli.
Principalmente questo errore risiedeva nel fatto che, per rappresentare le date, diversi software utilizzavano solo due cifre decimali per memorizzare l'anno; tali cifre potevano assumere i valori compresi da "00" a "99", dando per sottinteso, come base di partenza, l'anno 1900.
Quindi al raggiungimento dell'anno 2000, i sistemi avrebbero segnato l'1 gennaio 1900.
Il problema di fondo dell’utilizzo di un numero ridotto di cifre (2 al posto di 4), rappresentava la necessità di utilizzare il numero minore di byte di memoria possibile (del resto la capacità di memoria dei sistemi operativi era molto ridotta, se rapportata a quello di oggi. E non solo perchè poi i software si sono evoluti).
In realtà alcuni problemi comparvero già 12 anni prima ovvero nel 1988, quando un lotto di carne in scatola era stato rifiutato da un supermercato perché sembrava essere scaduto da più di 80 anni.
Quattro anni dopo (nel 1992), Mary Bandar di Winona, nel Minnesota, fu invitata a frequentare una scuola materna perché, secondo il computer, aveva 4 anni.
In realtà ne aveva 104 anni quindi declinò l'invito.
Dal 1951, quando Joe Lyons introdusse i primi computer aziendali, le date come detto erano state abbreviate per risparmiare spazio ed accelerare l'elaborazione: il secolo venne omesso, quindi il gennaio 1900 era 01/00 e il dicembre 1999 era il 12/99, così come è ancora oggi sul fronte di ogni carta di credito.
In realtà quella carne in scatola aveva una data di scadenza del gennaio 2000 e Mary Bandar nacque nel luglio 1888; queste date, 01/00 e 07/88, assomigliavano al gennaio 1900 e al luglio 1988, rendendo la carne scaduta da 88 anni (del resto il fatto successe nel 1988) e la 104enne Maria ringiovanita al punta da esser invitata per frequentare l'asilo nel 1992.


QUALI PROBLEMI PROVOCO' IL MILLENNIUM BUG?
Il costo totale dell'aggiustamento software e sistemi operativi svolti in previsione dell'Y2K è stato stimato di oltre 300 miliardi di dollari (oggi circa 426 miliardi di dollari oggi, presa in considerazione l'inflazione).
IDC ha calcolato che gli Stati Uniti spesero circa 134 miliardi di dollari (190 miliardi di dollari oggi).

Non successero eventi catastrofici/apocalittici come descritti all'avvicinarsi dell'evento, anche se qualche problema accorse, vediamone i principali.

-ci furono problemi nello United States Naval Observatory che gestisce il master clock (ora ufficiale del paese), diede la data sul suo sito Web come 1 gen 1900

-problemi in un centinaio di slot machine nel Delaware, USA

-sempre negli Stati Uniti, il sistema di elaborazione dei messaggi della Guardia costiera venne interrotto

-alla base offshore delle forze aeree a sud di Omaha, nel Nebraska, non fu possibile accedere alle registrazioni delle parti di manutenzione degli aeromobili

-ci furono interruzioni di corrente alle Hawaii

-all'aeroporto nazionale di Reagan, le linee di attesa del check-in si sono allungate dopo che i programmi di smistamento bagagli sono stati colpiti

-in Giappone alcuni sistemi di raccolta di informazioni di volo ebbero diversi problemi

-a Ishikawa, in Giappone, le apparecchiature per il monitoraggio delle radiazioni smisero di funzionare a mezzanotte; tuttavia, i funzionari dichiararono che non c'era nessun rischio per gli abitanti

-la centrale nucleare di Onagawa ebbe qualche problema di raffreddamento, non a caso suonò l'allarme 2 minuti dopo mezzanotte

-ad Osaka, Giappone, una compagnia di telecomunicazioni, ha riscontrato errori nella parte di gestione delle date della rete aziendale. Il problema venne risolto alle 02:43

-NTT DoCoMo , il più grande operatore di telefonia mobile del Giappone, riferì che il 1° gennaio 2000 alcuni modelli di telefoni cellulari stavano cancellando nuovi messaggi ricevuti, anziché i vecchi messaggi, a mano a mano che la memoria si riempiva

-sempre in Giappone, circa il 5% degli erogatori di contanti dell'ufficio postale non funzionò e si ebbero problemi anche negli uffici meteorologici

-a Sheffield, Regno Unito, ci furono valutazioni errate del rischio per la sindrome di Down inviate a 154 donne gravide e sono stati effettuati due aborti come risultato diretto del bug Y2K (errore di calcolo dell'età della madre). Quattro bambini affetti da sindrome di Down sono nati da madri a cui era stato detto che si trovavano nel gruppo a basso rischio (cioè praticamente zero le possibilità che succeda una cosa del genere)

-nel Regno Unito ci furono anche problemi con le transazioni di denaro

-sempre nel Regno Unito, le macchine per le biglietterie automatiche ("Quickfare") stamparono i biglietti con la data "00 JNR 00" per 3 mesi fino a metà marzo 2000. Questi erano incompatibili con gli ATG presso la stazione ferroviaria di Reading

-il sistema missilistico antiaereo del Regno Unito Rapier presentava un errore Y2K che gli avrebbe impedito di sparare

-molti sistemi di carte di credito e bancomat andarono in crash. Alcuni clienti hanno ricevuto fatture con 100 anni di interesse

-la stazione di pompaggio dell'olio a Yumurtalik fallì, tagliando le forniture a Istanbul

-i computer del governo andarono in crash in Cina ed ad Hong Kong

-un cliente di un negozio di noleggio video dello stato di New York si trovò sul conto $ 91.250

-anche in Australia si ebbero problemi con il sistema di convalida dei biglietti dell'autobus

-tribunali in Sud Corea e Spagna che riportavano documenti datati 1900

-in Italia i principali problemi li ebbe la Telecom con alcune bollette che riportavano la data 1900

-in Francia, il servizio nazionale di previsioni meteorologiche, Météo-France, indicò che la data sulla loro pagina Web mostrava una mappa con le previsioni del tempo di sabato "01/01/1900"

-in Bulgaria, i documenti di polizia sono stati emessi con le date di scadenza del 29 febbraio 2005 e del 29 febbraio 2010 (che non sono anni bisestili)

-alcuni software non hanno riconosciuto correttamente il 2000 come anno bisestile e hanno quindi lavorato su un anno di 365 giorni. L'ultimo giorno del 2000 (giorno 366) questi sistemi hanno mostrato vari errori trovandosi sfasati (31 dicembre 2000 e 1 gennaio 2001). In particolare alcuni treni norvegesi si ritrovarono ritardati fino a quando i loro orologi non furono rimessi indietro di un mese

Cos'è Il Tempo UNIX? Date Particolari e Millennium Bug

Il tempo zero dell'Informatica non inizia con la data di nascita di Gesù Cristo o di chi per lui ma dalla mezzanotte di giovedi 1 gennaio 1970.
Non esisteva a quei tempi una data zero e quindi i programmatori la dovevano fissare per ogni file, ogni volta, nel file-system finchè non scelsero una data che potesse andare bene e che non soffrisse di overflow con sistemi a 32 bit, il 1970 sembrò una buona scelta (anche se inizialmente era stato scelto l'1 gennaio 1971).
Detto anche tempo UNIX, esso è come detto utilizzato per i timestamp dei programmi informatici.
In poche parole, esso segna il tempo trascorso in secondi da quella data.
Questo sistema di misurazione temporale è molto usato da sistemi operativi UNIX e può essere facilmente convertito, grazie a un piccolo software, nel tempo universale.
Ma perchè venne scelto il 1970? I sistemi UNIX vennero progettati nel 1969, il primo pubblicato nel 1971 quindi si suppose che nessun sistema informatico avrebbe potuto rappresentare un tempo di sistema prima di questa data.


DATE DA RICORDARE E MILLENNIUM BUG
Questo strano orologio, proprio come il calendario comunemente usato, regala date molto particolari dal punto di vista numerico.
Per esempio, il 9 settembre 2001 è stata la volta dello Unix Billenium, il momento in cui l'orologio si è fermato a 1.000.000.000 secondi.
Il 18 marzo 2005, invece, la cifra ha segnato l’1.111.111.111.
Il 13 febbraio 2009 per un istante si è fermato sulla cifra di 1234567890 secondi.
Per l'occasione sono state organizzate celebrazioni in tutto il mondo e l'evento è stato celebrato anche da Google, con un doodle dedicato.
Mentre il 26 gennaio 2011 è stato il 15.000° giorno dello Unix Time e i festeggiamenti hanno avuto luogo a Bloomington in Indiana (USA).
Il 18 maggio 2033 invece sarà il giorno del secondo Billennium: i 2.000.000.000 di secondi.
Sono molti i sistemi operativi che presentano problemi con date particolari.
A cavallo tra il 1999 e il 2000 si parlò molto del “Millennium Bug”, un problema che si verificò sui computer al cambio di data dalla mezzanotte del 31 dicembre 1999 all’1 gennaio 2000.
Temendo conseguenze catastrofiche, furono da più parti predisposte misure per correggere sistemi operativi, applicazioni, firmware e altri sistemi che lavorano con le date.


LA FINE DEL MONDO
Non sarebbe un vero calendario, tuttavia, se non ci fosse anche una fine del mondo.
Questa è segnata per le 03:14:08 UTC del 19 gennaio 2038, data prevista per il Bug Dell'Anno 2038 (bugY2038).
In questo giorno, infatti, per i sistemi operativi a 32 bit che adoperano questa rappresentazione del tempo scoccherà l'istante in cui i contatori toccheranno il loro valore massimo, l'istante rappresentabile più distante possibile dal 1 gennaio 1970: 2147483647 secondi.
Dall'istante successivo, i contatori registreranno il valore negativo -2147483648, che corrisponderà (sempre a partire dal 1 gennaio 1970) alle 20:45:52 di venerdì 13 dicembre 1901.
In poche parole il numero di secondi trascorsi dall'epoca raggiungerà il valore di 2 alla 31esima potenza, che è al di fuori dei valori rappresentabili da tale tipo di dato.
Tali calcolatori e sistemi operativi potranno quindi riscontrare malfunzionamenti, non essendo più in grado di memorizzare correttamente il valore che indica la data corrente.
Questa festività, anzi Apocalisse, è anche nota come "The Friday 13th Bug".

Dopo Il Millennium Bug, Arriverà Il Bug Dell'Anno 2038

Passato indenne il Millennium Bug del 2000, c'apprestiamo (o meglio, mancano ancora un po' di anni) a vivere quello del 19 Gennaio 2038.
Però manca ancora un bel po' di tempo eh?
Ad ogni modo a causarlo sarebbero i processori a 32 bit quindi nessun problema per coloro che usano sistemi a 64 bit(per la verità tra una ventina d'anni i computer saranno drasticamente diversi da quelli di ora ed è assolutamente improbabile che si rimanga con questi processori).


BUG 2038
Il problema comunque scatterebbe a una data e un’ora specifica: 19 gennaio 2038 alle 03:14:07 (fuso orario di Greenwich).
Da quel momento in poi, i computer che utilizzeranno ancora sistemi a 32 bit non saranno in grado di stabilire la differenza tra il 2038 ed il 1970 (anno di partenza da cui sono settati gli attuali computer).
I sistemi Unix, infatti, non possono calcolare le date successive al 2038.
Questo perché tengono traccia del tempo utilizzando un intero di 4 byte che rappresenta il numero dei secondi dal primo gennaio 1970.
In pratica, un intero di 4 byte ha un valore massimo di 2.146.483.547: proprio questo tempo (conosciuto come “tempo massimo”) corrisponde al 19 gennaio 2048, ore 3.14.07.
I sistemi Unix, infatti, non erano stati toccati dal Millennium Bug(del 2000), ma ora ne vanno incontro ad un altro.
Il problema è che molte macchine che hanno come sistema operativo Unix/Linux sono quelle che controllano le principali arterie del mondo tecnologico, dall’aeronautica a internet.
Quello che accadrà sarà un semplice “reset” del tempo a 0, quindi al primo minuto del 1970.
Perché proprio 2.147.483.647? I computer misurano il tempo in secondi.
Quindi, 2.147.483.647 sono i secondi compresi nell’intervallo tra il primo gennaio 1970 (Tempo Unix) ed il 19 gennaio 2038 alle 03:14:07.
Il problema è generalizzato perché i processori, anche se di differenti dimensioni e capacità, funzionano tutti allo stesso modo, sia su device fissi sia su mobile.
Alcuni processori potrebbero continuare a funzionare bene con una data sbagliata mentre altri smetterebbero drasticamente di lavorare.


DA COSA è GENERATO IL BUG?
La maggioranza dei sistemi informatici mondiali (anche la stessa “struttura” sulla quale si appoggia internet) è basata su UNIX, il famoso sistema operativo open source dal quale sono derivati Linux e anche i prodotti della Apple.
Il sistema operativo UNIX memorizza le date in un formato definito dallo standard POSIX.
In pratica la data è memorizzata in un numero che rappresenta il numero di secondi a partire dalla mezzanotte del 1° Gennaio 1970, tale data viene anche chiamata “epoca” (The Epoch), per cui ogni secondo che passa, questo numero incrementa di una unità.
Gli orari sono in formato UTC, che corrisponde all’orario GMT (quello di Greenwich insomma).
La data viene memorizza in un numero a 32 bit e i sistemi colpiti saranno quelli che usano la variabile "signed".
Fortunatamente, non tutti i sistemi UNIX utilizzano il tipo signed e usano quindi il tipo unsigned che porta a non avere problemi su queste macchine (o meglio a spostarlo alle 06:28:15 di Domenica 7 Febbraio 2106) .
Un numero a 32 bit di tipo signed prevede che il numero positivo più grande memorizzabile sia 2147483647 che in base al sistema POSIX corrisponde  alle ore 03:14:07 di martedì 19 Gennaio 2038.
Un secondo dopo, come già spiegato, il numero verrà incrementato ancora di 1 e di conseguenza verrà posto ad 1 il bit più significativo di  tale numero(numero negativo).
Per cui facendo due calcoli col complemento a due il numero vale -2147483648 che nella fattispecie viene interpretato dal sistema POSIX come le ore 20:45:52 del giorno Venerdì 13 Dicembre 1901.
Questo fatto causerà enormi problemi in tutti gli ambiti in quanto dopo le 03:14:07 di martedì 19 Gennaio 2038 i sistemi UNIX crederanno di “essere tornati indietro nel tempo” al 1901 con conseguenze catastrofiche dal momento che oramai tutto è gestito da computer e tutto si appoggia alla rete internet.


SOLUZIONI
Detto del passaggio a sistemi a 64 bit, vanno fatte alcune considerazioni.
Cambiare il valore di time.h (che controlla appunto il tempo e come detto è un numero intero a 32 bit) per usare un sistema a 64-bit renderebbe il sistema incompatibile con software, sistemi di memorizzazione e tutti gli strumenti che usano una rappresentazione binaria del tempo.
Cambiare time.h in un intero unsigned, permetterebbe di rimandare il problema al 7 febbraio 2106, causando comunque problemi a molti programmi.
Molti sistemi operativi per sistemi a 64-bit usano già dei numeri interi a 64-bit per il time.h.
Il passaggio a questo tipo di architetture è in corso, e ci si aspetta che sia completo prima del 2038.
Tuttavia, ancora oggi esistono centinaia di milioni di sistemi a 32 bit sul mercato, di cui molti in sistemi integrati.
L'uso di time.h a 32 bit è anche stato inserito in vari formati di file, cosa che comporta la persistenza del problema anche oltre la vita delle macchine stesse.
L'uso di un valore di tipo signed a 64-bit sposterebbe l'emergere del problema in avanti nel tempo di circa 290 miliardi di anni.
Sono state avanzate anche varie proposte alternative, alcune delle quali in uso, per sfruttare questo spostamento eccessivo della data massima calcolabile: tra queste, includere nel calcolo delle ore i millisecondi o i microsecondi, abbreviando la vita utile delle macchine a 300.000 anni.

Cos'è Il Millennium Bug e Come Venne Risolto Il Problema

Il Millennium Bug, conosciuto anche come Y2K bug, è il nome che venne attribuito ad un bug informatico che si sarebbe manifestato al cambio di data dalla mezzanotte del 31 dicembre 1999 al 1º gennaio 2000 nei sistemi di elaborazione dati, sia PC privati che grandi elaboratori e controllori di processo. Si trattava sostanzialmente di un errore di programmazione che, al passaggio di millennio, ha impedito in alcuni programmi di riconoscere il cambiamento di data, provocando il blocco dei sistemi informatici. L'espressione Millennium venne aggiunta con l'avvicinarsi dell'anno 2000.
I computer più vecchi, infatti, indicavano la data del sistema con due sole cifre: per esempio l'anno 1998 era segnato come '98', il 1999 con il '99' e così via. Infatti se facciamo un passo indietro e torniamo a quando furono introdotti i primi calcolatori, possiamo notare che per risparmiare preziose risorse di sistema, allora limitate a pochi byte, si decise di indicare le date con i soli due numeri finali, omettendo l'indicazione del millennio e del secolo. Il "cambiamento di millennio" poteva quindi portare a problemi inaspettati, quando le banche dati informatiche avrebbero datato i nuovi documenti del 2000 con la cifra '00', creando confusione con la data '1900' (con conseguenti errori di ordinamento dei database. Pensate inoltre ai sistemi industriali e ad altri macchinari gestiti dai computer).
Questo metodo delle due cifre era stato in effetti molto utilizzato nella "preistoria" informatica, quando la memoria era scarsa e costosa. Già nella metà degli anni 80, la comunità internazionale iniziò ad interessarsi al problema. Temendo conseguenze catastrofiche per l'economia o la salute, quali ad esempio il blocco delle centrali elettriche e nucleari, testate atomiche lanciate a caso, istituti bancari e reti di telecomunicazione in tilt, vi furono ingenti investimenti volti alla rimozione delle cause del bug.
Al cadere della data critica non fu registrato nessun evento catastrofico dagli osservatori preposti (problemi si ma non eccessivamente significativi). Per la verità i computer dell'epoca (Windows 98 ad esempio) erano ovviamente già predisposti per il cambio di data, essendo ormai imminente il nuovo millennio. Il problema, nel suo complesso (vecchi sistemi operativi, antecedenti al 1998), fu risolto spendendo una decina di milioni di dollari.


USENET E SPENCER BOLLES SUL MILLENNIUM BUG
Il primo articolo pubblicato su Usenet che menziona questo problema è apparso nel newsgroup net.bugs a firma di Spencer Bolles il 19 gennaio 1985.
"Un mio amico mi ha posto una domanda interessante: dato che i computer sono nati nel ‘900 saranno preparati a capire le date dal 2000 in poi? A me sembra un qualcosa privo di senso.
Io ho pensato che il mio amico scherzasse, ma n realtà sembrava vivamente preoccupato".


LE PRECAUZIONI DELL'EPOCA
All'avvicinarsi del fatidico capodanno che avrebbe portato tutti nel nuovo millennio, le più importanti aziende italiane, americane e tutti i paesi industrializzati aggiornarono i loro PC ed i software per evitare problemi con il cambio di data. I vecchi BIOS vennero ovviamente aggiornati tramite internet dai siti dei produttori stessi. Dal punto di vista software, Windows 95 e soprattutto 98 furono abbastanza pronti, anche se vennero messe a disposizione diverse patch per entrambi per garantire la massima compatibilità e sicurezza. Il problema più grande invece riguardava ovviamente Win 3.11 che aveva bisogno di molti aggiornamenti per non avere problemi. Per Linux invece non ci furono eccessivi problemi. Per quanto riguarda gli applicativi "Office", Microsoft Office, StarOffice, Lotus e simili, per le versioni antecedenti al 97 venne messa appunto una patch. Tutti i programmi, quali grafica 2D/3D, giochi, audio, browser, montaggio video e altri non ebbero nessun problema in quanto non gestiscono date. Vennero inoltre messi in vendita moltissimi programmi che promettevano di controllare il sistema e di "risolvere" i problemi legati all'anno 2000. Qualche problema ci fu ma la catastrofe di cui si parlava, fortunatamente, non si verificò (anche grazie all'utilizzo di PC recenti e alla correzione dei bug di quelli più vecchi).
Per saperne di più: Quali Problemi Accaddero Durante Il Millennium Bug? (Y2K)

Ti consiglio anche quest'articoli: Arriva Il Bug Dell'Anno 2038 e Tempo Unix