Questo post é stato letto 130 volte!
Il bug y2k e il software ospedaliero: un problema di gestione date nel 2026
Un software ospedaliero, sviluppato negli anni ’80, ha manifestato un inatteso bug legato alla gestione delle date, che si paleserà a partire dal 2028.
Nonostante le apparenze, non si tratta del classico problema Y2K, ma piuttosto dell’effetto di una precedente “toppa” basata su un calendario di 28 anni.
Questo episodio evidenzia come problematiche di questo tipo possano ancora presentarsi ai giorni nostri, soprattutto in sistemi legacy.
Il caso specifico del bug y2k software ospedaliero gestione date ci offre uno spaccato interessante sulle sfide della manutenzione software a lungo termine.
La storia del bug y2k e le sue implicazioni
Il famoso bug Y2K, o “dell’anno 2000”, ha causato meno danni del previsto grazie a uno dei più vasti progetti di bonifica software preventiva nella storia dell’informatica.
Il problema era reale: molti sistemi salvavano l’anno con sole due cifre, portando a possibili interpretazioni errate come il 1900, valori nulli o date fuori intervallo.
Questo rischio riguardava mainframe, banche, assicurazioni, pubbliche amministrazioni, utility, telecomunicazioni, sistemi industriali, dispositivi embedded e apparecchiature mediche.
Le spese per gli interventi correttivi furono stimate in centinaia di miliardi di dollari, investiti in analisi del codice, sostituzioni hardware/software e test approfonditi sui sistemi dipendenti dalle date.
Il caso del software ospedaliero: un calendario “finto”
Nel 2026, un ordine di laboratorio con una data futura ha iniziato a fallire senza spiegazioni evidenti.
Ordini per il giorno successivo o per il 2027 funzionavano, ma quelli per il 2030 no.
Riducendo l’intervallo, il limite è stato identificato nel 1° gennaio 2028.
A prima vista, sembrava il tipico problema di un software datato.
Invece, la situazione è più complessa: non si tratta di un banale bug Y2K esploso con 26 anni di ritardo, ma di un problema più sottile: un bug Y2K mai risolto del tutto, ma mascherato per anni dietro un calendario finto.
Un sistema che vive nel passato: il LIS e il trucco dei 28 anni
Il problema riguarda un vecchio LIS (Laboratory Information System), un sistema sanitario che gestisce ordini, campioni, esami e comunicazioni.
Questa piattaforma, nata alla fine degli anni ’80 e migrata da HP-UX a Linux, è rimasta sostanzialmente invariata.
Nel software aziendale e sanitario, i sistemi che “funzionano ancora” tendono a durare molto più a lungo delle mode tecnologiche.
La scoperta chiave è stata che la macchina fisica del LIS era impostata al 1998.
Portare l’orologio al 2026 non risolveva il problema, anzi lo aggravava.
Si è scoperto che il LIS vive 28 anni nel passato: quando comunica con l’esterno, aggiunge 28 anni; quando riceve una data, sottrae 28 anni.
Questo permetteva al programma di operare in un intervallo temporale familiare, mentre i sistemi moderni vedevano date corrette.
Il trucco dei 28 anni non è casuale: nel calendario gregoriano, la disposizione dei giorni della settimana tende a ripetersi ogni 28 anni (7 giorni x 4 anni bisestili).
Questo permetteva al calendario del 1998 di corrispondere a quello del 2026, garantendo coerenza nelle date e negli ordini.
Tuttavia, questo trucco ha un limite temporale, dovuto alle eccezioni degli anni secolari nel calendario gregoriano (ad esempio, il 2000 è stato bisestile, il 2100 non lo sarà).
Soluzioni temporanee e il debito tecnico nel software
La correzione adottata per il LIS è stata quella di spostare lo scarto da 28 a 56 anni e impostare la macchina al 1970.
In questo modo, il sistema torna a operare in una zona “sicura” del suo calendario interno.
Il 2026 reale corrisponde al 1970 interno, e il limite dell’anno 2000 interno viene posticipato al 2056 reale.
Questa soluzione, tuttavia, non corregge il difetto originale, ma lo rinvia ulteriormente.
Il problema del 2038 e il debito tecnico
Questa vicenda fa eco al problema dell’anno 2038, o “Epochalypse”, che riguarda i sistemi Unix e Unix-like.
Molte rappresentazioni del tempo usano il numero di secondi trascorsi dal 1° gennaio 1970.
Se questo valore è conservato in un intero a 32 bit con segno, il limite si raggiunge il 19 gennaio 2038 alle 03:14:07 UTC, causando potenziali overflow e date errate.
Nel caso del LIS, il suo punto debole principale non sarebbe l’overflow Unix del 2038, ma la storica gestione delle date a due cifre.
Ogni software legacy ha il proprio calendario di scadenze, introdotte involontariamente dai suoi sviluppatori.
Negli anni ’80, salvare l’anno con due cifre era una scelta ragionevole per risparmiare memoria e disco.
Alla fine degli anni ’90, riscrivere un sistema sanitario critico sembrava troppo costoso o rischioso, rendendo lo spostamento del calendario una correzione “furba”.
Nel 2026, cambiare lo scarto da 28 a 56 anni è ancora una volta una soluzione rapida per evitare blocchi.
Il problema è che i sistemi informatici spesso durano più a lungo delle ipotesi su cui sono stati costruiti.
Una scorciatoia temporanea può rimanere in produzione per decenni, e un problema irrisolto può riapparire quando il software continua a essere utilizzato a lungo.
Questo episodio sottolinea l’importanza di monitorare costantemente i sistemi per diagnosticare per tempo eventuali problemi futuri.
Questo post é stato letto 130 volte!