El efecto 2038

El “Efecto 2038” es un bug que, en cierta medida, se parece al “Efecto 2000” del que tanto se habló en 1999. Este bug, relativo a la codificación del tiempo en los sistemas de 32 bits, nos emplaza a un posible fallo de sistemas en enero del año 2034.

Aunque era algo que se conocía, en el año 1999 mucha gente entró en “modo pánico” cuando los informativos y periódicos no paraban de hablar del Efecto 2000. También conocido como Y2K, bajo este término se escondía un bug que podía afectar a sistemas muy antiguos que codificaban el año en dos dígitos; por tanto, la llegada del año 2000 y su “00” podría interpretarse como el año 1900 y se podría desatar el caos absoluto.

Llegó el 1 de enero del 2000 y, finalmente, no pasó nada grave. Los aviones no cayeron del cielo ni se produjo un apagón masivo en el suministro eléctrico, las empresas invirtieron en solventar el problema y todos los temores se quedaron en una especie de leyenda urbana que muchos recordamos como algo del pasado que, realmente, quedó amplificado por los medios de comunicación y algunas campañas gubernamentales algo exageradas.

Quizás sea demasiado pronto para pensar en ello y, por este motivo, no se conozca mucho pero el “Efecto 2000” no es el único bug relativo a las fechas que existe y, de hecho, dentro de 24 años nos enfrentaremos a algo parecido en lo que se conoce como el Efecto 2038.

El Efecto 2038

Dudo mucho que en el año 2038 nos enfrentemos a un apocalipsis como el que algunos anunciaban con la llegada del año 2000 aunque, en cierta medida, estamos hablando de un problema parecido.
En la norma IEEE 1003, también conocido como POSIX, se definen una serie de estándares que normalizan una serie de interfaces para sistemas operativos y, de esta forma, poder crear aplicaciones multiplataforma. Entre los estándares que define POSIX encontramos la medida de tiempos de los sistemas de 32 bits; es decir, el reloj que usan estos sistemas.
El reloj que tienen muchos computadores no es más que un contador de segundos que se va incrementando con cada segundo que pasa. La gracia de este sistema es que se toma una fecha como referencia y, cuando se quiere saber la hora, se mira el contador de segundos y se hace la traslación a formato de fecha tradicional (día, mes, año, hora, minutos y segundos). Concretamente, la fecha de referencia es el 1 de enero de 1970 y, por tanto, el tiempo se mide como el número de segundos que han pasado desde dicha referencia.
En un sistema de 32 bits, la variable del tiempo se codifica como un entero con signo y, por tanto, se deja un bit para almacenar el signo y los 31 bits restantes para codificar los segundos. Si hacemos el cálculo de 2 elevado a 31 obtenemos como resultado 2.147.483.648 segundos que es un equivalente a unos 68 años.

Dicho de otra forma, cuando lleguen las 03:14:07 UTC del 19 de enero de 2038, el contador de segundos llegará al máximo número que puede almacenar en positivo y, si se sigue incrementando, se saldrá del rango de los números positivos y, por desbordamiento, entrará en el intervalo de los números negativos. Tras llegar al número 2.147.483.647, el contador se trasladará, en el intervalo de un segundo, al -2.147.483.648 y la fecha del sistema pasará al 13 de diciembre de 1901.
Este gran salto al pasado, evidentemente, no es algo simple y es un bug que se mira con cierta atención porque, al igual que ocurría en 1999, nadie sabe a ciencia cierta los efectos que podría tener en los sistemas desplegados.
¿Son los 64 bits una solución al problema? Obviamente, migrar hacia sistemas de 64 bits elimina el problema pero existen muchos sistemas antiguos (por ejemplo basados en COBOL) que sí requerirán soluciones (o migraciones).
 
Si alguien tiene curiosidad con este tema, quizás le interese probar la herramienta de conversión que ofrecen en Epoch Converter.

Fuente:hipertextual.com