Add option to show only start or end date in the DateTime Range custom formatter

Thanks for adding a patch with the request. I'm neutral to negative about adding this to the core formatters. I think don't think do-it-all plugins are good for datetime in core for the long term.

All three formatters would have to be updated. We need test coverage for all formatters, for datetime, dateonly, and allday, for when the start/end are different and the same, for all variations of the new options. In other words, every time we add an option to these, we compound the test coverage and surface area for new potential problems.

We would also need an update path, plus update path tests, for the formatter settings.

I would happily accept new formatters that do this in datetime_extras, assuming there is also some test coverage.

The daterange_compact module could help with this use case. It allows formats to specify different patterns for the start & end date. To omit either start or end date, one of the patterns (and the separator) can be left blank.

If this is to go into core, it needs tests. However, given the suggestion in #14, and the desire to not support every option/combination in core, I wonder if this is even still relevant?

This patch adds the options to the same options to DateRangeDefaultFormatter and DateRangePlainFormatter. I think this is a useful feature to have in core.

This patch is for 8.3.x.

I think this is a basic and useful feature for core, for example for creating a view for upcoming events and only show the start date.

This feature is in Drupal 7 and instead of two checkboxes there is a select with three options.

Show:
* Start date and End date (default)
* Only start date
* Only end date

This ports the 'fromto' setting from the D7 date module. I also added tests for this setting. I made the 'separator' field conditionally available with #states. There is no point providing a value for that setting when only showing one date: a separator makes only sense when showing both the start and end date. I hope I used #states in the right way.

I have expanded the DateTimeRangeTrait a bit as I noticed there was quite some duplicated code in settingsForm() and settingsSummary(). As in traits you cannot call parent::, I have aliased these methods in each field formatter class with respectively traitSettingsForm() and traitSettingsSummary(). Strictly spoken, the code in defaultSettings() is duplicated as well, but because of the small amount of duplication I left unduplicating that out.

I forgot to add the config schema changes to the patch. And because I needed to create a new patch anyway, I moved defaultSettings() to the trait as well.

I can't call it fully reviewed, but #25 passes my rigorous functional testing.

Works, have tests, #25 applies to Drupal 8.7.x-dev. I'm also using the patch and I think it's RTBC.

Confirming #25 works on 8.7.x-dev

Steps:

1. Added date range field to content type.
2. Create node and populate date range field.
3. Manage display of content type and configure date range field to show start and end date.
4. confirm node view shows both dates.
5. Manage display of content type and configure date range field to show start date.
6. confirm node view shows just start date.
7. Manage display of content type and configure date range field to show end date.
8. confirm node view shows just end date.

NW primarily for the post_update hook. Need to double check whether we need a update path to set the default value for formatter.

Still kinda neutral about whether this is needed for core proper.

1. +++ b/core/modules/datetime_range/config/schema/datetime_range.schema.yml
   @@ -31,6 +31,9 @@ field.formatter.settings.daterange_default:
   +    fromto:
   +      type: string
   +      label: 'Display'
        separator:
   

   Schema change means we need at least an empty post_update hook to ensure it gets read in.

2. +++ b/core/modules/datetime_range/src/DateTimeRangeTrait.php
   @@ -24,15 +35,19 @@ public function viewElements(FieldItemListInterface $items, $langcode) {
   -
   

   Nit, but extra change.

3. +++ b/core/modules/datetime_range/src/DateTimeRangeTrait.php
   @@ -46,4 +61,94 @@ public function viewElements(FieldItemListInterface $items, $langcode) {
   +    if ($separator = $this->getSetting('separator') && $this->getSetting('fromto') == 'both') {
   

   Nit, prefer ===

4. +++ b/core/modules/datetime_range/src/DateTimeRangeTrait.php
   @@ -46,4 +61,94 @@ public function viewElements(FieldItemListInterface $items, $langcode) {
   +  public function getFromToOptions() {
   +    return [
   

   Updating public interface, so need a CR. Not 100% sure if these helpers really need to be public?

5. +++ b/core/modules/datetime_range/src/Plugin/Field/FieldFormatter/DateRangePlainFormatter.php
   @@ -49,11 +51,16 @@ public function viewElements(FieldItemListInterface $items, $langcode) {
   +          $elements[$delta] = [];
   +          if ($this->startDateIsDisplayed()) {
   +            $elements[$delta]['start_date'] = $this->buildDate($start_date);
   +          }
   +          if ($this->startDateIsDisplayed() && $this->endDateIsDisplayed()) {
   +            $elements[$delta]['separator'] = ['#plain_text' => ' ' . $separator . ' '];
   +          }
   +          if ($this->endDateIsDisplayed()) {
   +            $elements[$delta]['end_date'] = $this->buildDate($end_date);
   +          }
   

   This code is replicated. Not sure how best to refactor this.

6. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeFieldTest.php
   @@ -1378,4 +1378,146 @@ public function testDateStorageSettings() {
   +    if ($datetime_type == DateRangeItem::DATETIME_TYPE_DATETIME) {
   

   Nit, ===

7. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeFieldTest.php
   @@ -1378,4 +1378,146 @@ public function testDateStorageSettings() {
   +    $field_formatters = [
   +      'daterange_default' => [
   +        'start_date' => '12/31/2012',
   +        'separator' => ' THESEPARATOR ',
   +        'end_date' => '06/06/2013',
   +      ],
   +      'daterange_plain' => [
   +        'start_date' => '2012-12-31',
   +        'separator' => ' THESEPARATOR ',
   +        'end_date' => '2013-06-06',
   +      ],
   +      'daterange_custom' => [
   +        'start_date' => '2012-12-31',
   +        'separator' => ' THESEPARATOR ',
   +        'end_date' => '2013-06-06',
   +      ],
   +    ];
   +    $datetime_types = [
   

   Something doesn't seem right here about testing date+time and just using the date portion using the contains assertions.

8. +++ b/core/modules/datetime_range/tests/src/Functional/DateRangeFieldTest.php
   @@ -1378,4 +1378,146 @@ public function testDateStorageSettings() {
   +      DateRangeItem::DATETIME_TYPE_DATE,
   +      DateRangeItem::DATETIME_TYPE_DATETIME,
   +    ];
   

   Need to add the allday variant.

Hi, I am trying to show the start date in views and just tried the patch #25. The options for showing start and end date appears, but they don't work for me in views. It just continues to show both start and end date. Using drupal core 8.6.0

I'm now suspecting it might not work as the field is of type: "Date time range (All day)" and not "Date" or "Date Range"

I solved it another way. In views I used "Rewrite results" for the date field with "{{ field_date_range_1__value }}" and then I reformatted the date string like this to get it as required:

function hook_preprocess_views_view_field(&$variables) {
  if ($variables['view']->id() == 'calendar_archive' && $variables['view']->current_display == 'page_1' && $variables['field']->table == 'node__field_date_range') {
    $date_string = $variables['output']->__toString();
    $date = DateTime::createFromFormat('Y-m-d\TH:i:s', $date_string);

    if ($date) {
      $variables['output'] = Drupal\Core\Render\Markup::create($date->format('d M Y'));
    }
  }
}

I patched it and I am using views to show the date range and selected the 'start date only' value, but its still showing

2019-02-08 - 2019-02-11

and I wanted to group this field, but the data was inserted :

date + time, and that is causing problem in views field grouping.

is there an option or hook where I can just show the start date and group them by start date ignoring all the time.

thank you

Patch #25 works fine for me, using 8.6.10.
It's a new site, so I don't need an update_hook, but it would be great if this could be backported, because there are many use cases for displaying start and end date (or datetime) separately.

Patch #25 works fine for 8.5.3

The patch did not work for me either using Drupal core 8.7.4.

Selecting display start date or display end date would not change the output in views.

It still showed both start and end date.

Thank you dudde, #33 worked for me.

Patch in #25 works for me as well, using 8.7.4

Patch in #25 works for me too, using 8.7.6

Would be great to see this patch getting into core!

Thanks @MegaChriz for your patch!

Why is the issue marked on "Needs work"? Drupal 8.8 will arrive very soon and the status of this issue should definitely be changed.

Regarding showing a single date in views, there is a more simple method than #33. Using 'Rewrite Results', format the raw value of the date field using Twig's date filter formats. For example:

{{ field_event_date__value|date("l, F j, Y", "America/New_York-4") }}

#41, the issue is NW because the comments in #30 need to be addressed.

Patch in #25 works for me too, using 8.7.7

#42 is a good solution, thank you

@butterwise thank you for sharing #42. It was a good solution to flexible lightweight date formatting in views.

For those wanting to do this within a field Twig template, here's how I adapted the standard field template to only render the year of the start date of the range, using the key of each item to access the item's value, via the element['#items'] array:

{% if label_hidden %}
  {% if multiple %}
    <div{{ attributes.addClass(classes, 'field--items') }}>
      {% for key, item in items %}
        <h3{{ item.attributes.addClass('field--item') }}>{{ element['#items'][key].value|date('Y') }}</h3>
      {% endfor %}
    </div>
  {% else %}
    {% for key, item in items %}
      <h3{{ attributes.addClass(classes, 'field--item') }}>{{ element['#items'][key].value|date('Y') }}</h3>
    {% endfor %}
  {% endif %}
{% else %}
  <div{{ attributes.addClass(classes) }}>
    <div{{ title_attributes.addClass(title_classes) }}>{{ label }}</div>
    {% if multiple %}
      <div class="field--items">
    {% endif %}
    {% for key, item in items %}
      <h3{{ item.attributes.addClass('field--item') }}>{{ element['#items'][key].value|date('Y') }}</h3>
    {% endfor %}
    {% if multiple %}
      </div>
    {% endif %}
  </div>
{% endif %}

patch #25 works for me in 8.9.3 version :)

Trying to get an ical feed to work, but it requires specifically formatted separate dates, which seems pretty impossible at the moment. Hope this can get in soon.

While this may work, it doesn't work as I expected it to. When I set display to "start date only" I expected it to still display the end time, but not the end date. What I really want another formatter that displays "{startdate} {starttime} {sep} {endtime}" when the start date and end date are the same date.

Because of the complexities of this, I think it's best that we get it right in contrib first, before trying to get it into core.

And FWIW, I don't agree with some of the review points in #30.

1) Why does this need an empty post_update hook? I installed a fresh site, created a node type with a Datetime Range field, created content with this node type, applied this patch, and ran 'drush updb', and it worked just fine.

2) It's unclear to me what this "Nit" is about.

3 & 6) Core does not have a standard for ===, actually, the standard is still == for PHP. See https://www.drupal.org/project/coding_standards/issues/2795691

4) Agree that these don't need to be public, but I see no harm in public getters. If we conclude we want these to public and merge it that way, then the CR will come later.

5) Agreed, something in the trait might help with this.

7 & 8) Tests could use times and all date.

This #25 patch helped me out. I´m using Drupal 8.9.13

Sharing a workaround for showing the start date only. Needed this for a month grouping for events, where the view wasn't using fields so a custom field template wasn't an option.

• In the field settings, choose 'Custom' for the formatter
• Rewrite the results as: {{ field_name | split(' - ')[0] | striptags}}

Mainly putting this here for myself so I can find it when I need it again in six months. Of course it works for the end date too if you use split(' - ')[1]. Not thrilled about it as a solution but it does work :)

I used the suggestion from #48. The patch from from #25 does not work for me, this is perhaps because I am using the Optional End Date module for this field.

When using #48, do not forget to include the classes in your template:

{%
  set classes = [
  'field',
  'field--name-' ~ field_name|clean_class,
  'field--type-' ~ field_type|clean_class,
  'field--label-' ~ label_display,
]
%}
{%
  set title_classes = [
  'field__label',
  label_display == 'visually_hidden' ? 'visually-hidden',
]
%}

Patch in #25 also does not work for me. As mentioned by others i get the config options but still shows start - end.

I am using D9.1 and field is date range with time.

used twig hack from #56.. thank you!

#25 worked for me on 9.2.7

Reading through the comments a bit closer this time and i see the issue is that people are testing (only) as a formatter for a field in a view mode - which does work. But although this adds new views field config it does not work in Views.

Patch from #25 worked for me against Drupal Core 2.7.10

Pretty sure this needs to be Needs Work. Although RTBC, it is only partially tested as these people, i suspect, are not testing in Views.

There are 2 different ways to go:

1. if the intent isn't to fix this for Views as well as basic field formatting (view mode); then it shouldn't show as an option in Views - and that should be removed

2. add the bit which supports Views

Obviously #2 is preferred.

Also, if i am wrong, and this does work in Views (although it doesn't for me and others above), please post that as part of your test results (i.e. state if testing as a basic field formatter or as a views field formatter).

Ah yes, I can confirm this is not working in views. I can see the options but no data is been outputted.

After some further testing a rebuild of my local site has got the field working, possibly some cache causing the date not to show.

Patch from #25 worked for me with views. I have drupal core 9.3.15

Patch from #25 works ONLY if i have both start_date and end_date. When end_date is null, start_date is not displayed. So i tried making end date optional, to be able to see start_date.

I have a view, that shows nodes title and field dates, format table. Field Date is setup to display only start date.
After optional_end_date module enabled (https://www.drupal.org/project/optional_end_date) i now get in view:
- both start and end date, for nodes that have both dates
- only start date, for nodes with null end date

I have core 9.4.0

Added reroll of patch #25 on Drupal 9.5.x.

I applied the patch in 69 to 9.4.1 and it does not seem to be working. I swear it worked once though but as soon as I added another date field to do the end date it stopped working. Now it doesn't work at all.

Suggestions?

Still pretty sure this does not work with Views. Not sure what the people are looking at that are suggesting it does. Perhaps post a screenshot of your views preview showing it working?

In case of confusion: This is about DateTime Range, a field that requires both start and end date.
It's not about using two separate DateTime fields or so.

I've enabled DateTime Range, and added three DateTime Range fields to a content time: with the different field settings Date and Time, Date only and Whole date.

The display of the Content type can be changed to use Display both Start and End dates, Start date only and End date only.. These are displayed correctly.

I've also created a view to display these fields. Here as well, I can choose between the three options and they are displayed correctly.

Sorry, wasn't asking if the UI was there. As reported above, everyone agrees it is. Even for a View (which your screenshot doesn't show). The suggestion was to show the Views preview showing the working output (which I'm pretty sure doesn't work).

I've just installed patch #69 on my site and after creating a new view and adding a timerange field the attached screenshot shows my views preview content.

I have used #25 before and it worked too. Though I had the feeling that the field config in the view sometimes was ... 'partially stuck'? ... because changing the date format was not reflected in the result and it was always rendered in iso format.

I am reviewing issues with status RTBC.

The issue summary is brief. I have added the standard template which needs to be completed. It should provide the proposed resolution so a reviewer or committer can check that the patch is doing what has been agreed to. Adding tag.

I skimmed the comments and see a patch review in #30 but I don't see evidence that that has been addressed. In #69 there is re-roll which is a good first step when a patch no longer applies. That should be followed up by responding to all earlier code reviews that have yet to be done.

I see that patch has a test, so no need to add that tag.

Since this issue changes the user interface, screenshots should be in the Issue Summary. This helps the reviewers and committers.

I have not done a code review.

Setting to NW

applied patch in #69 unfortunately against 9.4.x. It adds the drop down selection in the view, which is perfect, but it still outputs the format with start and end date.

I had the same issue as #57 and possibly #76, due to the fact that Optional End Date is overriding the formatter's viewElements() method.
I therefore refactored the actual rendering code into a separate method renderStartEnd(), which can be called from contrib modules extending DateTimeRangeTrait without affecting other code.

Also, I renamed some of the aliased methods (see #23) so they don't override their parents and no aliasing is necessary.

Appending a patch to Optional End Date to call the new rendering function here, since it is currently depending on this issue. Will open a separate issue in the module's issue queue once this is commited.

Leaving as NW due to #75.

#77 works perfect. Thank you!

Fix custom command fail for patch #77.

Made some updates to the issue summary as per #75.

Adressing #30 (1-6) and trying to fix the failing tests.

Fixed failing tests and addressed #30 (7 and 8).
Also updating the patch for Optional End Date.

Workaround: in Rewrite result use "{{ field_name__value|date('U')|format_date('format_name') }}"

The Needs Review Queue Bot tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

The workaround in #87 is such a good tip. This is just what I needed.
{{ field_reservation_time__value|date('U') }}
{{ field_reservation_time__end_value|date('U') }}

Awesome work done here +1 Apart from the work around commented, can someone of the patch and discussion involved sum up what the bottom line of to-do's is, so that others can chime in to help? Last comment in that manner was #75. Would love to know more about the back and forth thoughts on this.

Reroll of #86 for current 10.1.x (interdiff empty).
I'm re-adding the patch for optional_end_date module as well, for more visibility.

Fixing PHPStan error from #92.

the latest patch seems also 11.x compatible. so Back to Review

Not sure if an empty post update hook will get the needed changes.

Will need upgrade path tests to verify.

Added an upgrade path and a test for the new formatter setting.

Thanks! Upgrade paths are there so removing tag.

Think last thing we will need is a change record, maybe release notes.

Added a change record and a release note.

On Standard install on 11.x
Installed daterange module
Applied patch
Ran post_update and that ran fine.
Add a daterange field to the Article content type
Verified the config options are there.
Set to only show Start date

Created an Article and fill in daterange field
Verified start date is only shown.

Update to only show end date.
Verified end date is only shown.

Updated to show both
Verified both are shown.

Also seems points in #30 have been address

Hiding old patch files for clarity.

Posted some feedback on the MR

Looking good!! just one nit.

Appears all threads have been answered.

Good progress on this! Posted couple more comments on the MR.

Tested feature manually and reviewed implemented code. Changes looks good to me.

Added comment on the MR regarding the update path.

Changed the update path.

Appears additional feedback has been addressed. Don't see any outstanding tags or anything.

Update hook ran fine locally and tests are all green.

ReRTBC

Posted a review on the MR

I have addressed the feedback, except https://git.drupalcode.org/project/drupal/-/merge_requests/4841#note_234897. Does anyone have any alternative way of doing this.

Here I've worked on a small module, which basically introduces a new format which has this option dropdown to choose from start or end date to show on the frontend.

https://www.drupal.org/project/start_end_date_format

All the threads have been addressed.

I don't think this should be added back to the core, if it was removed from Drupal 8 upwards, there must have been a good reason for this. I think its best suited to be added via some contrib module. Here I've worked on a small module that provides a formatter from where you can choose which date value to show Start or End date. https://www.drupal.org/project/start_end_date_format

@ahmed.raza if you can find that ticket where it was removed and the reason it was removed that would help, but currently this ticket has momentum and several active participants.

Retested same as #102

On Standard install on 11.x
Installed daterange module
Applied patch
Ran post_update and that ran fine.
Add a daterange field to the Article content type
Verified the config options are there.
Set to only show Start date

Created an Article and fill in daterange field
Verified start date is only shown.

Update to only show end date.
Verified end date is only shown.

Updated to show both
Verified both are shown.

Believe all feedback has been addressed as well. Think the 10.2 window may have been missed but think it could be a highlight of 10.3?

This is off-topic, but has there been any thought of adding the start and end date values as separate field choices, similar to how for multivalue fields your choices are field_myvalue and field_myvalue:delta?

I'm triaging RTBC issues. I read the IS, skimmed the comments from my last visit here (#75), the MR and the change record.

Thank you for the release note snippet. In the future, it could be less detailed because it will be linked to the change record which can have all the details. After looking at the MR I think the images in the change record are outdated because the casing of the new text has changed.

#120 questions whether this should be done because it was removed from Drupal 8. There has been no investigation into that history. However, a product manager has been reviewing this issue so that is a good indication that this is a desired feature.

I see that this is a very large change 12 files + 728 − 69, larger than the recommended change size. That makes this challenging. Is there any way to reduce the size? I made two comments on the MR and both require work.

There are also other unresolved threads in the MR some of which were not minor changes.

Still, this is in good shape and close!

Updated the change record.

I see that this is a very large change 12 files + 728 − 69, larger than the recommended change size. That makes this challenging. Is there any way to reduce the size? I made two comments on the MR and both require work.

not sure about what can be done.

There are also other unresolved threads in the MR some of which were not minor changes.

All the threads are addressed, but I cannot close them, please close them who created the MR.

Other than this, I have addressed all the feedbacks.

Believe additional feedback has been addressed.

@quietone there's #3392124: Subsystem maintainer permissions on GitLab where hopefully submaintainers can help core committers by closing threads. But currently no one but the person who opened the MR can close the threads.

The current MR worked perfectly for a field formatter in a view. Thank you!

MR !4841 does not apply cleanly in Drupal 10.2.2

Various use statements are missing in datetime_range.module.
Once these are copy&paste from unpatched file, this patch works great!

Thank you ♥

Ah, this is my third visit here for triage. The recent changes are from my feedback and they have been addressed.

Leaving at RTBC.

Overall this looks very solid - I had one comment on the presave/post update on the MR.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Restoring status.

Depending when this lands can probably open a follow up ticket immediately for 11.x. removal right?

Depending when this lands can probably open a follow up ticket immediately for 11.x. removal right?

No - because the post update will have to be removed once database fixtures are updated, and that should happen only once when we're not going to commit any more to-be-removed updates to 10.3 (probably very close to the 10.3 beta deadline).

Thanks for adding the @todo.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!

Did my best with issue credit here, but it's a long issue with lots of contributors, so apologies if anyone got overlooked.

Should this be included in the 10.3 highlights list?

113 followers over 9 years I would definitely vote yes for highlighting it

This broke PHP 8.1. It does not support DateTimeRangeDisplayOptions::START_DATE->value - see https://stitcher.io/blog/new-in-php-82#fetch-properties-of-enums-in-cons...

Have to revert sorry.

Let's rework this so it's 8.1 compatible, commit to both branches, then we can open a follow-up to use the PHP 8.2 feature.

Converted the enum back to an interface, which should be 8.1 compatible.

Opened #3425141: Use enum in Datetime range formatter for the php 8.2 part.

Please make test data providers static methods.

- Made test data providers static methods.
- Some CS for more "readability"
- Added follow-up issue url for @todo comment.

put back on Needs Review and Version 11.x - as the MR is against this version

p.s. for "no reason" there was a Nightwatch failure for tests/Drupal/Nightwatch/Tests/Olivero/oliveroPrimaryTabsTest.js
but it passed ... on a second attempt.

feedback appears addressed

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

it seems there was update that brroke things on CSpell https://www.drupal.org/project/drupal/issues/3420742
updated and put back on previous status.

Glad to see this rolling! +1 for all the hard work in here. Also RTBC from me by local testing.

Committed/pushed to 11.x and cherry-picked to 10.3.x, thanks!