Discussion :

[Artemus24]

Salut escartefigue.

Tu me parles du bug de l'an 2000 et tu remontes aux années 80 ???
J'ai commencé à travaillé sur le problème des années à partir de 1997.
Et je ne faisais pas du PC mais du gros système BULL Gecos 7 et IBM MVS/TSO/ISPF.
Donc non, on n'était pas limité par des contraintes de volumétries ou de coût.

On devait juste descendre dans des applications, par toujours écrites en cobol, mais en assembleur IBM360 pour réparer les dates et faire passer les années sur 4 chiffres.
Et c'était souvent des patchs de codes à mettre en place afin de ne pas modifier la structure du programme.

Par la suite, après le bug de l'an 2000, on a fait des migrations, entre autre pour supprimer ces patchs, mais surtout pour tout renormaliser.
C'est à cette époque que l'on est passé définitivement de BULL vers IBM dans beaucoup de petites banques.

Je voie que tu as encore une bonne mémoire. Je ne me souviens plus trop de cette époque qui remonte à fort loin.

@+

[escartefigue]

Tu me parles du bug de l'an 2000 et tu remontes aux années 80 ???

Bien sur, ce fameux bug, dit "de l'an 2000" n'est que la conséquence du stockage des dates sans le siècle, stockage qui date lui des balbutiements de l'informatique, à l'époque des machines à lampes et des cartes perforées
le problème se posera à nouveau en l'an .... 10 000
Il faudra alors stocker les dizaines de milliers !
Je ne pourrai pas participer au projet "an 10 000", j'ai piscine et j'ai déjà donné !

[Artemus24]

Salut Escartefigue.

... des balbutiements de l'informatique, à l'époque des machines à lampes et des cartes perforées

Tu exagères un tout petit peu.
L'époque des lampes, c'étaient avant les années 1950. Dans les années 1960, il y avait les circuits imprimés.
Puis est apparu les circuits intégrés vers fin des années 1970. Je te dis ça de tête, mais je n'ai pas les dates exactes.

Oui, j'ai connu les perforatrices avec les fameuses cartes perforées d'IBM, ainsi que les terminaux 3279.

le problème se posera à nouveau en l'an .... 10 000

Tu as sauté une étape. Il y a déjà un problème avec la date de '2038/01/19 04:14:07'.
Tant que les ordinateurs travailleront encore en 32 bits, on ne pourra pas dépasser cette limite. Avec le 64 bits, aucun problème.
D'où justement, la pluralité des solutions pour contourner le choix de la représentation des date + time, fait par Unix.

Il y a un autre problème concernant les dates. Notre calendrier avance de 3/10000 de jour par an. Il faudra retrancher 1 jour tous les 3333 ans.
C'est la différence entre 365.2425 jours que nous appliquons sur notre calendrier et l'année tropique 365.2422.

@+