Muchos de los que tuvieron la suerte de utilizar alguno de los viejos ordenadores de 8 bits, como el primer IBM PC o las home computers anteriores, todavía se maravillan con el poder de procesamiento disponible en los modernos sistemas basados en procesadores de 32 bits. Es que el numero de bits que puede manejar el microprocesador de turno define en buena medida la potencia del sistema que controla y, al tratarse de una función del tipo “2 a la n”, donde “n” es el número de bits, las plataformas de 32 bits son mucho más que cuatro veces más poderosas que las de 8.

Como saben los programadores (o aquellos que leyeron nuestro cursillo de programación en Visual Basic o de microcontroladores) en una variable de 8 bits se pueden almacenar números comprendidos entre 0 y 255 (“2 a la 8” combinaciones posibles), mientras que en una de 32 bits el rango va de 0 a 18446744073709551615 (“2 a la 32”). En ambos casos, cuando se necesita trabajar con números con signo, se divide en dos el rango completo para incluir los números negativos, así que los extremos pasan a ser -128 / 127 y -2147483648 / 2147483647. Como puede verse, las plataformas de 32 bits son mucho más poderosas que las de 8. Sin embargo, puede que sean las responsables de una supuesta catástrofe informática conocida como “el efecto 2038”.

En algo más de 68 años la variable se “desbordará”

Para comprender el origen del problema necesitamos conocer un poco más a fondo la forma en que se gestionan internamente las fechas en los ordenadores, aclarando que por “ordenadores” también se entienden los sistemas integrados, como aquellos responsables de mantener tu casa calefaccionada, el piloto automático de un avión o tu teléfono móvil conectado a la red. La gran mayoría de estos sistemas informáticos funcionan con  software escrito en uno de los más populares y robustos lenguajes de programación de todos los tiempos: el lenguaje C. En la mayoría de sistemas de 32 bits se utiliza el tipo de dato time_t - entero de 32 bits con signo- para guardar el valor de un contador de segundos interno.

Básicamente, el funcionamiento es el siguiente: se toma una fecha como base y el sistema en cuestión cuenta los segundos que han pasado desde ese momento hasta el actual. El resultado es almacenado en la variable de 32 bits que es utilizada cada vez que alguna aplicación necesita conocer la fecha y hora para poder hacer su tarea. El valor de la variable, que expresa el  número de segundos transcurridos desde las 00:00:00 horas del 1 de enero de 1970, se convierte en la fecha completa (hora-minuto-segundo; día-mes-año) mediante un algoritmo muy simple, y todos contentos.

Un minuto tiene 60 segundos, una hora tiene 60 minutos (o 3600 segundos), un día 24 horas (o 86400 segundos), y un año tiene aproximadamente 365.25 días (o 31557600 segundos). Como puede verse, a medida que pasan los años el valor almacenado en la bendita variable de 32 bits se hace más grande. Mucho más grande. No es muy difícil dividir el máximo valor de esta porción de la memoria (2147483647) por el número de segundos de un año (31557600), para darse cuenta que en algo más de 68 años la variable se “desbordará”. Esto significa que exactamente a las 03:14:07 UTC del 19 de enero de 2038, el contador interno de casi todos los sistemas informáticos programados en C llegará a 2147483647 y, un segundo después, saltará al valor -2147483648.

Quien sabe, quizás podríamos volver a la edad de piedra.

Concretamente, el problema afecta a los programas que usan la representación del tiempo basada en el sistema POSIX, que es el explicado en el párrafo anterior.  Es la representación estándar en los sistemas tipo Unix y en todos los programas escritos en el lenguaje de programación C. La mayoría del software actual cae dentro de ese grupo y fallarán, dependiendo de como estén implementados,  como si estuviesen funcionando en 1901 ó 1970, en vez de en 2038.

A pesar de ser un problema bien conocido (los programadores conocen esta limitación desde la implementación misma del lenguaje C), no existe una forma sencilla de solucionar este problema. Podría cambiarse el tipo de variable empleado por un entero de 32 bits sin signo, pero esto haría que todos los programas que  hacen cálculos con diferencias de tiempo fallen. Y reescribir por completo esas aplicaciones es un trabajo enorme, que a veces ni siquiera puede encararse. También puede creerse (erróneamente) que, utilizando una variable de 64 bits podríamos salir del paso, pero al igual que con las de 32 bits sin signo, se perdería la compatibilidad binaria con el resto del software.

Es posible que la plataforma “PC” (o lo que sea que utilicemos como ordenador personal en 2038) esté exenta del problema. Actualmente los procesadores de 64 bits están convirtiéndose en la norma, y 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 seguramente estará lista mucho antes del “Día D”. Sin embargo, varios cientos de millones de pequeños y anónimos dispositivos que hoy funcionan con núcleos de 32 bits todavía estarán dando vueltas en 2038, y ocasionaran algún que otro problema. A diferencia de los SO como Linux o Windows, los programas de muchos de esos sistemas son escritos por particulares o empresas pequeñas, que quizás ni siquiera sigan en el negocio dentro de 30 años, por lo que difícilmente reescriban sus aplicaciones.

Seguramente te estés preguntando cuándo volveremos a estar en esta situación si, en lugar de una variable de 32 bis, utilizamos una de 64. La diferencia entre el rango que pueden manejar es tan grande, que el efecto se retrasaría unos 290 mil millones de años. Si logramos pasar sin problemas el 2038, el próximo evento de este tipo ocurriría el 4 de diciembre del año 292 277 026 596 a las 15:30:08 UTC, arruinándoles el domingo a más de cuatro usuarios de ordenadores.