[Bug]: Missing Transfer of Sts. Peter and Paul — June 29, 1973 (Sacred Heart Collision)

[scriptura]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

ENG TRANSLATION :

Good day, Father D'Orazio,

The following message is a report of a bug affecting you, which I have already reported in the issues of another perpetual calendar: Romcal. While reviewing your solution, I noticed the bug, but more importantly, I saw that you put your heart into your project and that it is still actively maintained. So here is the bug:

For the bug to occur, Easter must fall on April 22nd; we agree, this is not frequent:

• 1962 (therefore before the 1969 reform, this date is out of scope)
• 1973
• 1984
• 2057
• 2068
• 2114
• etc.

So, on June 29, 1973, the Solemnity of Saints Peter and Paul was simply omitted from your calendar, when it should have been moved to June 30.

On that day, we have a head-on collision between two entire liturgical units of the same rank (precedence 3) in the Table of Precedence:

• The Sacred Heart of Jesus (Temporal Cycle / Movable).
• Saints Peter and Paul, Apostles (Sanctoral Cycle / Fixed).

Although both celebrations have precedence 3, the general norms for the liturgical year and the calendar impose an internal hierarchy: Lord > Virgin > Saints. As a result, the Sacred Heart (Lord) takes precedence over Peter and Paul (Saints).

So far, so good on your end; However, you then encounter a logical error (Missing Transfer):

The Winner Takes All rule does not apply here. A Solemnity prevented by a higher-ranking celebration must be transferred to the nearest day that is not a day of Rank 1 to 8.

In 1973:

• June 29: Occupied by the Sacred Heart (precedence 3).
• June 30: Occupied by the Immaculate Heart of Mary (movable feast, precedence 12, precedence 10 since 1996) and by the First Martyrs of the Church of Rome (fixed feast, precedence 12).

Since precedence 3 > precedence 10, the Solemnity of Peter and Paul must be moved to June 30, thus removing the optional memorials of the Immaculate Heart of Mary and the Protomartyrs of Rome.

It therefore seems that your resolution pipeline does not handle the automatic replacement of all or part of the losing Solemnities. Without this mechanism, Peter and Paul disappear from the binary stream of 1973 (and the other dates already listed), which you'll agree is a bit of a nuisance!

My personal solution (based on Data-Oriented Design): assign a sub-weight (Class) to the integers of each precedence.

Example:

• lord (weight 0),
• virgin (weight 1),
• saint (weight 2),
• proper (weight 3).

Trigger a routine to find a free slot as soon as a Solemnity (precedence 3 or 4) is removed.

This is how I solved the problem for my own liturgical calendar; however, my approach is very different from what exists on the web. In my case, everything is compiled, with an access time of O(1).

Please take the time to verify my statements, of course.
Looking forward to your feedback.

---

ORIGINAL FR :

Bonjour P. D'Orazio,

Le message qui suit est la remonté d'un bug qui vous concerne, et que j'ai déjà signalé dans les issues d'un autre calendrier perpétuel : Romcal. En passant en revue votre solution, j'ai vu le bug, mais surtout que vous mettiez du coeur dans votre projet et que celui-ci était toujours activement maintenu, alors voici le bug :

Pour que le bug se produise il faut que Pâques tombe un 22 avril ; nous sommes d'accord, ce n'est pas fréquent :

• 1962 (donc avant la réforme de 1969, cette date est hors scope)
• 1973
• 1984
• 2057
• 2068
• 2114
• etc.

Donc, le 29 juin 1973, la Solennité de Saints Pierre et Paul est purement et simplement escamotée de votre calendrier, alors qu'elle aurait dû être transférée au 30 juin.

Ce jour-là, nous avons une collision frontale entre deux entiers de même rang (precedence 3) dans la Table des préséances :

• Le Sacré-Cœur de Jésus (Cycle Temporal / Mobile).
• Saints Pierre et Paul, Apôtres (Cycle Sanctoral / Fixe).

Bien que les deux célébrations soient de precedence 3, les normes générales pour l'année liturgique et le calendrier imposent une hiérarchie interne : Seigneur > Vierge > Saints. Résultat : Le Sacré-Cœur (Seigneur) l'emporte sur Pierre et Paul (Saints).

Jusque là tout va bien chez vous ; sauf qu'ensuite vous avez un bug logique (Missing Transfer) :

Le Winner Takes All ne s'applique pas ici. Une Solennité empêchée par une célébration de rang supérieur doit être transférée au jour le plus proche qui ne soit pas un jour de Rang 1 à 8.

En 1973 :

• 29 juin : Occupé par le Sacré-Cœur (precedence 3).
• 30 juin : Occupé par le Cœur immaculé de Marie (fête mobile, precedence 12, precedence 10 depuis 1996) et par les Premiers martyrs de l’Église de Rome (fête fixe, precedence 12).

Puisque precedence 3 > precedence 10, la Solennité de Pierre et Paul doit être transférée au 30 juin, évinçant ainsi les mémoires facultatives du Cœur immaculé de Marie et des Protomartyrs de Rome.

Il semble donc que votre pipeline de résolution ne gère pas le re-placement automatique de tout ou partie des Solennités perdantes. En l'absence de ce mécanisme, Pierre et Paul disparaissent du flux binaire de 1973 (et des autres dates déjà listées), vous conviendrez que c'est un poil embêtant !

Ma solution perso (orientée Data-Oriented Design) : attribuer un sous-poids (Class) aux entiers de chaque precedence.
Exemple :

• lord (poids 0),
• virgin (poids 1),
• saint (poids 2),
• proper (poids 3).

Déclencher une routine de recherche de slot libre dès qu'une Solennité (precedence 3 ou 4) est évincée.
C'est ainsi que j'ai résolu le problème pour mon propre calendrier liturgique ; mais mon approche est très différente de ce qui existe sur le web, chez moi tout est compilé, temps d'accès O(1).

Prenez le temps de vérifier mes dires bien sûr.
Au plaisir de vous lire.

Expected Behavior

No response

Steps To Reproduce

No response

Environment

- **OS**:
- **PHP**:

Anything else?

Version

dev (Unstable)

[JohnRDOrazio]

Thank you for this observation! This is the kind of feedback that is needed. I will look into this, and once fixed will implement a test that can be run in the LiturgicalCalendar/UnitTestInterface. My hope is that any liturgical API can produce testable results, so that we can easily compare and see where one API is failing compared to another. This would also require a unique, canonicalized ID for each liturgical celebration, so that every API can be compared to another. If you would like to participate in this endeavour, I have started to outline a repo to coordinate this effort: CatholicOS/cledr. Allow me to send you an invite to the CatholicOS organization!

[scriptura]

Thank you.

I won't be able to contribute to your project on a technical level; however, I can intervene, on an ad hoc basis, where it matters most to you. Since I need to test and identify any anomalies in the placement of feast days in my own calendar, which I've just created, I would be able to point out any borderline cases or new liturgical rules not yet supported if I find these anomalies in your calendar. If this type of assistance suits you, within the scope described here, I would accept your invitation.

Sincerely.

[JohnRDOrazio]

Perhaps there was a misunderstanding, I'm not asking you to contribute to my Liturgical Calendar API on a technical level; simply, I believe we need more coordination in the Catholic Church when it comes to technology, and even if multiple systems are in place (a PHP based liturgical API, a Rust based liturgical calculator, a typescript based liturgical API) curated by various developers, the systems should be testable and there should be a way to compare results. The only to achieve this is to establish some standards, such as a canonicalized ID for each liturgical celebration that everyone implements in their projects and their outputs. This is the scope of the CatholicOS/cledr repo, not so much a codebase, more of an attempt to establish canonicalized IDs that everyone agrees upon.

[scriptura]

Sorry, I understand the intention better now, thank you.

But in my case, I don't know if it's relevant because my data, in YAML files, is compiled into a u64 binary.

Let me explain:

My application is primarily data-driven (and therefore declarative: the rules aren't hardcoded, except for the calculation of the Easter date). The true value of my calendar data lies in the configuration of its YAML files, which are gathered here: corpus/. The stems of the YAML files act as IDs. But these IDs can't be used by the user because they aren't used at runtime. Everything is resolved AOT: pre-calculated in advance, then saved in a binary, before the runtime. The "recognizable" IDs from the YAML files are placed upstream of the Forge that generates the binary. Next, this Forge assigns IDs on the fly: a number.

Later, these numeric IDs will be permanently fixed in a variant_registry.lock file, and this file will be important in the future, but I reserve the right to redefine them until the calendar reaches version 1.0.0. In the meantime, you can already view all the IDs of the Roman General Calendar in variant_registry.lock.