Add support for optional end dates

#10 Works for me using optional_end_date module.

Actually it wasn't working everywhere, updated patch attached.

Needs a reroll for 2.1.x but wanted to query something first.

#10 still applies cleanly but does not work for date fields, only datetime fields. It does this by not modifying the service and passing in the start date for the end date.

#12 would need a reroll, but it aims to resolve this in DateRangeCompactFormatter by allowing null values rather than changing the default values. But even with formatTimestampRange modified to accept a null value, its keeping the login from #10 to set the end date as the start date.

I think given this is postponed, it would be simpler to keep the logic for #10 and apply it in the if block for date only fields?

The approach in #10 is probably the right way: let the field formatter deal with the NULL end date and leave the low level formatter service alone.

I'd prefer this because there some debate on what a null end value actually means. It could mean a single value, but it could also mean an unbounded range (from 1/1/2024 onwards). That kind of metadata would need to be obtained from a setting somewhere, either a field setting or a future setting for this formatter. Either way, the low level formatter wouldn't know.

Worth looking at in the context of #3445445 and work done to support single-value datetime and timestamp fields. Handling optional end dates is a relatively minor extension of that.

Rerolled from patch #10 and added fix for date fields in the field formatter.

erik.erskine → credited detroz → .

#16 looks good - I've committed this, and added some kernel tests for it.

Thanks everyone!

Automatically closed - issue fixed for 2 weeks with no activity.