Dopo averci scherzato tempo fa, pare che il problema della data nei software non sia sparito del tutto.

Il problema dell’anno 2000 era serio, anche se le conseguenze non sarebbero state quelle “previste” dagli “esperti” catastrofisti interrogati dalla stampa, la quale era a caccia più di sensazionalismi che di notizie. In ogni modo, sia con lo sforzo preventivo sia con l’intelligenza degli utilizzatori il problema dell’anno 2000 è stato superato.

Durante il periodo di caccia al baco precedente il primo gennaio 2000, i protocolli di test per verificare il software prevedevano, ovviamente, l’utilizzo di date successive all’anno 2000 nelle normali operazioni del software.  Ok, ma quanto successive al 2000? 2001? 2005? 2010? 2100? 3000?

La risposta esatta era, ovviamente, funzione sia della vita prevista del software sia del tipo di memorizzazione della data, sia della “finestra” di tempo dei dati in archivio.

Immaginiamo che il software abbia solamente due caratteri per l’anno che vanno da 00 a 99. Senza introdurre campi aggiuntivi (di “epoca”), io posso gestire solamente 100 anni. A questo punto, si tira una riga e si assume che se il valore è minore di (ipotizziamo) 50, è una data del nuovo millennio, altrimenti è una data del XX secolo.

Tutto bene, ma se quel software ha una base storica che inizia dal 1921? Nessun problema, si tira la riga al 20, tanto chi mai utilizzerà ancora questo software nel 2020?

Purtroppo sta succedendo (ed è successo proprio a me) che alcuni software abbiano tirato la riga al 9, ovvero se l’anno (a due cifre) è compreso tra 0 e 9 si parla del 2000, altrimenti è il 1900. Qualche giorno fa ho ricevuto da un cliente un export di dati da un software con dei calendari di eventi sia appena passati sia nell’immediato futuro: gli eventi fino al 31/12/2009 hanno la data corretta, quelli successivi sono collocati nel 1910.

Visto che il problema dell’anno 2000 era sentito nel mondo informatico da molti anni prima della fatidica data, è facile che il software in questione sia stato dichiarato Y2K compliant con il solito “trucco della finestra” descritto sopra, pensando che nessuno l’avrebbe più utilizzato nel 2010.

Il primo gennaio 1910 era una sabato, mentre il primo gennaio 2010 sarà un venerdì: se dopodomani qualche software che state utilizzando dirà che è sabato, non avrà semplicemente “perso” un giorno…

Aggiornamento 2/1/2010: SpamAssassin ha un problema con le date nel 2010. Pare che il problema sia stato risolto se usate sa-update.

Aggiornamento 3/1/2010: BusinessDay riporta che In Australia i POS della Bank of Queensland all’inizio del 2010 sono inspiegabilmente saltati al 2016 (via Slashdot).

Aggiornamento 3/1/2010: Gizmodo segnala che i telefoni cellulari con Windows Mobile 6.1 e 6.5 leggono la data degli SMS dopo il 31/12/2009 come 2016.

Aggiornamento 4/1/2010: Anche Syamantec Endpoint Protection Manager ha problemi con le date di quest’anno.

Mi fermo qui con l’elenco. I problemi sono ben di più.