Hace 17 años, el llamado "efecto Y2K" o problema del año 2000 no tuvo el impacto que pronosticaban los más tremendistas. El problema pronosticaba que la mayoría de dispositivos informáticos del mundo se bloquearían o comenzarían a funcionar de forma errada al llegar al año 2000.
El problema era por la forma en la que se había estado programando mucho software y que contaba los años representándolos con dos cifras...por lo tanto, cuando los calendarios y los relojes internos de los equipos llegasen al año 2000, creerían estar en el año 1900, puesto que los dos ceros finales eran los que determinaban el año.
Y el problema era muy real, pero afortunadamente los programadores tuvieron varios años para solucionarlo, actualizando los programas y sistemas simplemente representando los años con 4 cifras, así que al final el impacto fue mínimo y solo afectó a algunos equipos que no se habían actualizado, pero básicamente pasó el momento sin ninguna relevancia.
Aunque quedan aún muchos años....dos décadas, ya se está pronosticando un problema similar para el año 2038, al que popularmente muchos llaman "efecto o error Y2K38".
El problema se presentará exactamente el 19 de Enero del año 2038 a las 03:14:08 horas.
La mayoría de los equipos informáticos y programas de software, así como los mismos sistemas operativos usan de facto el sistema de representación horaria del sistema POSIX, que cuenta las horas en segundos y tomando como inicio las 00:00:00 horas del 1 de Enero del año 1970.
POSIX es el acrónimo de Portable Operating System Interface, y X viene de UNIX como seña de identidad de la API.
En la mayoría de los sistemas de 32 bits y que usan POSIX, el dato usado para guardar el contador de segundos (time_t) es un número entero con signo de 32 bits. Por lo tanto puede almacenar números en el rango -2.147.483.648 y 2.147.483.648.
Con este sistema POSIX, la fecha del 19 de Enero del año 2038 a las 03:14:07 horas se llegará al número máximo posible con el que se puede representar los segundos transcurridos desde el 1 de Enero de 1970. Un segundo después, el sistema se colapsará al desbordarse el contador y los programas entenderán que están en el año 1901 (o 1900 o 1970 dependiendo de la implementación del sistema en la programación) lo que causará problemas de resultados impredecibles, aunque similares a los que se pronosticaban con el problema del año 2000.
Los sistemas operativos basados en UNIX usan este tipo de representación horaria de forma estándar y la mayoría de otros sistemas operativos y programas de software también lo usan debido a que el lenguaje de programación C es usado en al menos alguna parte de su código y este lenguaje usa también el sistema POSIX para determinar las fechas.
Las últimas versiones del kernel Linux igualmente se ven afectados por este problema
Ni siquiera Android o iOS se libran de este efecto. Android se ve afectado por usar el kernel Linux, lo que provocará que los terminales se reinicien o dejen de funcionar en la fecha que indicamos anteriormente. En Android anteriores a la versión 4.0.4, el calendario permitía seleccionar una fecha posterior al 2038, pero aunque en el calendario se veía correctamente, el sistema se reiniciaba a la fecha actual, aunque curiosamente los sistemas no se reiniciaban ni se congelaban.
En iOS el mismo sistema no marca fechas posteriores al 1 de Enero del 2038, aunque a partir del iPhone 5s este problema ya no existe pues a partir de ese modelo se usan procesadores de 64 bits (en un momento explicamos la importancia de los procesadores de 64 bits en la solución de este problema).
Otros sistemas operativos móviles afectados son Ubuntu Phone, Ubuntu Touch, Firefox OS, Windows Phone 7 (aunque este permite llegar hasta el 1 de enero del 2040. Windows 8 no está afectado por este problema y cuentan las fechas desde el año 1601 hasta el año 3000.
El problema afecta solo a dispositivos que usen un procesador de 32 bits y a programas que usen el sistema POSIX como método para representar el tiempo. La mayoría del software actual caen en el grupo de afectados y cuando llegue la fecha límite del 19 de enero del 2038, creerán que se encuentran en el año 1970 o el año 1901 dependiendo de cómo estén implementados.
Los sistemas de 64 bits no tienen este problema...bueno, si lo tienen pero el efecto no entrará en acción hasta dentro de casi 3 billones de años.
Para dentro de 20 años, se espera que ya no existan en la práctica sistemas de 32 bits y el problema a nivel de hardware esté superado. A nivel de software, se espera que la inmensa mayoría de las aplicaciones estén ya adaptadas a sistemas de 64 bits y también solventen el problema, aunque hay algunos dispositivos que sí están haciendo temer que causen problemas. Estos dispositivos son los que tienen un sistema operativo embebido. O sea cajeros automáticos, módulos de cobro, sistemas de control de tráfico y otros dispositivos similares. Estos dispositivos, por su propia naturaleza no pueden actualizarse y deberán ser sustituidos por sistemas de 64 bits, lo cual representa en algunos casos un alto coste en renovación de infraestructuras.
A nivel de programación, solucionar el problema no es sencillo debido a los limitantes que presenta el lenguaje C usado en todos los programas que usan POSIX. Algunos han propuesto cambiar la variable time_t que comentamos anteriormente y que usa un sistema binario de 32 bits, por una de 64 bits. Pero esto sería una solución a medias y muchos programas de todas formas colapsarían al no saber manejar datos binarios de 64 bits.
Así que la solución a este problema, momentáneamente, sería dejar de usar dispositivos con procesadores de 32 bits y actualizar programas informáticos para que usen sistemas de 64 bits. Así mismo de momento solo se ha propuesto la sustitución de los dispositivos embebidos de 32 bits por otros basados en 64 bits. Todo esto representa un gran esfuerzo por parte de programadores, desarrolladores, fabricantes... y no se ve fácil, pero factible y necesario dada la peligrosidad de las consecuencias de no hacer nada.
De todas formas, se espera que en estos 20 años que tenemos para tratar de arreglarlo sean suficientes y el problema deje de serlo mucho antes de la fecha límite.
0 comentarios