Skip to content
tutorials

Cette Date Fera Planter Votre Code

Découvrez la date étrangement spécifique qui provoque une erreur d'exécution dans Ruby, et ce n'est pas un bug. C'est une leçon d'histoire vieille de 440 ans intégrée directement dans le code source du langage.

Dani Roth
Cette Date Fera Planter Votre Code

Le Bug Qui Est En Fait Une Leçon d'Histoire

Un curieux ArgumentError peut arrêter le code Ruby tentant d'analyser des dates spécifiques en octobre 1582. Les développeurs pourraient rencontrer cela lorsque Date.parse("October 9th, 1582") plante inexplicablement, impliquant un défaut fondamental dans les capacités de gestion du temps du langage. Cependant, ce n'est pas un bug ; c'est une conception intentionnelle et historiquement exacte.

Plongez dans le code source de Ruby, et vous découvrirez la constante Date::ITALY. Cet entier apparemment arbitraire est, en fait, un Julian day number précis, représentant le 15 octobre 1582. Cette date n'est pas aléatoire ; elle marque un moment charnière dans la chronologie mondiale.

Ce jour-là, l'Italie, l'Espagne et la Pologne, sous le pape Grégoire XIII, sont officiellement passées de l'ancien Julian calendar au plus précis Gregorian calendar. Pour corriger des siècles de dérive accumulée causée par les règles imprécises des années bissextiles du système Julian, 10 jours ont simplement été supprimés du calendrier. Le jeudi 4 octobre 1582 a été immédiatement suivi par le vendredi 15 octobre 1582.

L'Date object de Ruby reflète méticuleusement cet événement historique. Il utilise Date::ITALY comme limite d'initialisation par défaut, basculant dynamiquement ses calculs internes. Les dates antérieures au 15 octobre 1582 sont traitées en utilisant la logique du Julian calendar, tandis que celles postérieures adhèrent au système Gregorian. Par conséquent, tenter d'analyser une date comme le 9 octobre 1582 déclenche un ArgumentError car, dans ce contexte historiquement conscient, cette semaine n'a littéralement jamais eu lieu. Ce choix de conception transforme une erreur d'exécution potentielle en une leçon fascinante sur l'histoire du calendrier.

Quand 10 Jours Ont Disparu du Calendrier

Des siècles d'imprécision ont affligé le Julian calendar. Sa règle simple, ajouter un jour bissextile tous les quatre ans, s'est avérée légèrement trop généreuse, provoquant une dérive accumulée. Au 16e siècle, le calendrier s'était décalé d'environ 10 jours par rapport à l'année solaire, désalignant de manière critique les fêtes religieuses comme Pâques avec les saisons.

Pour corriger cette importante divergence temporelle, le pape Grégoire XIII a promulgué une réforme radicale en 1582, introduisant le Gregorian calendar. Sa solution fut drastique : il a simplement éliminé l'erreur accumulée. Après le jeudi 4 octobre 1582, le calendrier a immédiatement sauté au vendredi 15 octobre, faisant disparaître effectivement 10 jours de l'histoire humaine dans les régions affectées comme l'Italie, l'Espagne et la Pologne.

La Date class de Ruby, par défaut, respecte cette discontinuité historique. Son moteur interne reconnaît l'écart de 10 jours, traitant toute tentative d'instancier un Date object au cours de la période manquante comme une opération invalide. Interroger une date telle que le 9 octobre 1582, en utilisant Date.parse, déclenchera donc un ArgumentError, confirmant que, aux yeux du code, cette semaine n'a jamais eu lieu.

Chaos Calendaire : Il N'y Avait Pas Que l'Italie

L'Italie n'était pas la seule confrontée à ce casse-tête calendaire. La bibliothèque Date de Ruby inclut également la constante Date::ENGLAND, marquant le 14 septembre 1752. Cette date signifie l'adoption tardive par l'Empire britannique de la réforme grégorienne, près de deux siècles après l'Italie. Pour s'aligner sur le nouveau système, le calendrier britannique a sauté 11 jours, le 2 septembre 1752 étant immédiatement suivi du 14 septembre 1752. Ce changement spectaculaire a créé un écart de 11 jours dans tous les territoires britanniques, affectant les registres et les interprétations historiques pendant des décennies.

De telles anomalies historiques spécifiques ne sont pas des bugs, mais des choix de conception délibérés au sein de la bibliothèque standard de Ruby. Les développeurs ont créé la classe Date pour prendre en charge les applications nécessitant des calculs de dates historiques précis, garantissant que les opérations reflètent fidèlement les systèmes de calendrier passés, y compris ces jours « manquants ». Cette attention méticuleuse aux détails empêche une périodisation historique incorrecte, ce qui est crucial pour les logiciels universitaires ou d'archivage.

Pour les scénarios exigeant une chronologie cohérente et ininterrompue, Ruby offre une échappatoire essentielle. Les développeurs peuvent initialiser explicitement des objets Date en utilisant Date::GREGORIAN. Cette constante force un calendrier grégorien proleptique, qui applique les règles grégoriennes rétroactivement indéfiniment, ignorant ainsi efficacement tous les changements de calendrier historiques et leurs lacunes associées. Cela garantit des opérations chronologiques fluides sans interruptions historiques. Pour plus de détails sur ces constantes et d'autres fonctionnalités de date, consultez la documentation Class: Date (Ruby 3.1.0).

Cet article vous plaît ? Recevez-en un comme celui-ci chaque matin.

un e-mail par jour · désinscription en deux clics · aucun traqueur tiers

Ruby propose des classes distinctes pour la gestion des données temporelles : Date, DateTime et Time. Alors que Date et DateTime tiennent méticuleusement compte des réformes du calendrier historique, y compris la transition Julian-Gregorian et ses jours manquants, la classe Time fonctionne sur un principe fondamentalement différent. Cette distinction est essentielle pour les développeurs qui gèrent la logique temporelle.

Pour la plupart des applications modernes, Time est le choix recommandé. Il utilise un calendrier grégorien proleptique, traitant toutes les dates — même celles antérieures aux réformes de 1582 ou 1752 — comme si le système grégorien avait toujours été en vigueur. Cette approche contourne les complexités des changements de calendrier historiques, offrant une chronologie cohérente et continue. Les développeurs gagnent en simplicité et en prévisibilité sans avoir à tenir compte des discontinuités historiques.

Faites preuve d'une extrême prudence lors de la conversion entre les objets Time et Date, en particulier pour les dates historiques. Leurs modèles de calendrier sous-jacents divergents peuvent entraîner des bugs subtils et une corruption de données silencieuse. Un objet Date représentant le 9 octobre 1582 pourrait déclencher un ArgumentError en raison de son inexistence, mais la conversion d'un objet Time de cette même 'date' vers Date pourrait produire une valeur Date inattendue ou incorrecte, reflétant l'inadéquation inhérente du calendrier. Choisissez toujours la classe appropriée pour vos besoins temporels spécifiques.

Foire aux questions

Qu'est-ce que la constante Date::ITALY dans Ruby ?

C'est une constante intégrée représentant le numéro de jour julien pour le 15 octobre 1582. Cette date marque le début de la réforme du calendrier grégorien en Italie et dans d'autres nations catholiques.

Pourquoi l'analyse d'une date comme '10 octobre 1582' provoque-t-elle une erreur d'exécution dans Ruby ?

Cette date n'a jamais officiellement existé. Pour corriger la dérive du calendrier, le Pape Gregory XIII a décrété que le jeudi 4 octobre 1582 serait immédiatement suivi du vendredi 15 octobre 1582. Le moteur de date par défaut de Ruby le sait et considère les dates de cet intervalle comme invalides.

Qu'est-ce qu'un calendrier grégorien proleptique ?

C'est un système de calendrier qui applique les règles du calendrier grégorien aux dates antérieures à son adoption officielle. Cela fournit une arithmétique de date cohérente à travers l'histoire, ignorant les changements de calendrier historiques.

Comment puis-je éviter ces problèmes de calendrier historique dans mon application Ruby ?

Pour les applications modernes, utilisez la classe Time de Ruby, qui utilise un calendrier grégorien proleptique. Si vous devez utiliser la classe Date pour des calculs historiques mais avez besoin d'une logique cohérente, initialisez-la explicitement en utilisant Date::GREGORIAN pour contourner la prise en compte par défaut des réformes du calendrier.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$500 · AI tools & software only