Think about esto: es el 19 de enero de 2038, exactamente a las 03:14:07 UTC. En algún lugar de un centro de datos, un sistema UNIX funciona silenciosamente sobre su contador de reloj interno una vez más. Pero en lugar de avanzar a las 03:14:08, sucede algo extraño. El sistema de repente piensa que es el 13 de diciembre de 1901. El caos se produce.
Bienvenido al problema del año 2038. Se realiza por otros nombres divertidos: el Bug Millennium Unix, el Epochalypse o Y2K38. Es otro ejemplo de un límite informático basic que requiere una intervención humana importante para arreglar.
El problema Y2K period bastante easy. Muchos sistemas de computación almacenaron años como figuras de dos dígitos, a menudo en aras de minimizar el espacio necesario en sistemas altamente limitados, cuando la RAM y el almacenamiento, o el espacio en las tarjetas perforadas, estaban estrictamente limitadas. Esto generalmente limitó un sistema para comprender las fechas de 1900 a 1999; Al almacenar el año 2000 como un número de dos dígitos, en cambio aparecería efectivamente como 1900. Esto prometió causar el caos de todo tipo de maneras, particularmente en cosas como las transacciones de procesamiento de sistemas financieros en el año 2000 y en adelante.
El problema fue identificado por primera vez en 1958 por Bob Bemer, quien estaba trabajando en escalas de tiempo más largas con software program genealógico. La conciencia creció lentamente durante las décadas de 1980 y 1990 a medida que se acercaba la fecha crítica y cosas como los bonos de inversión a largo plazo comenzaron a aumentar el año 2000. Se gastó un gran esfuerzo para revisar y actualizar sistemas informáticos importantes para permitirles almacenar fechas de una manera que no se remontaría a 1900 después de 1999.
A diferencia de Y2K, que se trataba en gran medida de cómo se almacenaron y se muestran las fechas, el problema de 2038 se basa en la forma basic de los sistemas similares a Unix que realizan un seguimiento del tiempo. Desde principios de la década de 1970, los sistemas UNIX han medido el tiempo a medida que transcurrió el número de segundos desde el 1 de enero de 1970 a las 00:00:00 UTC. Este momento en el tiempo se conoce como la “época Unix”. La grabación del tiempo de esta manera parecía un enfoque perfectamente razonable en ese momento. Le dio a los sistemas una forma easy y estandarizada de manejar marcas de tiempo y tareas programadas.
El problema es que esta marca de tiempo se almacenaba tradicionalmente como un entero de 32 bits firmado. Gracias a la magia de Binary, un entero firmado de 32 bits puede representar valores de -2,147,483,648 a 2,147,483,647. Cuando contando segundos individuales, eso le da aproximadamente más y menos 68 años a cada lado de la fecha de la época. Haga los cálculos, y encontrará que 2,147,483,647 segundos después del 1 de enero de 1970 lo aterriza a las 03:14:07 UTC el 19 de enero de 2038. Esa es la última vez que puede representarse utilizando el entero firmado de 32 bits, después de haber comenzado en la Epoch de Unix.
Lo que sucede después no es bonito. Cuando ese mostrador intenta incrementar una vez más, se desborda. En la aritmética del complemento de Two, el primer bit es un bit firmado. Por lo tanto, el horario se desarrolla de 2,147,483,647 a -2,147,483,648. Eso se traduce al 13 de diciembre de 1901. En enero de 2038, esto será aproximadamente 136 años en el pasado.
Para un sistema no parpadeado que utiliza un entero de 32 bits firmado para rastrear el tiempo de UNIX, las consecuencias inmediatas podrían ser graves. El software program podría funcionar mal cuando se trata de calcular las diferencias de tiempo que repentinamente abarcan más de un siglo en la dirección incorrecta, y los registros y las entradas de la base de datos podrían corrompirse rápidamente a medida que las operaciones se realizan en fechas no válidas. Las bases de datos pueden rechazar las entradas “históricas”, los sistemas de archivos podrían confundirse sobre qué archivos son más nuevos que otros, y las tareas programadas pueden dejar de ejecutarse o ejecutarse en momentos inapropiados.
Este no es solo un problema futuro abstracto. Si creciste en el siglo XX, puede sonar muy lejos, pero 2038 está a solo 13 años de distancia. De hecho, el error 2038 ya está causando problemas hoy. Cualquier software program que intente trabajar con fechas más allá de 2038, como sistemas financieros que calculan hipotecas de 30 años, podría caer sobre este error en este momento.
La solución obvia es moverse de marcas de tiempo de 32 bits a 64 bits. Un entero firmado de 64 bits puede representar marcas de tiempo en el futuro, aproximadamente 292 mil millones de años de hecho, lo que debería cubrirnos hasta mucho después de la muerte por calor del universo. Hasta que descubramos una solución para ese límite físico basic, deberíamos estar bien.
De hecho, la mayoría de los sistemas operativos modernos basados en UNIX ya han realizado esta transición. Linux se mudó a valores TIME_T de 64 bits en plataformas de 64 bits hace años, y desde la versión 5.6 en 2020, admite marcas de tiempo de 64 bits incluso en {hardware} de 32 bits. OpenBSD ha utilizado marcas de tiempo de 64 bits desde mayo de 2014, mientras que NetBSD realizó el cambio incluso a principios de 2012.
La mayoría de los otros sistemas de archivos UNIX modernos, compiladores C y sistemas de bases de datos han cambiado a 64 bits de tiempo. Dicho esto, algunos han usado soluciones más hackier que patearán la carretera más que solucionar el problema durante todo el tiempo previsible. Por ejemplo, el sistema de archivos EXT4 utiliza un sistema complicado de campaña de tiempo que involucra nanosegundos que se agotan en 2446. XFS funciona un poco mejor, pero es solo bueno hasta 2486. Mientras tanto, Microsoft Home windows usa su propio sistema de 64 bits que rastrea los intervalos de 100 nanosegundos desde el 1 de enero de 1601. Esto se superará tan pronto como el año 30,828.
Sin embargo, el desafío no es solo en los sistemas operativos. El problema también afecta el software program y los sistemas integrados. La mayoría de las cosas construidas hoy en las arquitecturas modernas probablemente estarán bien en lo que respecta al problema del año 2038. Sin embargo, las cosas que se construyeron hace más de una década que estaban destinadas a funcionar casi independientemente podrían ser un problema. El software program empresarial, el equipo de redes o los controladores industriales podrían tropezar con el límite de fecha de UNIX en 2038 si no se actualizan de antemano. También hay dependencias oscuras y bits de código que pueden hacer que incluso las aplicaciones modernas sufran este problema. Si no los cuidas.
El verdadero desafío de ingeniería radica en mantener la compatibilidad durante la transición. Los formatos de archivo necesitan actualización y las bases de datos deben migrarse sin fechas de destrozar el proceso. Para los sistemas en los campos industriales, financieros y comerciales donde el tiempo de inactividad es anatema, este puede ser un trabajo muy desafiante. En casos extremos, resolver el problema puede implicar portar un sistema completo a una nueva arquitectura del sistema operativo, incurrir en grandes costos de desarrollo y mantenimiento para hacer el cambio.
El problema 2038 es realmente un estudio de caso en deuda técnica y las consecuencias a largo plazo de las decisiones de diseño. La época Unix parecía perfectamente razonable en 1970 cuando 2038 se sintió como ciencia ficción. Pocos desarrollar esos sistemas pensaron que una elección tomada en ese entonces tendría consecuencias duraderas más de 60 años después. Es un recordatorio de que las opciones de ingeniería pragmática de hoy podrían convertirse en los desafíos técnicos del mañana.
La buena noticia es que la mayoría de los sistemas orientados al consumidor probablemente estarán bien. Su teléfono inteligente, la computadora portátil y la computadora de escritorio casi seguramente ya usan marcas de tiempo de 64 bits. El trabajo actual está ocurriendo en segundo plano: administradores de sistemas corporativos que actualizan la infraestructura del servidor, los ingenieros de sistemas integrados que planean ciclos de obsolescencia y desarrolladores de software program de auditoría del código para supuestos relacionados con el tiempo. El resto de nosotros solo podemos relajarnos y ver la (idealmente) falta de fuegos artificiales cuando nos pasa el 19 de enero de 2038.
