Computadoras: El problema del año 2038

En informática, el problema del año 2038 (conocido también por el numerónimo Y2K38) podría causar que una parte del software falle en ese año. El problema afecta a los programas que usen 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 (ignorando los segundos intercalares).​ Las últimas versiones del kernel Linux comienzan a contar desde las 21:00 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. 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 causaría un problema mundial. Los sistemas que cuentan la hora desde (21:00 31/12/1969) llegaran 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.

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 (2,9 × 1011). Es decir, 22 veces la edad aproximada del Universo.

Muy relacionado con el tema del año 2038 está el año 2036 (numérico: Y2K36). 

El 7 de febrero de 2036 a las 06:28:16 UTC, el contador del protocolo de sincronización de hora NTP (Protocolo de tiempo de red), ampliamente utilizados en los círculos de Unix, llegará a su máximo valor en muchos dispositivos, especialmente los sistemas integrados, que todavía utilizan el antiguo estándar RFC 868. En las implementaciones modernas, este problema está resuelto en la RFC 5905. En este caso el contexto es que el tiempo de espera se lleva a cabo con un número de 32 bits en segundos, pero sin signo y con la hora de inicio del 1 de enero de 1900 a las 00:00:00 UTC.​ Con una implementación muy adecuada de los sistemas, no hay mayor problema durante el cálculo, ya que la sincronización de tiempo debería funcionar de acuerdo con un método de diferencia. Si un cliente no conoce la hora actual (inicio en frío en sistemas sin reloj de hardware) y no verifica una fecha mínima (por ejemplo, la fecha de su compilación o la fecha del software NTP), podría probar la fecha 1900-01-01 UTC, que no se puede mostrar en tiempo de Unix y entonces el reloj interno del sistema afectado puede saltar a valores "absurdos", lo que puede conducir a un fallo total.

El Boeing 787 presenta una falla de software que obliga a apagar cada cierto tiempo -y por completo- los sistemas eléctricos a fin de prevenir entrar en modo de fallo, lo que ocasionaría el apagado de los motores en vuelo. La remota posibilidad ocurre en un software contador de centésimas de segundos que se desborda después de poco más de 248 días de funcionamiento continuo (248×24 horas ×3600 segundos ×100 = 2 142 720 000).​ La Administración Federal de Aviación (FAA) consideró menos peligroso y económico el implementar una directiva de aeronavegabilidad contra sustituir el software de todos los aviones a nivel mundial.​

Comentarios