Et il y a une très belle animation wikipédia ici qui le montre bien.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Et il y a une très belle animation wikipédia ici qui le montre bien.
Il a à vivre sa vie comme ça et il est mûr sur ce mur se creusant la tête : peut–être qu'il peut être sûr, etc.
Oui, je milite pour l'orthographe et le respect du trait d'union à l'impératif.
Après avoir posté, relisez-vous ! Et en cas d'erreur ou d'oubli, il existe un bouton « Modifier », à utiliser sans modération
On a des lois pour protéger les remboursements aux faiseurs d’argent. On n’en a pas pour empêcher un être humain de mourir de misère.
Mes 2 cts,
--
jp
Sûr, mais là ils anticipent de 23 ans le problème et la solution mise en place est prête pour le futur (on a le temps de voir venir, avec 64 bits, on a plus de 10 fois le temps écoulé depuis le big bang...).Envoyé par yahiko
Si le "problème de l'an 2000" avait été anticipé par tous les systèmes dès 1977, on aurait probablement eu moins de problèmes (déjà qu'il n'y a pas eu grand chose...).
Ce n'est pas pour dire qu'on est garanti 100% qu'il ne se passe rien de fâcheux en 2038 mais on peut néanmoins espérer que le résultat sera encore moins spectaculaire qu'en 2000.
Le bug de l'an 2000 ne se situait pas au niveau de l'OS, mais au niveau applicatif. Dans une multitudes d'applications, on avait eu la fausse bonne idée de coder l'année sur 2 octets pour économiser de l'espace mémoire.
C'est fondamentalement différent je trouve au bug de l'an 2038 beaucoup plus circonscrit techniquement parlant.
Yahiko, il faut remettre les choses à leur place. Le codage des dates sur deux octets correspondait à un impératif technique. La mémoire était chère et de petite taille à l'époque ou une bonne part de ces programmes ont été crées. Je connais un ingénieur qui a réussi à faire entrer une table de logarithme dans 1024 bits (des bits, pas des octets, ni des bytes). S'il a fait ça, c'est bien qu'il n'y avait pas d'autre solution. Aujourd'hui il y en a, la mémoire est devenu meilleur marché, les ordinateurs moderne en disposent d'une quantité astronomique. Et le fait est que la situation est déjà trouvé.
Sauf que ça ne colle pas vraiment car coder l'année sur deux octets (donc en BCD plutôt qu'en complément à 2) est au contraire une terrible perte de mémoire et ça complique les calculs. Tout ça pour avoir une représentation qui ne peut couvrir que 100 ans alors qu'avec un seul octet on peut coder jusqu'à 256 ans.
C'est d'ailleurs pour cela qu'il n'y a pas trop eu de problèmes fondamentaux complexe à résoudre dans les applications à l'an 2000 : en interne les calculs se font le plus souvent avec des timestamp au format UNIX, Microsoft ou autre. Le soucis était surtout au niveau des IHM où on convertit en décimal.
Salut à tous.
Je ne comprends pas le sens que tu attribues au mot technique.
A l'époque, je faisais du cobol, et la date ne pouvait pas être stocké sur deux octets comme tu le prétends.
La représentation de la date était 'YYMMDD', avec un digit qui occupe un quartet dans la représentation packed (COMP-3) que l'on nomme en français condensé ou BCD (Binary Coded Decimal).
De plus, dans la représentation de ce format, il y a un signe 's', qui est obligatoirement présent sous IBM et parfois absente sous BULL (comp-4).
Donc sa représentation stockée est alors 'SYYMMDD0', soit quatre octets, complété par un zéro à droite.
Si on avait la représentation 'YYYYMMDD', elle serait stockée en 'SYYYYMMDD0', soit cinq octets. Sachant qu'à 99%, les siècles sont toujours à '19', (Je parle d'avant 2000'), le choix avait de supprimer les siècles, pour gagner 1 octet.
L'impératif n'est pas technique mais d'une part pour gagner de l'espace disque et non pas mémoire, et d'autre part conservé l'ordre 'YYMMDD' afin de pourvoir trier les fichier selon se critère.
Le gros bug à l'époque, c'est aussi dans le tri. Comme les fichiers devaient être triés avec une années sur deux digit, les années 2000, 2001, codé respectivement '00' et '01' se retrouvait en fin de fichier au lieu d'être au début.
D'où la nécessité de passer la date au format 4 digits afin de respecter l'ordre naturel du tri.
Mais de quoi parles-tu ?
Pour le cas qui nous intéresse (je parle de l'article), le type 'time_t' est une représentation binaire signée sur quatre octets (1 mot de 32 bits). Chaque bit représente 1 seconde.
Donc non, il n'y a pas de pertes mémoires, tout au contraire. Et cela couvre la période allant de '1970-01-01 00:00:00' jusqu'à '2038-01-19 03:14:07' GMT.
@+
Justement je répondait a yahiko et fenkys qui disaient que le bug de l'an 2000 (qui est en effet un autre sujet) étaient lié au fait que l'on avait voulu coder l'année sur 2 octet pour gagner de la place. Ce qui signifiait travailler en BCD ce qui est tout sauf efficace en taille et en puissance de calcul.
Après j'avoue que je ne connais pas le COBOL. D'après ce que tu dit, il est naturel de travailler en BCD avec ce langage. Ça me fait plutôt peur.
Salut Uther.
Tu as entièrement raison. L'erreur est d'avoir voulu supprimer les siècles, juste pour gagner de l'espace.
Et Fenkys a aussi raison car la volumétrie que l'on avait à notre disposition n'avait rien de comparable à maintenant.
Il fallait constamment trouver des astuces pour optimiser l'espace et en conséquence de quoi, les programmes devenaient totalement illisibles.
D'où les méthodologies pour bien se faire comprendre. C'est d'ailleurs une de conséquence du bug de l'an 2000 (je parle du gros système).
Ce n'est pas bien grave que tu ne connaisses pas le COBOL.
Chaque langage a ses contraintes et elles sont dues aux méthodologies employés pour le développement, mais aussi aux possibilités qui nous sont offertes.
Dans ce langage, on ne parle pas de BCD (l'expression est juste), mais on dit 'packed decimal', où plus simplement 'packed'.
BCD est la codification des digits (les chiffres) sur un quartet et c'est tout. Le packed est une suite de digit signé. C'est une des applications du BCD.
C'est la représentation numérique condensée la plus utilisé en COBOL, à cause de la précision exacte dans les calculs.
Je reconnais que cela prend pas mal d'espace, mais quand tu as des très grand nombres, il n'y a rien d'autre pour les stocker.
@+
Hé oh les mecs, tout n'est pas codé en BCD ou en binaire...
Non, ce n'est pas un souci d'IHM (ou très marginalement), mais au niveau du stockage de la date.
Je ne compte pas les fichiers où les dates sont en "claires" dans le monde réel pas dans la théorie.
Oui, le codage de l'année sur deux octets était une fausse bonne idée, notamment par rapport au bug du "tri" comme le soulignait un intervenant.
Cela permettait marginalement d'économiser de la mémoire pour tout ce qui est fichier où justement la date est/était en claire.
Aussi, même en stockage binaire ou BCD, le problème survient aussi si on ne considère que les deux derniers digits de poids faible de l'année. Et là aussi c'était une fausse bonne idée pour vaguement économiser de la mémoire.
Enfin, non, faut pas exagérer le problème de manque de mémoire. Dans les années 60, je veux bien.
Mais dans les années 90 où on continuait encore à ne stocker que les deux derniers digits de l'année, c'était surtout une question d'habitude.
Pour qu'il se reproduise....
Il faudrait qu'il se soit déjà produit... a t-on confirmation que le bug de l'an 2000 se soit produit?
Sinon je me fais pas trop de souci si le bug est reproduisible en JavaScript ils ont le temps de revoir leur copie concernant Linux...
Je pense que le problème est très inquiétant vue la quantité des applications embraquées qui se développent de nos jours.
Avant cette date,je veux croire que j’aurai une solution à proposer
ma théorie, un problème bien connu est a moitié résolu.
2038 c'est demain au boulot!
il reste 18 ans
facile ! en 2038 j'appelle mon SAV pour un équipement grand-public acheté en 2025
(obsolescence programmée oblige) le SAV me répond tranquillement :
désolé Monsieur, vous avez acheté ce matériel il y a plus de 12 ans, il est doté d'un processeur 32 bits, hélas nous n'assurons le support que pendant les 10 années qui suivent sa fin de commercialisation, ni les pièces de rechange ni le logiciel ne sont disponibles désormais pour votre équipement
23-18=5 ans --> valeur du déterrage du post.
On a encore 23 ans pour le faire.
il reste 18 ans
Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
Mon article sur le P2V, mon article sur le cloud
Consultez nos FAQ : Windows, Linux, Virtualisation
"Aux âmes bien nées, la valeur n'attend point le nombre des années." (Pierre Corneille)
rdv en 2038 si le post existe encore
J'appelle le SAV aussi pour les centrales nucléaires ? Ca se passe comment ? Il y un numéro vert ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
de mon aide, vous pouvez cliquer sur 
.
Partager