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/
[^] # Re: Volontaire ?
Posté par metaentropy . En réponse au journal Pâques, le bug d'Excel et la difficile adaptation de LibreOffice. Évalué à 3 (+3/-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