Problème de l'an 2038 [fermé]

Quelle est la probabilité que le problème de l'Année 2038 soit très problématique?

J'ai rencontré ce problème dans un système Linux embarqué qui devait gérer les dates après 2038 dans certains certificats cryptographiques à long terme, donc je dirais que la similitude de cela dépend de votre domaine d'application.

Alors que la plupart des systèmes devraient être prêts bien avant 2038, si vous vous trouvez aujourd'hui à calculer des dates très loin dans le futur, vous pouvez avoir un problème.

Je pense que ce sera un problème important, beaucoup plus pernicieux que les problèmes de l'an 2000 de 1999/2000 car le code affecté est généralement de niveau inférieur (c'est CTIME) et il est donc plus difficile de repérer les endroits où le temps est stocké de cette façon.

Pour compliquer davantage les choses, le fait que Y2K ait été perçu comme un squib humide rendra plus difficile d'attirer l'attention sur le problème dans la perspective de l'événement.

Références culturelles:

Cory Doctorow essayait un nouveau modèle pour la mise en service / publication de nouvelles sous licences ouvertes, et j'ai suggéré un thème pour 2038, ce qu'il a brillamment fait dans Epoch: http://craphound.com/?p=2337

Il y a quelques années, des problèmes ont déjà été signalés, dans des domaines tels que les programmes hypothécaires faisant des calculs sur les prêts à 30 ans: 2008 + 30 = 2038.

Un système d'exploitation 64 bits n'est finalement pas pertinent pour le problème 2037. (CTIME s'épuise plus près de 2037 que 2038).

La question n'est pas la profondeur de bits de l'OS, mais plutôt comment l'OS stocke le temps. Ou comment la colonne de base de données choisit-elle de stocker l'heure. Ou comment cet annuaire fournit-il le temps de stockage de l’attribut de syntaxe de temps à l’arrière

C'est un problème beaucoup plus grave que les gens ne le pensent, car il est tellement endémique et courant d'avoir utilisé des compteurs de temps 32 bits.

Chaque instance qui stocke du temps doit être revisitée, et toutes les API mises à jour, et tous les outils qui l'utilisent également mis à jour.

Les couches d'abstraction qui vous permettent de régler l'heure via un format d'heure lisible par l'homme, au lieu des données brutes écrites, le facilitent, mais ce n'est qu'un cas.

Je soupçonne que cela va être beaucoup plus important que la plupart des gens ne le pensent.

C'est mon avis, mais ce problème est dû à un problème de compteur 32 bits, aujourd'hui la plupart des systèmes d'exploitation sont mis à jour pour gérer le temps sur 64 bits (au moins sur les ordinateurs 64 bits), donc je suppose que tous les systèmes d'exploitation et logiciels seront prêts longtemps avant 2038, disons 2020. Il est donc possible que vous ne rencontriez des problèmes que si, en 2038, vous exécuterez toujours des logiciels à partir de 2020.
Ce ne sera probablement pas un problème dans presque tous les cas. J'espère.

Pas si grave.

Lors du premier blitz Y2K, dans lequel les fournisseurs de logiciels et de matériel étaient tenus de certifier leurs produits comme "conformes Y2K" afin d'être vendus (je me souviens que les câbles réseau sur PC Connection étaient certifiés conformes Y2K), beaucoup d'entreprises ont fait des audits détaillés de tout , en réglant les horloges à l'avenir et en testant.

À l'époque, comme le coût des tests était si élevé, ils ont presque toujours testé avec plusieurs dates, comme 1/1/99 (certains développeurs peuvent avoir utilisé 99 comme sentinelle), 31/12/99, 1/1 / 00, le saut de 2000, 19/01/38, et bien d'autres. Voir ici pour une liste fastidieuse.

Ainsi, je crois que tout logiciel important qui existait en 1999 n'aura probablement pas 2038 bugs, mais de nouveaux logiciels écrits depuis par des programmeurs ignorants pourraient le faire. Après que l'ensemble des programmeurs de la débâcle de l'an 2000 aient généralement été beaucoup plus conscients des problèmes d'encodage de date, il est donc peu probable qu'il ait un impact aussi important que celui de l'an 2000 (qui, en soi, était quelque chose d'un anticlimax).

Les systèmes 32 bits en cours d'exécution d'ici là seront un problème.

#include <time.h>
#include <stdio.h>

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

il doit être de 1 au lieu de 9 mais ctime ne gère pas de date plus grande:

8 - Sun Jun 13 07:26:08 1141709097

Le temps de mon système (64 bits bien sûr) peut fonctionner encore 1 million d'années de plus. La solution est de mettre à jour les systèmes en 64 bits.

Le hic, c'est que les programmes ne peuvent pas le gérer. Particulièrement vieux, propriété et non entretenu. Les développeurs sont habitués aux faits suivants:

• intsont 32 bits (en fait, ils sont conservés en 32 bits sur les systèmes 64 bits, entre autres, car on supposait qu'ils étaient toujours 32 bits)
• La plupart des types (tels que time_t) peuvent être coulés en toute sécuritéint

Dans le logiciel FLOSS populaire, les deux choses ne passeront probablement pas à travers l'examen de «nombreux yeux». Sur les moins populaires et propriétaires, cela dépendra largement de l'auteur.

Je suppose que sur le monde libre * nix, le 2038 passera «inaperçu» alors que je m'attends à des problèmes sur les plates-formes «propriétaires» (c'est-à-dire celles avec un grand nombre de logiciels propriétaires) - surtout si une partie de la partie cruciale ne sera pas maintenue.

Si c'est quelque chose comme Y2K, certaines personnes ont déjà été touchées et changent de logiciel, mais la plupart des développeurs l'ignoreront jusqu'à un certain point dans les années 2030, probablement en 2035 environ, moment auquel il y aura beaucoup de travail à faire et toute personne assez âgée connaître K&R C et pas encore trop sénile pourra soudainement se sous-traiter pour beaucoup d'argent. La transition actuelle montrera beaucoup de choses qui n'ont pas encore été faites, probablement rien de si important.

Le problème de l'an 2000 était de deux chartes représentant l'année au lieu de quatre.

De nombreux systèmes n'avaient aucun moyen de distinguer entre 2000 et 1900 car ils ne stockaient que le «00».

Presque tous les systèmes utilisent maintenant 4 caractères pour stocker l'année ou utilisent une bibliothèque quelconque.

Permet donc à tous de s'inquiéter de l'année 10000 (Y10K) à la place. Sauf pour les rédacteurs de système d'exploitation et de bibliothèque ...