Poco después del año 2000, hicimos bromas sobre » ¡El próximo, Y2038!»pero en ese entonces se sentía una eternidad en el futuro y era probable que fuera el problema de otra persona. Ahora que estamos a mitad de camino, y ya hemos llegado al punto en el que los problemas de Y2038 pueden causar fallas de software, es una buena oportunidad para comenzar a planificar para Y2038. Por ejemplo, es posible que el software ya tenga problemas para trabajar con certificados de vida útil de 20 años o hipotecas de 20 años, y la frecuencia de estos problemas solo aumentará a medida que nos acerquemos a Y2038. En Akamai ya estamos realizando pruebas y planificación interna con objetivos estratégicos para el año 2038, y parece probable que el alcance de este trabajo siga creciendo en los próximos 19 años, a medida que este importante esfuerzo aumente en urgencia.

Muy poco salió mal el 1 de enero de 2000 para nosotros (¡con un poco de Javascript en un sitio de marketing de Akamai que mostraba «19100» como la fecha actual!), pero una cosa que se pierde es que el limitado impacto global de esa noche se debió a dos factores: 1) la cantidad de preparación avanzada que se hizo; 2) muchos «problemas de Y2K» en realidad ocurrieron con años de anticipación en lugar de durante el vuelco en sí. Los segundos intercalares son, de alguna manera, más aterradores que los problemas de formato de fecha, ya que son más difíciles de probar y mucho menos del impacto ocurre por adelantado. Existe el riesgo de que la falta de impactos del año 2000 haga que las organizaciones y los tecnólogos se preparen menos para el año 2038. También es más difícil explicar el «año 2038» a los laicos que el año 2000, lo que podría dificultar la priorización y el enfoque del trabajo avanzado. El gran número de dispositivos integrados de Internet de las cosas (IoT) que se están ubicando en nuestro entorno también hace que el riesgo probable y el impacto potencial sean considerablemente mayores para el año 2038 que para el año 2000.

Nuestra experiencia inicial con la planificación del año 2038 (además de ver el impacto de las personas al escuchar que se planteaban preocupaciones que al principio parecían estar a 19 años de distancia) es que se necesita un enfoque gradual y enfocado en esta etapa. Sin duda se necesitarán programas mucho más involucrados e integrales algunos años más adelante. En esta fase inicial, algunas áreas en las que centrarse incluyen: 1) software que se ocupa de fechas y horas futuras; 2) formatos de archivos y mensajes en línea; 3) dispositivos con una larga vida útil implementada y sus dependencias. Por supuesto, a medida que nos acerquemos, será fundamental comenzar a enfocarse en conjuntos más amplios de sistemas, incluida la garantía de que puedan manejar la transición de Y2038 de manera segura.

Software que se ocupa de fechas futuras

Quizás el área más importante en la que centrarse inicialmente es el software que se ocupa de fechas futuras, como para el manejo de certificados X. 509 o para la planificación financiera. Hay muchas representaciones de formato de fecha y hora, no todas las cuales tendrán un problema de Y2038. Por ejemplo, el software que necesitaba lidiar con tiempos de siglos pasados (mucho antes de 1970) a menudo elegía diferentes representaciones de fecha y hora. Sin embargo, al probar los casos de certificados X. 509 (como los utilizados para HTTPS) y autoridades de certificación (CA), hemos encontrado numerosos problemas de software en el laboratorio que comienzan a surgir con certificados y CA que expiran más allá de Y2038.

OpenSSL en particular tiene múltiples formatos de tiempo, con ASN1_UTCTIME teniendo un límite en Y2049 (un problema distinto para planificar a partir de Y2038), por lo que el uso de las funciones ASN1_TIME proporciona compatibilidad con todos los rangos de tiempo. Convertir tiempos de espera de una biblioteca como OpenSSL out en time_t de 32 bits es un área adicional que probablemente tenga problemas.

En muchos de estos casos ha sido posible resolver los problemas simplemente portando y compilando software heredado para arquitecturas de 64 bits (por ejemplo, para pasar de un entero time_t de 32 bits a un time_t de 64 bits). En otros casos se han necesitado cambios más extensos, especialmente cuando los tiempos se convierten en enteros para matemáticas o cuando se involucran formatos de cable de mensajes o cuando los valores se almacenan en bases de datos. Al probar y arreglar el soporte para CA de 20 años, una cosa que se mostró es que las dependencias descendentes también entran en juego. Por ejemplo, si una fecha de 20 años en el futuro se introduce en un sistema de registro o un sistema de monitoreo, y si esos cambios se introducen en sistemas de alerta o bases de datos de informes o sistemas de aprovisionamiento, es posible que también necesiten correcciones.

Formatos de archivo y mensajes en línea

Como se mencionó anteriormente, cuando se colocan marcas de tiempo de 32 bits en mensajes, bases de datos o formatos de archivo, el impacto puede extenderse mucho más allá de un sistema específico. Estos también son sistemas con dependencias externas donde a menudo se necesita una planificación más avanzada a medida que las interacciones cruzan los límites del sistema. Para estas colecciones de sistemas interoperables, los cambios pueden necesitar ser liberados en un orden específico y la compatibilidad con versiones anteriores a menudo entra en juego. Además, si hay protocolos estandarizados formal o informalmente que usan valores de marca de tiempo de época de 32 bits en los mensajes, cualquier migración o corrección podría basarse en la reparación del estándar. Como tal, estos se vuelven importantes de los que preocuparse, al igual que con una cadena de dependencias como:

1. Actualice el protocolo / los estándares para admitir las marcas de tiempo posteriores a Y2038.
2. Implementar soporte para estándar actualizado en bibliotecas de software.
3. Obtener una nueva versión de las bibliotecas incorporadas en los paquetes de software.
4. Obtenga paquetes de software incluidos en el nuevo producto de envío.

Entonces, si cada uno de estos toma algunos años y el producto de envío tiene una larga vida útil, los largos plazos de entrega aquí ya pueden ser un problema.

Dispositivos con una larga vida útil de implementación y sus dependencias

Otra área en la que comenzar a centrarse desde el principio son los dispositivos con una larga vida útil de implementación. Como se acaba de mencionar, seguir las dependencias externas que tienen estos dispositivos también es importante. Los dispositivos integrados que se envían con hardware de 32 bits también pueden no tener una solución fácil de «solo compilar para un tiempo de 64 bits» a través de una actualización de software, o hacerlo podría tener un impacto en el rendimiento inaceptable.

Los automóviles conectados y otros dispositivos IoT son probablemente un área de preocupación específica, pero estoy seguro de que hay muchos otros tipos similares de dispositivos y aplicaciones. Por ejemplo, dadas las tendencias actuales, es probable que más del 10% de los automóviles vendidos hoy en día sigan funcionando en 2038, y con el aumento de la edad de los vehículos y el número de vehículos en la carretera, esto puede ser aún mayor. Si se necesitan algunos años para que el envío de automóviles cumpla generalmente con Y2038, con la distribución actual (y creciente) de las edades de los vehículos motorizados, podemos terminar con una fracción significativa de automóviles con el potencial de tener problemas graves en diecinueve años. Es probable que este mismo patrón también exista en algunas otras industrias, como la electrónica de consumo (como consolas de juegos para el hogar y televisores inteligentes), donde los dispositivos pueden enviarse con certificados de CA de más de 20 años preinstalados.

Los dispositivos con una larga vida útil implementada pueden requerir pruebas más completas tanto del dispositivo como de sus dependencias, como pruebas de que el sistema operativo y el software siguen funcionando correctamente antes, durante y después del punto de transición de Y2038.

¡Feliz Año Nuevo!

El problema de Y2038 se encuentra en una categoría similar a la de IPv6: se trata de un despliegue de varias décadas que en el caso general es importante pero aún no urgente (según la Matriz de Eisenhower). Desde esta perspectiva, ahora es un buen momento para comenzar a planificar, clasificar y probar antes de que sea urgente (o demasiado tarde). Concéntrese primero en el software que se ocupa de fechas futuras, formatos de archivos y mensajes en línea y dispositivos con una larga vida útil implementada. A continuación, utilice la experiencia del enfoque inicial para crear un programa más completo en los próximos años. En cualquier caso, establezca una barra mínima y comience a asegurarse de que el software, los sistemas, los protocolos y los productos nuevos que está creando e implementando no presenten problemas de Y2038 ni señalen preocupaciones cuando vea marcas de tiempo de 32 bits desde la época unix incluidas en los nuevos diseños.

Erik Nygren es Socio y Arquitecto Jefe de la organización de Ingeniería de Plataformas de Akamai. Celebrará su 20 aniversario en Akamai en junio.

Gracias a varias personas de Akamai por sus contribuciones a este artículo.

Mientras se han tomado precauciones en la preparación de este documento, Akamai Technologies, Inc. no asume ninguna responsabilidad por errores, omisiones o daños resultantes del uso de la información aquí contenida. La información aquí contenida está sujeta a cambios sin previo aviso. Akamai y el logotipo de Akamai wave son marcas comerciales o marcas de servicio registradas en los Estados Unidos (Reg. U. S. Pat. & Tm. Fuera). Publicado el 10 de enero de 2019.