Sommaire
- Où l'on décide de la date de Pâques
- Bon, et Excel, dans tout ça ?
- LibreOffice Calc : la délicate position d'outsider
Bonjour Nal,
En cette période de Pâques, laisse-moi te conter une histoire.
Depuis des temps ancestraux, les hommes fêtent le retour du printemps. Pour les juifs, la fête prend le nom de Pessah. Pour les chrétiens, elle correspond non seulement au retour du printemps mais aussi (surtout) à la résurrection du Christ, rien que ça. Ce qui en fait la fête la plus importante du calendrier chrétien, bien plus que la naissance dudit Christ. Après tout, le fait qu'il soit né n'est pas ce qui le distingue (tout le monde naît un jour), mais ce n'est pas tout le monde qui ressuscite après être mort.
Il était donc crucial de fêter Pâques, et de fêter Pâques correctement.
Où l'on décide de la date de Pâques
En 325, les prêtres en vue du moment font une petite réunion d'équipe à Nicée, sur la côte d'Azur en Turquie, pour se mettre d'accord sur quelques points litigieux. C'est très ISO9001, ça s'appellera le concile de Nicée. Ils y décideront entre autres de la date de Pâques. Puisque la résurrection est réputée avoir eu lieu, selon les Évangiles, au moment de la Pâque juive, on décide de copier plus ou moins la Pâque juive. En plus, c'est cool, parce que ça permet de gommer les célébrations des juifs sous les célébrations des chrétiens, et vu qu'on n'aime pas trop les juifs, si on peut les invisibiliser, c'est pas plus mal1.
Ce cher Jules
Le calendrier en vigueur à l'époque est le calendrier julien. Il a été mis en place sous le règne de Jules César, et pour lui rendre hommage, d'ailleurs, son mois de naissance sera d'ailleurs renommé Iulius (juillet) après sa mort.
Il s'agit d'un calendrier solaire, ce qui signifie que les durées y sont calculées sur la base de la rotation de la Terre autour du Soleil. En théorie, un cycle complet correspond à une rotation complète autour du Soleil. Problème, la Terre ne tourne pas autour du Soleil en un nombre entier de jours, mais en 365,25 jours. On y décide donc que, tous les 4 ans, on ajoutera un jour intercalaire pour tenir compte de ce décalage. C'est l'invention de l'année bissextile, et par souci de simplicité, seront bissextiles toutes les années multiples de 4. C'est facile à calculer, et comme 100 est divisible par 4, on peut ne tenir compte que des deux derniers chiffres pour calculer si une année est bissextile.
Ça marche pas trop mal, mais un problème se pose à nos conciliers de Nicée : la Pâque juive est basée sur un calendrier lunaire, ou plutôt luno-solaire, avec l'ajout d'un mois intercalaire sur décision d'un groupe de prêtres. Et ça, on n'en veut pas : d'une part, ça met un boxon pas possible dans le calcul des échéances de contrats, et d'autre part, on ne veut pas confier à des humains la tâche de fixer arbitrairement une date aussi sacrée que Pâques. Pâques sera donc fixée au premier dimanche suivant la première pleine lune du printemps, soit la première pleine lune suivant l'équinoxe. Et comme mesurer l'équinoxe, c'est un poil lourd, on convient qu'il survient à date fixe (logique, puisqu'on est en calendrier solaire) : le 21 mars.
1254 ans fast forward
En 1579, on s'aperçoit d'un petit souci : l'équinoxe ne tombe pas juste. En fait, il s'est décalé de 10 jours, donc au lieu de tomber le 21 mars, l'équinoxe tombe le 11 mars. Et ça, c'est grave ! On risque de fêter la résurrection d'un Christ déjà ressuscité depuis une bonne lune ! En fait, le problème est le suivant : l'année ne dure pas 365,25 jours comme le croyaient les romains, mais 365,2425 jours. La solution est donc de supprimer quelques années bissextiles : 3 années bissextiles sur 400 disparaissent donc. C'est le calendrier grégorien, du nom du pape qui le met en vigueur : Grégoire XIII. Pour choisir quelles années bissextiles faire sauter, on décide que les années séculaires (celles dont le numéro se finit par 00) seront bissextiles si et seulement si elles sont multiples de 400. Ça supprime effectivement 3 années bissextiles sur 400.
Oh, et on efface aussi 10 jours pour rattraper le décalage. Le lendemain du 4 octobre 1582 sera le 15 octobre 1582.
Bon, autant le dire tout de suite, ça ne prend pas forcément super bien. Déjà, on est en pleines guerres de religion, il y a des catholiques, des protestants, des juifs, et en Orient, des orthodoxes, donc choisir un calendrier, c'est choisir son camp. Noter que sans ce décalage de 10 jours, la réforme aurait sans doute été nettement moins conflictuelle : après tout, elle aurait été promulguée en 1582 pour une application concrète en 1700, soit 118 ans pour la mettre en place : ça va. Mais petit à petit, les occidentaux vont s'accorder sur le fait qu'on ne peut pas laisser le calendrier dériver, et que c'est quand même pratique de ne pas avoir à faire de conversions de dates entre pays. On s'accorde donc sur le calendrier le plus précis à l'époque : le calendrier grégorien.
Il y aura d'autres tentatives de réforme calendaire : citons notamment le calendrier révolutionnaire, mais aucune n'a réellement pris.
Oh, et les orthodoxes dans tout ça ? Disons-le tout net : une réforme calendaire instaurée par un pape romain, c'est niet. Ils resteront sur leur calendrier julien. Du moins jusqu'en 1923.
Le calendrier julien révisé
Si le calendrier julien était l'azerty du calendrier, le calendrier grégorien serait le bépo, et le calendrier julien révisé serait l'Ergo-L. En effet, une année astronomique ne fait pas 365,2425 jours, mais est plus proche de 365,2422. C'est le serbe Milutin Milanković qui propose donc en 1923 un calendrier révisé : au lieu de compter comme bissextiles toutes les années multiples de 400, il propose qu'une année soit bissextile si et seulement si le reste de la division du numéro de l'année par 900 vaut 200 ou 600. Il se trouve que ça colle avec le calendrier grégorien de 1601 à 2800, ce qui est pas trop mal. C'est actuellement le calendrier qui donne la meilleure approximation de l'année astronomique.
L'auteur est serbe, il n'est pas pape, donc ça passe : la moitié des églises orthodoxes adoptent le calendrier révisé. L'autre moitié reste au calendrier julien. Point amusant : lorsque l'église orthodoxe d'Ukraine déclare son indépendance de celle de Moscou à la suite de la guerre en Ukraine, elle passe au calendrier julien révisé (alors que celle de Moscou était au calendrier non révisé). Choisir son calendrier, c'est choisir son camp.
Noter qu'en occident, on reste au calendrier grégorien, mais que ça ne devrait rien changer au cours des 774 prochaines années, donc bon. Et si les occidentaux se débrouillent bien, il n'y aura plus d'humains en 2800 pour compter les années.
Bon, et Excel, dans tout ça ?
L'algo simpl(ist)e pour savoir si une année est bissextile est de juste regarder si le millésime est divisible par 4. Après tout, il marche dans 99,25% des cas. C'est donc celui que semblent avoir implémenté les devs d'Excel. Comment le vérifier ? Facile :
- Lancer Excel
- Dans une cellule (mettons A1), entrer la date du 28 février 1900 dans la locale adaptée (en français, 28/02/1900).
- Dans une autre cellule (mettons A2), entrer la date du premier mars (01/03/1900)
- Dans une autre cellule, calculer la soustraction : =A2-A1
- Excel affiche 2, comme s'il existait un 29 février 1900.
Excel utilise le calendrier julien !
Alors on pourrait être tenté de considérer les devs Excel comme des abrutis infoutus de chercher "calendrier grégorien" sur Wikipédia. On n'aurait pas forcément tort, mais je me permets de suggérer une autre hypothèse. La première version d'Excel date de 1985. À l'époque, la rapidité d'un algo était encore plus cruciale que son exactitude dans ce qui était considéré comme un cas limite. Calculer le reste de la division par 4 de deux chiffres, c'était ultrarapide. La contrepartie, c'était une erreur de 1 jour pour une année il y a 85 ans.
Et ensuite ? Pourquoi ne pas avoir corrigé le bug dans les versions ultérieures ? Eh bien, pour la rétrocompatibilité. On peut faire beaucoup de reproches à Microsoft, mais un élément central de leurs logiciels, c'est la rétrocompatibilité : ce qui a tourné avec une version doit tourner avec les suivantes. Une fois qu'on a commencé à tourner en calendrier julien, passer en calendrier grégorien ferait buguer tout un paquet de feuilles Excel qui ont pu corriger ce bug par elles-mêmes. Il est plus sûr de garder le bug. Noter qu'Excel ne fournit pas, par défaut, de fonction qui le force à calculer en calendrier grégorien.
LibreOffice Calc : la délicate position d'outsider
Dans LibreOffice, il n'y a pas de contrainte de rétrocompatibilité. Faire le test énoncé plus haut dans LOCalc donne bien 1 : LOCalc calcule en calendrier grégorien. Mais !
- Faites le test, enregistrez votre tableur (au format ods ou autre, peu importe)
- Ouvrez-le avec Excel : le bug est revenu !
- Enregistrez-le dans Excel et rouvrez-le dans LibreOffice Calc : vous avez de nouveau la valeur 2. Y compris en forçant un recalcul des valeurs.
Autrement dit, LibreOffice ne réimplémente pas le bug d'Excel. Mais lorsqu'une feuille a été ouverte dans Excel, LibreOffice est forcé d'assurer la compatibilité… Et d'implémenter le bug. Noter qu'Excel n'a pas cette politesse : il ne tient aucun compte du fait qu'un tableur ait été ouvert (ou même créé) sous LibreOffice : même si la feuille est au format ods, il reste en calendrier julien. Y compris pour des documents créés très récemment, où la question de la rétrocompatibilité est complètement caduque.
-
Précisons à toutes fins utiles que ce paragraphe est écrit du point de vue des prêtres de l'époque. N'allez pas me prêter des pensées antisémites que je n'ai pas. Moi je voulais juste contextualiser un bug dans Excel. ↩
# Passionnant !
Posté par Serge Julien . Évalué à 10 (+13/-0).
Merci pour toutes ces informations !
Sinon :
…fallait oser, ce qui m'a inspiré le titre du présent commentaire ;-)
[^] # Re: Passionnant !
Posté par Liorel . Évalué à 5 (+3/-0).
Je n'ai pas "osé", parce que je ne l'avais pas remarqué. Mais effectivement, joli jeu de mots involontaire ;)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Passionnant !
Posté par Benoît Sibaud (site web personnel) . Évalué à 10 (+15/-0).
Et si la parole de l'auteur est crue, s'y fier.
[^] # Re: Passionnant !
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+0/-0).
Et que faire si elle est cuite ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Passionnant !
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
au plat ou en omelette pascale ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Passionnant !
Posté par sebas . Évalué à 2 (+0/-0). Dernière modification le 25 avril 2025 à 13:10.
Ça pourrait être un dicton qui couronne des p… Oups, non, rien…
# Rétrocompatibilité à nuancer tout de même.
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 2 (+3/-3).
À chaque passage de version, j’entend des romuliens râler sur leurs périphériques et logiciels qui ne fonctionnent plus. Pas vous ?
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Rétrocompatibilité à nuancer tout de même.
Posté par groumly . Évalué à 4 (+3/-1).
Non.
[^] # Re: Rétrocompatibilité à nuancer tout de même.
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
Surtout que la dite rétrocompatibilité est souvent du flan qui ravi les fans
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Corruption ISO
Posté par Benjamin Henrion (site web personnel) . Évalué à 10 (+20/-0).
Grâce au rachat des organismes de standardisation ISO par Microsoft, on arrive a même mettre tout ça dans un standard ISO, c'est dingue ce qu'on arrive à faire quand on a de la thune.
https://linuxfr.org/news/open-xml-en-force
"Certaines propositions d'OOXML sont purement et simplement des reprises de bugs dans la suite Microsoft Office. Par exemple, OOXML demande que l'année 1900 soit considérée comme bissextile, entrant en contradiction avec toutes les normes actuelles sur la représentation des dates ;"
# Un peu d'espoir ....
Posté par totof2000 . Évalué à 8 (+8/-2).
Ca donne un peu d'espoir pour l'adoption d'IPV6 …
Par contre je ne pense pas qu'on se mettra tous d'accord de la même façon sur l'adoption d'un environnement desktop unique sur Linux … Mais peut-être arriverons-nous à s'accorder sur le meilleur éditeur qui soit : VI.
[^] # Re: Un peu d'espoir ....
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Oh vii
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Un peu d'espoir ....
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1 (+0/-1).
Oh vii
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Volontaire ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10 (+8/-0). Dernière modification le 25 avril 2025 à 09:43.
En 1985, je ne sais pas ce qu'on avait comme ordinateur, mais on parle de calculer le reste de la division par 4, le reste de la division par 100 et le reste de la division par 400. Le nombre de chiffres du numérateur a, je pense, peu d'importance puisque je doute que les ordinateurs en question calculent en décimal.
Je veux bien entendre que trois divisions euclidiennes, c'est trois fois plus long qu'une seule, mais on parle d'opérations à peu près instantanées, même sur les calculatrices de poche de l'époque non ? Sur une pascaline, je ne dis pas, mais sur un PC de 1985 quand même…
[^] # Re: Volontaire ?
Posté par Liorel . Évalué à 6 (+4/-0).
Tu oublies les 10 jours à faire sauter, et le fait de repasser en calendrier julien avant 1582. Et certaines opérations sont plus longues, comme calculer le jour de la semaine du 14 février 1435 (pas d'autre choix que de compter le nombre total de jours depuis une date de référence puis calculer le reste de la division euclidienne par 7).
Mais l'un dans l'autre, tu as probablement raison, d'où le fait que je ne fasse que "suggérer" l'hypothèse. Il est très possible que les devs soient juste des abrutis qui se sont condamnés à vivre avec un bug ad vitam æternam. Et surtout, Excel n'est pas un LL, donc on n'aura jamais accès à un bugtracker où les devs discutent du pourquoi du bug et des moyens de le résoudre ou des raisons de ne pas le faire.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Volontaire ?
Posté par Renault (site web personnel) . Évalué à 8 (+5/-0).
Après Excel comme tout tableur a été conçu avant tout comme un outil pour gérer de la comptabilité.
Gérer des dates aussi loin dans le passé n'était probablement pas dans leurs préoccupations initiales.
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
C’est marrant un outil pour gérer la comptabilité qui propose la gestion des dates mais mal… Et aussi on entend dire que ça roule le monde entier.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par Renault (site web personnel) . Évalué à 4 (+1/-0).
On voit que dans le cas présent le problème ne se manifeste que si tu manipules des dates anciennes ou très lointaines dans le futur.
Une comptabilité ne va probablement jamais manipuler de telles dates avant des siècles. À l'époque cela devait vraiment être une considération secondaire et même aujourd'hui pour ce cas d'usage l'impact reste marginal.
Après oui les tableurs ont un champ d'utilisation plus large, où l'impact peut être réel cette fois, mais ce n'est probablement pas le cas le plus courant. Et à l'époque cela n'avait pas été conçu ainsi.
[^] # Re: Volontaire ?
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
Ce n'est pas ce que j'en ai compris. Enfin, lointaines, oui, mais pas autant que tu l'imagines.
Pas des siècles. Pas même un siècle. Des décennies, oui.
Si j'ai bien compris, parmi ce qui n'est pas correctement géré, il y a les années 1900 et 2100 qu'Excel considère comme bissextiles alors qu'elles ne le sont pas.
Ça laisse présager un bug de l'an 2100, même si c'est effectivement assez lointain.
[^] # Re: Volontaire ?
Posté par Liorel . Évalué à 5 (+4/-1).
2100, dans certains domaines, c'est demain. Pour des prêts à 100 ans ou des baux emphytéotiques, l'erreur a déjà un impact.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Voilà ! Autant les dates passées je peux comprendre (encore que toutes les implémentations qui ne veulent pas se prendre la tête partent plus ou moins de l’année du calendrier grégorien ou celle d’après) mais juger que des dates futures sont trop lointaines ressemble à de l’obsolescence programmée.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -2 (+4/-7).
Personne ne va utiliser Office 2016 en 2100, si quelqu'un est encore en train d'utiliser Excel 2016 en 2095, il aura encore 5 ans pour s'occuper de gèrer le problème, et si Excel 2095 est un produit qui existe, il aura probablement un workaround pour gèrer cela.
Bref, comment faire une montagne d'un trou souris…
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
C’est exactement ce que je dis : ils ont du se dire chez ms que leur tableur ne sera plus utilisé avant l’année bissextile suivante ou celle d’après.
Ou alors tu es en train de nous dire que Office 2020 va abandonner la compatibilité avec Office 2016 ? Et aujourd’hui les gens font déjà des contorsions pour un usage correct (donc des workaround déportés chez les usagers.) Bref, comment continuer à mettre son éléphant sous un tapis…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -2 (+2/-5). Dernière modification le 25 avril 2025 à 17:43.
En disons 2090, si Microsoft et Excel existent encore, ils se poseront autour d'une table et réfléchirons au meilleur moyen de gèrer le problème. Il y a plusieurs approches possible et selon la situation à ce moment ils regarderont quel genre de mode de compatibilité ils ont besoin.
Mais il n'y a aucun sens à discuter de ce problème aujourd'hui, il ne va affecter personne avant 70 ans.
Bref, Excel 2020, 2024 … 2088 n'auront aucun problème, et peut-être que 2092 aura quelque chose, ou pas, on n'en sait rien.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 10 (+9/-0).
Le problème de cette approche c’est quelle rend l’outil que t’es entrain de créé limité par design. Ce n’est pas parce que tu n’imagine pas quelque chose que ça n’existe pas.
Pourquoi est-ce que ce serait une mauvaise idée de travailler les données du début du siècle dernier à part le fait que MS est trop bon en rétrocompatibité pour payer ces dettes techniques ?
C’est juste bête. Ça ne va pas leur faire perdre de l’argent. C’est juste la différence entre un travail fait pour être bon et un travail à minima où non seulement on bâcle la conception, mais on refuse de le corriger parce que ça coûte trop chère de corriger le travail fait à la rache.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -1 (+3/-5). Dernière modification le 25 avril 2025 à 18:06.
Tout est question de priorité, que demandent les clients ?
Est-ce que c'est quelque chose que la plupart des client veulent, ou quelque chose qui les met en danger, etc… ? Non ? Alors est-ce vraiment si important aujourd'hui ou vaut il mieux mettre la priorité ailleurs ?
Une simple question de management de projet comme dans tout autre projet software. Si on te mettait comme project manager de Excel demain et que tu avais devant toi la liste de toutes les choses à faire, ce serait loin d'être la priorité.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 8 (+8/-2).
A oui c’est les ressources limitées de Microsoft avec les moyens très réduits donné à l’unique développeur, les utilisateurs se sentaient en danger sans Clippy.
Ou alors c’est un bug qui leur en touche une sans faire bouger l’autre à tel point qu’ils se sont même pas posé la question au moment de faire ooxml.
C’est bien ce que je dis. Si tu ne montre pas ce que ça peut apporter comme abonnement rien à faire de nettoyer sa dette technique.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -2 (+2/-5).
Oh mais si seulement c'était si simple !
Les dates dans Excel sont utilisées par des centaines de millions d'utilisateurs.
Faire un changement amène toujours un risque de régression. Si Aujourd'hui ils essaient de faire ce changement ils prennent le risque d'affecter négativement ces millions d'utilisateurs. Pour quel bénéfice en retour ? Quasiment rien, 3 pekins à qui cela pose problème.
Oublie l'argent, d'un point de vue satisfaction du client corriger ce truc maintenant n'est absolument pas la bonne chose à faire.
En 2090 quand ce problème sera vraiment un problème pour une grande partie des utilisateurs la donné sera différente mais aujourd'hui cela n'a aucun sens.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 10 (+9/-0).
Comme tout changement pourtant ils arrivent encore à travailler.
Une dette technique ne s'efface pas avec le temps, elle s'alourdit. Si vraiment ils trouvent que c'est trop dangereux aujourd'hui, ils ne la corrigerons jamais. Ce n'est pas la complexité intrinsèque le problème, c'est l'envie de le faire.
Encore une fois ils avaient l'occasion de corriger facilement avec ooxml ils ne l'ont pas fait.
C'est bien ce que je leur reproche. Ils se foutent de la qualité de leur produit tant que ça se vend. C'est une logique assez répendue, mais ce n'est pas pour ça que je trouve que c'est une bonne choses.
Ce qui les empêche de le faire ce n'est pas de la compatibilité ou les risques pour les utilisateurs, ça c'est leur travail et ils gèrent ça quotidiennement, c'est la volonté de s'en occuper.
Ce n'est pas MS qui la mort dans l'âme s'empêche de corriger des bugs pour protéger ses utilisateurs de problème de compatibilité, mais MS qui en a rien à faire d'un bug si tu montre pas que ça fait fuir suffisamment d'utilisateurs
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -3 (+1/-5).
La réalité est que comme partout ailleurs il y a plus de travail que de gens pour le faire, du nouveau boulot apparaît tout le temps, et il y a une priorité à mettre aux tâches.
La manière d'assigner une priorité aux tâches, comme partout, est liée à ce que les clients veulent, aux problèmes opérationnels, à la complexité et au risque des changements, etc…
La réalité est que ce truc est mineur, il m'emmerde quasiment personne. Le corriger présente un risque potentiel, et vu qu'il n'emmerde quasiment personne le bénéfice en retour du risque est négligeable pour la base utilisateur.
Tu appelles cela dette technique, oui effectivement, mais c'est loin d'être le seul problème dans cette catégorie et celui ci, comme expliqué au dessus, n'a vraiment pas la priorité.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 7 (+6/-1).
Je ne comprends pas ce que tu veut. Je dis que trainer cette dette technique montre selon moi qu’ils ne sont pas piloté par la qualité de leur produit. Tu me dit que oui mais bon c’est pas la priorité.
Tu ne fais que me répéter des choses que je sais déjà et qui sont la raison de mon avis.
En 40 ans ils ont trouvé le temps de faire un paquet de choses, mais rien pour gérer cela (même pas en optin, même pas une détection du problème pour avertir, même pas une gestion de calendrier pour pouvoir dire qu’ils gèrent par la même occasion le calendrier chinois,…).
Une équipe qui a des moyens considérables sur plusieurs décénies et qui laisse trainer ce genre de bug montre un intérêt limité pour la qualité de ce qu’ils livrent.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -5 (+1/-7).
Mais bien sûr qu'ils ont la qualité comme priorité mais la qualité c'est quoi ?
C'est répondre aux attentes des utilisateurs. Les utilisateurs veulent évidemment un produit stable, qui donne des résultats corrects, une UX agréable, des performances acceptables, un produit sûr, avoir les features qu'il faut, etc..
La qualité ce n'est pas résoudre des bugs qui n'affectent quasiment personne au détriment des choses ci dessus
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 8 (+6/-0).
Ça c'est une hypothèse avancée sans argument. C'est mes parents généalogistes amateurs qui m'ont décrit le problème. C'est quelque chose de connu dans ces communautés. Je présume que c'est aussi un fait qu'on apprend si on fait des études d'histoire.
Le mode de distribution d'excel et sa popularité rend cette hypothèse très délicate. Il y a potentiellement un biais du survivant.
Ce n'est pas le cas du coup.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -3 (+1/-5).
Poses toi la question de combien de gens cela représente dans le monde d'Excel comparé à la population d'utilisateurs.
C'est très clairement une toute petite minorité.
[^] # Re: Volontaire ?
Posté par Computer (site web personnel) . Évalué à 2 (+2/-0).
Loin de moi l'idée de défendre Microsoft (c'est de la daube on est bien d'accord). Mais dans le monde Unix les informaticiens ont bien merdé aussi.
Heure Unix.
Sur ce genre de sujet, qui passe à tort pour trivial, les informaticiens ont tendance à surestimer leur compréhension.
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 5 (+3/-0). Dernière modification le 27 avril 2025 à 19:38.
…dans quel sens ? Si c’est par rapport à la seconde intercalaire, je cite Wikipedia : « Depuis 1986, l'UTC est défini par la recommandation 460-6 de l'UIT-R : son objet est l'usage calendaire civil en se basant sur une mesure scientifique précise du temps. […] L'instabilité de TAI est plusieurs millions de fois plus faible que celle de UT1 liée à la Terre. C'est pourquoi l'UTC est aligné par rapport au TAI depuis 1972, plutôt qu'à l'UT1 comme c'était précédemment le cas depuis 1961. »
Le système est né avant (1970) son invention (1972) : compter les secondes est ce qui se faisait de mieux et de plus simple (on pouvait tenter de descendre aux dixièmes ou centièmes de secondes mais sans garantie sur toutes les plateformes où ce serait porté). Par la suite, la seconde intercalaire a été prise en compte car des applications critiques tournent sur le système (la démarche est donc à l’opposé de ce qui est dénoncé ici : s’en foutre et prétendre vouloir préserver la compatibilité boguée)
On est bien d’accord que de nos jours (en fait depuis les années 80 ou 90 selon le cas) on ne doit plus réinventer la roue dans les applications, mais s’appuyer sur les bibliothèques qui mutualisent les travaux d’experts.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Un bien bel article, mais hardu à lire en fin de soirée :)
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 2 (+1/-1). Dernière modification le 28 avril 2025 à 08:11.
Je suis pas sûre de savoir le problème (la seconde intercalaire ? la limite de taille de
t_time? la précision à la seconde ?), mais mon problème n’est pas qu’ils aient fait une erreur mais qu’ils ne fassent rien pour l’adresser. Je ne connais aucun OS de type unix qui ne gère pas correctement tous ces problèmes.Et c’est justement une bonne raison pour ne pas laisser des bugs trainer dans les outils.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par Computer (site web personnel) . Évalué à 3 (+3/-0).
Plus rapidement : la mesure du temps est maintenant calée sur des horloges atomiques car c'est ce qu'il y a de plus précis (c'est le TAI¹). Mais dans la vie de tous les jours on veut quelque chose qui soit plus ou moins calé sur la rotation de la terre et sa révolution autour du soleil (c'est UT1 et notre calendrier de manière plus générale), parce que c'est quand même plus pratique…
Le temps UTC est une mesure bâtarde entre les deux : il est calé sur UT1 tout en garantissant l'absolue régularité de la seconde du TAI (on a le meilleur des deux mondes). Pour arriver à ce résultat il faut de temps à autre rajouter une 61ème seconde (on a donc h:m:60 tout à fait légal, 2 fois par an), la seconde intercalaire.²
Le problème Posix est qu'il se cale sur UTC, mais ne représente pas l'heure sous la forme h:m:s, mais d'un unique nombre (donc impossible de rajouter cette fameuse seconde intercalaire). Il y a plusieurs solutions possibles pour résoudre le problème³ mais rien n'a été fait.
--
¹ La conservation de l'énergie (l'une des plus importantes loi de la physique) est directement déductible de l'invariance par translation du temps. En ce sens le TAI est le seul temps physique qui vaille.
² À noter que le cycle solaire connaît des variations plus importantes (±15 min. de souvenir) mais ces variations sont elle-mêmes cycliques (elles s'annulent au bout d'un an), et seule la dérive sur le temps long est prise en compte. UT1 est un temps lissé, ne subsiste que la dérive sur le temps long.
³ http://www.madore.org/~david/computers/unix-leap-seconds.html, donc non dans certains cas d'applications "faire confiance à la lib. écrite par des experts" n'est pas la bonne stratégie. Dans le même genre je ne compte plus la multiplication de l'usage des flottants en lieu et place des décimaux pour représenter des éléments de comptabilité…
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 5 (+3/-0).
Ça l’est sauf quand gérer le temps fait parti de ton travail. Par exemple parce que tu as des besoin de précision important, mais ça peut aussi être parce que tu fais des opérations non triviales (multi calendrier par exemple) mais dans ces cas là tu es sensé savoir ce que tu fais. Gérer les dates antérieures à 1900 ne me semble pas en faire parti. Pour les dizaines de milliards d’utilisateurs d’Excel qui activent toutes les optin qu’ils trouvent et font des arrêt cardiaque quand ils voient un message, assumer que savent ce qu’ils savent ce qu’ils font au sujet des dates me semble pas une bonne idée.
POSIX a un certains nombre de problèmes dont des plus graves que ça et oui c’est un problème, mais justement ceux qui doivent sortir des logiciels (et pas juste des PDF) ne s’interdisent pas de traiter ces problèmes sous prétexte que ça prend pas 5 minutes et que oulala… c’est compliqué.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par 2PetitsVerres . Évalué à 4 (+2/-0).
Pas nécessairement deux fois par an (ce n'est arrivé qu'une fois en 1972). C'était souvent une fois par an, maintenant plutôt 0. Et le système prévoit également :
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 1 (+0/-1).
Hmm…
Comme dit le premier lien que tu as pointé dit bien que UTC est aussi un décompte de secondes… « Autrement dit, UTC est identique au TAI (il en a la stabilité et l’exactitude) à un nombre entier de secondes près, et les secondes intercalaires lui permettent de coller à UT à 0,9 s près » puis « […] Une différence de deux heures UTC permet de calculer un délai écoulé de façon exacte tant que les deux événements ne sont pas à cheval sur une seconde intercalaire (voir ci-dessous la probabilité et l'amplitude de l'erreur). Pour calculer un délai exact en toutes circonstances, il faut tenir compte des secondes intercalaires. » (ce qui est exactement le même souci que tu déplores avec POSIX)
Mais, mais, je lis par ailleurs en effet que « Le “temps UTC” ne doit pas être considéré comme un compteur de secondes mais plutôt comme un compteur en plusieurs morceaux nommés “secondes (tm_sec), minutes (tm_min), heures (tm_hour), jours depuis le 1er Janvier de l'année (tm_yday) et années calendaires moins 1900 (tm_year)”, chacun étant représenté par un entier. »
Et même, est-ce vraiment la source du problème ? Dans le premier lien, on voit bien que TAI est représenté par un unique nombre (et on comprend qu’il en est de même pour UTC pour pouvoir faire « TAI - UTC » non ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par groumly . Évalué à 5 (+3/-0).
Quand t’es à l’echelle d’excel et que ta base d’utilisateurs c’est des centaines de millions de personnes, et des sheet legacy de 1997, le concept de qualité devient variable.
En l’occurrence, qualité veut aussi dire “ne pas casser de façon silencieuse une spreadsheet vieille de 10 ans”, et “ne pas créer d’ambiguïté dans la base utilisateur à propos de la gestion des dates”, à savoir qu’on a maintenant 40 ans de littérature qui parlent de ce bug en long en large et en travers, le corriger veut dire rendre toute cette documentation fausse, mais seulement à partir d’une certain version.
bref, le problème de la qualité va un peu plus loin que “les dates sont pas correctes partir de 2100”.
(Tiré d’un commentaire plus bas). lol, c’est un peu l’hôpital qui se fout de la charité, la quand même. Toi non plus, t’as pas d’arguments, à part l’anecdote de tes parents.
Je sais bien que MS n’a pas la cote par ici, mais c’est un peu gonflé de sortir ça, et ensuite prendre la position que les PM d’excel, le tableur de référence qui a dominé la planète pendant 30 ans (et qui fait tourner doom, soit dit en passant), sont incompétent au point de ne pas être capable d’évaluer les ramifications de corriger ce problème. T’as déjà travaillé sur un produit vieux de plus de 10 ans, avec une échelle à peu près correcte? Ce genre de problème est très courant, et la réponse la plus rationnelle est malheureusement souvent “ouais, ça craint, et on passe un peu pour des mickeys, mais objectivement, c’est loin d’être le truc le plus important à faire la maintenant tout de suite”.
Est ce que MS aurait dû copier ce bug en 85? C’est honnêtement dur à dire, peut être, peut être pas.
Est ce qu’ils auraient dû le corriger 5 à 10 ans plus tard? Peut être, probablement, ou probablement pas. Ca aurait potentiellement coûté une feature que les utilisateurs d’excel trouvaient plus importante.
Par contre, ce qui me parait clair, c’est que 40 ans plus tard, ça devient extrêmement difficile de corriger le problème. Ce qui, je suppute, a lourdement pesé dans le balance de la décision du program manager d’excel, qui, croit le ou non, est a priori plutôt compétent, et acces à beaucoup plus d’informations que toi.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 3 (+2/-1).
Les 2 seules choses que je dis c’est :
Si pour vous garder des bugs qui empêche des usages légitimes de logiciel c’est OK ne soyez pas surpris qu’on dise que vous ne faites pas un travail de qualité.
En y réfléchissant 10 minutes je trouve plusieurs façons de l’adresser. Je n’ai aucun doute sur le fait qu’ils sont bien plus compétents que moi et que ce n’est qu’une question de volonté. Tu parler de la littérature au sujet de ce bug (qui doit être assez creuse vu qu’à part dire qu’il existe il n’a pas de solution de contournement), on a 1000 fois plus de contenu sur la conduite du changement.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -1 (+1/-3).
J'ai vu plus bas 2-3 hypothèses que tu as données pour une solution.
Tu as évalué leur effet sur le fonctionnement interne d'Excel, les risques que ces changement poseent, sur ce que cela impliquerait potentiellement pour les utilisateurs existants et leur feuilles de calcul, … ?
Tu ne te rend visiblement pas compte que c'est un truc très sensible, à appréhender très soigneusement, parce que si ils se loupent, cela peut avoir de sérieuses conséquences vu l'utilisation énorme d'Excel par exemple chez les groupes financiers et autre.
Ensuite, ils ne veulent certainement pas compliquer l'expérience utilisateur pour tout le monde juste pour ce truc.
Bref, non, c'est loin d'être simple. Et tout cela, pour une infime minorité de gens.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 5 (+4/-1).
Mettre un warnings c’est le danger absolu ? Maintenant une bonne part de leurs utilisateurs sont en version web, tu va me dire qu’ils ne font pas de feature flip et canary release ? Un optin ça casse quoi à qui ?
C’est une API et oui ça se gère on l’a tous fait. Ça doit être fait avec sérieux, mais ça se fait très bien faut arrêter de sortir des arguments d’autorité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à -2 (+1/-4).
Mettre un warning que tout le monde voit (parce que tout le monde à peu près utilises des dates) c'est un problème ENORME , parce que quand tu parles de disons 300 million d'utilisateurs, ca te fait 3 millions de gens qui appellent le support, qui paniquent, … au minimum par exemple. Cela fera un certain nombre de gens qui choisiront la mauvaise option quand tu as un optin, etc…
Non vraiment, tu ne te rends pas compte de l'impact qu'un changement a sur des plateformes de cette taille. Excel n'est pas un soft qui change à vitesse grand V, et pour une bonne raison.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 6 (+5/-1).
Pardon mais c’est pas crédible. Si tu trouve que garder des bugs c’est la meilleure chose à faire et que si t’arrive avec un peu de mauvaise fois à trouver des problèmes à mes quelques idées griffonnées c’est bien qu’il est impossible de faire mieux. Ça ne me dérange pas de passer pour un extra terrestre à tes yeux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par pasBill pasGates . Évalué à 0 (+1/-2).
Je n'ai dit nulle part que c'est impossible à règler. Je te dit depuis le début que :
a) ce n'est pas aussi simple que tu le penses à règler
b) cela pose des risques à considèrer, à mitiger
c) cela ne se fait pas en 5 minutes
Et que ces paramètres là font que dans l'ordre des priorités, au vu du bénéfice à en tirer pour la population d'utilisateurs qui est très faible, ben ce n'est pas du tout en haut de la liste des priorités.
Tu insistes à croire qu'ils ne le font pas car ils s'en foutent, sans chercher à comprendre comment ils prennent leurs décisions, en croyant que tes 3 options imaginées en 5 minutes sont simples et pourraient vite être implémentées si seulement ils n'étaient pas des braneleurs et voulaient avoir un produit de qualité.
Je te le redis, si demain tu étais le project manager d'Excel, avec tous ces critères à gèrer, tu prendrais exactement la même décision qu'eux.
[^] # Re: Volontaire ?
Posté par Liorel . Évalué à 6 (+5/-1).
Après ça dépend vraiment de plusieurs paramètres :
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Volontaire ?
Posté par Dring . Évalué à 4 (+2/-0).
Alors sur le fait qu’utiliser Excel pour des choses sérieuses c’est pas bien et qu’il faut utiliser son SI : oui mais dans la vraie vie Excel est utilisé partout et tout le temps pour pallier aux manquements du SI, que ce soit en termes de fonctionnalités ou de vélocité à livrer. Voire pour contourner les bugs du SI.
Les dates sont stockées comme des flottants : la partie entière représente le nombre de jours écoulés depuis un point de départ (genre 1er janvier 1901 - pas l’EPOCH donc) et la partie décimale représente une fraction de la journée (donc 0 c’est minuit, et 0.5 c’est midi).
C’est pas mal dans le sens où cela permet de faire de l’arithmétique assez facilement sans passer sa vie à faire des conversions. En compta ou en finance, on a généralement rien à foutre de la notion d’heure.
Et les historiens peuvent faire comme tout le monde : quand le format « date » les fait chier, ils stockent leurs dates en texte ou en nombre. Excel n’a clairement pas été pensé pour eux, mais Excel est l’outil le plus détourné de l’univers connu et inconnu.
[^] # Re: Volontaire ?
Posté par 2PetitsVerres . Évalué à 2 (+1/-1).
Tous les outils sont limités par design. Il n'existe pas aujourd'hui d'outil universel capable d'effectuer toutes les tâches, et si tu veux en créer un, bonne chance.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
Donc ne créons des outils que pour un seul usage et surtout ne corrigeons pas les bugs si l’usage ne semble pas digne d’intérêt. Ce serait dommage que des utilisateurs s’imagine qu’on fasse les logiciels pour eux.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par totof2000 . Évalué à 2 (+1/-1). Dernière modification le 29 avril 2025 à 02:50.
Ca s'appelle Unix, avec un tas de petits outils qui font peu de choses mais qui le font bien.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
C’est quoi l’unique chose que le bourn shell fais ? C’est quoi l’unique chose que fait awk ? L’outil pour dédupliquer c’est unique, pourquoi sort a l’option -u ?
Cette phrase est souvent très mal utilisée. L’idée c’est de ne pas ajouter des features trop orthogonales pour ne pas avoir bloat le logiciel, mais ici l’outil a déjà une gestion de date.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par totof2000 . Évalué à 2 (+0/-0).
Le shell ne fait rien, il faut faire. Awk fait du traitement de texte formatte en colonnes. "Faire une seule chose" ne signifie pas être minimaliste ( il n'y a qu'a lire la quantité de pages de man de awk pour s'en convaincre) : ça veut juste dire ne pas chercher à se disperser et vouloir tout faire avec le même outil.
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 1 (+0/-1).
Du coup ton point c’est qu’un tableur ne devrait pas gérer de dates ou que’Excel gère bien les dates ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par totof2000 . Évalué à 2 (+0/-0).
Je n'ai jamais dit ça, j'ai juste dit que ton argument ironique "ne créons des outils que pour un seul usage" n'est pas forcément pertinent dans le débat. Je voulais jute relever que cette approche existe (l'approche unix est un exemple). Est-ce mieux ou moins bien ? Aucune idée. Ce sont juste deux approches différentes : l'approche "couteau suisse" ou tu as un outil polyvalent, et l'approche outil spécialisé qui sera un peu moins polyvalent mais qui fera ce qu'il fait mieux que le couteau suisse dans beaucoup de situations. Après le débat "ouil Excel gère mal les dates" je m'en fous un peu …. Je déteste excel : non pas l'outil en lui même (bien que je trouve les interfaces "modernes" à la microsof inutilisables - pas seulement pour Excel mais pour toute leur suite… on n'y retrouve plus rien), mais surtout parce qu'on a tendance à l'utiliser un peu trop là ou une base de données (ou autres outil) serait plus efficace. Et si un jour j'ai besoin d'un outil qui traîte es dates correctement, j'utiliserai LibreOffice (ou un autre tableur).
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 0 (+0/-2).
Non ça n’a rien à voir. Cette philosophie n’est pas là pour faire des logiciels opiniated au point de laisser des bugs trainer ainsi parce qu’ils ne toucheraient que des utilisateurs qui font des choses jugées pas intéressantes.
C’est une approche d’achitecture qui consiste à privilégier le découpage à l’ajout builtin de fonctionnalité. Ici il pourrait s’agir de déléguer cette partie à un autre logiciel qui, pour respecter le reste des principes unix, devrait avoir une API texte via stdin/stdout.
Mais c’est vraiment une règle qui n’a jamais était respectée à la lettre. Le nombre d’outils de base qui sont turing complete, la quantité de fonctionnalités qui sont implémentées plusieurs fois,… Rien que par exemple pourquoi tous ces outils ont implémenté la manipulation de fichiers ? Ils auraient pu laisser ça au shell qui est fait pour et qui le fait bien. Elle est extrêmement subjective (elle dépend beaucoup de l’échelle à la quelle tu te place) et n’est pas une règle incassable. Par exemple l’option -u de sort est faite parce que filtrer avant le pipe peut économiser pas mal de ressources.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Ça tombe bien, le mois dernier on m’a remonté un script qui plantait en reportant ne pas connaitre cette option
-upour la commandesortEt c’est vrai, toutes les machines n’ont pas une implémentation avec des options exotiques…Comme ils disent c’est un « pattern scanning and processing language » (synopsis) puis plus précisément mais succinctement « the awk programming language, which is specialized for textual data manipulation. An awk program is a sequence of patterns and corresponding actions. » (description)
Par exemple
sccomme les ancêtres VisiCalc et SuperCalc n’a pas de gestion de dates… C’est du texte qui peut être formaté comme date (identification par^D) en faisant appel àstrftime(plutôt que de réinventer la roue avec des bugs) et permet, si besoin, d’appeler des commandes externes.Par contre
oleoa des fonctions de conversion et extraction de dates, sans bug connu, mais pas de calculs en soi (bien qu’ayant repris bon nombre de fonctions de 1-2-3.) Il est possible, si besoin, d’écrire des macros.LibO Calc et Gnumeric ont toute la gestion de date que l’on trouve dans Excel mais sans les erreurs… qui ne sont réintroduites que lorsque MS modifie le fichier…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par Olivier Abad . Évalué à 6 (+5/-0).
man emacs
[^] # Re: Volontaire ?
Posté par 2PetitsVerres . Évalué à 5 (+3/-0).
Il fait tout, sauf éditeur de texte. CQFD.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Volontaire ?
Posté par TImaniac (site web personnel) . Évalué à 2 (+0/-0).
Excel gère déjà correctement l'année 2100 ;-)
[^] # Re: Volontaire ?
Posté par metaentropy . Évalué à 0 (+0/-0).
Excel n'a pas de bug de l'an 2100 (c'est facile à vérifier) et connaît bien le calendrier grégorien mais fait une exception pour 1900 pour des raisons de rétrocompatibilité avec Lotus-1-2-3, ce dernier étant à l'origine du bug.
Mais ce problème est "négligeable", car Excel ne gère aucune date en dessous du 1er janvier 1900, de telle sorte que seule les dates comprises en Janvier et Février 1900 souffrent de ce problème.
Le vrai problème d'Excel que je rencontrais encore il y a quelques années, c'est le copier-coller entre classeurs créés sur Macintosh et classeurs créés sur PC, car cela engendre un décalage de 4 ans de toutes les dates. Cela est dû au fait que jusqu'à Excel pour Macintosh 2008 l'époque par défaut était le 1er Janvier 1904 alors que la version PC a toujours utilisé le 31 décembre 1899 (affiché comme le 00/01/1900 par Excel) par défaut. À partir de la version 2011 d'Excel pour Macintosh (https://support.microsoft.com/en-us/office/date-systems-in-excel-e7fe7167-48a9-4b96-bb53-5612a800b487) l'époque par défaut est passée au 31 décembre 1899 comme sur PC, résolvant donc le problème à long terme. Le choix de l'époque est toujours stocké dans le fichier, de telle sorte que le transfert d'un unique fichier entre Mac et PC n'a jamais été un problème. Le souci concerne le copier-coller entre classeurs dont l'époque n'est pas la même.
En m'aidant de https://winworld.pc, des manuels, de tests sur émulateurs et de quelques vidéos YouTube qui montrent l'usage de vieux logiciels, j'ai pu reconstituer la chronologie de l'histoire :
Microsoft Multiplan pour DOS et Macintosh (du moins jusqu'à la version 2.0 comprise en 1985) et Lotus 1-2-3 release 1 (1983) ne géraient pas les dates.
Ainsi, quand Microsoft Excel 1.0 sort sur Macintosh en 1985, il est le premier à gérer les dates. L'époque est fixée au 1er janvier 1904, probablement pour être cohérent avec l'horloge interne des Macintosh (https://dev.to/ovid/fixing-a-40-year-old-software-bug-jmm) qui stocke le nombre de secondes écoulées depuis le 1er janvier 1904.
Lotus 1-2-3 release 2 sort sur PC en 1986 et utilisait le 31 décembre 1899 comme époque avec le bug de l'année 1900 (considérée à tort comme bisextile).
Lorsque Microsoft porte Excel sur PC (en version 2.0 car la version 1.0 est exclusivement Macintosh) en 1987, Lotus 1-2-3 est déjà bien implanté et Microsoft décide donc d'être aussi compatible que possible avec Lotus 1-2-3, décalant alors l'époque au 31 décembre 1899 et reproduisant le bug de l'année 1900, tout en offrant déjà la possibilité de choisir l'époque et de la stocker dans le fichier. À l'époque Macintosh et PC échangeaient peu de fichiers et la base d'utilisateur Excel pour Macintosh ne devait pas être suffisante pour que Microsoft considère cette incompatibilité comme un problème majeur, surtout avec l'option de compatibilité offerte.
Quant aux dates dans Visual Basic pour Applications (VT_DATE OLE), elles sont partiellement compatibles avec le calendrier 1900. Février 1900 est bien considéré comme une année normale (non bisextile) et les dates des cellules Excel sont décalées des dates VT_DATE OLE pour janvier et février 1900.
https://www.joelonsoftware.com/2006/06/16/my-first-billg-review/
Il y a aussi la réponse officielle de Microsoft sur le sujet:
https://learn.microsoft.com/en-us/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year
[^] # Re: Volontaire ?
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Ce que je ne comprends pas c'est pourquoi ça demeure aussi longtemps. Les fichiers créés après une date donnée ou bien les fichiers créés après une version donnée pourraient ignorer le comportement historique. Une détection du cas dans les fichiers plus anciens pourrait soulever dans les versions modernes une alerte voire une proposition de mise à jour ou de laisser ainsi ; au cas par cas.
Adhérer à l'April, ça vous tente ?
[^] # Re: Volontaire ?
Posté par Dring . Évalué à 4 (+2/-0).
Y'a aussi que "les gens" on tendance à faire un peu plus qu'une seule cellule par fichier Excel avec une date dedans.
Le Excel d'origine avait une limite à 32768 lignes et 255 colonnes, mais imagine juste 10,000 lignes avec 10 colonnes de dates tentant d'afficher le jour de la semaine, le tout sur un 80286 à 8mhz…
[^] # Re: Volontaire ?
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
En 1985, l’idée d’utiliser des tableurs comme base de données n’était pas si répandu. Les ordinateurs n’étaient pas si répandu et je saurais plus dire si les services comptables ont était rapidement informatisés, mais les secrétariats il ne me semble pas.
J’ai pas connu Excel de 1985, mais Lotus ne faisait pas ces calculs en temps réel. Tu rentre tes données, tu lance ton calcul et tu va aller te faire un café. C’était un workflow commun.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Je crois que cela existe encore dans tous les tableurs avec un bouton ou une entrée de menu qui s’appelle « tout recalculer » (ou maintenant quelque chose comme « actualiser la feuille » ?)
Et sinon, (1) même là où c’était répandu, les ordinateurs n’étaient pas assez rapides et l’affichage type console pas assez pratique pour jouer à cela. Et (2) c’est toujours une mauvaise idée d’utiliser un tableur comme une base de données.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par Dring . Évalué à 2 (+0/-0).
Même sans mettre de formules, ce calcul est nécessaire si ton format de date inclut le jour de la semaine.
[^] # Re: Volontaire ?
Posté par Le Pnume . Évalué à 7 (+5/-0).
Cette limite était vraiment cool ;-) , à cause d'elle j'ai découvert R, découverte que je n'ai jamais regrettée.
[^] # Re: Volontaire ?
Posté par Liorel . Évalué à 6 (+4/-0).
R c'est la vie :). Pour la petite histoire, c'est en préparant un scrupt R qui devait gérer des durées et faire mieux que le tableur Excel déjà existant que j'ai eu l'idée de ce nourjal.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Volontaire ?
Posté par groumly . Évalué à 10 (+17/-0).
OP s'est un peu gouré la cause du bug est pas excel, mais Lotus 1-2-3, sorti en 83. Excel avait comme contrainte d'être 100% compatible avec Lotus, y comprit au niveau des bugs.
Pour contexte, on parle de l'IBM pc original, a savoir 8088 (genre 4 registres) et 16kB de ram au dessus d'un bus tres lent (mais qui, ironiquement, était toujours plus rapide que le CPU, pour te donner une idée de la lenteur du bouzin).
Dit autrement: c'est vraiment pas grand chose.
lol, non, c'était les années 80. L'implementation a battre, c'était comparer les 2 lower bits avec 0, a savoir un bitwise AND
year & 00000011. Ca, c'est effectivement instantané sur un 8088, le reste de la division euclidienne, c'est beaucoup de boulot en comparaison.Et c'était pas juste faire ca une fois, mais le faire une fois par cellule, tout en laissant de la place pour les autres calculs de la spreadsheet.
Aussi, les mecs avait pas git et un IDE, le code source c'était de l'assembleur sur le PC de Jean-Guy, pardon, non stocke sur une disquette. La taille et la complexité du source était un probleme a gérer a l'époque.
Il y a pas mal de reference sur le sujet de ce bug dans excel, mais assez peu sur la réelle root cause, a savoir lotus. Vu le contexte hardware, le cas d'usage et la philosophie de l'époque, c'est typiquement le genre d'optimisations qui avait un gros impact sur le produit, a un cout négligeable.
[^] # Re: Volontaire ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2 (+1/-1).
Est-ce qu’on peut tout simplement imaginer que les devs ne connaissaient peut-être pas les subtilités du calendrier grégorien ?
Il n’y avait pas Wikipédia et moi, sans ce journal, je me souvenais que la règle c’était : bissextile si divisible par 4 sauf les siècles qui ne le sont pas.
J’avais la vague idée que, dans certains cas, les siècles le sont quand même sans pouvoir préciser plus et sans être certain.
On peut imaginer que les devs ont implémenté ce bug de bonne foi, non ?
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Volontaire ?
Posté par groumly . Évalué à 6 (+4/-0).
J’en doute, vu qu’ils se sont fades du code pour parser les dates.
La encore, c’était les années 80, et le côté “ouais, un mois à 30 jours, un jour 86400 secondes/24 heures”, c’est un truc de pti jeune fougueux.
c’est possible, mais j’en doute.
le côté “t’sais quoi? Personne s’en servira jamais pour des dates dans le passé, et ça va nous faire gagner 43 bits en ram, et 72 en storage” me parait vachement plus probable.
[^] # Re: Volontaire ?
Posté par Dring . Évalué à 2 (+0/-0).
Pour les mois de 30 jours, c’est con mais ça fait partie des trucs où certains calculs financiers standards se basent dessus.
[^] # Re: Volontaire ?
Posté par Pol' uX (site web personnel) . Évalué à 2 (+0/-0).
Spas grave si en parallèle on ne considère pas en plus que les années font 12 mois.
Adhérer à l'April, ça vous tente ?
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Si l’un des devs était Ploum l’erreur n’aurait pas existé… Parce que
(le genre de situation où l’on demande confirmation aux collègues, on va voir ce qui est fait dans les autres sources auxquelles on a accès, on pose la question quelque part : école/bibliothèque/enseignants-chercheurs/etc.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Volontaire ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Donc c’était intentionnel et non une erreur (bogue)… Ou les deux ? (« So for 1-2-3, this was a bug, but for Excel, it was a feature, even if meant sometimes getting dates wrong. »)
Ceci dit, il me semble (mais à vérifier) que Lotus avait corrigé le tir avec l’évolution du matériel et tout ça (versions post DOS je crois.)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Compatibilité
Posté par barmic 🦦 . Évalué à 6 (+4/-0).
Super journal !
C’est pratique quand fermer un bug en wont fix les fais passer en spécialistes de la compatibilité, mais c’est loin d’être effectivement le cas. Gérer la compatibilité correctement ce n’est pas figer les bugs dans le marbre, mais faire autant de changement que possible sans casser les comportements.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Les jours fériés
Posté par GG (site web personnel) . Évalué à 10 (+11/-0).
J'ai eu à compter le nombre de jours ouvrés, de dimanches et de jours fériés entre deux dates.
Or, il y a 6 jours fériés mobiles, en France, qui dépendent du jour de pâques.
Je devais le faire sur Excel, francisé, et, j'ai été obligé d'implémenter des calculs compliqués pour convertir le format de date dans le format américain pour appliquer les formules, qui découpaient la chaîne de caractère etc.
Bref, c'était difficile de ne pas faire d'erreurs. L'horreur.
Dans Libre Office Calc, il y a une fonction, qui s'appelle EasterEgg(), et ça fonctionne, simplement, très bien.
Pourquoi faire compliqué quand on peut faire simple?
Bien entendu, l'export du tableau vers Excel ne fonctionne pas.
Donc, j'ai continué le travail sur Libre Office.
Voilà, depuis ce jour, un petit cabinet d'Avocats utilise Libre Office Calc pour calculer les indemnités journalières. (Mais rassurez-vous, pour tout le reste c'est le logiciels de la suite Microsoft, avec tous les problèmes que ça implique).
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Les jours fériés
Posté par Liorel . Évalué à 2 (+0/-0).
Je serais curieux de savoir comment fonctionne la fonction, surtout pour le futur (pour le passé, il suffit de regarder dans une table). Les phases de la Lune sont notoirement difficiles à calculer dès qu'on dépasse quelques années d'avance.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Les jours fériés
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 8 (+5/-0).
Il me semble que la date de Pâques n'est pas déterminée en fonction de la Lune réelle mais d'une Lune fictive, en fait un algorithme public.
# Année
Posté par patrick_g (site web personnel) . Évalué à 4 (+1/-0).
Selon l'article Wikipédia c'est en 325.
[^] # Re: Année
Posté par Liorel . Évalué à 2 (+0/-0). Dernière modification le 25 avril 2025 à 12:55.
Oups ! Si un modérateur peut corriger… Et du coup, le fast forward devient faux aussi, il faut le réduire de 4 ans.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Année
Posté par Benoît Sibaud (site web personnel) . Évalué à 7 (+4/-0).
Corrigé, merci.
En même temps c'est pas vraiment 4 ans, parce qu'il y a une bissextile dedans :).
# La création du monde selon Microsoft
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
En fait, Microsoft considère que la date de la création du monde est le 1er janvier 1900. Les dates plus anciennes ne sont pas considérées comme des dates dans Excel.
Il y a (avait ?) aussi un truc rigolo avec les imprimantes et les dates pour Windows. En l'absence de date, l'année d'impression est (était ?) 1600. Je ne me souviens plus exactement dans quelles conditions j'avais découvert ça.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: La création du monde selon Microsoft
Posté par TImaniac (site web personnel) . Évalué à 6 (+4/-0).
https://fr.wikipedia.org/wiki/Epoch
# Excel et Wikipédia
Posté par 2PetitsVerres . Évalué à 3 (+1/-0).
On aurait raison. Enfin, abrutis je ne sais pas, mais infoutus de chercher sur wikipédia, c'est sûr. Pour un problème de calendrier, évidemment, vu que 2001 > 1985.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Excel et Wikipédia
Posté par Liorel . Évalué à 3 (+1/-0).
C'était évidemment le sens du sous-entendu, mais je te remercie d'avoir appliqué la deuxième loi de Van Rossum :
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Excel et Wikipédia
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3 (+2/-2).
On va dire infoutus de se documenter. Perso, les règles d'années bissextiles, c'est un truc que j'ai appris à l'école primaire.
Sans Wikipédia, si je ne m'en souvenais pas, je saurait où demander : à l'école la plus proche.
[^] # Re: Excel et Wikipédia
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+1/-1).
Spécial vendredi :
https://www.dictionnaire-academie.fr/article/A9B1252
L’année bissextile revient tous les quatre ans.
(vs https://fr.wiktionary.org/wiki/ann%C3%A9e_bissextile
ou https://fr.vikidia.org/wiki/Ann%C3%A9e_bissextile )
[^] # Re: Excel et Wikipédia
Posté par Voltairine . Évalué à 3 (+1/-0).
Pas mieux chez le gros Robert
Plus précis chez Larousse
[^] # Re: Excel et Wikipédia
Posté par aiolos . Évalué à 6 (+4/-0).
On peut aussi noter qu’avant Wikipedia on avait des encyclopédies en N volumes pour obtenir un condensé de la connaissance humaine… on en trouvait chez ses grand-parents qui se faisaient refourguer ça en porte à porte (un volume par mois pedant 2 ans) ou en consultation dans les bibliothèques.
Probablement que c’est ici que tu aurais commencé à chercher l’information sur les années bissextile plutôt que d’aller sonner à la porte d’une école.
[^] # Re: Excel et Wikipédia
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Même sans encyclopédie, les lecteurs et les lectrices d'Asimov auront pu trouver l'information dans une de ses nouvelles des Veufs noirs !
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Outsider
Posté par TImaniac (site web personnel) . Évalué à 7 (+5/-0).
A l'époque, c'était Excel l'outsider : ils ont copié le comportement de Lotus 1-2-3 pour soucis de compatibilité.
https://learn.microsoft.com/fr-fr/office/troubleshoot/excel/wrongly-assumes-1900-is-leap-year
[^] # Solution ?
Posté par Arthur Accroc . Évalué à 4 (+2/-0). Dernière modification le 27 avril 2025 à 06:59.
Alors, d’après le document que tu pointes,
Et à vue de nez, toutes ces catastrophes se produiraient parce que la date est certainement représentée par un décalage par rapport à l’Epoch et que corriger l’année 1900 décalerait donc toutes les valeurs d’un jour.
J’entrevois pourtant une solution simple avec bien moins d’impact que de décaler les valeurs : corriger le caractère non bissextile de l’année 1900 et décaler l’Epoch du 1ᵉʳ janvier 1900 au 31 décembre 1899. Ainsi les valeurs resteraient identiques, sauf pour les dates antérieures au 1ᵉʳ mars 1900.
Comme actuellement les calculs avec ces dates sont faux, mais que c’est censé n’être pas grave parce que quasiment personne ne les utilise, ce ne serait donc pas grave qu’elles soient potentiellement impactées.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Solution ?
Posté par barmic 🦦 . Évalué à 4 (+3/-1).
Ils peuvent créer de nouvelles fonctions correctes, ils peuvent mettre un warning si une date peut être poser problème, ils peuvent gérer des calendriers pour pouvoir choisir lotus/grégorien/chinois,…
S'ils voulaient s'en occuper, ils le feraient
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Solution ?
Posté par Liorel . Évalué à 5 (+3/-0).
En fait, un des problèmes est que les dates sont basées sur un Epoch faux.
Pour le prouver, rien de plus simple : dans une cellule Excel, taper "01/01/1900". Puis clic droit sur la cellule, "Format", afficher le jour de la semaine. Excel affiche dimanche.
Refaire la même manip dans le langage de son choix, moi j'ai choisi R avec lubridate.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Solution ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 28 avril 2025 à 16:42.
Pour LibreOffice, Calligra, Gnumeric le 1er janvier 1900 est un lundi.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Solution ?
Posté par Liorel . Évalué à 7 (+5/-0).
Du coup on peut faire faire des trucs très rigolos à LibreOffice :
Enregistrer, fermer. Si on a enregistré en ODS, Excel nous avertit gentiment qu'on a utilisé des fonctionnalités incompatibles avec le format de fichier choisi, ce qui ne manque pas de piquant. Réouvrir le fichier avec Calc.
On a maintenant un mercredi et un jeudi séparés de 2 jours. On aura beau recalculer, rien n'y fait : on a toujours une cellule A3 qui affiche 2. Mais il y a mieux !
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Solution ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 28 avril 2025 à 17:06.
Je n'ai pas Excel pour rigoler, mais OnlyOffice fait pareil puisqu'il a le même bug.
Ce n'est pas la première fois que la fiabilité d'Excel est remise en question d'ailleurs.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Solution ?
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Et pour OnlyOffice, le 1er janvier 1900 est un dimanche (format par défaut OOXML).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Why Companies Don’t Fix Bugs
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Is this in the requirements?
Je ne réponds pas à un message particulier, mais je voulais juste pointer vers le blog d’Ibrahim Diallo :
https://idiallo.com/blog/companies-dont-fix-bugs
[^] # Re: Why Companies Don’t Fix Bugs
Posté par barmic 🦦 . Évalué à 4 (+2/-0).
Merci pour le lien
J’ai ce problème actuellement avec une de mes PR qui n’est pas mergée parce que le code qu’elle corrige parait trop complexe.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Why Companies Don’t Fix Bugs
Posté par Benjamin Henrion (site web personnel) . Évalué à 2 (+0/-0).
Je me demande si avec la dernière législation sur le Product Liability Directive (PLD) ne change pas la donne:
https://www.heise.de/en/background/Software-providers-beware-They-are-now-liable-for-defective-products-10028867.html
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.