LocalDateTime bounds and elements refuse Z and an offset that tsrange and DateTimeRange read #130

LocalDateTimeRange, its multirange and LocalDateTimeSet refuse a bound or element with Z or an offset, which PostgreSQL's timestamp input reads by dropping the offset — and which the BCL sibling DateTimeRange reads the same way. Loud (FormatException). Measured on main (3ecfa10) against PostgreSQL 17.10:

DateTimeRange.Parse("[2026-01-01 10:00:00+02,)", null);       // wall clock 10:00 kept
LocalDateTimeRange.Parse("[2026-01-01 10:00:00Z,)", null);     // FormatException
LocalDateTimeSet.Parse("{2026-01-01 10:00:00+02}", null);      // FormatException

SELECT '[2026-01-01 10:00:00+02,)'::tsrange, '[2026-01-01 10:00:00Z,)'::tsrange;  -- ["2026-01-01 10:00:00",) twice

Found by LiteralCorpusProbeTests (#123), family offset, on LocalDateTimeRange, RangeSet<LocalDateTimeRange>, LocalDateTimeSet and LocalDateTimeSet<T>.

Authority. docs/serialization.md#dates-and-times-are-strict-iso-8601: "A DateTime takes an optional Z … or an offset … The wall clock is kept as written, and the offset is never applied", and "The NodaTime types follow the same grammar". The DateTime rule is stated as PostgreSQL's own rule for timestamp input.

Cause. NodaPatterns.DateTime / DateTimeSpace have no offset suffix.

Options. Accept and drop the suffix as IsoTemporal.ParseDateTime does, or say in the document that LocalDateTime refuses it. Not breaking either way.