[rudycelekli]

Why

written_date reads dates whose month is a name ("17 March 2020", "Mar. 17, 2020"). It splits the text into words on whitespace, commas and periods only. "17-Mar-2020" is the default date display in Excel's d-mmm-yyyy format and in Oracle exports, so it is how dates arrive from spreadsheet tables, ledgers and many filings rendered from them. Because a hyphen does not separate words, the whole thing is one word, and the date is not read. The month is a name, so the day and month order is not in doubt.

So a date attribute or interval endpoint written "17-Mar-2020" is dropped, and literal_object treats it as a thing instead of a value, while "17 Mar 2020" works.

What changes

The month-name reader also splits on -. The existing guards decide the rest: all-number forms ("04-03-2020") are still ambiguous and unread, a two-digit year ("17-Mar-20") is still not guessed, "mid-March 2020" is still not a date, and ISO "2020-03-17" still goes to parse_time and is kept as written.

How it was checked

• A new test, a_date_with_hyphens_and_a_month_name_is_read, covers "17-Mar-2020", "17-MAR-2020", "1-January-2021", "Mar-2020", read_time("30-Sep-2025"), and the four cases above.
• With the fix reverted the test fails: left: None right: Some(String("2020-03-17")).
• cargo test -p utopia-extract --lib: 113 passed.
• cargo fmt -p utopia-extract --check and cargo clippy -p utopia-extract --all-targets -- -D warnings pass.

Before review

• Every commit is signed off (git commit -s)
• cargo fmt --all --check, cargo clippy and cargo test pass for the touched crate