Views filtering of optional end dates

Blank end dates are automatically populated with the same value as the start date. See #874322: To Date & All Day Date Handling & #523218: Default value for To date: Blank should stay blank for more details.

This might work, but IIRC, I don't think two date fields can be compared (can't do start date = end date in views)
( start date <= now AND start date = end date )
OR
( start date <= now AND end date >= now )

I've just encountered this issue too, for me this is definitely a bug.
Because I use already the date views module I decided to extend the filter handler in a very pragmatic way.
If the filter "empty" or "not empty" is used for an end-date value the handler adds a comparison with the from-date value now.
Now the filter seems to work as expected :)

Looks like the failed tests are related to Migrate (Class 'Migration' not found) and not the changes I made.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

Any luck on this? It's totally what I'm looking for too :)

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

Subscribed.

The patch in #3 did not pass tests of date repeat and date migrate, which I dont use in my site, so I decided to apply it regardless. Works great, but it's still a hack around the main problem: Optional empty end date should be NULL

I have a hunch that the automated tests are failing regardless of the patch (e.g. current HEAD is broken for unrelated reasons).

In the site I'm working on the expected behavior for the exposed date filter is that a "between" search with a blank end date should be treated as a ">=start_date" search. (Using "now" as the end date is wrong because we also want to see future items.) That makes the most sense to me for any exposed date filter that's set to "between." Setting it the same as the start date is presumptuous and semantically confusing for users. At the moment a blank end date in the form is just causing it to do no date filtering at all, which must be a bug.

(I'm using Date module 7.x-2.6)

Could please someone confirm that the patch works? I can't imagine that the test fails have something to do with the patch. They fail because the Migrate class couldn't be enabled - but this patch has nothing to do with Migrate.
If nobody has encountered any errors with the patch and it solves the problem for you, please set this issue to RTBC.

Can confirm the patch works as advertised. Have been running this in prod for nearly a month.

Patch #3 worked for me. Thanks @dat-peter!

But with this patch, we can't published a content just one day because start date = end date is equal to no end date...

The best way in my opinion is really not populate end date when the checkbox "Define an end date" is uncheck so we can test if there is really no end date or if we choose to set the end date same as the start date.
In association with a help text in date field configuration to say that an uncheck checkbox "Define an end date" means published all the time.

What did you think about it ?

+1 to #27

+1 to #27 too

Guy's if you say +1 to #27 this means "needs work". And for the maintainers of views is not really useful to have a patch that's not ready marked as RTBC ;)

Btw. I'm absolutely fine with this, but currently it's unlikely that I find some time to dig deeper and fix it.
Thus, if someone has an idea how to fix it please feel free to take over.

#3: date-views-filter-handler-end-date-fix-1635810-3.patch queued for re-testing.

The issue is not so simple. There can be multiple reasons for the lack of an end date:

1. Something begins, and will end when something else is put in its place, e.g., a policy.

2. Something begins, and will end on some future date when it's done, e.g., an open-ended stage run or construction with no fixed schedule.

For items 1 and 2, if there must be something in the end date, the most future date possible would seem to be most appropriate, e.g., Dec. 31, 9999, or whatever the maximum date value is. (Sorry if I'm setting us up for a Y10K problem.) Views could already test for this.

The ideal English date display for items 1 and 2 would be: Effective [start date]

3. Something begins, and will probably end on the same day, when the work for that day is done, e.g., a public hearing, or at worst case in the wee hours after midnight early the next morning.

4. There is also the idea that something is being published, and it will always have been published, but at some point it won't be particularly interesting that it's been published, e.g., a press release that is not about something that has a definite end time. (But we can't just drop the start and end dates off, because there are press releases that do concern matters with specific end times.)

For item 3 or 4, if there must be something in the end date, having the same start and end date would seem to be appropriate, and issue #1635810 would be needed to solve it.

The ideal English date display for items 3 and 4 would be: [start date]

For completeness:

5. There is a definite interesting, typically future, start date and a definite interesting end date, both known, e.g., definitely scheduled construction.

This of course is what date entry is best set up for, as there is no ambiguity, and is already solved. Enter the start and end date.

The ideal English date display would be: [start date] - [end date] or [start date] to [end date] or [start date] through [end date]

6. The start date is in the relatively distant past. Whether or not it is known, there is no particular reason to display it, e.g., a bus route that is about to be discontinued.

In this case, it's easy to know what to put in for the end date, but not for the start date. Ideally, the start date would be the most past date it is possible to display in a Drupal date field, e.g., Jan. 1, 0001. Again, we would never want to display this date.

The ideal English date display would be: Through [end date]

That said, one could reasonably argue that item 6 is just a contrary way of stating item 1. Still, it would be nice to be able to express item 6 in case there's a use case, and to be consistent with how I'm proposing we handle end date.

I think it is too much to ask staff to have to put in Dec. 31, 9999, or put in identical times for start and end, so ideally in place of the check box Show End Date, there would instead be radio buttons:

• Indefinite end date (default default)
• Indefinite same-day end time
• Indefinite start date/definite end-date
• Definite start and end dates

where the default could be overridden by the administrator by content type.

It's a whole 'nother issue for #1 and #2 remembering to go back and put in an end date if and when it finally happens. While that's outside the scope of this discussion, use of a most-future end date would allow such cases to be easily reported to whoever is responsible for checking for the up-to-date-ness of the website.

To solve the problem of filtering on start date == end date, I'm using the new views_handler_filter_fields_compare, but with the attached patch.

I added two additional fields to my view: one is the start date only and another is the end date only. These two fields can be compared using the above-mentioned filter.

The trick is that filter_fields_compare only pays attention to one SQL column per field. Start-end dates have two columns in each field, of course. So, I added a test to the filter to check if the views field option for end date was set. This is hacky. I think the views field handler in the date module is weird.

Hi,
I tryed the #3 patch but it do not work for me.
When the end date is not inserted it will be set to start date value so I solved this with this code:

function hook_views_query_alter(&$view, &$query) {
  if( $view->name === 'name' && $view->current_display === 'block_1'){
    $query->where[2]['conditions'][1] = array(
        'field' => "field_data_field_xxxxx.field_date_value2 = field_data_field_xxxxx.field_date_value",
        'value' => array(),
        'operator' => 'formula'
    ); 
  }
}

but you have to be sure that the 'field_data_field_xxxxx' key is present in
$query->tables
and in
$query->table_queue
arrays.

I hope this will help someone.

Why not add an extra column in the date field tables, that stores the state of the "display end date" checkbox?

This would not cause trouble with the current behavior, but would allow to check against this column within a boolean view handler.

Note: this field should only be added when the end date field if optional.

Here is a patch that matches the proposal exposed in comment 41.

There is an update hook for the existing fields.

The "has_todate" column is an integer, and I didn't modify the views handler to specify a boolean handler, but it can be easily improved, if necessary.

Seems like the tests related to the migrate module are outdated...

I'm going to suggest that if we need the end date to be "never" instead of being populated with the start date, there are a couple of potential solutions already existing. One option is to provide some value that stands in for "never" in the end date (such as 9/9/9999) and then do special display handling for that date. (Users can't be expected to enter 9/9/9999 in exposed forms, but we can instead show a "never" checkbox that hides the end date field.)

Another option is to add a boolean "No End Date" checkbox field to your content type (and your view exposed form) and do some extra filtering (with Views-Or module if needed) based on that.

I happen to think, however, that equating No End Date with Start Date was a bad early decision. Date module should be able to distinguish between a single date field and a date range field, and to filter date ranges more smartly.

If Date itself cannot now distinguish between a range with no end date and a range with a single date, clearly it needs fixing. These are not the same thing.

What #44 says. The behaviour is unexpected to everyone in this thread, so it is probably to many more, and so it should be remedied.

Suggestion (rough, and without digging into code so far):
Turn "End date" from a bool field into an option field (0, 1, 2) where 0 and 1 stay unchanged but 2 means "never ending".
Depending on how it is saved internally, probably add a bool column to the field data table, saying "field never ends".

While this would not break any existing use, with some simple changes (views handler, display handler) date field would work as expected for both people who wouldn't consider the status quo an issue and those who do.

I desperately lack time, however, if there were a serious signal to have this in a next release, I would invest some hours for this.

Also sorry in case I should have overlooked an existing similar suggestion in the thread. :)

ITMT, #38 is working for me:
- Apply the patch to the 'Views' module (!)
- Add your date field as a FIELD (you might exclude it from the display)
- Add the "Global comparison", and add the two fields.

#41 provides a solution nicely.

The patch however has an issue during the update of old field values. It does the reverse of what you expect.

This should fix the update issue.

Thanks B-Prod!

Wonder why this test didn't get run. All the results are gone too.

Will this make a test happen?

Guess not.

The patch prevents migrations to effected fields as the new column is not covered for them and it can not be null.

Here is the same patch from #47 with an updated hook number so that it runs on the current stable date module.

How about approaching this by modifying the op_empty operator in date_views_filter_handler_simple ?

Sorry, an error got into the patch. This one is better

Thanks so much #57 It works fine

doesn't apply to date 2.10.