From 2fac687318a9256f9ea4664c7458bc0e344f0d00 Mon Sep 17 00:00:00 2001 From: Marcel Date: Fri, 12 Jun 2026 19:37:11 +0200 Subject: [PATCH] docs(person): note YEAR seeding of legacy precisions in ADR-039 Co-Authored-By: Claude Fable 5 --- docs/adr/039-person-life-dates-localdate-precision.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/adr/039-person-life-dates-localdate-precision.md b/docs/adr/039-person-life-dates-localdate-precision.md index e21ebd6e..e4bba762 100644 --- a/docs/adr/039-person-life-dates-localdate-precision.md +++ b/docs/adr/039-person-life-dates-localdate-precision.md @@ -45,6 +45,13 @@ are semantically nonsensical for a birth or death, and `APPROX` is excluded from form to reduce cognitive load for the senior author audience. Legacy `APPROX` rows still render correctly (display delegates to `formatDocumentDate`). +The edit form seeds a stored non-offered precision (`APPROX`/`SEASON`/`RANGE`) into +the select as `YEAR`, so an untouched save coerces it to `YEAR` ("ca. 1944" becomes +"1944"). Accepted: nothing currently writes those precisions to persons (the form +offers DAY/MONTH/YEAR, the importer writes YEAR/UNKNOWN, V76 backfills YEAR), so the +case is only reachable via direct API writes — and seeding `YEAR` is strictly safer +than the alternative of silently claiming `DAY` precision. + ### 3. Derived-year pattern for backward-compatible DTOs `PersonNodeDTO` (Stammbaum) and `RelationshipDTO` keep `Integer birthYear/deathYear`,