Après ça dépend vraiment de plusieurs paramètres :
Déjà, utiliser Excel comme base de données, c'est assez consensuellement reconnu comme une mauvaise solution. Excel est une grosse calculette, capable de faire beaucoup de choses pas trop mal, mais aucune à la perfection. Quand on a des décisions cruciales à prendre, on les base sur un SI digne de ce nom, pas sur Excel. Qu'on soit ingénieur ou financier. Sinon on ne vient pas se plaindre.
Ensuite, il faut voir comment sont stockées les dates en interne dans un fichier xls(x). Si c'est un entier depuis l'Epoch, alors c'était une grosse erreur de design d'entrée de jeu, surtout que l'Epoch est faux, ce qui veut dire qu'on a ajouté un bug pour en corriger un. Si les dates sont stockées sous une forme de type JJ/MM/AAAA ou assimilé (ça pourrait tout à fait être YYYYMMDD), aucun problème et on ne pètera rien en corrigeant. La réticence de Microsoft à corriger me conduit à envisager la première hypothèse.
Enfin, ça interdit aussi tout un paquet d'usages d'Excel : avoir 2 bugs qui se corrigent mutuellement permet de limiter la casse à condition que la plage de dates concernée soit très restreinte C'est le cas, puisque seuls 59 jours (du 01/01/1900 au 28/01/1900) sont faux. Mais pour que ça tienne la route, on est obligé d'interdire les dates antérieures. En Excel, impossible de calculer que la veille du dimanche 1er janvier 1900, on était samedi ! Notamment, ça interdit tout usage d'Excel aux historiens (il est vrai qu'ils ont moins d'argent que les financiers). Corriger l'Epoch permettrait de lever cette restriction et d'ouvrir tout un éventail d'applications historiques.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Volontaire ?
Posté par Liorel . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à 6.
Après ça dépend vraiment de plusieurs paramètres :
Ça, ce sont les sources. Le mouton que tu veux est dedans.