[rudycelekli]

Why

Date attributes keep the precision that was written: a month is 2024-03, a year is 2024. date_trunc only parsed a full YYYY-MM-DD or an offset timestamp, so truncating either of those values produced no result. A rule that floors a month-precision date to its month, or a year-precision date to its year, dropped the fact.

What changes

YYYY-MM and YYYY parse as that month and that year. Truncation still cannot invent a finer part: a month truncated to a day, or a year truncated to a month, stays absent. Offset timestamps are unchanged, and a timestamp without an offset is still rejected.

How it was checked

In calendar_truncation_uses_utc_and_rejects_ambiguous_or_invalid_dates:

• month truncation of 2024-03 is 2024-03-01
• year truncation of 2024-03 is 2024-01-01
• year truncation of 2024 is 2024-01-01

On the original function the month case fails with left: None. With the change, cargo test -p utopia-reason --lib passes (108). cargo fmt -p utopia-reason and cargo clippy -p utopia-reason --all-targets -- -D warnings pass.

Before review

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

[WaylandYang]

Thanks, the bug is real: normalize_attr_value stores 2024-03 and 2024, and date_trunc gives no value for them today. Two things: please update ADR 0036's list of accepted date inputs (it still names only an ISO calendar date or an RFC 3339 timestamp), and require four ASCII digits for the year form so +202 or -123 aren't read as years.

[rudycelekli]

ADR 0036 now lists the month (2024-03) and four-digit year (2024) inputs and says a value cannot be truncated finer than it states; the bare-year form now requires four ASCII digits, with "+202" and "-123" added as no-value cases in calendar_truncation_uses_utc_and_rejects_ambiguous_or_invalid_dates. Rebased on dev.