[JeroenDeDauw]

@alistair3149 this is the result of my product-level research into the date topic. This looked at all existing PRs plus various tools out there and I did some solution space exploration, most notably looking at a single type vs multiple types. Please take over from here. The ADR can be changed. It looks reasonable to me and the text is in decent shape.

Btw, I imagine a new PR from master is cleaner than continuing with the PR chain. Such chains do not seem sensible to me given how we work. It does not make sense to review them chronologically; reviewing the end state is more efficient, at which point it's simpler as a single PR.

---

For

• Date field: an incomplete date leaves the Subject unsaveable with no message #1486

Records how NeoWiki handles dates, for whoever continues the date work.
ADR 40
keeps Date & Time as it is, lets Date take a year or a month while asking for a full date by default, and adds EDTF
date as a Property Type of its own, off unless a wiki enables it.
DateTypesResearch.md
holds the findings behind it. This branch is meant to become the Date PR, so the ADR lands with its code.

Human input

Goal and shape: set by @JeroenDeDauw, who redirected Claude's proposals several times and made each call below;
Claude wrote the texts.

• Directions: find the best shape for dates across the wikis that use NeoWiki, weighing how often each need comes
  up; "uncommon use cases should not get in the way of the common ones", so someone adding a plain date never sees
  calendar models or EDTF; "a cohesive design for the date topic even if they are different types"; a
  Pareto-efficient shape, with options on types where they help; one PR instead of a stacked chain; an ADR as the
  record.
• Redirections: Julian dates left out until someone needs them, with room left; typed EDTF with a readable preview is
  enough at first, as in WikibaseEdtf; EDTF date takes every level the library parses; EDTF date is off by default
  and on for ECHOLOT, registered only where a wiki enables it, after weighing API and import use, the code that
  runs, and Property Types that come from extensions; no general rule about Constraints in the ADR.
• Redirections in review of the ADR: the bound rule left to the reference docs; Gregorian stated for all three
  types; an administrator, not the wiki, enables EDTF date; Julian dates recorded as a later addition rather than out
  of scope; the first EDTF date input "like in Wikibase EDTF"; Property Definition as the glossary term; the most
  precise Date form first; cuts in the Decision section and in the first alternative.
• Questions that changed or tested a call: "why does it win over one type with options?"; "what does Wikibase do
  here?", which moved years and months into Date; "what does skipping level 2 gain us?"; whether Notion and Coda use
  one type with options.
• Choices: a missing minPrecision means a full date, with the usual warning severity, so on wikis that enforce
  validation a year in an existing Date property warns instead of blocking; values are proleptic Gregorian, and how
  other calendars arrive is decided later; the type keeps the name EDTF, since those who enable it know the format,
  and admins can rename it through its interface message.
• Alternatives @JeroenDeDauw weighed: one date type with options against several types; EDTF inside Date against its
  own type; offering every type everywhere against hiding EDTF in the Schema editor against not loading it.

Outcome: @JeroenDeDauw reviewed and edited the ADR's Decision, Consequences, Implementation Thoughts and first
alternative; the research doc is not yet read by a human. Left for you: first, whether Date should take years and
months at all. @JeroenDeDauw is not fully sold on rejecting "Date for full days only". Keeping Date to full days
would keep it simple for every program that reads it and put every imprecise date in EDTF date. The cost: a wiki
without EDTF date could not store a bare year as a date, and most of the chain's Date work would move to EDTF date.
Then the research doc's facts and the next steps below.

Claude's calls

• Not discussed with @JeroenDeDauw: starting the Date PR from this branch, with
  Add EDTF property type #1811 following it rather than joining it; the ADR number; EDTF
  date values getting their earliest and latest days in Neo4j.
• Considered by Claude, omitted: a single "Date" entry in the type picker with toggles that pick the type underneath;
  listing Date before Date & Time in the picker, after a tester chose the wrong one; RDF for EDTF date values beyond
  the datatype.
• Not verified: how Airtable's "Include time" maps to its API types.
• Where your judgment helps: how a wiki enables EDTF date, a setting or a separate extension; the Neo4j layout for
  EDTF date values, so one query covers both types (Date keeps the earliest day under the property's key and the
  latest under <Name>_latest, while Add EDTF property type #1811 puts the EDTF text under the property's key); which Constraints EDTF
  date gets beyond required; how EDTF date values without both ends, such as open intervals, reach queries.

Next steps

On this branch, Alistair:

1. Bring in the code of Accept year and month precision in the date property type #1514,
   Enter and show dates of year, month or day precision #1515 and Schema editor: date bounds of any precision and minPrecision #1516,
   then close those three. Recheck first the findings of a September review that no tracker holds: an unreadable
   stored date erased on save (DateInput.vue), a numeric default blanking the Schema editor, and docs and demo
   data showing 1645-01-01 for 1645.
2. Make a missing minPrecision mean a full date, accept "year", keep "day" writable, and show the date picker
   by default.
3. Remove the texts that say Date will grow into full EDTF: the description of
   Accept year and month precision in the date property type #1514, PartialDate's docblock, schema-format.md.
4. Add the minPrecision codes to ADR 26's table and status line.

On #1811, Lukas Günther, after this PR merges:

1. Rebase onto master.
2. Register EDTF date only on wikis that enable it.
3. Store the earliest and latest day in Neo4j for values that have both. The library returns 1970 for an unspecified
   year, and an open interval end has no date.
4. Type RDF literals with http://id.loc.gov/datatypes/edtf/EDTF instead of xsd:edtf.
5. Add invalid-edtf to ADR 26.

Elsewhere:

• The release notes say that Date values can now be a year or a month; that queries see such a value as its first
  day unless they also read its latest day, and that Oxigraph leaves years and months out of comparisons with full
  dates; and that on wikis that enforce validation a year in an existing Date property warns instead of blocking.
• Add EDTF property type #679 keeps EDTF date as its own type.
• Support Julian-calendar dates in date values #1841 waits for a decision on calendars: a calendar on each
  value, as proposed there and in @JeroenDeDauw's comment on Accept year and month precision in the date property type #1514,
  or a Property Type of its own.
• To file: after a property's type changes, saving through the Subject editor leaves type-mismatch in place.

Verification evidence

• Earlier thinking: Opus subagents searched the project's GitHub history, team notes and meeting records; the public
  records are linked in the research doc.
• Code facts were read on master: SubjectValidator, Schema.ts, SubjectEditor.vue, extension.json, ADR 26;
  Wikibase's ValidatorBuilders.php and json.md; Semantic MediaWiki's Time.php; the EDTF library's README and
  ExtDate.php.
• Wikidata and other Wikibase counts: measured by Opus subagents on 2026-11-07; the main query is in the research doc.
• The ADR's outline was triangulated: two Opus reviewers adopted it after three rounds of fixes; two blind Opus
  agents, without seeing it, reached the same design (EDTF date as its own type because readers go by a Statement's
  type, years and months in Date, a full date by default).
• A blind Opus judge reviewed both texts. Four Opus reviewers then checked the PR for noise and consistency with the
  docs, for content missing from the session or attributed to the wrong person, for facts, and for business-sensitive
  content; the fixes that held up are applied, and the public-safety pass found nothing to change.

_{AI-authored — Claude Code, Opus 5.5 (max), on a Professional Wiki account}

[JeroenDeDauw]

I suspect this is the wrong call. Business wikis probably don't need year or month (and if they need year they can just use number and have it work well enough for their use cases). CH wikis that need partial dates would have EDTF for that use case. So there is no clear reason not to keep the date type as simple as possible, by always requiring a day.

I'd also like another look to be taken at whether combining date and dateTime could end up better than keeping them separate.

[JeroenDeDauw]

@luguenth FYI