[USE CASE] EDTF complete SOLR indexing

[francisayyad03]

Overview of Use Case
This use case focuses on how content managers or librarians working with complex date formats can leverage this EDTF Date Processor to index full EDTF dates (including partial dates and multiple date possibilities) rather than only storing the year. By indexing complete date information in Solr, items are sortable by precise dates, while still allowing for incomplete or multiple dates.

Title (Goal): Indexing Incomplete or Multiple EDTF Dates with Full Date Precision

Primary Actor:
Content/Librarian Manager or Metadata Specialist who needs to accurately capture and sort content by full dates (even if partial), rather than only storing a single “year” value.

Scope
Architecture: Involves Drupal’s Search API, Solr, and this new EDTF date handling.
Access: Applies to editorial or metadata workflows where storing month and day (or multiple possible dates) is important for search and filtering.

Story:
“As a Metadata Specialist, I want to index and store the full EDTF date (day, month, and year) rather than just the year so that users can sort and filter results with greater accuracy, especially when multiple date possibilities are provided or partial (year-only or year-month) data must be converted into sortable Solr date values.”

Unlike the existing EDTFYear processor (which extracts only the year), this processor indexes the entire date to Solr, thereby:

Allowing more precise date-based sorting, including month and day.
Supporting incomplete date entries (e.g., just year or year-month) by normalizing them to the first day of the month or year.
Handling multiple dates (e.g., {2020-05-01, 2020-09-15}) by splitting them into separate date values for Solr indexing.

Examples:

• Single Incomplete Date:
  Input (field value): 2012-05 or 2012
  Processor Behavior: Converts 2012-05 or 2012 → 2012-05-01T00:00:00Z for Solr indexing.
  Key Benefit: Date sorting is more precise than just storing “2012.”

• Single Complete Date:
  Input (field value): 2012-05-02
  Processor Behavior: Converts 2012-05-02 → 2012-05-02T00:00:00Z for Solr indexing.
  Key Benefit: Date sorting is more precise than just storing “2012.”

• Multiple Dates
  Input (field value): {2012-01-01,2012-04-15}
  Processor Behavior: Splits into two indexed Solr date values:
  2012-01-01T00:00:00Z
  2012-04-15T00:00:00Z
  Key Benefit: Items with more than one possible date can appear in date-based queries correctly.

• Filtering Years
  Configuration: open_start_year = 2000, open_end_year = 2015
  Result: Dates earlier than 2000 or later than 2015 are omitted from being sorted, focusing search results on a defined time interval.