El efecto 2038: qué se rompe, qué ya está a salvo y qué toca revisar

El 19 de enero de 2038, a las 03:14:07 UTC, el contador de segundos con signo de 32 bits que Unix arrastra desde 1970 se desborda y pasa a negativo. A partir de ese momento, cualquier cosa que compare marcas de tiempo se comporta de forma errática; make es el ejemplo clásico, porque decide qué recompilar mirando fechas de ficheros. La parte tranquila es que los sistemas de 64 bits no tienen ese problema y que el kernel de Linux lo resolvió en la versión 5.6, publicada en 2020.

Lo que queda por revisar está una capa más abajo.

Kernel, sistemas de ficheros y bases de datos

Con un kernel anterior al 5.6, el desbordamiento sigue ahí. En el sistema de ficheros el soporte varía: ext4, btrfs y XFS aguantan si están bien configurados, y ext3 no. Merece la pena comprobar la configuración, no solo el nombre del sistema de ficheros.

Las bases de datos guardan las fechas como les parece. Postgres usa timestamptz de 64 bits, que aguanta hasta el año 294.276. MySQL guarda datetime en 5 bytes. SQLite no tiene un tipo de fecha nativo y almacena cadenas en ISO 8601, así que el orden depende del formato que hayas escrito. DuckDB usa microsegundos en 64 bits.

No es el único contador con fecha de caducidad

El contador de semana del GPS, de 10 bits, ya dio la vuelta en 1999 y en 2019, lo volverá a hacer en 2038 y en 2058, y entonces pasará a 13 bits. El de NTP, sin signo y de 32 bits, se agota el 7 de febrero de 2036. En Postgres, el wraparound de los identificadores de transacción lo evita el autovacuum desde la versión 8, en 2005.

La lista sigue: el 787 de Boeing puede tumbar las cuatro unidades de control de los generadores si no se reinicia la alimentación en 51 días. La sonda Deep Impact se perdió porque un contador de décimas de segundo en 32 bits se salió de su rango. Discord lidia con los identificadores Snowflake de 64 bits porque JavaScript solo representa 53 bits con seguridad. Los agotados IPv4 y la lenta transición a IPv6. Y el DRM de los Blu-ray, AACS, lleva un campo de caducidad de 32 bits grabado a fuego que puede dejar discos y reproductores inservibles en una fecha que nadie eligió.

Los años bisiestos tienen su propia colección: Excel y Lotus 1-2-3 dan por hecho que 1900 fue bisiesto, cuando no lo es; la PlayStation 3 se quedó inservible el 29 de febrero de 2010, que tampoco era bisiesto; y el Zune de Microsoft se congeló el 31 de diciembre de 2008.

Todo esto viene de decisiones que en su día tuvieron sentido: el año de dos dígitos de Y2K se eligió cuando cada tarjeta perforada tenía 80 columnas y los discos guardaban sectores de tamaño fijo. La conclusión que se saca del repaso no va de fechas, sino de método: las decisiones de ingeniería tomadas a partir de una medición aguantan décadas mejor que las tomadas por intuición, y el código debería poder arreglarlo cualquiera, no solo quien lo escribió. Para quien administra sistemas, la tarea pendiente es concreta: mirar la versión de kernel y el sistema de ficheros de las máquinas que sigan en servicio en 2038, y no dar por hecho que la base de datos guarda las fechas como uno cree.