Blog éclectique & sans sujet précis - Mot-clé - an 2000<p>Si ça me passe par la tête, si ça n’intéresse que moi, alors c’est peut-être ici. Ou pas.</p>2024-02-13T09:44:49+01:00L'éditeur est le propriétaire du domaineurn:md5:bf83720a7189bba489682d945b972671DotclearDate de péremption de mariageurn:md5:401c781dd973433a78ec21d7a344e6f52013-11-16T00:00:00+01:002016-07-08T11:56:56+02:00ChristopheBug de l’An 2000 et d'autres tempsabominationadministrationan 2000base de donnéesbon sensbugBusiness Objectsdommagedysfonctionnementdéveloppementgénéalogieperfectionnismeprise de têteprécisionsabotageSAPscience-fictionSQL <p>Dans une base de données quelconque qui restera anonyme <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-1" id="rev-wiki-footnote-1">1</a>]</sup> un mien collègue a déniché qu’un mariage pouvait avoir une date de fin future planifiée (nous ne parlons pas des divorces passés ou proches).</p>
<p>En l’occurrence, tous les mariages étaient censés se dissoudre le 31 décembre 9999. C’est évidemment stupide. Cette donnée aberrante est l’équivalent en date d’un <a href="https://fr.wikipedia.org/wiki/Nombre_magique_%28programmation%29">nombre magique</a> : une telle donnée possède un autre sens que sa simple valeur, en l’occurrence le fait que la date de fin de mariage n’<em>existe pas</em>, le mariage n’a pas été dissous.</p>
<p>Cela peut-il poser un problème réel dans le futur ? Je concède que la perspective est lointaine, mais <a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2006/03/02/92-les-bugs-qui-nous-attendent">il n’y a pas qu’un programme concerné par ce genre de phénomène</a>, loin de là.</p>
<p>Il n’est pas complètement impossible que, grâce aux progrès de la médecine, du voyage dans le temps, de la cryogénisation, ou de la numérisation des cerveaux, certains d’entre nous voient l’an 9999 <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-2" id="rev-wiki-footnote-2">2</a>]</sup>. Il est encore plus improbable, mais pas impossible non plus, que les données de cette application aient été conservées <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-3" id="rev-wiki-footnote-3">3</a>]</sup>, pour une raison ou une autre, jusqu’à cette époque reculée, pour payer une aide sociale ou une pension quelconque (de la part de quel État, caisse et en quelle monnaie ?). Au passage, il ne devrait rester aucun couple n’ayant <em>pas</em> divorcé (1% de taux de divorce annuel pendant 8000 ans multiplié par 4 milliards de couples = plus aucun couple du XXI<sup>è</sup> siècle encore marié en 9999), ce qui résoudra le problème par le vide.</p>
<p>Bref, nous nageons dans la pure spéculation, mais il reste une morale : cette application est mal programmée, elle ne distingue pas ce que toute base de données devrait connaître depuis plusieurs décennies, à savoir la distinction entre une donnée et une donne <em>absente</em>, ce qu’en langage de base de données on nomme <code>NULL</code> <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-4" id="rev-wiki-footnote-4">4</a>]</sup>.</p>
<p>Au passage : <a href="https://fr.wikipedia.org/wiki/Edgar_Frank_Codd">Saint E. F. Codd</a> aurait même voulu <a href="https://en.wikipedia.org/wiki/Null_%28SQL%29#Criticisms" hreflang="en">distinguer valeur existante inconnue et valeur sans signification</a>, c’est-à-dire « Non renseigné » et « Non applicable ». <br />Exemple : dans un logiciel administratif, la date de naissance peut être « Non renseignée », mais on sait qu’il y en a forcément une <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-5" id="rev-wiki-footnote-5">5</a>]</sup> ; par contre le champ « Nom marital » vaudra « Non applicable » pour tous les gens non mariés ou qui ont déclaré ne pas en utiliser — mais il pourrait être « Non renseigné » si on sait que M<sup>lle</sup> Dupont a changé de nom en se mariant.</p>
<p>Les développeurs informatiques ne sont parfois même pas fichus de gérer correctement le cas du <code>NULL</code>. Il a quelques propriétés surprenantes dont il faut tenir compte, comme <code>1 + NULL</code> = <code>NULL</code>, ou comme la clause <code>IF NULL = NULL</code> qui renverra toujours « faux ». Noter que selon les bases de données, une chaîne vide est équivalente à un <code>NULL</code> (Oracle) ou pas (SQL Server, PostgreSQL...). Pour ne pas embrouiller plus les choses, le <code>N/A</code> a donc finalement été laissé de côté. Et, mine de rien, mes collègues et moi sommes obligés de le réintroduire de manière plus fastidieuse et visible dans les bases de données décisionnelles que nous sommes payés pour créer. Signalons également le cas pathologique de <a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/07/05/175-la-guerre-des-erp-sap-vs-oracle-applications-5-schemas-de-donnees">SAP R/3</a>, qui n’utilise pas les <code>NULL</code> même s’il les connaît, et préfère <code>INITIAL</code>, matérialisé en pratique par un espace solitaire !</p>
<p>Pour revenir aux dates : j’ai rencontré tout récemment une autre application qui stockait des valeurs magiques : 1<sup>er</sup>janvier 1900 (admettons, cette date ne reviendra pas), et 1<sup>er</sup>janvier 2050. Une date pareille est une erreur, il y a une chance non négligeable que les données soient encore utilisées à cette date, même si le responsable de ce choix sera probablement à la retraite <sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#wiki-footnote-6" id="rev-wiki-footnote-6">6</a>]</sup>.</p>
<p>Dans un registre similaire, un nombre peut aussi être infini, c’est même standardisé, <a href="https://www.simple-talk.com/blogs/2010/04/13/from-nan-to-infinity-and-beyond/" hreflang="en">mais le support par certaines bases de données est bancal...</a>. On dérive vers l’ontologie, puisque l’infini n’est pas de ce monde : une base de données le reflétant doit-elle pouvoir le contenir ?</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-1" id="wiki-footnote-1">1</a>] <em>Parce que 1) je ne m’en souviens pas précisément, ce billet fut entamé il y a bien des mois ; 2) c’est sans doute une base d’un client ; et 3) ça n’a pas d’importance tant le problème est courant.</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-2" id="wiki-footnote-2">2</a>] <em>En cas de cryogénisation, la blague dit que tous les programmeurs COBOL seront réveillés un peu avant cette date pour un </em>remake<em> du bug de l’an 2000. </em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-3" id="wiki-footnote-3">3</a>] <em>En fait, la NSA en aura probablement une copie jusqu’à la fin des temps.</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-4" id="wiki-footnote-4">4</a>] <em>J'ai au passage une pensée (haineuse) envers les traducteurs de BusinessObjects qui ont traduit “Is not null” par « N’est pas nul » (soit : « n’est pas zéro »), un véritable contresens qui me coûte un quart d’heure d’explication à chaque formation que je donne. Si encore c’était la seule abomination linguistique du produit...</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-5" id="wiki-footnote-5">5</a>] <em>Le cas de certaines divinités est négligé.</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#rev-wiki-footnote-6" id="wiki-footnote-6">6</a>] <em>Quoique par les temps qui courent, ça n’est même plus sûr.</em></p></div>
https://www.coindeweb.net/blogsanssujetprecis/index.php?post/Date-de-peremption-de-mariage#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/694Les pièges dans le développementurn:md5:027397c82f7b17b77f214e2771de88882008-04-07T21:04:00+00:002014-02-26T14:06:23+00:00ChristopheInformatique : l’art du développementan 2000apparencebase de donnéesbon sensbugchiffrescomplexitédommagedysfonctionnementgénéalogiegéographiehistoireinformatiquemathématiquesorganisationparadoxeparanoïaprise de têteprécisionsaturationsciencetempsthéorie<p>Quand les premiers programmeurs ont commencé à développer les premiers logiciels, ils se sont aperçu avec horreur qu’ils allaient perdre un temps effroyable en débogage : la belle rigueur mathématique qui enfanta l’informatique ne résista pas au choc avec la vie réelle, et plus concrètement à l’alimentation du bel ordinateur par des données mal foutues, non standardisées, parasitées, ou comprenant des situations tellement tordues que personne n’y avait pensé.</p> <p>Certaines situations exceptionnelles peuvent être prévisibles, mais arrivent une fois sur cent. Sans ordinateur, un être humain qui suit une procédure les remarque souvent spontanément, et adapte son comportement en conséquence.</p>
<p>Un ordinateur, lui, suit bêtement la règle, et l’applique dans des cas qu’un gamin de quatre ans trouverait débiles. D’où les classiques des débuts de l’informatisation administrative, comme les factures à 0,00 franc, ou les dossiers d’inscription à l’école envoyés à de vieilles dames de 106 ans. Les sociétés qui transforment des humains en téléopérateurs-perroquets assimilés à des machines sans initiative génèrent le même genre de bugs, juste avec de la viande en guise de matériel.</p>
<p>Je me méfie comme de la peste des spécifications écrites par des gens qui raisonnent « en règle générale » (à peu près la totalité de la population). Or, pour un développeur, il n’y a pas une règle générale et son 0,0001% d’exception, mais bien <em>deux</em> cas à traiter. Si le deuxième, exceptionnel, est renvoyé à un humain, cela me convient ; encore faut-il anticiper et détecter cette exception, prévenir cet humain, et donner à celui-ci le droit et le moyen matériel de passer « en manuel ». Notre civilisation pèche de plus en plus sur ce point.</p>
<p>Donc par déformation professionnelle, je <em>dois</em> devenir vicieux et mettre en doute les choses les mieux établies. Prenons quelques exemples. Demandez-vous si les règles suivantes sont <em>vraiment</em> universelles :</p>
<ul>
<li><strong>Toutes les années ont 365 jours.</strong></li>
</ul>
<p>Non, il y a les années bissextiles. Je sais, c’est facile. Mais il faut y penser réellement quand on calcule, par exemple, un taux annuel à partir de quantités journalières, et la formule devient subtilement plus compliquée qu’une bête multiplication. L’impact n’est pas négligeable (une journée de travail en plus, c’est 0,5% d’heures travaillées en plus sur l’année, et 5% en plus en février) et des comparaisons entre années doivent en tenir compte.</p>
<p>Cela fait aussi un cas à ajouter au jeu de test...</p>
<ul>
<li><strong>Toutes les années divisibles par 4 sont bissextiles.</strong></li>
</ul>
<p>Ça c’était au temps du calendrier julien. En calendrier grégorien, les années divisibles par 100 (1800, 1900...) ne sont <em>pas</em> bissextiles.</p>
<p>Pour les informaticiens versés dans les dates lointaines et étrangères, il faut faire attention : <a href="http://fr.wikipedia.org/wiki/Passage_au_calendrier_grégorien#Date_du_passage_au_calendrier_gr.C3.A9gorien_par_pays">selon les pays, le passage au calendrier actuel s’est étalé de 1582 à 1929</a>.</p>
<ul>
<li><strong>Toutes les années divisibles par 4 non divisibles par 100 sont bissextiles.</strong></li>
</ul>
<p>Depuis l’an 2000, on sait que non : par exception à l’exception qui veut que les années divisibles par 100 ne soient <em>pas</em> bissextiles, les années divisibles par 400 <em>sont</em> bissextiles. Il reste à espérer que les logiciels retouchés pour l’an 2000 ne l’ont pas été avec une simple exception pour 2000, sinon ceux encore en activité en 2400 nous sauteront à nouveau à la face.</p>
<ul>
<li><strong>Toutes les années divisibles par 4 non divisibles par 100 sont bissextiles, et aussi celles divisibles par 400.</strong></li>
</ul>
<p>Le 1er avril 1999, le site des éditions allemandes Heise annonçait la découverte de documents d’époque révélant que <a href="http://www.heise.de/newsticker/meldung/4387" hreflang="de">lors de la mise en place du calendrier grégorien et de la règle de la divisibilité par 100 ou 400, il avait été aussi précisé que les années divisibles par 1000 ne seraient pas non plus bissextiles, même si elles étaient divisibles par 400 (cas de l’an 2000), avec l’exception de 5è niveau des années divisibles par 4000, qui seraient bien bissextiles</a>.</p>
<p>Cette règle flanquait par terre une bonne partie du travail effectué pour corriger le bug de l’an 2000, et l’industrie entière a préféré prendre cette histoire comme un poisson plutôt que reprendre de zéro le travail. Je vous laisse vous faire votre avis. :-)</p>
<ul>
<li><strong>L’année commence en janvier et finit en décembre</strong>.</li>
</ul>
<p>Ne pensent cela que ceux qui n’ont pas travaillé avec des comptables. Les années fiscales et civiles n’ont pas forcément grand rapport, il y a un décalage de plusieurs mois.</p>
<ul>
<li><strong>Il y a 12 mois dans l’année (calendrier grégorien).</strong></li>
</ul>
<p>Pour le commun des mortels en Occident, oui.</p>
<p>Pour un système de gestion financière de collectivité locale française, il peut y en avoir 14 :</p>
<p>- les 12 mois habituels ;<br />- un pseudo-mois nommé par exemple « Décembre N-1 » rattaché à l’année N mais comprenant par exemple toutes les décisions prises à la fin de l’année civile antérieure (on vote en décembre le budget de l’année prochaine) ;<br />- un pseudo-mois « Journée complémentaire » qui regroupe toutes les opérations qui doivent être rattachées à cette même année N, mais qui pour des raisons pratiques sont effectuées en réalité au début de l’année suivante.</p>
<p>Pour une entreprise qui change sa référence d'année fiscale (par exemple de mars à mars au lieu de janvier à janvier), une année de transition est démesurément longue ou raccourcie.</p>
<p>Je suis sûr qu’il y a dans le monde une flopée d’exemples d’astuces de ce genre propres à un métier, une administration, une entreprise, un service, qui flanquent en l’air nombre d’algorithmes un peu naïfs.</p>
<ul>
<li><strong>En Occident, les mois sont janvier, février, mars, avril...</strong></li>
</ul>
<p>J’ai des ancêtres nés en ventôse de l’an V de la République...</p>
<p>Un logiciel traitant de cadastres, de généalogie, d’actes juridiques... peut avoir besoin de ces données remontant à deux siècles. Le recalcul permanent en calendrier grégorien est source d’erreurs, et il vaut mieux aussi stocker la date originelle pour comparer avec les documents originaux. (Bon, soyons réaliste, un champ « commentaire » pourrait suffire en pratique.)</p>
<ul>
<li><strong>Il n’y a pas de 30 février ni de 31 juin.</strong></li>
</ul>
<p>Dans le calendrier grégorien occidental récent, non.</p>
<p>Dans un champ rempli par les utilisateurs, et non contrôlé, on peut avoir n’importe quoi.</p>
<p>L’exemple type est le « <a href="http://www.iherve.com/oracle/Forms_Apps_FF.htm" hreflang="en">flexfield</a> » d’Oracle Applications (l’ERP). En gros, c’est un champ optionnel avec filtre paramétrable qui s’ajoute aux champs habituels d’un écran, et que peut remplir l’utilisateur. L’endroit idéal pour stocker une information non prévue dans le logiciel original, par exemple un code, un texte... ou une date de départ ou d’arrivée ou de rappel ou de Dieu sait quoi.</p>
<p>J’ai vu cent fois le cas de dates totalement corrompues dans ces champs : la valeur est stockée dans une colonne dédiée prévue pour cela (genre <code>SEGMENT1</code>, <code>SEGMENT2</code>, ... <code>SEGMENT20</code>), qui est <em>forcément</em> une chaîne (type Oracle <code>VARCHAR2</code>). Si cela ne porte pas à conséquence pour stocker un nombre (sauf pour le symbole décimal), les ambiguïtés pour une date sont énormes :</p>
<p>- L’utilisateur peut remplir un peu n’importe quoi s’il est mal luné.<br />- Il n’est pas à l’abri d’une faute de frappe et on obtient une année 202.<br />- Le symbole de délimitation n’est pas clair.<br />- Si des Américains sont impliqués, il y a le risque de voir des dates au format MM/JJ/AAAA... (et le pire est que pour les jours inférieurs à 13, vous ne pourrez <em>pas</em> détecter une erreur.)<br />- Les années de champs remplis avant l’an 2000, voire après, risquent d’être sur deux chiffres.<br />- Si des données sont importées d’autres systèmes, ou écrites par un programme directement en base (ça se fait, sous Oracle Appli...), en contournant les filtres éventuellement en place pour éviter les cas précédents, un développeur imprudent risque de stocker dans le format par défaut de sa session, qui ne sera pas forcément celui prévu par une autre session (<code>DD/MM/YYYY</code> n’est pas la même chose que <code>DD-MON-RR HH24:MI:SS</code>). S’il n’y a pas ambiguïté pour un humain, l’ordinateur ne trouvera pas tout seul le bon format.</p>
<p>Une autre erreur est de caser les dates sous forme de chiffres (!). On peut donc tomber sur un <code>20051232</code> pour le 32 décembre 2005. Oui, ça peut arriver quand on fait des calculs sous forme <code>DateB = DateA + 1</code> comme il est si pratique avec un <em>vrai</em> champ DATE de base de données qui est fait pour ça, et que la routine de calcul est boguée.</p>
<p>Bref, je me méfie toujours des dates non stockées sous forme de champ de type <code>DATE</code> (et même : la faute de frappe qui oublie un chiffre à l’année reste possible si l’interface humaine n’est pas blindée...).</p>
<ul>
<li><strong>Il n’y a pas eu <em>réellement</em> de 30 février (bis).</strong></li>
</ul>
<p>Oui, moi aussi je l’ai cru.</p>
<p>Dans leur chaotique transition au calendrier grégorien au XVIIIè siècle, les Suédois ont réussi à créer un 30 février. Un calendrier révolutionnaire soviétique rapidement abandonné aurait eu des mois de 30 jours. Dans des modèles mathématiques, on arrondit parfois les mois à 30 jours (mais peut-on encore les nommer avec les noms habituels auxquels ils ne correspondent plus ?).</p>
<p><a href="http://fr.wikipedia.org/wiki/30_février">Voir l’article de Wikipédia pour les détails</a>.</p>
<p>(<strong>Ajout du 1er janvier 2012</strong>) Et puis tant qu’on y est dans les bizarreries : les Samoa, ayant changé deux fois de fuseau horaire et franchi deux fois la ligne de changement de date, ont eu deux 4 juillet 1892, mais pas de 30 décembre 2011. Ce genre de bizarrerie disparaît si toutes les dates sont stockées et calculées en <a href="http://fr.wikipedia.org/wiki/Temps_universel">Temps universel</a>, mais quel développeur en prend la peine dans les applications où les fuseaux horaires ne jouent habituellement pas ?</p>
<ul>
<li><strong>Il y a 52 semaines dans une année.</strong></li>
</ul>
<p>Comme il y a bien <em>toujours</em> sept jours dans la semaine depuis des temps immémoriaux, et en laissant de côté les cas des années de transition entre les calendriers julien et grégorien, on peut calculer qu’il y a
365/7= 52,14 semaines dans l’année. Donc le 31 décembre peut tomber dans un début de 53è semaine. Quoi qu’on fasse, on n’aura jamais un nombre entier de semaines dans une année.</p>
<p>Il y a un moyen normalisé de calculer le numéro de la semaine, c’est la <a href="http://fr.wikipedia.org/wiki/Numérotation_ISO_des_semaines">semaine ISO</a>. Le 1er janvier peut tomber la semaine 01 de l’année en cours, ou 52 ou 53 de l’année précédente. Le système ISO prévoit donc carrément des années différentes de longueur variable avec un nombre entier de semaines, mais ce n’est pas du tout entré dans les mœurs. En conséquence, un tableau qui affiche année civile/trimestre/mois/semaine ISO commencera à 2008/1/janvier/1 et finira à 2008/4/décembre/1. D’où <em>deux</em> semaines 1 dans l’année (civile) 2008...</p>
<p>Ce qui est rigolo, c’est que j’ai vu des différences dans le calcul de la semaine entre le monde entier et Outlook, ou entre deux versions de Business Objects (6.5 et XIR2). Je n’ai pas pu creuser, c’est peut-être lié aux paramétrages locaux.</p>
<ul>
<li><strong>Il y a toujours 24 heures dans une journée.</strong></li>
</ul>
<p>...Sauf deux fois dans l’année lors des transitions entre heure d’hiver et heure d’été... Donc de 23 à 25 heures. Et il faut éventuellement prévoir le gag d’avoir un événement à 2h59 (heure d’été) suivi d’un autre à 2h01 (heure d’hiver).</p>
<ul>
<li><strong>Une heure comprend toujours 3600 secondes.</strong></li>
</ul>
<p>Plutôt entre 3599 et 3601 : <a href="http://www.obspm.fr/actual/nouvelle/dec05/second.fr.shtml">presque chaque année, des secondes sont enlevées ou rajoutées en fin d’année pour recaler le temps universel et la rotation de la Terre</a> (tout de même la référence finale). Si dans un ERP on néglige le problème (le développeur est déjà heureux si tous les serveurs sont synchrones à la seconde près entre eux), les calculs de trajectoires de satellites doivent en tenir compte.</p>
<p>D’ailleurs le calcul temporel en orbite doit être assez folklorique puisqu’il faut même tenir compte d’éventuelles corrections relativistes (les détails sordides sont <a href="http://www.ipgp.jussieu.fr/~tarantola/Files/Professional/Teaching/Seminar/Lessons/Coll/Corrections-GPS.pdf">là</a> et <a href="http://fr.wikipedia.org/wiki/Synchronisation_GPS">là</a>).</p>
<ul>
<li><strong>Le numéro de Sécurité Sociale identifie un individu de manière unique.</strong></li>
</ul>
<p>Non, il y a même une possibilité de doublon entre des gens nés à cent ans d’intervalle au même endroit. <a href="http://fr.wikipedia.org/wiki/Numéro_de_Sécurité_sociale">Voir Wikipédia pour les détails et le passionnant historique</a>. D’ailleurs il est possible de changer de numéro de Sécu (par exemple <a href="http://transmonde.net/etre/changer_secu.htm">pour un transexuel</a> ou quelqu’un <a href="http://fr.wikipedia.org/wiki/NIR#Signification_des_chiffres_du_NIR">né dans l’Algérie française</a>).</p>
<p>Noter aussi qu’il existe des gens n’en possédant pas : étrangers, enfants... De plus, en Europe, le numéro de Sécurité Sociale est considéré comme une donnée personnelle, à diffusion restreinte et il n’est donc pas censé se retrouver n’importe où, doit être anonymisé, etc.</p>
<p>C’est un exemple fascinant à verser au dossier du débat « clé primaire arbitraire <em>vs.</em> clé primaire fonctionnelle. » (<del>J’en causerai un jour.</del> <em>Ajout postérieur</em> : <a href="https://www.coindeweb.net/blogsanssujetprecis//index.php?post/2008/05/28/403-cle-primaire-de-substitution-ou-cle-naturelle">C’est fait !</a>)</p>
<ul>
<li><strong>Les numéros des départements français ont deux chiffres.</strong></li>
</ul>
<p>...Sauf dans les DOM-TOMs ! Guadeloupe : 971 , St Pierre & Miquelon : 975</p>
<p>...Et vous avez tout faux si vous croyez que c’est du numérique (Corse : 2A et 2B).</p>
<p>De manière plus générale, la géographie offre une montagne d’aberrations diverses à toute personne
cherchant à y établir des règles. Rien que la transposition des lois votées à Paris par l’assemblée de Tahiti, ou leur compatibilité avec la loi alsacienne, donne du travail à maints juristes.</p>
<ul>
<li><strong>Un enfant a <em>biologiquement</em> un et un seul père et une et une seule mère.</strong></li>
</ul>
<p>Évidemment non.</p>
<p>Depuis quelques années il existe des mères porteuses, ce qui est autorisé dans certains pays. On peut choisir de prendre en compte la mère porteuse, ou celle qui a fourni l’ADN (qui peut d’ailleurs être une autre que celle qui va élever l’enfant), mais ce choix doit être conscient.</p>
<p>Comme dans le cas des enfants adoptés, où la filiation est modifiée par l’adoption. Selon le cadre et le but du logiciel développé (généalogie, études génétiques...) il faudra trancher, et se demander ce que l’on fait dans certains cas tordus du genre des enfants clonés (ça arrivera), ou pour <a href="http://www.rtlinfo.be/rtl/news/article/112183/--Un+homme+enceinte">un transexuel (devenu homme) qui accouche d’un enfant</a> (biologiquement c’est juste une femme qui a un enfant, mais civilement il est le père). Je prédis l’enfer informatique à cette famille, aucun logiciel n’est prévu pour gérer ce genre de cas.</p>
<ul>
<li><strong>Il n’y a que deux sexes.</strong></li>
</ul>
<p>En fait, cela dépend de ce que vous voulez faire de l’information. En tête du numéro Sécu peuvent apparaître 3, 7 ou 8 pour les transexuels et autres statuts provisoires. Pour un simple libellé de courrier, il y a trois possibilités traditionnelles (M., Mme, Mlle).</p>
<p>Dans une application pour un zoo ou un laboratoire de biologie, il faudra tenir compte des bestioles capables de changer de sexe à volonté. Sans compter les hermaphrodites comme les escargots, ou les espèces où le concept de sexe n’existe pas.</p>
<ul>
<li><strong>Tout le monde a un nom et un ou plusieurs prénoms.</strong></li>
</ul>
<p>J’ai rencontré pendant mes études un Indonésien qui n’avait qu’un nom. Je ne sais pas comment il avait rempli sa demande de visa.</p>
<ul>
<li><strong>12 > 2</strong></li>
</ul>
<p>Si vous manipulez des nombres, déclarés comme nombres auprès de l’ordinateur, oui.</p>
<p>Si vous manipulez des nombres stockés sous forme de chaînes de caractère (cela arrive tous les jours...), l’ordre lexicographique prend le pas et vous aurez tout ce qui commence par « 1 » qui sera trié avant (donc inférieur à) « 2 » : « 1 », « 10 », « 12561265463 »,..., « 2 », « 2564536 », ..., « 3 »,... Une conversion explicite en nombre peut être nécessaire suivant l’outil et le langage.</p>
<p>Je suis preneur de toute autre « règle générale qui ne l’est pas » à ajouter à cette liste !</p>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2008/04/07/466-les-pieges-dans-le-developpement#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/420Dans trente ans, encore un bug de classe « fin du monde »urn:md5:ad067a9381306867551641386b4381112008-01-19T00:00:00+00:002011-05-24T20:39:06+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000apocalypsebugcomplexitécourt termedommagedysfonctionnementhiérarchieinformatiqueperspectivepsychologietemps<p>Dans trente ans pile, le monde informatique rencontrera le <a href="http://www.2038bug.com/" hreflang="en">Bug de 2038</a> (déjà surnommé Y2K38 par référence au Y2K de 2000 ; on remarquera que l’abréviation Y2K38 est plus longue que le chiffre 2038 — snobisme quand tu nous tiens...).</p> <p>En 2000 c’était simple et compréhensible par un gamin de dix ans : les programmeurs avaient été trop bêtes ou négligents ou leurs chefs trop pingres pour caser 4 chiffres dans les dates, et il avait fallu tout corriger si on ne voulait pas que notre civilisation s’effondre. Je reste d’avis que la quasi-hystérie de certains milieux sur le sujet est la raison principale qui l’a transformé en non-événement complet. Comme un commentateur l’a écrit, un missile de croisière parti tout seul s’abîmer en mer n’aurait pas fait de dégât mais aurait marqué les esprits. Ça ne s’est pas passé, et le bug apparaît rétrospectivement comme une fausse alerte.</p>
<p>En 2038 ce sera plus délicat :</p>
<ul>
<li>le concept de date Unix codée en secondes sur 32 bits est nettement plus ésotérique pour le téléspectateur moyen, et surtout pour ses chefs non techniciens ;</li>
<li>le correctif qui consiste à tout recompiler en 64 bits aura été appliqué de manière à peu près universelle d’ici là (quand on voit qu’une machine à laver utilise des puces qui était à la pointe en 1985, on peut être optimiste), d’où paradoxalement un net relâchement de l’effort éventuel sur les dernières puces restantes ;</li>
<li>le bug sera nettement plus coton à traquer (pas de champ bêtement déclaré comme <code>ANNEE VARCHAR(2)</code>) ;</li>
<li>le nombre d’applications, de logiciels embarqués, de puces cachées... aura explosé d’ici là (il n’y a qu’à voir la progression depuis 1978...) ;</li>
<li>les programmes en Cobol qui traînent depuis 30 ans et ont dû être corrigé il y a huit à dix ans sont la preuve vivante de la longévité de nombre de logiciels. (Mine de rien, les trois systèmes d’exploitation principaux du moment (DOS/Windows, Unix, MacOS), même réécrits entre temps, ont des racines qui remontent toutes à plus de 20 ans... Du code qui tournera en 2038 existe donc déjà.)</li>
</ul>
<p>« Bah, c’est dans 30 ans ! Après moi le déluge ! » diront les développeurs de base... Justement, dans trente ans :</p>
<ul>
<li>rares sont ceux d’entre eux qui seront effectivement à la retraite pour s’en contreficher (tous ceux qui ont moins de 40 ans n’ont pas d’illusions à se faire vues les courbes démographiques…) ;</li>
<li>et la plupart d’entre eux seront de toute façon encore de ce monde (vue la progression de l’espérance de vie), donc forcément concernés.</li>
</ul>
<p>Ce qui est rigolo est que <a href="http://it.slashdot.org/article.pl?sid=08/01/15/1928213" hreflang="en">certains évoquent des problèmes liés au calcul des intérêts sur 30 ans pour certains prêts</a> (maximum légal au États-Unis paraît-il), qui apparaîtraient déjà. D’une part 30 ans n’est qu’un cas particulier, les prêts plus longs existant déjà de toute manière. D’autre part, si les banquiers corrigent le problème tout de suite, on aura largement le temps de l’oublier avant 2038... Si des industries calculent effectivement sur le très long terme, la plupart vend du « jetable ».</p>
<p>Bah, comptons sur quelques consultants pour remuer la sauce. Il devrait donc y avoir un pic d’activité des SSII entre 2035 et 2038, mais allez savoir dans quel pays en développement accéléré tout cela sera sous-traité à ce moment. En Afrique noire ? Au fond des dernières régions peu développées de Chine ? En Europe redevenue une région à bas coût ? Ou les Intelligences Artificielles s’occuperont-elles toutes seules du problème ?</p>
<p>En tout cas, notre civilisation est en régression : il y a une autre trentaine d’année, dans le passé cette fois, mon grand-père payait la dernière traite d’un prêt pour un immeuble acheté par un vague cousin ou oncle... 70 ans plus tôt !</p>
<p>Et une chose est sûre, le commis qui a calculé les mensualités n’était pas sensible à quelque bug YK que ce soit.</p>
<p><strong>Micro-bibliographie sur Internet :</strong></p>
<ul>
<li><a href="http://www.2038bug.com/" hreflang="en">2038bug.com</a></li>
</ul>
<ul>
<li><a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/03/02/92-les-bugs-qui-nous-attendent">Les Bugs qui nous attendent</a>, billet du présent blog de mars 2006 ;</li>
</ul>
<ul>
<li><a href="http://it.slashdot.org/article.pl?sid=08/01/15/1928213" hreflang="en">Discussion sur Slashdot d’il y a quelques jours</a></li>
</ul>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2008/01/19/465-dans-trente-ans-encore-un-bug-de-classe-fin-du-monde#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/419Une notation Y10K-complianturn:md5:42d2e1a9037fb23aa6f4cc686f85bf152007-01-10T11:14:00+00:002010-11-21T21:13:24+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000bugcomplexitéconquête de l’inutilehumourmathématiquesperspectivetempséonsAprès l’An 2000, il nous faut préparer à l’an 10 000, et voir encore plus loin. <p><em>(Caveat : Merci de débrancher la prise de terre de votre cerveau avant de lire ceci.)</em></p>
<p>D’une part le Bug de l’An 2000 a traumatisé certains personnes. D’autre part certains scientifiques probablement optimistes (mais allez savoir...) estiment qu’une espérance de vie de mille ans sera très vite à notre portée (je ne retrouve plus l’article) - et pourquoi pas plus ?</p>
<p>Quitte à rêver, supposons que bientôt la technologie nous permette de nous déplacer dans des nefs spatiales se déplaçant à la vitesse de la lumière entre les étoiles. Les habitants des nefs ne vieilliraient biologiquement que de quelques dizaines/centaines d’années, mais, contraction temporelle des vitesses relativistes aidant, des millénaires et plus pourraient s’écouler pendant le voyage sur Terre et ailleurs. Ceci en supposant bien sûr que la numérisation de nos cerveaux ne nous accorde pas une quasi-immortalité<sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#pnote-215-1" id="rev-pnote-215-1">1</a>]</sup>.</p>
<p><strong>Vue l’inertie et la masse de logiciels à adapter, la prise en compte d’années très lointaines en informatique doit donc commencer tout de suite !</strong></p>
<p>La <a href="http://rfc.net/rfc2550.html" hreflang="en">RFC2550 : Y10K and beyond</a> résout déjà le problème. (Rappelons que les RFC définissent le comportement des logiciels devant communiquer avec d’autres, notamment les protocoles Internet.) Elle date du 1<sup>er</sup> avril 1999.</p>
<p>Je cite :</p>
<blockquote><p>“<em>Y10K compliant programs MAY choose to limit the range of dates they support to those consistent with the expected life of the universe.<br /> Y10K compliant systems MUST accept Y10K dates from 10 ** 12 years in the past to 10 ** 20 years into the future.<br />Y10K compliant systems SHOULD accept dates for at least 10 ** 29 years in the past and future.”<br /><br />« Les systèmes compatibles An 10000 ONT LE DROIT de choisir de limiter leur espace aux dates compatibles avec la durée d’existence supposée de l’univers.<br />Ces systèmes DEVRAIENT accepter au moins les dates 10 ** 29 années dans le passé et le futur. »</em></p>
</blockquote>
<p><strong>Existant</strong></p>
<p>La RFC s’étend sur les systèmes informatique de comptage du temps déjà utilisés (décompte en secondes depuis 1970 pour Unix, valable jusque 2038 ; années sur deux chiffres insuffisantes comme démontré en 2000 ; années sur 4 chiffres ne fonctionnant pas après l’an 9999 ; années codées sur 16 bits non utilisables au-delà de 65 535...) et recherche d’autres possibilités.</p>
<ul>
<li>Coder l’année sur <strong>cinq chiffres</strong> est un pis-aller qui permettra de dépasser le bug Y10K, mais posera problème en l’an 100 000 : une civilisation qui se met en tête de conquérir notre galaxie rencontrera le Bug avant la fin de son exploration (du moins dans le cadre des lois connues de la physique, qui interdisent un voyage à une vitesse supérieure à celle de la lumière).</li>
</ul>
<ul>
<li>Des années sur six chiffres codées sur 32 bits produiraient un bug de l’an 214 749. À peine suffisant pour un aller-retour d’un bout à l’autre de la Galaxie. Mais le 128 bits deviendra vite une option raisonnable qui permettra de compter jusqu’aux environs de 17.10<sup>33</sup><sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#pnote-215-2" id="rev-pnote-215-2">2</a>]</sup> - de quoi voir venir.</li>
</ul>
<ul>
<li>Cependant il y a aussi le problème de la granulométrie. À quoi bon stocker les années si on n’a pas accès aux millisecondes ? Nous ignorons la précision que les voyages interstellaires/temporels exigeront ; aussi la RFC, dans un premier temps, descend prudemment jusqu’à la <strong>femtoseconde</strong> (10<sup>-15</sup> secondes).<br />Malheureusement, un format de date de la forme <code>YYY...YYMMDDHHMMSSmmmuuunnnpppfff</code> (notation américaine) ne permet de compter que jusque 17 billions d’années dans le futur avec 128 bits.<sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#pnote-215-3" id="rev-pnote-215-3">3</a>]</sup></li>
</ul>
<ul>
<li>De plus, on peut prévoir que la femtoseconde devrait être la durée entre deux cycles d’un Pentium® MMDCLXVI de l’an 10 000, aussi cette précision sera-t-elle vite insuffisante également. (<em>Le calcul date de 1999, et même si l’envolée des gigahertz s’est notablement ralentie récemment, le problème se posera tôt ou tard, en 20 000, 100 000 ou après ; de plus la multiplication des processeurs dans une même machine, que l’on constate déjà, rendra les impératifs de synchronisation parfaite d’autant plus sensibles.</em>)</li>
</ul>
<ul>
<li>La RFC en déduit l’inadéquation de toute représentation sur un format fixe du type <code>YY...YYMMDD...</code>. Une représentation en virgule flottante pose de nombreux problèmes classiques (arrondis...)<sup>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#pnote-215-4" id="rev-pnote-215-4">4</a>]</sup>.</li>
</ul>
<h3>Descriptions des besoins</h3>
<p>Les solutions simplistes ayant échoué, posons le problème plus posément :</p>
<ul>
<li>L’informatique et les délais de migration étant ce qu’ils sont, une compatibilité avec les anciens format de date avec année sur quatre chiffres est impérative.</li>
</ul>
<ul>
<li>L’ordre de grandeur de la date doit être reconnaissable très rapidement.</li>
</ul>
<ul>
<li>L’ordre de tri des chaînes de caractères résultantes doit suivre l’ordre chronologique (par exemple, 20070108 suit 20061231 dans le temps comme dans l’ordre de tri, au contraire de 31122006, 14102005 et 220119999 qu’on ne peut trier sans connaître et décortiquer leur format).</li>
</ul>
<ul>
<li>Le format adopté au-delà de l’an 10 000 doit être généralisable, compatible et aisément triable avec d’autres formats, même de précision supérieure.</li>
</ul>
<ul>
<li>L’âge de l’Univers est estimé au grand maximum à 20 milliards d’années, et son espérance de vie à 10<sup>11</sup> à 10<sup>14</sup> années selon que notre destin à long terme soit scellé par le <a href="http://www.astronomes.com/c6_univers/p644_univferme.html">Big Crunch</a> ou la mort thermique. Même <a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/11/19/280-pour-la-science-de-novembre-2006">s’il y échappe</a>, l’âge de l’univers est supposé rester un nombre fini.<br />Cette incertitude sur la Fin explique que la RFC spécifie que les logiciels <em>peuvent</em> se limiter à la prise en compte de dates dans cette fourchette.</li>
</ul>
<h3>La syntaxe</h3>
<p>On adopte une syntaxe en texte simple (ASCII) de la forme déjà énoncée ci-dessus, commençant impérativement par <code>YYYYY</code> après 10 000, et utilisant autant de niveaux de précision que désiré de la forme <code>MMDDHHMMSSmmmuuunnnpppfff...</code> (précision décroissante vers la droite).</p>
<p>Le problème vient que le nombre de chiffres de l’années peut lui aussi être variable selon que l’on dépasse 10 000, 100 000, 1 000 000... Il faut donc stocker l’ordre de grandeur du nombre dans la notation.</p>
<ul>
<li>Les années pré-10 000 doivent simplement se voir amendée d’un zéro préalable (<code>02006</code> pour notre année).</li>
</ul>
<ul>
<li>Les années d’après 10 000 commencent par un <code>A</code> précédant le chiffre de l’année (<code>A10000</code>...<code>A99999</code>). <br />En ASCII, le A suit le 9, donc ces années seront placées dans l’ordre lexicographique <em>après</em> les années 0...9999.</li>
</ul>
<ul>
<li>Le système s’étend aisément jusqu’à l’année 999 999 999 999 999 999 999 999 999 999 (notée <code>Z999999999999999999999999999999</code>), proche de 10<sup>30</sup>, ce qui explique que la RFC considère que les développeurs pourraient faire un peu d’effort pour implémenter la gestion des dates au moins jusque là (<em>should</em>).</li>
</ul>
<p>L’aspect pratique est évident : pour comparer l’ordre de grandeur de <code>H100000000000</code>, <code>I1000000000000</code> et <code>K100000000000000</code>, il suffit de comparer le premier caractère ; il est inutile de compter les chiffres. Les historiens de l’an 100 000 000 000 auront déjà assez de travail pour résumer la masse formidable de données à leur disposition.</p>
<h3>Au-delà de 10<sup>30</sup></h3>
<p>Les progrès de la technologie éviteront peut-être la fin de l’Univers vers 10<sup>14</sup>, et l’année 10<sup>30</sup> sera atteinte et dépassée. La notation doit être étendue si l’on veut faire un travail propre et définitif.</p>
<p>Une option naïve est de rajouter un symbole postérieur (au sens ASCII du terme) à Z, par exemple <code>^</code> : l’an 10<sup>56</sup> est noté <code>^^A100000000000000000000000000000000000000000000000000000000</code>. Deux circonflexes suffisent jusque 10<sup>732</sup>, trois jusque 10<sup>18 308</sup>.</p>
<p>En généralisant, on tombe sur un algorithme à base de suite de Fibonacci sur le nombre de <code>^</code> précédant les numéros d’années ; cette représentation est compacte.</p>
<h3>Années avant Jésus-Christ</h3>
<p>Pour maintenir l’ordre lexicographique, il est nécessaire de prendre le « complément Y10K » de l’année et d’ajouter quelques conventions de nommage décrites dans la RFC, qu’il me serait trop fastidieux de répéter ici. <br />La dernière année avant Jésus-Christ se note donc <code>/9998</code>, 9999 av. J.-C. est <code>/0000</code>, qui était précédée de <code>*Z89999</code>.</p>
<h3>Points problématiques</h3>
<ul>
<li>La comparaison de dates de divers calendriers (maya, hittite, khmer...) n’est toujours pas possible.</li>
</ul>
<ul>
<li>Ce système ne prend pas en compte une éventuelle (et probable sur le très long terme) <strong>réinitialisation du calendrier</strong> avec un nouvel an zéro (<em>Remarque : Notre calendrier a été mis en place avant l’arrivée du zéro en Occident, il n’y avait donc pas équivoque ; mais une nouvelle ère commencerait-elle par l’An Zéro ou l’An Un ?</em>).</li>
</ul>
<ul>
<li>La <strong>destruction du système solaire</strong> dans les prochains milliards d’années va compromettre la pertinence d’un décompte en jours et années terriennes. (<em>J’ajoute personnellement que si le calendrier international actuel survit à la dissémination de l’humanité sur des planètes aux calendriers tous différents, le changement d’orbite de la Terre après le début de l’agonie du Soleil posera le problème de manière plus aïgue. Cependant, dans les échelles de temps que nous considérons, on peut penser que l’homme saura préserver le Soleil dans son état actuel encore quelques quadrillions de millénaires, au moins sous une forme simplifiée utilisable pour les besoins du calendriers, ou sous forme de réalité virtuelle</em>).</li>
</ul>
<ul>
<li>La probabilité que l’Homme se retrouve seul dans l’Univers est faible ; la coordination de nos dates avec les Gaz Sapiens de la Galaxie du Sombrero ou les Microbes Pensants de l’Amas d’Ophiuchus reste une question ouverte.</li>
</ul>
<ul>
<li>Le maintien sous une forme utilisable des archives datées après la Fin des Temps est incertaine.</li>
</ul>
<h3>Détails techniques</h3>
<p>La notation ci-dessus oblige à revoir nombre de standards (MIME, SNMP, DNS...) qui se basaient naïvement sur des années à quatre chiffres. En revanche, posséder un nombre variable de chiffres dans une date évite les problèmes de <em>buffer overflow</em> exploitables par des pirates.</p>
<h3>Délais</h3>
<p>Le Bug de l’An Dix Mille se posera dans sept mille neuf cent quatre-vingt-treize ans, et même bien avant à cause des prévisions, crédits bancaires, etc. utilisant des dates futures.</p>
<p>À mon humble avis, vues l’évolution de l’immobilier, celle du recul de l’âge de la retraite, et les estimations optimistes de certains scientifiques sur les possibilités de prolongation de notre vie sur plusieurs siècles, ou sous forme numérique, les premiers crédits bancaires sur mille ans devraient voir le jour avant les années 2900. Le Bug Y10K se manifestera peut-être dans moins de six mille ans ! Il nous faut donc nous bouger ! <a href="http://www.loyd.net/y10k/index.html" hreflang="en">Certains organismes proposent déjà leurs services</a>.</p>
<div class="footnotes"><h4>Notes</h4>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#rev-pnote-215-1" id="pnote-215-1">1</a>] <em>Mais que vaut l’immortalité en tant que simple processus tournant sur un système sous-dimensionné à partager avec quelques dizaines d’autres milliards d’entités numériques ?</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#rev-pnote-215-2" id="pnote-215-2">2</a>] <em><del>Et là je déplore que Dotclear, qui propulse le présent blog, ne permette apparemment pas de gérer les exposants...</del><br /><strong>Correctif</strong> : Il faut convertir le billet en XHTML auparavant et utiliser les balises HTML habituelles. Dommage que la syntaxe wiki ne le permette pas.</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#rev-pnote-215-3" id="pnote-215-3">3</a>] <em>NB : À ce stade, nous ignorons le problème posé par la poignée de milliards d’années d’avant Jésus-Christ.</em></p>
<p>[<a href="https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#rev-pnote-215-4" id="pnote-215-4">4</a>] <em>Remarquons qu’Oracle stocke les dates sous forme de nombre représentant les jours depuis une date reculée dans le passé ; les heures, minutes, secondes sont donc représentées par la partie fractionnaire du nombre, mais on ne descend pas au-dessous de la seconde en précision.</em></p>
</div>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2007/01/10/215-une-notation-y10k-compliant#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/193Le Bug de l'An 2000 (IV) : Les bugs qui nous attendenturn:md5:e7db08a2653d4f04b1c65ae84de305892006-03-02T09:58:00+00:002010-10-26T13:50:28+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000apocalypsebugcomplexitédommagedysfonctionnementinformatiquetempséons<p>Des bugs similaires à 2000 vont continuer à frapper. Le pire sera celui de 2038.</p> <h3>Les autres Bugs qui nous attendent :</h3>
<ul>
<li><strong>2004/2005/2006</strong> : Les écoles commencent à voir arriver des élèves nés en 2000.</li>
</ul>
<ul>
<li><strong>09/09/2009</strong> : Mois, jour, année sont identiques, il est possible qu’on ait des bugs similaires à ceux du 9 septembre 1999.</li>
</ul>
<ul>
<li><strong>2010</strong> : C’est l’année prévue pour le passage de <a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/01/12/38-ipv4ipv6-i">IPv4 à IPv6 (voir mes billets sur le sujet)</a>, c’est-à-dire de l’ancienne à la nouvelle version du protocole de communication d’Internet.<br />Il n’est pas sûr que cela se fasse, même si la nouvelle version de IP permettra de lever la pénurie d’adresses IP (mal réparties dès le départ) et d’ajouter des fonctionnalités. Le parc installé étant important, la transition promet d’être rude. Certains supposent que <a href="http://www.tldp.org/HOWTO/IP-Masquerade-HOWTO/">NAT et masquerading</a> devraient suffire à jamais, ce qui rendrait la gestion du Réseau bien plus délicate...</li>
</ul>
<ul>
<li><strong>1er janvier 2010</strong> : Dépassement de capacité pour certaines implémentations de la librairie C ANSI.</li>
</ul>
<ul>
<li><strong>1er janvier 2020</strong> : Les macros Excel pèteront les plombs : 1/1/19, au moins sous les moins récentes versions d’Excel, signifie 1/1/2019, mais 1/1/20 c’est 1920... De même, les panneaux de contrôle des Macs ne permettront plus le réglage.</li>
</ul>
<ul>
<li><strong>2025</strong> (environ) : Certains prévoient une saturation des codes américains à 7 chiffres pour le téléphone et les codes postaux.</li>
</ul>
<ul>
<li><strong>1er janvier 2028</strong> : Certains programmes avec la date sur 7 bits reviendront à 0 (en fait à 1900, vu qu’ils étaient déjà revenus à 100 en 2000, et que certains se sont sans doute contentés d’ajouter 1900).</li>
</ul>
<ul>
<li><strong>1er janvier 2030</strong> : Pour le même genre de raison, certains PC sous Windows pèteront les plombs. Cette date pourra différer (2040, 2050...) selon les machines. En effet, les dernières versions de Windows permettent à l’utilisateur de choisir quelle date fera office de "pivot" entre les deux siècles (en général 2030, les dates à 2 chiffres supérieures à 30 étant interprétées comme 19xx).</li>
</ul>
<ul>
<li><strong>1er janvier 2032</strong> : Dépassement de capacité pour de vieux Macs et machines sous PalmOS.</li>
</ul>
<ul>
<li><strong>6 février 2036</strong> : Répétition du bug de 2038 avec les systèmes qui comptent les dates sur des entiers de 32 bits non signés depuis le 1er janvier 1900. (Simple décalage de 70 ans du bug de 2106).</li>
</ul>
<ul>
<li><strong>1er janvier 2037</strong> : Retour à zéro pour les serveurs <a href="http://www.crir.univ-avignon.fr/ntp.html">NTP</a>.</li>
</ul>
<ul>
<li><strong>19 janvier 2038, 3 h14 min 08 s</strong> : Les compteurs des programmes en C respectant la norme POSIX atteindront 2^31 secondes (après le 1er janvier 1970) et reviendront à zéro (ou plutôt au vendredi 13 décembre 1901, 20 h 45 min 52 sec).<br />D’ici là on suppose que tous les programmes (notamment toutes les versions d’Unix) auront été recompilés avec une date en 64 bits, ce qui devrait suffire pour 300 milliards d’années. Mais la conversion provoquera des bugs collatéraux, et il est probable que quelques-uns des millions de systèmes 32 bits actuels seront encore là en 2038.<br />(<strong>Mise à jour de janvier 2008, trente ans pile avant le bug</strong>) Selon les commentateurs de <a href="http://it.slashdot.org/article.pl?sid=08/01/15/1928213" hreflang="en">cette enfilade</a>, soit ce sera du gâteau parce que tout sera recompilé en 64 bits d’ici là, soit ce sera une catastrophe parce que ce bug sera beaucoup plus délicat (et moins médiatisé) que celui de l’an 2000.</li>
</ul>
<ul>
<li><strong>6 février 2040</strong> : Retour à zéro pour d’anciens Macintoshs et les regrettés Newtons. Encore le bug de 2036, mais calculé depuis 1904 cette fois. Apple a même <a href="http://developer.apple.com/qa/ops/ops23.html" hreflang="en">une page sur le sujet</a> (démarrer de 1904 simplifie le calcul des années bissextiles).</li>
</ul>
<ul>
<li><strong>17 septembre 2042</strong> : Retour à 0 pour de vieux mainframes IBM. Ce serait un équivalent du bug de 2036 avec des <em>updates intervals</em> à la place de secondes. Mise à jour déjà prévue pour étendre le format.</li>
</ul>
<ul>
<li><strong>1er janvier 2044</strong> : Dépassement de capacité 26 années après 1980 pour les derniers systèmes sous DOS.</li>
</ul>
<ul>
<li><strong>1er janvier 2046</strong> : Dépassement de capacité pour ce qui restera des Amiga.</li>
</ul>
<ul>
<li><strong>2050 à 2075</strong> : Dépassement du milliard pour les numéros de Sécurité Sociale américains.</li>
</ul>
<ul>
<li><strong>2048</strong> : Le vrai bug Y2K, pour ceux qui auront utilisé le même K que dans kilo-octet, qui vaut 1024 ;-) (en fait Y2Ki pour les puristes).</li>
</ul>
<ul>
<li><strong>1er janvier 2100</strong> : Beaucoup de BIOS de PC n’iront pas plus loin, si jamais ils ont duré jusque là.</li>
</ul>
<ul>
<li><strong>1er mars 2100</strong> : Première année divisible par 4 de l’ère informatique dont le 29 février ne sera PAS bissextile !</li>
</ul>
<ul>
<li><strong>7 février 2106 06:28:15</strong> : Répétition du bug de 2038 pour les machines utilisant encore des 32 bits non signés. (C’est loin ? Pensez que certains des enfants nés il y a peu verront cette date).</li>
</ul>
<ul>
<li><strong>11 avril 2262</strong> : Si le bug de 2038 est résolu avec un système à 64 bits signés, et qu’on en profite pour utiliser une résolution d’une nanoseconde, les nouveaux systèmes retourneront au 21 septembre 1677.</li>
</ul>
<ul>
<li><strong>3 mars 3333</strong> : Il existe <a href="http://developers.slashdot.org/article.pl?sid=03/12/21/1952207" hreflang="en">au moins un développeur</a> qui a admis avoir codé l’infini avec cette date.</li>
</ul>
<ul>
<li><strong>28 novembre 4338</strong> : Dépassement pour les programmes respectant la norme ANSI Cobol 85 : on est arrivé à 10^6 jours après l’origine des temps du 1er janvier 1601.</li>
</ul>
<ul>
<li><strong>31 décembre 9999</strong> : Date maximale qu’Oracle accepte, et considérée comme l’infini pour certains programmes.</li>
</ul>
<ul>
<li><strong>1er janvier 10 000</strong> : Le bug de l’an 10 000 ! <strong>Il est possible que nous nous y frottions</strong> : ce siècle pourrait voir démarrer des projets (voyages interstellaires, terraformation de Mars, enfouissement de déchets nucléaires...) qui dureront des milliers d’années. Ou nous inventerons tout bêtement les traitements d’immortalité.<br />Les éventuels programmeurs Cobol en sommeil cryogéniques seront ranimés d’urgence.</li>
</ul>
<ul>
<li><strong>19 100</strong> : Des programmes soumis à certains bugs de l’an 2000 attendront cette date pour recommencer à fonctionner.</li>
</ul>
<ul>
<li><strong>29 940</strong> : Le système de dates des Macintosh (OS 9) s’effondrera à son tour si 2020 n’a pas déjà été fatal.</li>
</ul>
<ul>
<li><strong>31 juillet 31 086</strong> : Dépassement de capacité pour les DEC VMS.</li>
</ul>
<ul>
<li><strong>586 418</strong> (à peu près) : Les vieux systèmes VAX (qui comptent sur 64 bits le nombre de microsecondes depuis 1860) feront tilt.</li>
</ul>
<ul>
<li><strong>5 000 000 ap. J.-C.</strong> : Les programmes en Java ne sont pas conçus pour aller au-delà de cette date.</li>
</ul>
<ul>
<li><strong>4 décembre 292 277 026 596 ap. J.-C.</strong> : Les programmes en C avec date sur 64 bits qui ont échappé au bug de 2038 se croiront à nouveau en 1970.</li>
</ul>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2006/03/02/92-les-bugs-qui-nous-attendent#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/97Le Bug de l'An 2000 (III) : Les autres bugs auxquels nous avons survécu.urn:md5:2962722462e8bca66fb2876e19c741842006-02-09T21:40:00+00:002010-10-26T10:51:24+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000bugcomplexitédommagedysfonctionnementinformatiquetemps<p>Entre le Bug de l’An 2000 et maintenant ont sévi quelques bugs mineurs.</p> <h3>Les autres Bugs auxquels nous avons survécu</h3>
<ul>
<li><strong>1er janvier 2001</strong> : Nouvelle erreur pour les systèmes qui n’avaient compté que 365 jours en 2000.<br />Apparemment pas de problème recensé dû à ce bug.</li>
</ul>
<ul>
<li><strong>02/01/01</strong> : Premier jour du nouveau siècle où il est impossible de distinguer mois, année, jour quand il n’y a que deux chiffres à l’année. Le problème fut sans doute plus psychologique qu’informatique.</li>
</ul>
<ul>
<li><strong>10 septembre 2001</strong> : Le <em>Billenium</em> : les compteurs de date Unix passent de 999 999 999 à 1 000 000 000 secondes depuis 1970. Quelques petits bugs très ciblés sur certains logiciels (Kmail 1.x, KNode 0.4, OpenLDAP, CVSup...).</li>
</ul>
<ul>
<li><strong>1er janvier 2002</strong> : En Europe, fin du passage à l’euro, diffusion des pièces et disparition complète du franc en quelques semaines.<br />Finalement la transition ne fut pas si terrible, à part des queues sans fin dans certaines banques, et des conversions en francs ou marks qui vont rester encore un paquet d’années dans les têtes.</li>
</ul>
<ul>
<li><strong>2004</strong> : S’ils étaient encore en service, certains vieux systèmes DEC qui comptent la date depuis 1972 sur 5 bits se sont crus revenus 32 ans en arrière.</li>
</ul>
<ul>
<li><strong>10 janvier 2004</strong> : 2^30 secondes depuis le 1er janvier 1970. La première moitié du bug de 2038 en quelque sorte. Certains éditeurs ont sorti des correctifs.</li>
</ul>
<ul>
<li><strong>29 février 2004</strong> : Première année bissextile après l’an 2000. Les corrections des algorithmes de 2000 qui croyaient 2000 non bissextile ont été mis à l’épreuve à l’épreuve ce jour-là.</li>
</ul>
<ul>
<li><strong>17-18 juillet 2004</strong> : Encore un bug potentiel de systèmes GPS arrivés à 256 semaines (8 bits) après le 22 août 1999.</li>
</ul>
<ul>
<li><strong>2005</strong> : Certaines très vieilles versions 16-bits d’Unix BSD rendent l’âme.</li>
</ul>
<p><em><a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/03/02/92-les-bugs-qui-nous-attendent">À suivre...</a></em></p>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2006/02/09/91-les-autres-bugs#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/96Le bug de l'An 2000 (II) : Le Jour du Bugurn:md5:cee86adf11b094232b644b71e014e9de2006-02-06T22:43:00+00:002014-02-26T10:33:15+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000bugcomplexitédommagedysfonctionnementinformatiquetemps<p>Le Bug a frappé, sans grand dommage, le 1er. Puis le 3. Puis le 29 février. Puis le 31 décembre.</p> <p><em>Ceci est une version allégée d’une des pages de mon site : <a href="https://www.coindeweb.net/humour/y2k.html">Le Bug de l’An 2000… et les autres</a>, qui contient notamment beaucoup plus de liens.</em></p>
<h3>Le Jour du Bug</h3>
<ul>
<li>Le fameux <strong>1er janvier 2000</strong> : Tous les logiciels dont les dates sont sur quatre chiffres et qui n’ont pas été modifiés se croient à nouveau en 1900 (pour pas mal de vieux PCs, ça sera seulement le 4 janvier 1980).</li>
</ul>
<ul>
<li><strong>Résultat</strong> : il semble que les dégâts sur toute la planète aient été très limités. <br /><br />Dans la nuit du 31 décembre au 1er janvier, les cellules de surveillance de toute la planète n’ont rien eu à signaler ; quasiment une déception.<br /><br />RAS à la SNCF, dans les banques, à Bercy (où la cellule d’alerte n’a reçu que des souhaits de bonne année) ou chez les opérateurs téléphoniques. Même Cybercable (aujourd’hui le tristement célèbre <a href="http://www.luccas.org/">Noos</a>), dont certains équipements ont été mis à jour en décembre 1999, a tenu le coup…</li>
</ul>
<ul>
<li>On signale tout de même le 1er janvier :<br /><br />
<ul>
<li>Premier endroit à passer la date du Bug, l’aéroport d’Auckland annonce au monde que tout s’est passé sans encombre - par un mail daté de l’an 100.<br /><br /></li>
<li>(Bogue indirect mais lié à l’an 2000) Le <strong>compteur de la Tour Eiffel</strong> tombe en panne quelques minutes avant le Bogue, en plein compte à rebours.<br /><br /></li>
<li>Certains compteurs à rebours commencent à afficher des <strong>temps négatifs avant l’an 2000</strong>.<br /><br /></li>
<li>Dramatique : <strong>le système informatique des pompiers de Berlin s’est effondré</strong>. <br />D’abord le système principal a planté (problème de format de dates dans un programme de synchronisation de l’heure, hâtivement rajouté, dans l’émulation d’un environnement GCOS sous AIX sous lequel tournait le programme ; cette configuration était destinée à faire passer l’an 2000 à un système vieillissant destiné à être totalement remplacé plus tard) ; son clone de secours a fait de même ; le recours à l’ancien système, avec transmission par fax, a été chaotique (manque d’entraînement et saturation).<br />Puis le système d’affichage de la position des unités dans la ville est tombé en panne (plantage dans un cas particulier après la mise à jour des cartes réseau, et suite à la saturation de celui-ci dans le contexte tendu dû aux problèmes précédents).<br />Ce fut le début du chaos, avec des unités envoyées en patrouille sans coordination.<br />(Détails : <em><a href="http://www.heise.de/ct/inhverz/search.shtml?T=anatomie+computer+gaus&Suchen=suchen" hreflang="de">Anatomie eines Computer-GAUs</a></em>, article du magazine <a href="http://www.heise.de/ct" hreflang="de">C’t</a>, numéro 2000/13 ; avec plein de détails et de leçon à tirer pour la gestion des catastrophes informatiques, et des choses à ne pas faire, comme maintenir trop longtemps un vieux système ou mettre en production au dernier moment des composants mal testés).<br /><br /></li>
<li>Autres problèmes moins critiques chez les pompiers de Hambourg.<br /><br /></li>
<li>En Suède, trois <strong>électrocardiographes</strong> sont tombés en panne, sans conséquence pour les malades (le logiciel n’est défectueux que dans sa version suédoise).<br /><br /></li>
<li>De même à Nouméa, un appareil biomédical a flanché.<br /><br /></li>
<li>Des machines à sous sont tombées en panne quelques heures dans le Delaware.<br /><br /></li>
<li>Un nombre incalculable de <strong>pages Web affichent l’année 19100, ou 4000, ou 100</strong> (y compris des pages d’entreprises très connues comme Oracle…).<br /><br /></li>
<li>Au <strong>Pentagone</strong>, le système informatique chargé de récupérer les images des satellites espions est tombé en panne deux à trois heures.<br /><br /></li>
<li>À l’usine de <strong>têtes nucléaires</strong> d’Oak Ridge (États-Unis), un ordinateur a été hors d’usage trois heures. Le reste est secret-défense.<br /><br /></li>
<li>Un logiciel de communication avec un satellite de communication militaire français a planté à cause d’un système d’alarme déclenché à tort. Sans impact opérationnel paraît-il.<br /><br /></li>
<li><strong>Saturation des réseaux téléphoniques</strong> en Nouvelle-Zélande et Australie ; pas forcément de lien avec le Bogue.<br /><br /></li>
<li>En France, ralentissement général et temporaire de l’Internet, sans lien probable avec le Bogue.<br /><br /></li>
<li><strong>Des millions de PC un peu anciens reviennent à 1980</strong> - en général il suffira de les remettre à l’heure.<br /><br /></li>
<li>Des fax se croient en 19100.<br /><br /></li>
<li>Un émulateur de Gameboy a signalé à ses utilisateurs non enregistrés que leur compte en banque était effacé parmi d’autres bugs artificiels :-)<br /><br /></li>
<li>Au Japon, trois incidents mineurs dans des centrales nucléaires, dont un seul serait lié au bogue.<br /><br /></li>
<li>Au nord-ouest de l’Iran, panne d’électricité pendant une demi-heure… due à un chat.<br /><br /></li>
<li>Île de Pâques : pas de téléphone, pas d’électricité, pas d’eau… comme avant, quoi ;-)<br /><br /></li>
<li>Flopée de bugs indirects dus à des mises en production hâtives de produits pas complètement finis, ou simplement lors d’un changement de système à l’occasion du Bug - chaque modification, même mineure, porte fatalement son lot de bugs.<br /><br /></li>
<li>Une flopée d’ignorants/imbéciles/têtes de mules/crétins finis se croient déjà au XXIème siècle, alors on le redit : <strong>LE XXÈME SIÈCLE ET LE IIÈME MILLÉNAIRE ONT FINI LE 31 DÉCEMBRE 2000, PAS EN 1999</strong> !!!!!! (Et il n’y a pas eu d’année zéro !)</li>
</ul></li>
</ul>
<ul>
<li><strong>Le 3 janvier 2000 et les jours d’après</strong><br /><br />Dieu merci, le 1er janvier était tombé un samedi, donc les programmes n’étaient pas utilisés.<br />Bien des bugs ne sont apparus que lors de la remise au travail le lundi 3. La plupart des bogues resteront cachés au fin fond des petites entreprises mais certains sont apparus au grand jour. Entre autres :<br /><br />
<ul>
<li>D’innombrables <strong>terminaux de paiement</strong> pas mis à jour n’acceptent plus les cartes de crédit. 100 000 Suédois sont privés d’opérations bancaires.<br /><br /></li>
<li>En Gambie, un système comptable gouvernemental est tombé en panne.<br /><br /></li>
<li>Un serveur de mise à jour de drivers allemand ne marche plus.<br /><br /></li>
<li>Certains personnes en Allemagne en se connectant à leur banque avec un certain logiciel se retrouvent avec des sommes de plusieurs centaines de millions de marks ; la mise à jour n’affiche plus les opérations en 2000.<br />Après coup, au moins en Allemagne, il se révèle que plus d’un logiciel (dont les très répandus <strong>QuickBooks, Quicken 2000 et Microsoft Money 99/2000</strong> !!) ont besoin de patchs pour afficher autre chose qu’une date fantaisiste. <br />L’ampleur du problème laisse pantois. Des problèmes de coordination entre banquiers et éditeurs lors de la mise à jour des pages pour l’an 2000 est sans doute à l’origine.<br /><br /></li>
<li>Un Belge s’est vu demander 16000 BEF pour n’avoir pas rendu ses livres depuis 1e 04/01/1900.<br /><br /></li>
<li>Un Allemand s’est vu crédité par erreur de 13 millions de francs, un Américain de 20 millions de dollars.<br /><br /></li>
<li>Un client de Wal-Mart (supermarchés américains) s’est vu refuser un échange de batterie achetée le 1er janvier par un ordinateur car il datait de 99 ans (heureusement il y avait un humain).<br /><br /></li>
<li>Retour au papier-crayon dans certaines administrations grecques.<br /><br /></li>
<li>À Rhode Island, 8 fausses ordonnances d’incarcération ont été données à cause de la précipitation de la mise à jour du système informatique.<br /><br /></li>
<li>Quelques utilisateurs (selon Microsoft) d’Hotmail auraient vu certains courriers redatés en 2099.<br /><br /></li>
<li>Microsoft a présenté sur son site des livres dont la date de parution était 1900, et des patchs An 2000 datant de 1970 !<br /><br /></li>
<li>On ne compte pas les autres pages, y compris chez les plus grands, affichant les dates <strong>19100</strong> (une foule de sites), <strong>100</strong> (bourse allemande, Toyota), <strong>192000</strong> (Sybase), <strong>1900</strong> (GMX), <strong>2098</strong> (Compaq), <strong>4000</strong> (Gigabyte) ou <strong>3900</strong> (Oracle).<br /><br /></li>
<li>Je reçois des mails datant de l’<strong>an 100</strong> (logiciel coupable : cette vieille m… d’elm)…<br /><br /></li>
<li>Des clients de Visa et Eurocard/Mastercard ayant fait des achats à l’étranger auraient été débité deux fois.<br /><br /></li>
<li>Un client de Quelle (l’équivalent allemand de la Redoute) reçoit en janvier une facture avec une date de mise en recouvrement en décembre 2000.<br /><br /></li>
<li>Dans la catégorie des bugs induits par la peur du bug : les <strong>disques durs de serveurs qui tournaient depuis des années</strong>, et éteints pendant le passage à 2000, qui ne redémarrent pas (le démarrage est le pire moment pour un disque dur et un ordinateur).</li>
</ul></li>
</ul>
<h3>Les Bugs à retardement</h3>
<ul>
<li><strong>29 février 2000</strong> : Pas de bol si vous croyiez vous en tirer en revenant en 1900 ou 1980. Au contraire de ces dernières, <strong>2000 est bissextile</strong> ! (pas si grave, de toute façon le jour de la semaine était déjà faux). <br /><strong>Remède</strong> : si le millésime vous indiffèrait, vous pouviez renvoyer votre machine en 1972 : le lien entre les dates et le jour de la semaine était le même qu’en 2000. <br />Dans la réalité, pas de problème majeur à part quelques 30 février par-ci par-là, la météo japonaise qui a pété les plombs, et certaines vieilles versions de Windows NT qui n’ont pas dû accepter de s’installer ce jour-là.</li>
</ul>
<ul>
<li><strong>31 décembre 2000</strong> : En Norvège, deux douzaines de <strong>trains</strong> ne redémarrent pas à cause d’un bug de l’an 2000 retardé d’un an (le 31/12/2000 avait été négligé lors des tests).</li>
</ul>
<p><em><a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/02/09/91-les-autres-bugs">À suivre…</a></em></p>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2006/02/06/90-le-jour-du-bug#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/95Le bug de l’An 2000 (I) : Avant 2000urn:md5:f5c7fadd3ece6d3ff7fa5fc1f750b3542006-02-05T16:43:00+00:002014-02-26T10:31:05+00:00ChristopheBug de l’An 2000 et d'autres tempsan 2000bugcomplexitédysfonctionnementinformatiquetemps<p>Le bug du 1er janvier 2000 était le plus médiatique et le plus méchant. Mais il n’a pas frappé qu’en 2000, et a masqué d’autres bugs de la même classe.</p> <p><em>Ceci est une version allégée d’une des pages de mon site : <a href="https://www.coindeweb.net/humour/y2k.html">Le Bug de l’An 2000… et les autres</a>, qui contient notamment beaucoup plus de liens.</em></p>
<h3>Avant l’An 2000</h3>
<ul>
<li><strong>1er janvier 1970, 1er janvier 1980</strong> : Certains programmes, parfois sur cartes perforées, ne codaient l’année que sur un chiffre… Le phénomène a eu lieu surtout en 1970, mais tout le monde n’avait pas retenu la leçon la décennie d’après.<br /><br />(<strong>Rappel de théorie</strong> : De manière générale, un tel problème de date dépend de :
<ul>
<li>(1) la date de <strong>départ</strong> ;</li>
<li>(2) l’<strong>espace</strong> octroyé pour la différence par rapport à cette date ;</li>
<li>et (3) la <strong>résolution</strong> employée.<br /><br />Le Bug de l’An 2000 sous-entend une date de base en 1900, 2 chiffres en base 10 pour la stocker, et une résolution d’un chiffre par an : il « boucle » en 2000. <br />Le système ci-dessus part de 1970, sur un chiffre en base 10, consommé un par an. <br />Le système Unix actuel part de 1970, utilise 32 bits (2^31 valeurs) qui s’incrémentent de 1 par seconde, et bouclera en 2038.)</li>
</ul></li>
</ul>
<ul>
<li><strong>1975</strong> : Premières manifestations du Bug de l’An 2000 dans les programmes qui calculaient les échéances de <strong>crédits bancaires</strong> sur 25 ans.</li>
</ul>
<ul>
<li><strong>1er janvier 1976</strong> : Les petits malins qui en 1970 avaient décidé de passer l’unique chiffre des années de décimal en hexadécimal (donc avec A=11, B=12… jusque F=15), ont vu le bug les rattraper à nouveau.</li>
</ul>
<ul>
<li><strong>Vers 1977</strong> : On rapporte qu’une vieille dame du Midwest aurait, à 105 ans, été conviée à s’inscrire à l’école.</li>
</ul>
<ul>
<li><strong>1er janvier 1978</strong> : Crash des machines qui tournaient sous OS/8 sur PDP-8 et 12. La date était stockée sur 3 bits à compter de 1970.</li>
</ul>
<ul>
<li><strong>17 août 1979 (?)</strong> : Un programme avait cette date comme<strong> indicateur de fin de fichier</strong>. Le fournisseur conseillait vivement de ne PAS utiliser le logiciel cette date ou de mentir sur la date.<br />(On notera que les fournisseurs de l’époque semblaient plus honnêtes que ceux de maintenant et n’attendaient pas que d’autres trouvent les bugs pour avertir leurs utilisateurs.)</li>
</ul>
<ul>
<li><strong>1er janvier 1980</strong> : Un programme scientifique nommé MACRO-11, sur un des derniers PDP-11, se croit en <strong>197:</strong>.</li>
</ul>
<ul>
<li><strong>4 janvier 1980</strong> : Jour Zéro où reviennent la plupart des PCs qui ont oublié leur date.</li>
</ul>
<ul>
<li><strong>13 octobre 1983</strong> : Digital répond à un appel support d’un de ses client qui se plaint que 2000 est interprété comme une année bissextile - comme quoi le problème était parfois dans l’humain, pas dans la machine….</li>
</ul>
<ul>
<li><strong>19 janvier 1985</strong> : <a href="http://groups.google.com/group/net.bugs/browse_thread/thread/64696a1b035aab72" hreflang="en">Première discussion sur Usenet sur le problème de l’an 2000</a>.</li>
</ul>
<ul>
<li><strong>4 janvier 1987</strong> : 2^29 secondes après le fatidique 1er janvier 1970 (premier avertissement pour le Bug de 2038). Des programmes en Common Lisp ont eu des problèmes de recompilation.</li>
</ul>
<ul>
<li><strong>1989</strong> : Le Japon, à la mort de l’empereur Hiro Hito, a changé d’Ère, et les dates y sont à nouveau comptées à partir de 1.</li>
</ul>
<ul>
<li><strong>31 décembre 1995</strong> : Première date qui pour certains programmes signifiait « <strong>Pas de date de fin de validité</strong> », c’est-à-dire l’infini. Arrivés à cette date certains programmes vont commencer à effacer des données qu’ils croient périmées.</li>
</ul>
<ul>
<li><strong>Mai 1997</strong> : Une base de donnée nommée <em>Advanded Revelation</em> comptait les jours à partir du 1er janvier 1970. Le passage de 4 à 5 chiffres a causé quelques bugs.</li>
</ul>
<ul>
<li><strong>1er janvier 1999</strong> : Nouvelle manifestation du 99 comme date limite. Au même moment, des centaines de millions d’Européens passent à l’<strong>euro</strong> et doivent abandonner leurs monnaies nationales.<br />Globalement, le système bancaire s’est adapté sans problème ; quelques problèmes à la Poste au tout début, et dans les taxis de Singapour en guise de bug avancé.</li>
</ul>
<ul>
<li><strong>1er avril 1999</strong> : En guise de poisson, le magazine allemand <a href="http://www.heise.de/" hreflang="de">C’t</a> annonce que des documents sur la mise en place du calendrier grégorien en 1582 ont été découverts, précisant que les années divisibles par 400 ne sont bissextiles que si non divisibles par 1000 ; 2000 n’est donc pas bissextile.</li>
</ul>
<ul>
<li><strong>22 août 1999, 0h</strong> : Des systèmes <strong>GPS</strong> ont pu se croire à nouveau le 6 janvier 1980.<br />Ce passage s’est apparemment bien déroulé car les systèmes récents tenaient compte du problème, sauf pour quelques voitures japonaises à balise GPS.</li>
</ul>
<ul>
<li><strong>9 septembre 1999</strong> : Le code <code>9/9/99</code> était souvent utilisé dans les années 80 comme <strong>date d’expiration</strong> non valide (archives permanentes). Des données risquaient donc d’être automatiquement effacées ce jour-là…<br />Vérification faite, ce problème relevait plus du canular que de la réalité. À moins que la sensibilisation sur le bug de l’an 2000 n’ait permis aussi l’éradication de ce bug au passage.</li>
</ul>
<ul>
<li><strong>31 décembre 1999</strong> : Encore une date qui comme le <code>9/9/99</code>, signifiait « Ne pas effacer », surtout dans le monde des mainframes IBM.</li>
</ul>
<p><em><a href="https://www.coindeweb.net/blogeclectique/index.php?post/2006/02/06/90-le-jour-du-bug">À suivre…</a></em></p>https://www.coindeweb.net/blogsanssujetprecis/index.php?post/2006/02/05/89-avant-2000#comment-formhttps://www.coindeweb.net/blogsanssujetprecis/index.php?feed/atom/comments/88