No sucedió nada realmente de importancia cuando el calendario cambió del año 1999 al 2000, pero… qué mal lo pasó mucha gente pensando en las consecuencias. Y cuánto tiempo y dinero costó a la industria revisar y corregir el problema del año 2000, aunque luego resultó que incluso los países que menos se preocuparon del tema tampoco se vieron inmersos en fallos significativos.
Todo surgió de una mezcla de imprevisión y falta de recursos: durante las últimas décadas del siglo XX las limitaciones de los equipos con poca memoria y capacidad de almacenamiento, junto con la falta de visión de futuro hicieron que muchos programadores prefirieran guardar las fechas que indicaban los años con solo dos dígitos en vez de cuatro. Usar algo como «77» para 1977 era cómodo y económico, sobre todo para quienes pensaban que sus sistemas ya no existirían o no se usarían en el año «00» (2000). Sin embargo, muchos de esos sistemas perduraron más allá de lo previsible, y la industria se enfrentó durante los años previos al 2000 a una revisión generalizada de millones y millones de líneas de código para garantizar que no hubiera una catástrofe de dimensiones mundiales.
En general problemas como el del efecto 2000 (Y2K en inglés) y el de otros «bugs» o fallos de programación ya habían causado en esas décadas de despliegue de la tecnología del software fallos más que notables: sondas espaciales a la deriva, equipos médicos emitiendo dosis radiactivas letales, explosiones de oleoductos, caídas de grandes redes telefónicas, cohetes y aeronaves desviadas de su trayectoria… No parecía una cuestión baladí a priori.
Se había especulado con posibles fallos en transacciones bancarias y de bolsa, en los sistemas eléctricos y de suministro de energía, en los cajeros automáticos, la industria de los seguros, los sistemas de facturación… Todo software que manejara fechas era susceptible de verse inmerso en un pequeño o gran desastre. Y todo hardware autónomo cuyo software dependiera también de un reloj y un calendario podría encontrarse en la misma situación. Y en 1999 ya vivíamos rodeados de procesadores y software por todas partes.
Lo más temido era sin duda un «efecto en cascada» que hiciera que algunos sistemas primarios fallaran, tales como los suministros de energía o de transportes, produciendo a su vez fallas graves en otros sistemas. Si fallaban las centrales de electricidad… ¿de qué serviría que el ordenador de casa o el teléfono móvil funcionara perfectamente? Si los sistemas de bolsa operan correctamente pero la red telefónica ha caído, ¿cómo se podría transmitir la información? ¿Y si había problemas y se veían afectados los servicios de emergencia? ¿Si no llegaba la gasolina a las gasolineras? ¿Si los hospitales no podían funcionar?
Se crearon comités, planes de contingencia, empresas especializadas, auditorías de software, propuestas oficiales de los gobiernos del mundo para que todas las empresas estuvieran preparadas… pero nada relevante sucedió. «A toro pasado», e incluso antes, se consideró un tanto desmesurada la situación; el Wall Street Journal llegó a llamarlo el fraude del siglo. Muchos expertos apuntaron a que esa táctica de «meter miedo» a la gente y a las empresas con un problema de dimensiones universales, fácil de entender pero difícil y caro de solucionar no era sino una excusa para hacer negocios y obtener pingües beneficios. Otros apuntaron incluso a que los grandes ingresos que obtuvo la industria del software en esa época alimentaron en buena parte el boom del desarrollo de software y en buena medida de Internet también.
Se llegó a calcular que el problema movió en total unos 300.000 millones de dólares en la industria del software. ¿Si no se hubiera puesto toda esa maquinaria preventiva en marcha hubiera habido algún cataclismo planetario? Muy probablemente no, pero tampoco es fácil asegurarlo con certeza pues la mayor parte de los países y empresas involucradas hicieron todo lo posible para evitar que sucediera lo peor, aun a costa de una gran inversión.
¿Qué sucedió el 1 de enero de 2000?
Nada relevante.
Bien porque los sistemas habían sido actualizados, bien porque eran inmunes o bien porque el efecto no fue mayor que cuando se va la luz y los relojes se ponen a cero, la gran totalidad de los problemas pasaron casi desapercibidos. Los puntos más críticos tales como plantas de energía, aeropuertos, hospitales y demás mantuvieron sus –por otra parte habituales– equipos de guardia especialmente atentos durante esa medianoche. Pero no surgieron problemas relevantes. Muchos habían ensayado en simulaciones meses antes. Por otro lado, algunos problemas se hicieron notar horas o días después, a veces tras reiniciar ciertos equipos o sistemas. Otros colearon durante años, pero su incidencia fue meramente anecdótica.
Durante el cambio de año…
- Un sistema de una central nuclear en Japón hizo saltar una alarma, pero sin consecuencias.
- También en Japón, algunos teléfonos móviles y programas de correo electrónico eliminaron mensajes de los usuarios creyendo por la fecha «00» que eran demasiado antiguos.
- Algunas máquinas de validación de billetes de transporte público dejaron de funcionar en Australia.
- Un par de sistemas en Estados Unidos y Francia –irónicamente encargados precisamente de mantener la hora oficial– emitieron de forma incorrecta la fecha de año nuevo como 1/1/19100.
¿Y qué sucedió en los años siguientes?
Algunas anécdotas que colearon desde el 2000, con bugs directamente relacionados o muy, muy similares, incluyeron…
- En 2006 se retrasó una misión de la lanzadera espacial para que no coincidiera con el cambio de año, porque los técnicos no tenían claro si podría afectar a los sistemas de a bordo. El lanzamiento y regreso de la nave tuvo lugar unos cuantos días antes, durante diciembre, evitando así esa «incomodidad» que pesaba sobre la conciencia de los programadores.
- En 2008 un problema muy similar hizo que todo los Zune de Microsoft se quedaran colgados debido a un fallo de programación, al tratarse de un año bisiesto. La solución consistió en esperar 12 horas.
¿Y qué nos espera para el futuro?
La próxima situación del mismo calibre podría ser el llamado problema del año 2038, que se producirá el 19 de enero de 2038 a las 3:14:08 y podría afectar principalmente a todos los sistemas Unix y derivados, que utilizan valores numéricos almacenados como 32 bits. El efecto consistirá en un aparente «salto hacia atrás» en el tiempo hasta 1901. Como es previsible que la mayor parte de los equipos ya utilicen valores de 64 bits para entonces, este efecto 2038 probablemente no tendrá efecto adverso alguno.
Sería raro que sucediera algo en el año 10000, el primero de cinco dígitos, porque los años ya no suelen almacenarse como «cadenas de caracteres», pero vaya usted a saber si hay alguna anécdota para entonces. Suerte a nuestros tatara-tatara-tatara-tarara… nietos.
Mirando un poco más allá, el siguiente problema, para fechas almacenadas como números con valores de 64 bits, se produciría si acaso dentro de 290.000 millones de años, pero para entonces ya estaremos ya todos criando malvas: tal vez no exista ni nuestro planeta, ni nuestra galaxia ni siquiera este Universo, así que, como dirían los programadores de los 60… ¡para qué preocuparse!
Actualización (31 de diciembre de 2009): Junto con otro grupo de gente que vivió aquel día estuve ayer en la radio hablando del tema en el informativo Hora 25 de la Cadena SER; se puede escuchar también aquí: Hora 25: El efecto 2000 (30/12/2009)
{Foto (CC) WimKlerkx.nl.}
