Bonjour à toutes et à tous.
En lisant l'article, je ne comprends pas le rapport avec le bug de l'an 2000.
A l'époque, j'ai travaillé sur ce bug où justement, comme dit l'article, les années étaient représentés sur deux digits dans les gros systèmes.
Un digit, en cobol est représenté sur un quartet, c'est-à-dire quatre bits. L'astuce utilisée était de deux sortes :
1) si on avait la possibilité de faire passer la représentation de l'année de 2 digit à 4, on le faisait.
Sauf que la longueur de l'enregistrement augmentait d'autant et pouvait dans certain cas provoquer un problème de volumétrie.
2) on ne modifiait pas le stockage de l'année sur 2 digits, mais dans les programmes cobol, on traite l'année en ajoutant devant le siècle.
Si l'année > "70" alors on traduisait le siècle par "19" sinon par "20".
Cela permettait de ne pas modifier la volumétrie des fichiers mais par contre, on risque de rencontrer un problème en 2069.
Je pense que la plupart de ces programmes auront disparu d'ici là.
Encore que, j'ai rencontré dans les années 2000, dans des banques, des programmes écrits en 1960 et qui fonctionnaient encore.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
J'ai voulu m'assurer que ce problème existe bien. J'ai fait un programme en 'c' et testé sous linux version debian, afin de vérifier cette hypothèse.
D'abord, quelques explications. On récupère la date et l'heure système, en utilisant cette instruction en 'C' :
time_t temps = time(NULL);
Ensuite, la zone 'temps' sera interprété afin de nous fournir la bonne représentation de la date et de l'heure que nous désirons obtenir, comme ci-après :
1
2
3
4
| printf("%d\n\n", temps);
strftime(format, sizeof(format), "%x %X", temps_local);
printf("-> forme local : %s\n", format); |
Pour le test, j'ai modifié la zone 'temp' de cette façon , ce qui correspond à l'hypothèse de l'article, soit 2^31 - 1 = 2 147 483 647.
time_t temps = 2147483647;
Et a l'affichage, voici ce que j'obtiens :
1
2
3
| 2147483647
-> forme local : 01/19/38 04:14:07 |
La date et l'heure s'affiche correctement, soit le 19 janvier 2038 à 04:14:07.
Je refais le même test, mais avec temp = 2 147 483 648.
Il n'y a pas d'erreur, juste que je n'obtiens aucun résultat, c'est à dire la valeur NULL.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ta remarque Femkys est pertinente, car c'est un problème UNIX et pas seulement LINUX.
Envoyé par
Femkys
Une petite précision, le passage de 2038 ne fera pas passer le système en 1970 mais plutôt en 1902 (le time_t est signé pour pouvoir exprimer des dates antérieures à 1970).
Toutes les dates et heures sous Unix sont une représentation en base (le 01/01/1970 à 00:00:00) et en déplacement.
Seul le déplacement est stocké sous le format 'time_t' qui est un 'int'.
Et bien NON ! Quand la zone 'temp' est négative, il retourne un NULL. C'est-à-dire que l'on ne peut pas avoir des dates en dessous de '1970'.
Mais à vrai dire, aura-t-on encore des machines unix ayant une représentation en 32 bits de la date, en 2039 ?
Comme pour le bug de l'an 2000, beaucoup de bruit pour pas grand chose !
Car dans le silence, il y a des ingénieurs qui ont déjà pensé à ce problème, et qui sera résolu d'ici cette date fatidique.
@+
mauvaise analyse au départ ?
Répondre avec citation
de mon aide, vous pouvez cliquer sur 
.
Partager