Date filter selecting the same day in between filter returns no results

Discussion on this on several issues:
#2832652: Date between filter is filtering wrong
#2832058: Add time to views date filter
#2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter

And that (of course) all leads back to #2369119: Fatal error when trying to save a View with grouped filters using other than string values.

The problem is that we use the start of the day for both start and end date. To get a result that is more in line with expectations we should probably use 00:00:00 for the start date and 23:59:59 for the end date when generating a timestamp.

All the referenced issues are working on fixes that at least make it clear to end users that the start of day is used or to make the used time configurable.

Not sure if we should look into modifying the default used time or just see if the other issues manage to make it configurable.

The offending code is in filter/Date:

  public function validateValidTime(&$form, FormStateInterface $form_state, $operator, $value) {
    $operators = $this->operators();

    if ($operators[$operator]['values'] == 1) {
      $convert = strtotime($value['value']); // I has a sad :(
      if (!empty($form['value']) && ($convert == -1 || $convert === FALSE)) {
        $form_state->setError($form['value'], $this->t('Invalid date format.'));
      }
    }
    elseif ($operators[$operator]['values'] == 2) {
      $min = strtotime($value['min']);
      if ($min == -1 || $min === FALSE) {
        $form_state->setError($form['min'], $this->t('Invalid date format.'));
      }
      $max = strtotime($value['max']);
      if ($max == -1 || $max === FALSE) {
        $form_state->setError($form['max'], $this->t('Invalid date format.'));
      }
    }
  }

If you enter a date w/o a time portion, then strtotime uses sets it to 00:00:00 (unlike what \DateTime does). The problem figuring out user intent here with a function that will try to handle any input.

#2627512: Datetime Views plugins don't support timezones is also related here, and that does some major rework on some of the low level date handling.

#2647292: Date/time Views filter tries strotime() relative to Unix epoch is also related.

From steps to reproduce:

> Now chose twice the same day

I would argue that this bug affects all date exposed filters using the between operator, because using strtotime will always have the end date stamp for the absolute beginning of the day (00:00), so no items from the end day will ever be included.

I do understand the logical argument that a views filter between the dates 2019-01-01 and 2019-01-02 should only include items from 2019-01-01, since logically 2019-01-02 starts at 00:00. However our users won't see it that way.

The "offending" line is in core/modules/views/src/Plugin/views/filter/Date.php#170

$b = intval(strtotime($this->value['max'], 0));

I will add a patch to change this behavior if your users agree with ours. I don't expect this to be accepted, since this is probably a much bigger discussion, but we need a quick(ish) fix. Perhaps we need a checkbox with the text "include end date in the result set", but that also sounds a bit over-engineered.

Added simple fix to the max date for including it in the max date.

This has a patch, but still needs tests. Setting to "Needs work".

A possible problem I see with #10 is that by adding a full day it will also add results that start at 'NextDay 00:00:00', so we would have to take one second off.
Which in turn could lead to events starting at 'ThisDay 23:59:59' on a day we have a leap second falling off (not likely I know :D)

Edit: Hmm maybe BETWEEN handles that right, not sure. Needs tests.....

I think this should be handled in strtotime function, as this patch

Rerolled for 9.2.x , with some changes to tests based on new implementation from #15.

Thanks.

When I tried to apply the patch from comment 17 on Drupal 9.2.4, the changes made to the test file FilterDateTest.php for me failed to apply. I have re rolled the patch and that seems to have done the job for me.

1. +++ b/core/modules/views/src/Plugin/views/filter/Date.php
   @@ -167,7 +167,7 @@ public function acceptExposedInput($input) {
   +    $b = intval(strtotime($this->value['max'] . ' +1 day', 0)) - 1;
   

   Shouldn't we only do this when there is no time component on the passed value?

2. +++ b/core/modules/views/src/Plugin/views/filter/Date.php
   @@ -176,7 +176,8 @@ protected function opBetween($field) {
   -    // It is necessary to do it this way because $a and $b are formulas when using an offset.
   +    // It is necessary to do it this way because $a and $b
   +    // are formulas when using an offset.
   

   Unrelated change, so we should take that out

And some more test coverage of edge cases would be nice.

The patch still is valid on D11.1

The problem occurs and is solved in both cases: with Date filter 'date' option and with 'offset' option. Updating summary.
A test is added, but #20 is still relevant.

checked the issue, still exists. Created a patch below is that it contains current timestamp added to offsets to resolve the offset issue.

MR in #28 didn’t fix the actual issue where, if the same date is provided in the filter, it won’t filter the full day as expected.

As the problem lies in:

• For offset type with identical min and max (e.g., +1 day):
• ***CURRENT_TIME***+86400 AND ***CURRENT_TIME***+86400), only the exact timestamp is matched.
• This results in no records unless an exact match exists.
• For date type, with identical min and max (e.g., 2025-03-03):
• Both $a and $b will be same 2025-03-03 00:00:00 with no result

Solution:

• Offset Type:
• If min === max and the offset is a whole day (% 86400 === 0), adjust max to end of day (+86399 seconds).
• Retains original behavior for offsets with time (e.g., +1 day 4 hours).
• Date Type:
• When max has no time (H:i:s = 00:00:00), adjust max to 23:59:59 for full-day matching

Addressed time component check and added test for edge cases mentioned in #20. Moving to NR.

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.

Moving to NR.

@Lendude I’ve updated the logic so that the “end of day” adjustment is applied only when the min and max values are on the same calendar date.
This fixes the issue in existing Views where the “until” filter was returning an extra day’s results.

However, this change introduces a new scenario:

• A filter with min date = 2025-08-08 and max date = 2025-08-08 will now return the same results as min date = 2025-08-08 and max date = 2025-08-09, since both cases include the entire day of 2025-08-08.

Another solution I'm thinking for the issue is to remove this logic entirely and simply validate that the max value must always be greater than the min value, either by time offset or by date, to avoid identical results for different ranges.

What are your thoughts on this?

Think validating max is greater then min makes sense here.