Probablemente recuerde el pánico que rodeó el año 2000. Los medios de comunicación se divirtieron prediciendo el colapso global cuando el reloj marcó el año 2000. Pero si bien muchos sistemas heredados fueron reparados en aquel entonces, un cronómetro diferente todavía corre en el fondo de gran parte de la Internet moderna. Se llama problema del año 2038. Y tiene sus raíces en cómo los lenguajes de programación C manejan el tiempo.
La mayoría de la gente supone que el problema se trata de años de dos dígitos, como el año 2000. No lo es. La cuestión central se encuentra más profundamente en el código. Específicamente, cómo los programas C almacenan datos de fechas.
El límite de 32 bits
Aquí está la realidad técnica. La biblioteca de tiempo estándar en C utiliza un entero con signo de 4 bytes para realizar un seguimiento del tiempo. Son 32 bits. Este formato define la “época” como el inicio del 1 de enero de 1970 a las 12:00:00 a. m. UTC. Cada segundo después de ese momento se almacena como un número simple.
Por ejemplo, la marca de tiempo “919642718” representa 919 millones de segundos después de la época. Eso aterriza el 21 de febrero de 1999. Es conveniente porque restar una marca de tiempo de otra te da los segundos exactos entre dos eventos. Luego, las bibliotecas convierten esos segundos en minutos, horas o años.
Pero hay un techo duro.
Un entero de 32 bits con signo tiene un valor máximo de 2.147.483.647. Una vez que ese contador llega a cero segundos después del 1 de enero de 1970, se da vuelta.
Esa transferencia ocurre el 19 de enero de 2038.
Después de esa fecha, el número entero se desborda. Se convierte en un número negativo. Para un sistema que se basa en este formato, ese valor negativo es una fecha no válida. En realidad, es un problema técnico en la matriz de cualquier software que no se haya actualizado.
Por qué esto es más fácil que el año 2000
¿La buena noticia? Arreglar esto no es tan complicado como las pesadillas de los mainframes de finales de los 90.
En el año 2000, muchos sistemas no estandarizaron la forma en que almacenaban las fechas. Algunos usaban MM-DD-AA. Otros utilizaron AA-MM-DD. La falta de un formato universal significaba que los desarrolladores tenían que buscar código en cada aplicación y cambiar manualmente la lógica de fechas.
El problema del año 2038 es más limpio.
La biblioteca de tiempos estándar encapsula todo el proceso de cronometraje. Define sus propios tipos y funciones. Por tanto, los programas bien escritos pueden simplemente recompilarse. Los ingenieros sólo necesitan cambiar la biblioteca por una versión que utilice un tamaño de bytes mayor.
Por ejemplo, pasar de un entero de 4 bytes a un entero de 8 bytes amplía significativamente el rango. Un entero con signo de 8 bytes puede contar mucho más allá de 2038 sin desbordarse. Es una actualización de software. No es un reemplazo de hardware. No es una reescritura de código. Un intercambio de biblioteca.
Windows y Mac: diferentes temporizadores, diferentes problemas
No todos los sistemas utilizan el formato C de 32 bits. Los diferentes sistemas operativos tienen sus propias peculiaridades.
Windows NT, por ejemplo, utiliza un número entero de 64 bits. Realiza un seguimiento del tiempo en incrementos de 100 nanosegundos. Pero comienza a contar a partir del 1 de enero de 1601, no de 1970. Esto retrasa mucho más la fecha del desbordamiento. Es probable que Windows alcance su límite alrededor del año 2184.
Apple ha adoptado un enfoque diferente. Según la propia documentación de Apple, macOS está estructurado para seguir siendo válido hasta el año 29.940. Eso es aproximadamente dentro de 27.000 años. Entonces, si estás en una Mac, no necesitas preocuparte de que tu calendario falle en 2038.
¿Quién más está en riesgo?
Los sistemas basados en Unix son la principal preocupación. Pero no están solos.
Los sistemas integrados también son vulnerables. Muchos dispositivos de IoT, controladores industriales y servidores de bases de datos más antiguos dependen del mismo formato de hora de 32 bits. Si no se han actualizado, empezarán a malinterpretar las fechas posteriores al 19 de enero de 2038.
Las soluciones a corto plazo pueden implicar parchear el software para manejar correctamente los valores de tiempo negativos. Pero eso es una venda. La solución permanente requiere actualizar a un formato de hora de 64 bits.
La pregunta no es si el código se romperá. Se trata de si los sistemas que ejecutan ese código se actualizarán antes de que se acabe el tiempo.
La mayor parte de la infraestructura de la que dependemos ya está avanzando hacia el cronometraje de 64 bits. Pero no todo lo es. Servidores antiguos. Equipos industriales heredados. Alguna lógica incorporada. Esos son los eslabones débiles.
Cuando llegue el 19 de enero de 2038, el reloj llegará a su límite. Para algunos sistemas, no será un evento. Para otros, será una parada difícil. No habrá mucho tiempo para parchear el código si espera hasta el último minuto.
