Il bug Y2K torna nel 2026: il software sanitario viveva 28 anni nel passato

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.

I problemi di gestione delle date possono emergere anche nel 2026

Il racconto riguarda un vecchio LIS, cioè un Laboratory Information System: è un sistema che, in ambito sanitario, gestisce ordini, campioni, esami, risultati e comunicazioni con altri sistemi clinici. Può parlare con la cartella clinica elettronica, con il sistema di accettazione, con gli strumenti di laboratorio e con altri applicativi tramite messaggi HL7, uno degli standard storici usati nella sanità per far dialogare software diversi.

Protagonista della vicenda è una piattaforma nata alla fine degli anni ’80: portata da HP-UX a Linux verso la fine degli anni ’90, il sistema in questione è rimasto sostanzialmente immobile, senza ricompilazioni importanti e senza una riscrittura profonda. Un caso estremo, ma non assurdo: nel software aziendale e sanitario i sistemi che “funzionano ancora” tendono a vivere molto più a lungo delle mode tecnologiche e, spesso, più a lungo delle aziende che li hanno sviluppati.

Un sistema che vive nel passato

La parte decisiva della storia arriva quando il tecnico controlla la macchina fisica del LIS e trova una data apparentemente assurda: 1998. Siamo nel 2026, ma il sistema crede di vivere nel 1998. Portare l’orologio al 2026 non risolve il problema: anzi, peggiora tutto: gli ordini smettono di funzionare. È il primo indizio importante: la data sbagliata non era un errore accidentale, era parte del meccanismo che teneva in piedi il sistema.

Facendo alcune prove, il comportamento diventa evidente. Se la macchina è impostata al 1980, l’ordine arriva agli altri sistemi come se fosse del 2008. Il 1975 diventa 2003. Il 1990 diventa 2018. Il 1998 diventa 2026. Il 1999 diventa 2027. Il 2000, invece, rompe tutto.

La regola nascosta è quindi molto semplice: il LIS vive 28 anni nel passato. Quando deve comunicare con l’esterno, aggiunge 28 anni; quando riceve una data dal mondo reale, sottrae 28 anni. Così il cuore del programma continua a lavorare dentro una finestra temporale che conosce bene, mentre i sistemi moderni vedono date apparentemente corrette.

Il trucco dei 28 anni non è casuale

Nel calendario gregoriano, per lunghi tratti, la disposizione dei giorni della settimana tende a ripetersi ogni 28 anni. Il motivo è intuitivo: la settimana ha 7 giorni e gli anni bisestili seguono normalmente un ritmo di 4 anni. Sette per quattro fa 28. Se non intervengono eccezioni, un anno distante 28 anni può avere lo stesso calendario: stessi mesi, stessi giorni della settimana, stessa posizione del 29 febbraio negli anni bisestili.

Se il calendario del 1998 corrisponde a quello del 2026, il vecchio LIS può continuare a credere che sia il 1998, mentre il resto dell’ospedale lavora nel 2026: le date sembrano coerenti, gli ordini mantengono il giorno della settimana corretto e i messaggi HL7 possono essere tradotti con una semplice somma o sottrazione sull’anno.

Il trucco, però, funziona solo entro una finestra temporale favorevole: non è una proprietà eterna del calendario gregoriano. Gli anni secolari, per esempio, introducono un’eccezione: un anno divisibile per 100 non è bisestile, a meno che sia divisibile anche per 400. Per questo il 2000 è stato bisestile, mentre il 2100 non lo sarà.

Questa regola diventa importante perché mostra il limite ultimo del “trucco” utilizzato dagli sviluppatori.

La nuova toppa: spostare tutto di 56 anni

La correzione raccontata è quasi comica nella sua semplicità: cambiare lo scarto da 28 a 56 anni e impostare la macchina al 1970. In questo modo il sistema torna a vivere in una zona sicura del proprio calendario interno.

Con il nuovo scarto, il 2026 reale corrisponde al 1970 interno. Il 2027 diventa 1971. Il 2028 diventa 1972. Il vecchio limite dell’anno 2000 interno non viene più raggiunto subito: si sposta molto più avanti, fino al 2056 reale, quando il sistema interno arriverebbe di nuovo al 2000.

La soluzione non corregge ovviamente il difetto originario ma si limita a rinviarlo ulteriormente.

Epochalypse: il problema del 2038 c’entra?

La vicenda richiama anche il cosiddetto problema dell’anno 2038, a volte chiamato Epochalypse.

Nei sistemi Unix e Unix-like, molte rappresentazioni storiche del tempo usano il numero di secondi trascorsi dal 1° gennaio 1970. Se quel valore viene conservato in un intero con segno a 32 bit, il limite arriva il 19 gennaio 2038. Superata quella soglia, il contatore può andare in overflow e produrre date sbagliate.

Nel caso del vecchio LIS, però, la macchina continuerebbe a vivere in un intervallo interno tra gli anni ’70 e ’90, mentre le date comunicate all’esterno verrebbero corrette con una semplice operazione aritmetica sull’anno. Questo non significa che il sistema sia sano, tutt’altro.

Significa solo che il suo punto debole principale non sarebbe l’overflow Unix del 2038, ma la gestione storica delle date e degli anni a due cifre. Ogni software legacy ha il proprio calendario delle scadenze: per alcuni è il 2000, per altri il 2028, per altri ancora il 2038, il 2100 o una data completamente diversa, introdotta involontariamente da chi ha scritto il codice decenni prima.

Quando una toppa temporanea diventa parte del software

Negli anni ’80, salvare l’anno con due cifre poteva sembrare ragionevole: memoria e disco avevano costi davvero importanti (anche oggi che parliamo sempre più di crisi di RAM e storage…), i vincoli erano reali e il 2000 pareva lontano.

Alla fine degli anni ’90, riscrivere un sistema sanitario critico poteva sembrare troppo costoso o troppo rischioso, quindi spostare il calendario indietro di 28 anni poteva apparire una correzione furba. Nel 2026, cambiare lo scarto da 28 a 56 anni può sembrare ancora una volta il modo più rapido per evitare un blocco senza mettere le mani su un sistema che funziona, seppur abbia un’anima “preistorica”.

Il problema è che i sistemi informatici vivono spesso più a lungo delle ipotesi su cui sono stati costruiti. Una scorciatoia pensata per guadagnare qualche anno può restare in produzione per decenni. Un’anomalia nota a pochi può diventare parte essenziale del funzionamento; un problema irrisolto può riapparire quando il software rimane in uso molto a lungo.

Il vecchio LIS non insegna solo qualcosa sul bug Y2K. Rende evidente che il debito tecnico non scompare quando il sistema continua a funzionare ed è bene non astenersi dal monitorare costantemente il funzionamento dei sistemi per diagnosticare per tempo eventuali problemi che possono presentarsi in futuro.