aboutsummaryrefslogtreecommitdiff
path: root/lib/kernel/calendar.mli
diff options
context:
space:
mode:
Diffstat (limited to 'lib/kernel/calendar.mli')
-rw-r--r--lib/kernel/calendar.mli31
1 files changed, 24 insertions, 7 deletions
diff --git a/lib/kernel/calendar.mli b/lib/kernel/calendar.mli
index 9fbd7e7..1c0b0ed 100644
--- a/lib/kernel/calendar.mli
+++ b/lib/kernel/calendar.mli
@@ -11,13 +11,30 @@
every deferred candidate (RG 96-98): a losing I-class candidate the
rite's rules send to [Precedence.Transfer] does not stay put -- it moves
to the next day [rite.transfer_target] names as admissible, and both
- ends of the move are recorded ([transferred_in] on the day it arrives,
- [transferred_out] on the day it left). Every deferred candidate is
- accounted for exactly once: placed, or -- only if the placement fixed
- point is not reached within the round guard, which nothing in the 1962
- calendar is expected to trigger -- left in [Liturgical_day.omitted] with
- a reason that says so, never silently dropped. See [calendar.ml]'s
- [place_transfers] for the algorithm and its termination argument. *)
+ ends of the move are recorded: [transferred_in] on the day it arrives
+ (at most one -- RG 96 sends each departure to the next day that is not I
+ or II class, and the first to arrive occupies it), [transferred_out] on
+ the day it left (a list, not an option: RG 97-98 has coinciding I-class
+ feasts transfer "in order", so one day can lose more than one). Every
+ deferred candidate is accounted for exactly once: placed, or -- only if
+ the placement fixed point is not reached within the round guard (which
+ nothing in the 1962 calendar is expected to trigger), or the rite's own
+ [transfer_target] names a date outside this liturgical year's own range
+ (unproven to occur in the real EF calendar, but not ruled out by
+ construction) -- left in [Liturgical_day.omitted] with a reason that
+ says which, never silently dropped. See [calendar.ml]'s
+ [place_transfers] for the algorithm and its termination argument.
+
+ [Precedence.Repose]-disposed losers are gathered the same way
+ [Precedence.Transfer]-disposed ones are (Precedence folds both into
+ [deferred] as one case) and are routed through the same RG 96 search.
+ That is only correct for [Transfer]: [Repose] denotes RG 100-102's
+ *repositio*, a distinct rubric this module does not implement. Nothing
+ in the EF ruleset currently returns [Repose] (design spec ยง1.3:
+ "declared, not exercised" -- perpetual impediment arises from
+ proper/diocesan calendars, out of this plan's scope), so the gap is
+ latent rather than a live bug; documented here rather than given a
+ second mechanism for a disposition nothing emits. *)
(** [year rite layer y] resolves every day of the liturgical year that opens
in civil year [y]: from [rite.year_start y] through the day before