Il bug Y2K o “dell’anno 2000”, come abbiamo sempre detto in Italia, fece pochi danni non perché “fosse inventato”, ma perché fu uno dei più grandi progetti di bonifica software preventiva della storia dell’informatica. Il problema era reale: molti sistemi salvavano l’anno con due cifre, quindi 00 poteva essere interpretato come 1900, come valore nullo, come errore o come data fuori intervallo. Il rischio toccava mainframe, banche, assicurazioni, pubbliche amministrazioni, utility, telecomunicazioni, sistemi industriali, dispositivi con chip embedded e anche apparecchiature mediche. La spesa per gli interventi correttivi fu stimata da Gartner in 300-600 miliardi di dollari e comportò analisi del codice, sostituzioni hardware/software e test su sistemi dipendenti dalle date.
Ci ha però fortemente colpito una storia di questi giorni, anno del Signore 2026. Un ordine di laboratorio inserito con una data futura fallisce senza spiegazioni. Un ordine per domani funziona. Uno per il 2027 funziona. Uno per il 2030 no. Riducendo progressivamente l’intervallo, il limite diventa chiaro: 1° gennaio 2028.
A prima vista sembra il classico problema da software vecchio, uno di quei guasti che emergono quando un’applicazione scritta decenni prima incontra una data che i suoi progettisti non avevano considerato. In realtà il caso è molto più interessante: non siamo davanti a un normale bug Y2K esploso con 26 anni di ritardo, almeno non in senso stretto. Siamo davanti a qualcosa di più sottile: un bug Y2K mai corretto davvero, ma nascosto per anni dietro un calendario finto.
