J'écrivais des scénarios de test pour certaines méthodes pratiques que je mets à jour et j'ai décidé de voir ce qui se passerait si j'utilisais la méthode _LocalDate
de isLeapYear()
en 0. Si je comprends bien, l'année 0 n'a jamais existé: l'année précédente 1 AD était 1 BC. (Ceci est basé sur un article que j'ai lu il y a de nombreuses années et dont j'ai oublié la source.) À ma grande surprise, mon test a indiqué que l'année 0 était une année bissextile!
Je me rends compte que la classe Java.time.LocalDate
implémente ISO-8601 mais ISO-8601 indique-t-il vraiment que l'année 0 existait? Je suis réticent à croire que les personnes qui ont testé LocalDate
auraient raté cela comme test, mais je suis également réticent à croire qu'une norme internationale telle que ISO-8601 commettrait une erreur aussi évidente.
L'autre possibilité est que l'article que j'ai lu était simplement faux. (Ou alors c'était correct mais cela a été repensé plus tard.)
Ce n'est pas extrêmement important, mais je suis curieux de savoir où se trouve l'erreur: ISO-8601, la classe LocalDate
de Java, ou ma compréhension de la façon dont le temps est compté.
TL; DR: LocalDate
fait ce qu’il est documenté de faire, conformément à une norme internationale (ISO 8601). Que ce soit "correct" ou non est une toute autre question.
Le LocalDate
Javadoc inclut lui-même cette mise en garde:
Il est équivalent au système proleptique de calendrier grégorien, dans lequel les règles actuelles pour les années bissextiles sont appliquées à tous les temps. Les règles ISO-8601 conviennent parfaitement à la plupart des applications écrites aujourd'hui. Cependant, toute application utilisant des dates historiques et nécessitant leur exactitude trouvera l'approche ISO-8601 inappropriée.
Wikipedia a plus d'informations sur le calendrier proleptique grégorien . Entre autres choses, il est écrit:
Mathématiquement, il est plus pratique d'inclure une année 0 et de représenter les années précédentes comme étant négatives, dans le but spécifique de faciliter le calcul du nombre d'années entre une année négative (BC) et une année positive (AD). C'est la convention utilisée dans la numérotation par année astronomique et dans le système de date standard international ISO 8601. Dans ces systèmes, l'année 0 est une année bissextile.
Pardonnez-moi un moment pendant que je m'éloigne du contexte historique pour tout cela.
Les années du calendrier occidental sont apparemment comptées à partir de la naissance de Jésus-Christ, mais l'idée de le faire a commencé au VIe siècle et notre calendrier actuel est basé sur des calculs du XVIe siècle. Les chiffres romains ne représentant ni zéro ni nombre négatif, les années ont été comptées soit "après Jésus" (AD, pour anno domini ), soit "avant Jésus" (BC, pour " avant Jésus-Christ"). Ainsi, traditionnellement, 1 av. J.-C. était suivi de AD 1, sans année zéro entre les deux.
Cependant, au premier siècle, personne ne comptait les années de cette façon; À titre de comparaison, l’Évangile de Luc décrit l’année où Jésus a commencé son ministère comme
la quinzième année du règne de Tibère César, Ponce Pilate gouverneur de la Judée, Hérode tétrarque de Galilée et son frère Philippe tétrarque d'Ituraea et de la région de Trachonite, et Lysanias, tétrarque d'Abilène,
En apparence, cela aurait été 30 ap. J.-C. puisque Luc décrit Jésus comme étant "âgé d'environ trente ans" à l'époque. Mais les historiens modernes s'accordent généralement pour dire que Dionysius Exiguus, qui a proposé le système anno domini en 525 ap. J.-C., s'est trompé et que la numérotation des années a été décalée d'au moins un ou deux ans. (La date exacte est encore quelque peu controversée; voir Wikipedia si vous tenez à plus de détails.)
Mais il est trop tard pour réparer maintenant; même la transition du calendrier julien au calendrier grégorien, qui représentait un écart de moins de deux semaines, s'est heurtée à une résistance politique considérable, le passage à l'euro ayant duré plusieurs siècles dans toute l'Europe - vous pouvez imaginer à quel point un changement de numérotation d'année perturbant serait maintenant!
Alors, qu'est-ce que cette histoire a à voir avec le logiciel aujourd'hui? Malheureusement, en raison de la multitude de façons dont les dates ont été calculées et écrites au cours de l'histoire, vous devez soit abandonner le calendrier en agissant de manière cohérente lorsque vous avancez ou reculer dans le temps, soit vous devez abandonner les dates calculées. avoir une correspondance avec les dates que de vraies personnes auraient utilisées à l'époque. La divergence se produit plus rapidement que vous ne le pensez: de nombreux pays européens utilisaient encore le calendrier julien il y a moins de 100 ans, avec un écart de près de deux semaines par rapport aux autres pays européens!
Naturellement, LocalDate
se lave les mains et met en œuvre le calendrier de la manière dont nous l’utilisons aujourd’hui. Rappelez ce que dit la Javadoc: "Pour la plupart des applications écrites aujourd’hui, les règles ISO-8601 conviennent parfaitement. Toutefois, toute application utilisant des dates historiques et nécessitant leur exactitude trouvera l'approche ISO-8601 n'est pas appropriée. "
De Wikipedia :
... il y a une année zéro dans la numérotation des années astronomiques (où elle coïncide avec l'année julienne 1 BC) et dans l'ISO 8601: 2004 (où elle coïncide avec l'année Grégorienne 1 BC)