Fixture: missalemeum-ef-2038.txt
Task: the 2038 oracle extension, 2026-08-17 (branch ef-oracle-2038).
WHY 2038 AND NOT ANOTHER YEAR
----------------------------
docs/research/rules-register.md ยง6.7 recorded that step 4 of the reading-
resolution chain -- the Common route, data/ef/commons.sexp -- had NO external
witness of any kind. Only five saints route through a Common, and across all
of 2005-2050 they are the OBSERVED office on five days total:
isidore-of-seville 2008, 2035, 2046
frances-rome 2038
sts-felicitas-perpetua 2038
gregory-the-great never (impeded by Lent's privileged ferias every year)
patrick never (same)
None falls inside the 2026-2027 fixture's own window, so layer 4 had never
once compared a Common-routed citation. 2038 is the year that covers TWO of
the five at once, which is why it was chosen over 2035 or 2046.
SOURCE, AND HOW IT DIFFERS FROM THE 2026-2027 FIXTURE'S
-------------------------------------------------------
This fixture is a LIVE capture, not an archived snapshot, and that is a
material difference from missalemeum-ef-2026-2027.provenance's own source:
endpoint : https://www.missalemeum.com/en/api/v5/proper/YYYY-MM-DD
fetched : 2026-08-17, one request per day, 2038-01-01..2038-12-31,
365 files, 0 failures, 0.25s between requests
local : the JSON was written into a scratch directory laid out as
/missalemeum/en/YYYY-MM-DD.json so the existing extractor
could read it unchanged
docs/research/sources.md already records that **the live endpoint HAS DRIFTED
from lectio's archived 2026-2027 snapshot, so the two are not
interchangeable.** That is why this is a SEPARATE fixture with its own
comparison and its own allow-list rather than extra rows appended to the
2026-2027 one: merging them would put two different versions of the same
source behind a single set of expectations, and a future disagreement could
not be attributed to either the calendar or the drift. Nothing here is
compared against the 2026-2027 fixture.
Because it is a live capture of a third-party service, it is also NOT
reproducible byte-for-byte on demand the way the snapshot-derived fixture is:
re-running the fetch tomorrow may legitimately return different content if
missalemeum changes. The SHA below pins WHAT WAS COMPARED, and a mismatch
means the fixture file changed, not that missalemeum did.
SHA-256 of the extracted fixture:
2ac17136be5f6a831bb115ab62f0bb993f69973fdd847d269b43915746ef2151
Asserted by test_oracle.ml's own 2038 fixture-SHA test, the same discipline
the 2026-2027 fixture uses. Regenerate deliberately; never copy a mismatch's
actual value back in, which defeats the pin.
Exact commands:
# fetch (365 requests, be polite -- this is someone else's server)
d=2038-01-01
while [ "$d" != "2039-01-01" ]; do
curl -s -A "colitur-validation/0.1" \
"https://www.missalemeum.com/en/api/v5/proper/$d" \
-o /missalemeum/en/$d.json
sleep 0.25
d=$(date -I -d "$d + 1 day")
done
# extract (the third argument is the expected day count -- see the tool's
# own header; it used to be hardcoded to 730 and was generalised for this)
python3 tools/extract_missalemeum_oracle.py \
test/fixtures/missalemeum-ef-2038.txt 365
Output: one line per civil day, 2038-01-01 through 2038-12-31 inclusive
(365 lines), pipe-separated, IDENTICAL schema to the 2026-2027 fixture:
date|rank|colors|title|tempora|commemorations|displaced|n_masses|commemoration_ids|first|gospel
Known extraction warnings for this year, checked rather than suppressed:
2038-04-23 has no "Lectio" and no "Evangelium" section -- it is Good
Friday (Easter 2038 is 25 April, the latest date Easter can fall), whose
"Missa Praesanctificatorum" has a multi-lesson structure with no single
reading in the Epistle/Gospel slot this schema assumes. Both fields are
"-", with a warning on stderr naming the date, never a silent guess --
exactly the shape the 2026-2027 fixture already records for its own two
Good Friday rows.