Jesús de Baldomá

Un segundo después de las 23:59:59 del día 31 de diciembre de 1999 se puso en marcha el tan temido efecto 2000 para el que se predecía una catástrofe a escala planetaria. Que se sepa, no ocurrió nada grave.

Básicamente, el efecto 2000 venía del hecho de que la mayoría de los programas, a la hora de guardar las fechas en la base de datos, las guardaban en formato dd/mm/aa (el año con dos dígitos) en lugar de hacerlo en formato dd/mm/aaaa (año con cuatro dígitos). Eso implicaba errores de cálculo como por ejemplo, al calcular la edad de alguien que hubiera nacido en 1970, en el año 2000, en vez de tener 30 años pasaba a tener 00-70= -70 años.

Seguramente, sucederá algo parecido con el efecto 10.000 pero me temo que no estaremos para verlo y, lo más seguro, es que (si para entonces existen los ordenadores como los concebimos ahora), ese sea el menor de los problemas.

En cambio, existe algo mucho más cercano que seguramente sí viviremos: el efecto 2038.

¿En qué consiste el Efecto 2038?

Muchos sistemas informáticos representan del tiempo mediante el sistema POSIX que, básicamente, se limita a contar el número de segundos transcurridos desde las 00:00:00 del día 1 de enero de 1970 (ignorando los segundos intercalares).

Esta representación es un estándar de facto en los sistemas tipo Unix y también, debido al gran alcance del lenguaje de programación C, en muchos otros programas escritos para otros sistemas operativos.

En la mayoría de sistemas de 32 bits, el tipo de dato time_t usado para guardar el contador de segundos es un entero de 32 bits con signo, es decir, que puede representar un rango de números entre -2.147.483.648 y 2.147.483.647, por lo que el último segundo representable con este formato será a las 03:14:07 UTC del 19 de enero de 2038 (cuando el contador habrá llegado al 2.147.483.647).

Un segundo después, el contador se desbordará, y saltará al valor -2.147.483.648, causando el fallo de programas que interpretarán el tiempo como que están en 1901 ó 1970 (dependiendo de la implementación), en vez de 2038. A su vez, esto causaría cálculo y procesamiento incorrecto.

No hay una forma sencilla de arreglar este problema para las combinaciones existentes de CPU/SO. Cambiar la definición de time_t para usar un tipo de 64 bits rompería la compatibilidad binaria para el software, almacenamiento de datos, y, por lo general, cualquier cosa que tenga algo que ver con la representación binaria del tiempo. Cambiar time_t a un entero de 32 bits sin signo afectaría a los programas que hacen cálculos con diferencias de tiempo.

La mayoría de sistemas operativos para arquitecturas de 64 bits utilizan enteros de 64 bits para time_t. La migración a estos sistemas está todavía en proceso y se espera que se complete antes del 2038. Sin embargo, cientos de millones de sistemas de 32 bits son utilizados todavía en el 2007, muchos en sistemas embebidos, y no es posible asegurar que todos ellos habrán sido reemplazados antes del 2038.

Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años. Para ser más precisos, ocurriría el domingo, 4 de diciembre del año 292.277.026.596 a las 15:30:08 UTC.

Fuente: Wikipedia.