Debian cambia por completo a un sistema de tiempo de 64 bits sin esperar al problema de 2038

• Debian oficializa la adopción de time_t de 64 bits incluso en arquitecturas de 32 bits a partir de Debian 13, para bloquear por adelantado el problema Y2K38 (Unix Epochalypse)
• Debido a las limitaciones del time_t de 32 bits existente, después del 19 de enero de 2038 podría ocurrir que la hora retroceda hasta 1900, por lo que decidieron no seguir dejando este problema sin atender
• El hardware de 64 bits ya es seguro, pero se enfatiza la necesidad de actuar con anticipación porque Debian sigue teniendo demanda en dispositivos de 32 bits sensibles al costo, como embebidos e IoT
• Se está llevando a cabo un trabajo a gran escala para migrar simultáneamente el tipo time_t, distribuido en un total de 6,429 paquetes, asumiendo de una vez la ruptura de compatibilidad ABI
• Algunas arquitecturas heredadas con soporte legado, como i386 y hurd-i386, quedarán como excepción, aunque también se menciona la posible introducción de una nueva arquitectura x86 (i686) basada en time_t de 64 bits

---

Respuesta de Debian al bug Y2K38: transición a tiempo de 64 bits

• Debian cambiará al tiempo de 64 bits en todos los entornos, excepto en parte del hardware más antiguo que todavía soporta, para evitar el próximo problema Y2K38 o Unix Epochalypse
• Con esto se previene el error en los valores de tiempo causado por exceder el rango de un signed int de 32 bits, previsto para el 19 de enero de 2038

Contexto del problema Y2K38 y Unix Epochalypse

• El problema Y2K38 ocurre en sistemas Unix que representan los segundos transcurridos desde el 1 de enero de 1970 con un signed int de 32 bits; después de 2038 se produce un desbordamiento y la hora puede regresar por error al pasado, como 1900
• Al igual que el antiguo Y2K (problema del año 2000), esto se origina en una decisión de arquitectura de elegir un formato de datos demasiado corto
• En el caso de Y2K, la respuesta anticipada de los desarrolladores ayudó a evitar un caos mayor
• El software para hardware de 64 bits ya está a salvo, pero Debian sigue usándose ampliamente en entornos embebidos, de bajos recursos y heredados

Principales medidas de Debian

• A partir del lanzamiento de Debian 13 "Trixie", se aplicará por defecto time_t de 64 bits en todas las arquitecturas principales
• El hardware de 64 bits ya está protegido, pero los dispositivos embebidos y el hardware heredado basados en procesadores de 32 bits presentan más problemas
• Ese tipo de equipos sigue utilizándose en sectores sensibles al costo y de gran volumen de distribución, como control automotriz, IoT, televisores y routers
• Muchos equipos nuevos usan Linux compilado a medida, como OpenEmbedded, Alpine, Android o Gentoo, pero se espera que los dispositivos embebidos basados en Debian sigan vigentes durante varios años más

Implementación y cambios

• Las variables time_t están distribuidas en 6,429 paquetes, por lo que se necesitó un trabajo de gran escala
• Como este cambio puede romper la compatibilidad de ABI (interfaz binaria de aplicación), se ajustaron al mismo tiempo todas las bibliotecas y paquetes relacionados
• Según el equipo de mantenimiento, este trabajo ya está completado y suficientemente probado

Excepciones y planes futuros

• El port de i386 (x86 tradicional) seguirá manteniendo time_t de 32 bits para conservar la compatibilidad de ejecución con binarios existentes
• Podría discutirse por separado la aplicación de tiempo de 64 bits y una ISA (arquitectura de conjunto de instrucciones) moderna en la arquitectura i686
• El port hurd-i386 no hará la transición por falta de soporte del kernel; en su lugar, está en marcha una migración hacia hurd-amd64

Notas para desarrolladores

• Los desarrolladores pueden probar si su software se rompe o no con la adopción de variables de tiempo de 64 bits siguiendo la guía publicada en la wiki de Debian
• Más detalles y documentación técnica están disponibles en la wiki de Debian

[GN⁺]

Comentarios en Hacker News

• Steve Langasek se enfocó en resolver este problema durante los últimos años de su vida y logró grandes avances; de ahora en adelante, cada vez que vea time_t de 64 bits me acordaré de él
  • Gracias por volver a compartir esta buena noticia, se extraña a Steve; me pregunto si Joey sigue activo en Debian
• Sobre el problema Y2K (el problema del año 2000 causado por representar el año con dos dígitos), en ese tiempo ahorrar 2 bytes tenía muchísimo valor; el software de los 70 a los 90 cambiaba rápido, así que no se esperaba que siguiera usándose más de 5 años; me parece una visión demasiado despectiva
  • Incluso hoy se siguen usando mucho los años de 2 dígitos; por ejemplo, la fecha de vencimiento de las tarjetas de crédito (mm/yy) usa esa representación porque es cómoda y corta; alcanza de sobra para la vida útil de la tarjeta, pero en 2100 podría causar problemas de conversión; gran parte de Y2K venía de problemas de UI (campos de texto de dos caracteres, +1900 hardcodeado, etc.); el bug de Y2K que vi directamente fue en un foro de internet que pasó de 1999 a 19100 (un simple error de salida); Y2K no era solo un problema de COBOL
  • En esos casos, la “optimización prematura” en realidad habría ayudado; incluso si la fecha se hubiera representado como un int simple con 0 en 1900, se habrían ahorrado más bytes todavía; con 3 bytes se cubre desde 1900 hasta unos 44,000 días después, y con 2 bytes incluso alcanza hasta ~2070
  • Lo que confunde a la gente es que no se trataba de agregar 2 bytes, sino 2 caracteres; en COBOL, tanto números como datos se asignaban con ancho fijo según el tamaño del texto, así que para guardar un año de 4 dígitos hacían falta 4 posiciones de caracteres; esos tamaños de campo quedaban hardcodeados en todo el programa: acceso a datos, UI, archivos batch, archivos intermedios, archivos de transferencia, etc.
  • Justo antes de Y2K, había conocidos que compraron muchísimas opciones put esperando que se desplomaran las acciones de los grandes bancos, pero al final casi no pasó nada grave
  • Trabajando con COBOL a fines de los 80, vi un programa que guardaba el año con un solo dígito; cuando me explicaron la estructura me pareció rarísimo, pero los registros se borraban automáticamente cada 4 años, así que en la práctica no daba problemas; siempre estaba claro de qué año se trataba
• time_t de 64 bits resolverá el Epochalypse, pero no todos los sistemas simplemente pasarán a segundos de 64 bits; ext4 ya cambió a una resolución fraccional de 30 bits (a nivel de nanosegundos) y 34 bits para los segundos, pero aun así volverá a tener problemas dentro de varios siglos; supongo que en algún momento terminaremos estableciéndonos en timestamps de 128 bits con 64 bits de segundos + 64 bits fraccionales, y con eso se cubriría todo el futuro predecible de la historia humana
  • El tiempo en segundos de 64 bits equivale a unos 585 mil millones de años, cálculo en WolframAlpha
  • Incluso 64 bits de resolución fraccional podrían no alcanzar; para acercarse al tiempo de Planck habría que usar hasta 144 bits
  • Me dio curiosidad cómo maneja los timestamps ext4, y también cómo lo hacen los sistemas de archivos zfs y btrfs; supongo que btrfs probablemente use 64 bits, y espero que zfs también (o quizá lo estoy confundiendo con ext4)
• Se dice que Debian va a resolver Y2K38, es decir, el problema del Unix Epochalypse, pero en realidad ya completó la transición a time64_t en todos los ports de 32 bits excepto i386; i386 es la única excepción por compatibilidad binaria existente, y todos los demás, incluido m68k, ya fueron cambiados; yo mismo hice la transición de m68k, powerpc, sh4 y hppa
• time_t no es una variable sino un tipo de dato
  • Lo que dice el artículo se basa en la wiki de Debian; el texto original especifica: “time_t realmente aparece por todos lados. Aparece en el código fuente de 6,429 de 35,960 paquetes. Los paquetes que exponen en su ABI estructuras que incluyen time_t deben migrar toda su ABI al mismo tiempo”; la wiki lo explicaba con más claridad que el artículo
  • “For everything” especifica que aplica a armel, armhf, hppa, m68k, powerpc y sh4, pero no a i386; i386 no tiene futuro, y como su objetivo principal es ejecutar binarios y bibliotecas dinámicas existentes, no se quiere romper eso
  • “Se aplicará después del lanzamiento de Debian 13 Trixie” en realidad significa que viene incluido en Trixie
• Ojalá también hicieran ilimitado/dinámico el límite de longitud de la línea de comandos; aunque tengo 96GB de memoria, me sale seguido el error “argument list too long” y es molesto
  • Puedes recompilar el kernel para quitar el límite de longitud de la línea de comandos (alrededor de 100 mil caracteres), referencia en Stack Overflow; no parece una solución de fondo, y cuesta imaginar para qué usarías argumentos tan largos como un JPEG de 4k
  • Basta con aumentar el valor de RLIMIT_STACK; por ejemplo, ulimit -s 4000 da una pila de 4MB; para subirlo más hay que editar /etc/security/limits.conf y volver a iniciar sesión
  • Quizá podrías empaquetarlo en Electron y pasarlo como una solicitud http post json
  • Se puede redefinir MAX_ARG_STRLEN y recompilar el kernel; otra opción es usar una máquina con mayor tamaño de página (por ejemplo, un kernel RHEL Arm con páginas de 64k); pero es mucho más fácil usar pipes en vez de un buffer de comandos para pasar datos entre procesos
  • Lo mismo pasa con el límite de las rutas de archivos; algunos sistemas de build (Debian + python + dh-virtualenv, etc.) pueden generar rutas larguísimas, y sería más cómodo simplemente permitirlo
• Aunque se cambie a 64 bits, en algún momento igual se llegará al límite; me pregunto qué estará haciendo la humanidad el 4 de diciembre del año 292277026596 a las 3:30:07 p. m. (UTC)
  • Probablemente para entonces estén celebrando el centenario número 100 de la adopción total de IPv6
  • Dentro de 5 mil millones de años el Sol se convertirá en gigante roja y toda la superficie de la Tierra se evaporará
  • Para entonces ojalá ya nos hayamos pasado a un sistema de calendario mejor, aunque el problema de los timestamps seguiría ahí
  • Bastará con pasar a tiempo de 128 bits
  • Quizá aplique RFC 2550 (Y10K & beyond), publicado el 1 de abril de 1999
• Ya pasaron 11 años desde que OpenBSD 5.5 aplicó el mismo cambio, notas de lanzamiento de OpenBSD 5.5
  • Este es un caso de que les ganó a todos; en los 90 descubrí que la API de 32 bits de OS/2 devolvía tiempo de 64 bits, y escribí mi propia biblioteca estándar de C++ con time_t de 64 bits para usarla
  • Es un poco otro tema, pero en momentos como este me dan ganas de cambiar mis servidores a OpenBSD en vez de Linux
  • OpenBSD puede darse el lujo de preocuparse menos por la compatibilidad, y además tiene muchos menos usuarios, así que hay menos probabilidad de bugs o casos límite al hacer cambios
• Cuando dicen “Debian ya está lo bastante terminado y probado, así que el cambio se aplicará después del lanzamiento de Trixie”, me pregunto si eso significa que no va incluido en Trixie
  • Las notas de lanzamiento de Trixie dicen que sí viene incluido, notas de lanzamiento de Trixie
• Es la primera vez que escucho llamar Unix Epochalypse a Y2K38, pero es simpático, así que podría pegar
  • Ese nombre también aparece en Wikipedia sobre el Year 2038 Problem, y se viene usando en broma desde 2017
  • También existe el proyecto epochalypse-project.org
  • La expresión “it’s kind of fetch” parece una referencia a la película Mean Girls
  • Faltan unas 12 años, 5 meses, 22 días, 13 horas y 22 minutos para el Epochalypse