Debian 13 passe son horloge en 64 bits pour éviter le bug de l’an 2038

Petit mot générique :
Il est tout à fait possible de calculer des valeurs supérieures à l'adressage de la machine : simplement, une variable dépassant la taille maximum de l'architecture signifie que cette variable ne tiendra jamais dans un seul registre, ce qui veut dire que le compilateur produira des séquences d'instructions plus complexes pour réaliser les calculs.
Concrètement, tu perdras quelques cycles de CPU à chaque opération sur une variable 64 bits dans un programme compilé en 32 bits. C'est fonctionnel, mais pas optimal. Et si les opérations sont nombreuses, intensives et ayant de l'importance, tu vas réduire ta capacité de traitement.

Ici, le système s'occupera d'incrémenter l'horloge et les accès se feront en lecture pour comparaison : chaque accès nécessitera un stockage de la variable dans 2 registres (ou via deux pointeurs mémoires dans 2 registres). Rien de bien dramatique, mais c'est effectivement inefficace.

Cependant, c'est la théorie : dans la pratique, la norme prévoir le type utilisé pour stocker un horodatage.

Concernant le typage de time_t, il n'est tout simplement pas défini directement, laissant indirectement son typage relatif à l'architecture utilisée : c'est tout l'intérêt de types intermédiaires.
Spécifiquement, la page de manuel du noyau GNU/Linux (source) renvoie vers les normes :
- POSIX.1-2008
- C11 7.27.1§3

Cette dernière norme indique que time_t est un size_t, qui a la taille de ce que renvoie l'opérateur sizeof, soit la taille maximum de l'adressage possible suivant l'architecture.
Il est intéressant de noter ici que la norme de 2011 prévoit l'utilisation de size_t, qui est normalement un entier non-signé, mais pour des raisons historiques (pouvoir stocker nativement des dates avant le 1970-01-01 ?), GNU/Linux (et Unix en général) l'utilise de manière signée.

Alors, comment la bibliothèque temporelle GNU C fait-elle pour générer une possibilité d'horodatage 64 bits sur une architecture 32 bits ?
time_t étant contraint par la norme à l'architecture, le choix a été fait d'exposer des structures et fonctions associées supplémentaires : un programme 32 bits souhaitant utiliser un temps 64 bits doit donc effectuer des appels à des variantes spécifiques des fonctions de la bibliothèque.
Cela signifie du code spécifique, qui ne résistera pas à l'épreuve du temps (ces fonctions spécifiques seront dépréciées, puis retirées, à l'avenir). Avec derrière, je le rappelle, un symbole ne tenant in fine pas dans un registre unique.
Cf. https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html

C'est précisément pour éviter ces appels spécifiques, application par application, ce qui appelle un catastrophe d'échelle industrielle, que Debian a choisi d'effectuer le travail d'intermédiaire reliant les appels standard aux API de temps vers la version 64 bits sur les architectures 32 bits, car "quelque chose" doit le faire : décision politique.
Ils ont donc choisi d'agir au niveau de la mise en paquet, avec le changement de valeur par défaut d'une directive de configuration déjà implémentée de manière rétrocompatible depuis deux ans.
Cf. https://wiki.debian.org/ReleaseGoals/64bit-time#Background

Une belle leçon de gestion d'un changement complexe par la multiplicité de ses dépendances : si seulement nous pouvions assister à cela plus fréquemment plutôt que de la brutalité d'amateurs dans les groupes de mainteneurs et surtout… les entreprises.

2000 était une vaste blague (essentiellement SGBD avec des champs obsolètement typés, et applications codées avec le fiac), mais 2038 s'annonce réellement douloureux pour une architecture entière.

Comme d'hab', la majorité attendra le dernier moment pour s'en inquiéter ou bouger si elle doit le faire, alors que j'ai des souvenirs de professeurs/chercheurs nous sensibilisant à ce problème dans les années 2010, et ils en parlaient certainement avant, mais j'étais alors trop jeune pour entendre leur discours.
Ceux qui découvrent le problème ne font qu'exprimer leurs propres manques, en premiers desquels le manque de curiosité et l'attentisme; ceux qui y ont pensé sont au courant depuis fort longtemps, et l'indiquent à qui s'intéresse à la question.