El 19 de enero del 2038, cuando el reloj marque las cinco y catorce minutos con siete segundos de la madrugada, una falla informática hará que gran parte de las computadoras, programas, servidores o cualquier tipo de dispositivo que utilice un sistema de 32 bits, falle a escala global pensando que vuelve a ser el año 1901.
La explicación específica
El problema del año 2038, también conocido por el numerónimo Y2K38, podría causar que una parte del software falle ese año. El problema afecta a los programas que usan la representación del tiempo basada en el sistema POSIX (Tiempo Unix), que se basa en contar el número de segundos transcurridos desde el 1 de enero de 1970 a las 00:00:00. Las últimas versiones del kernel Linux comienzan a contar desde las 21 del 31 de diciembre de 1969. En Android ocurre lo mismo, ya que utiliza esta versión de kernel, aunque no es posible seleccionar la fecha desde el menú de ajustes.
Esta representación es un estándar de facto en los sistemas tipo Unix y también en los programas escritos para muchos otros sistemas operativos debido al gran alcance del lenguaje de programación C. 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 (-231 y 231-1; 1 bit para el signo, y 31 para representar su valor en complemento a dos), 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 llegue a 2 147 483 647.
// Día de la Libertad de Software: mitos y verdades del gesto más democrático de la tecnología
Un segundo después, el contador se desbordará y saltará al valor -2 147 483 648, que causará el fallo de programas que interpretarán el tiempo como que están en 1901 (dependiendo de la implementación), en vez de en 2038. A su vez, esto causaría cálculo y procesamiento incorrecto, y un problema mundial. Los sistemas que cuentan la hora desde (21:00 31/12/1969) llegarán a su tope a las 00:14:07.
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.
// Las tres mejores herramientas online para convertir archivos
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 mucho antes de 2038. Usar un entero de 64 bits retrasaría la fecha del problema unos 290 mil millones de años. Es decir, 22 veces la edad aproximada del Universo.
¿Será el Y2K38 un problema?
Aunque parece una catástrofe, en realidad no hay de qué preocuparse. Ya hace unos años que los procesadores de 32 bits se están reemplazando por los de 64 bits y, al tener una mayor capacidad, tardaría siglos en tener ese problema.
// Las tres mejores alternativas al procesador de texto más conocido
Por ejemplo, Microsoft lleva ofreciendo versiones de 64 bits de su sistema operativo desde Windows XP Professional en 2005, mientras que el sistema macOS de Apple lleva siendo exclusivo de 64 bits desde Mac OS X 10.7 “Lion” en 2011, y los primeros teléfonos celulares de Android con 64 bits empezaron en 2014.
De esta manera, si ya desde 2017 los 32 bits están siendo abandonados, es lógico pensar que para 2038 incluso los de 64 bits también se reemplazarán por otros más avanzados. Es prácticamente imposible que para dentro de 20 años existan aún los procesadores de 32 bits. Y en el caso que quede algún sistema o dispositivo secundario en los 32 bits, los fabricantes tienen dos décadas para realizar actualizaciones de software.
