Debian passe à un système de temps entièrement en 64 bits sans attendre le bug de 2038

• Debian officialise l’adoption de time_t en 64 bits, y compris sur les architectures 32 bits à partir de la prochaine version Debian 13, afin de bloquer à l’avance le problème Y2K38 (Unix Epochalypse)
• En raison des limites du time_t 32 bits existant, l’heure pourrait revenir à 1900 après le 19 janvier 2038 ; il a donc été décidé de ne plus laisser ce problème en suspens
• Le matériel 64 bits est déjà à l’abri, mais la demande pour Debian subsiste sur des appareils 32 bits sensibles aux coûts, comme l’embarqué et l’IoT, d’où la nécessité d’agir en amont
• Un chantier de grande ampleur est en cours : faire basculer simultanément le type time_t, réparti dans 6 429 paquets, en acceptant une rupture de compatibilité ABI
• Certaines architectures legacy prises en charge, comme i386 et hurd-i386, restent des exceptions, mais l’introduction d’une nouvelle architecture x86 (i686) fondée sur time_t 64 bits est également évoquée

---

Réponse de Debian au bug Y2K38 : passage au temps en 64 bits

• Debian passe au temps en 64 bits sur tous les environnements, à l’exception de certains des matériels les plus anciens encore pris en charge, afin d’éviter le problème Y2K38, aussi appelé Unix Epochalypse
• Cela permet d’empêcher l’erreur de valeur temporelle due au dépassement de la plage d’un signed int 32 bits, prévue pour le 19 janvier 2038

Contexte du problème Y2K38 et de l’Unix Epochalypse

• Le problème Y2K38 concerne les systèmes Unix qui représentent le nombre de secondes écoulées depuis le 1er janvier 1970 avec un signed int 32 bits : après 2038, un overflow se produit et l’heure peut revenir à tort dans le passé, comme en 1900
• Comme pour Y2K auparavant, cela provient d’une décision architecturale ayant retenu un format de données trop court
• Lors du passage à l’an 2000, l’anticipation des développeurs a permis d’éviter une perturbation majeure
• Les logiciels pour matériel 64 bits sont déjà sûrs, mais Debian reste largement utilisé dans les environnements embarqués, modestes ou legacy

Principales mesures prises par Debian

• À partir de la version Debian 13 "Trixie", time_t en 64 bits devient la valeur par défaut sur toutes les principales architectures
• Le matériel 64 bits est déjà protégé, mais le problème est plus fréquent sur les appareils embarqués et matériels legacy reposant sur des processeurs 32 bits
• Ces équipements restent employés dans des domaines sensibles aux coûts et produits en grands volumes, comme le contrôle automobile, l’IoT, les téléviseurs ou les routeurs
• Beaucoup d’équipements récents utilisent leur propre Linux compilé avec OpenEmbedded, Alpine, Android ou Gentoo, mais les usages d’appareils embarqués basés sur Debian devraient perdurer encore plusieurs années

Mise en œuvre et changements

• Les variables time_t sont réparties dans 6 429 paquets, ce qui a nécessité un travail de grande ampleur
• Cette évolution peut rompre la compatibilité ABI (Application Binary Interface) ; elle a donc été coordonnée simultanément dans toutes les bibliothèques et tous les paquets concernés
• D’après l’équipe de maintenance, ce travail est achevé et suffisamment testé

Exceptions et plans futurs

• Le port i386 (x86 historique) conserve un time_t 32 bits afin de préserver la compatibilité d’exécution des binaires existants
• L’architecture i686 pourrait faire l’objet de discussions séparées pour adopter le temps en 64 bits et une ISA plus récente
• Le port hurd-i386 ne sera pas migré faute de prise en charge suffisante côté noyau ; à la place, une transition vers hurd-amd64 est en cours

Notes pour les développeurs

• Les développeurs peuvent tester, via les méthodes décrites sur le wiki Debian, si leur logiciel risque de casser avec l’adoption de variables de temps en 64 bits
• Davantage de détails et la documentation technique sont disponibles sur le wiki Debian

[GN⁺]

Avis Hacker News

• Steve Langasek s’est concentré sur la résolution de ce problème durant les dernières années de sa vie et a permis de grands progrès ; désormais, chaque fois que je verrai time_t en 64 bits, je penserai à lui
  • Merci d’avoir rappelé cette bonne nouvelle, Steve me manque ; je me demande si Joey est toujours actif dans Debian
• À propos du problème Y2K (le bug de l’an 2000 causé par la représentation de l’année sur 2 chiffres), économiser 2 octets avait alors une très grande valeur ; les logiciels des années 70 à 90 évoluaient vite, donc on ne s’attendait pas à ce qu’ils soient utilisés plus de 5 ans ; je trouve que c’est une vision un peu trop méprisante
  • On utilise encore souvent les années sur 2 chiffres aujourd’hui ; par exemple, la date d’expiration des cartes bancaires (mm/yy) emploie ce format parce qu’il est pratique et court ; c’est suffisant pour la durée de vie d’une carte, mais cela pourrait poser un problème de conversion en 2100 ; la plupart des problèmes Y2K venaient de l’interface utilisateur (champ texte de deux caractères, +1900 codé en dur, etc.) ; le bug Y2K que j’ai vu moi-même, c’était un forum Internet passé de 1999 à 19100 (simple erreur d’affichage) ; Y2K n’était pas un problème propre à COBOL
  • Dans ce genre de cas, une « optimisation prématurée » aurait en fait pu aider ; même si on avait représenté une date par un simple entier valant 0 en 1900, on aurait économisé encore plus d’octets ; avec 3 octets, on couvre de 1900 à environ 44 000 jours plus tard, et avec 2 octets, on peut encore aller jusqu’aux environs de 2070
  • Ce que les gens confondent, c’est que le problème n’était pas d’ajouter 2 octets, mais 2 caractères ; en COBOL, qu’il s’agisse de nombres ou de données, on allouait une largeur fixe en caractères ; pour une année sur 4 chiffres, il fallait donc 4 positions de caractères ; ces tailles de champ étaient codées en dur dans tout le programme : accès aux données, UI, fichiers batch, fichiers intermédiaires, fichiers de transfert, etc.
  • Juste avant Y2K, je connaissais des gens qui s’attendaient à un effondrement du cours des grandes banques et avaient acheté en masse des options put, mais au final il ne s’est presque rien passé
  • En travaillant en COBOL à la fin des années 80, j’ai vu un programme qui ne stockait l’année que sur 1 chiffre ; quand on m’a expliqué la structure, j’ai trouvé ça étrange, mais comme les enregistrements étaient automatiquement supprimés tous les 4 ans, cela ne posait aucun problème en pratique ; il était toujours évident de quelle année il s’agissait
• Le time_t 64 bits résoudra l’Epochalypse, mais tous les systèmes ne passent pas simplement à des secondes sur 64 bits ; ext4 est déjà passé à une résolution fractionnaire sur 30 bits (au niveau de la nanoseconde) et à une résolution en secondes sur 34 bits, mais le problème réapparaîtra quand même dans quelques siècles ; je m’attends à ce qu’on finisse un jour par se stabiliser sur des horodatages 128 bits avec 64 bits pour les secondes et 64 bits pour la partie fractionnaire, ce qui couvrirait tout l’avenir prévisible de l’histoire humaine
  • Un temps en secondes sur 64 bits correspond à environ 585 milliards d’années, calcul WolframAlpha
  • Même une résolution fractionnaire sur 64 bits pourrait ne pas suffire ; pour se rapprocher du temps de Planck, il faudrait aller jusqu’à 144 bits
  • Je me demandais justement comment fonctionnent les horodatages d’ext4, et ça me rend curieux de savoir comment les systèmes de fichiers zfs et btrfs gèrent le temps ; j’imagine que btrfs utilise probablement 64 bits, et j’espère que zfs aussi (je les confonds peut-être avec ext4)
• On dit que Debian corrige Y2K38, c’est-à-dire le problème Unix Epochalypse, mais en réalité la transition vers time64_t est déjà terminée sur tous les ports 32 bits sauf i386 ; i386 est la seule exception à cause de la compatibilité binaire existante, et tous les autres, y compris m68k, ont été modifiés ; j’ai moi-même effectué la transition pour m68k, powerpc, sh4 et hppa
• time_t n’est pas une variable, c’est un type de données
  • Le contenu de l’article provient du wiki Debian ; l’original précise : « time_t apparaît vraiment partout. Il apparaît dans le code source de 6 429 paquets sur 35 960. Les paquets qui exposent via leur ABI des structures contenant time_t doivent effectuer toute la migration ABI en même temps » ; le wiki l’expliquait plus clairement que l’article
  • « For everything » précise que les cibles sont armel, armhf, hppa, m68k, powerpc et sh4, mais pas i386 ; i386 n’a pas d’avenir et sert surtout à exécuter d’anciens binaires / bibliothèques dynamiques, donc on ne veut pas le casser
  • « Prévu après la sortie de Debian 13 Trixie » signifie en réalité que cela sera inclus dans Trixie
• Ce serait bien si la limite de longueur de ligne de commande devenait aussi illimitée / dynamique ; même avec 96 Go de mémoire, l’erreur « argument list too long » est fréquente et pénible
  • On peut recompiler le noyau pour lever la limite de longueur de ligne de commande (environ 100 000 caractères), référence Stack Overflow, mais ça ne semble pas résoudre le problème de fond ; je me demande à quoi pourraient servir des arguments aussi longs qu’un JPEG 4k
  • Il suffit d’augmenter RLIMIT_STACK, par exemple ulimit -s 4000 donne une pile de 4 Mo ; pour aller plus haut, il faut modifier /etc/security/limits.conf puis se reconnecter
  • On pourrait peut-être empaqueter ça dans Electron et le transmettre via une requête JSON en HTTP POST
  • Il suffit de redéfinir MAX_ARG_STRLEN et de recompiler le noyau ; utiliser une machine avec une taille de page plus grande (par exemple un noyau RHEL Arm avec des pages de 64k) est aussi une option ; mais il est bien plus simple d’utiliser des pipes au lieu d’un tampon de commande pour faire passer des données entre processus
  • Les limites sur les chemins de fichiers relèvent du même problème ; dans certains systèmes de build (Debian + python + dh-virtualenv, etc.), les chemins peuvent devenir très longs, et ce serait plus pratique de simplement les autoriser
• Même en passant au 64 bits, on finira un jour par atteindre une limite ; je me demande bien ce que l’humanité fera le 4 décembre 292277026596 à 15:30:07 (UTC)
  • Probablement célébrer le 100e anniversaire de l’adoption complète d’ipv6
  • D’ici 5 milliards d’années, le Soleil sera devenu une géante rouge et toute la surface de la Terre se sera évaporée
  • J’espère que d’ici là on sera passés à un meilleur système de calendrier, même si le problème des horodatages restera
  • Il suffira de passer au temps sur 128 bits
  • On pourrait peut-être appliquer la RFC 2550 (Y10K & beyond), publiée le 1er avril 1999
• Cela fait déjà 11 ans qu’OpenBSD 5.5 a appliqué le même changement, notes de version d’OpenBSD 5.5
  • Ils ont tous été battus sur ce point ; dans les années 90, j’avais remarqué que l’API 32 bits d’OS/2 renvoyait un temps sur 64 bits, et j’ai donc écrit et utilisé moi-même une bibliothèque standard C++ avec time_t sur 64 bits
  • C’est un peu un autre sujet, mais ce genre de période me donne envie de migrer mes serveurs vers OpenBSD plutôt que Linux
  • OpenBSD a moins besoin de se soucier de la compatibilité et a beaucoup moins d’utilisateurs, ce qui réduit les risques de bugs ou de cas limites lors de changements
• Quand on dit que « Debian est maintenant suffisamment finalisé et testé, donc la bascule aura lieu après la sortie de Trixie », est-ce que cela veut dire que ce ne sera pas appliqué dans Trixie ?
  • Les notes de version de Trixie indiquent que ce sera bien appliqué, notes de version de Trixie
• C’est la première fois que j’entends appeler Y2K38 « Unix Epochalypse », mais c’est mignon, donc ça pourrait prendre
  • Le nom apparaît aussi dans l’article Wikipédia sur le Year 2038 Problem ; il circule comme plaisanterie depuis 2017
  • Il existe aussi le projet epochalypse-project.org
  • L’expression « it’s kind of fetch » ressemble à une référence au film Mean Girls
  • Il reste environ 12 ans, 5 mois, 22 jours, 13 heures et 22 minutes avant l’Epochalypse