Add support for optional end dates

I can confirm that the daterange compact formatter doesn't work with optional end date.
I made a patch where the start date is used for the end date if the end date is not set.
I'm not really sure if this is always the expected behaviour. It seems correct in my case.

@alduya, thank you for the patch, it works as it should.
I've tested it and the code looks good for me. I make this RTBC.

Patch no longer applies, here's an update

Confirmed patch in #5 is working.

Thanks for raising this & the patch.

I'm not sure we can consider it RTBC because the issue it depends on, #2794481: Allow end date to be optional is still a moving target. There's a lot of discussion about what a missing end date means. It could be a single value (as this patch would suggest), a never-ending range, or an unspecified end date. The issue also discusses missing start dates.

So I think we need to see how that pans out before deciding what to do here.

We'd want to write a test to go with this too. However, as things are currently (and without introducing a dependency on https://www.drupal.org/project/optional_end_date), it's not possible to create a field value with the missing end date.

I've noticed the datettime attribute doesn't get set on the start date if there's no end date value.

In twig:

content.field_sh_agendaitem_time.0.start_date["#attributes"]["datetime"]

This is empty/blank when there is no end date, but has a value where there is an end date. So some things behind the scenes are still not working correctly without an end date.

EDIT: This turned out to be completely unrelated but I'll leave the fix/answer here for anyone who may stumble on this.

When you have both an end date and start date, they're available as separate array keys:

content.field_sh_agendaitem_time.0.start_date
content.field_sh_agendaitem_time.0.end_date

However, when you only have a start_date, there are no longer separate array keys, and the start date is available as the first value:

content.field_sh_agendaitem_time.0

The default version is 2.x. With patch 2970628-3.patch from #9 I'm getting an error:
Fatal error: Cannot use Drupal\datetime\Plugin\Field\FieldType\DateTimeItemInterface as DateTimeItemInterface because the name is already in use in /var/www/html/web/modules/contrib/daterange_compact/src/Plugin/Field/FieldFormatter/DateRangeCompactFormatter.php on line 14

Added patch for 2.x branch (there is no 2.x-dev branch, I can't switch issue to it, but we should use the 2.x branch.)

#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? Otherwise I think a reroll of 12 could change the conditional here to if ($start_timestamp === $end_timestamp || is_null($end_timestamp) https://git.drupalcode.org/project/daterange_compact/-/blob/2.1.0/src/Da... if end timestamp is empty, but then should pass null for the end timestamp in the formatter so that the logic is the same between dates and datetimes.

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 like "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: Support code datetime & timestamp field types 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.

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

Thanks everyone!