Timestamp field type uses numeric filter and argument plugins rather than date in Views

This seems a duplicate of #2648950: [PP-2] Use form element of type date instead textfield when selecting a date in an exposed filter. Closing this, but feel free to reopen if you think that this is a different issue,

In https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/view... the filter is set to date, which is correct. But this is later overridden in https://git.drupalcode.org/project/drupal/-/blob/9.5.x/core/modules/view... ($attributes['type'] is int) and the filter is changed to numeric.

As a quick test I did this:

diff --git a/core/modules/views/views.views.inc b/core/modules/views/views.views.inc
index de79773321..9c7fe8f6e6 100644
--- a/core/modules/views/views.views.inc
+++ b/core/modules/views/views.views.inc
@@ -605,6 +605,9 @@ function views_field_default_views_data(FieldStorageConfigInterface $field_stora
         if ($field_storage->getType() == 'boolean') {
           $filter = 'boolean';
         }
+        elseif ($field_storage->getType() == 'timestamp') {
+          $filter = 'date';
+        }
         break;
 
       case 'blob':

..and it seems to work, so I think that's where it gets twisted.

This issue present in Drupal 10.0.x as well. Any update expected for this issue in core itself?

Should probably move this to 11.x now.

I tried the hack in #7 but it didn't work for me under 10.x

I have had some success in combating the problem by using https://www.drupal.org/project/better_exposed_filters but it's not perfect.

This is a very annoying bug for filtering dates (manifesting as timestamps) by exposed filter... :/

#7 works with me in conjunction with the date_popup module.

#7 works for me using Drupal 10.3.6, patch is attached.
It should work with Drupal 11 as the views.views.inc file is the same for these 2 releases.

Thanks for working on this but issues should be in MRs vs patches and will need test coverage.

I've opened an MR.

Like #13 the patch does the job for me in Drupal 10.3.6.
Thanks for the MR #16
I was happy when I found this issue and its solution - after a couple of hours! :-)

Minor refactor of MR for code readability. Rebased MR. Test coverage still required.

Added a screenshot to the steps to reproduce. It shows the form where the date time field with timestamp formatter is selected. The field is being added to the 'Article' content type.

This MR is no longer necessary as the required changes have already been addressed in the source branch. The fix for the issue can be found in EntityViewsData.php.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/views...

#21 if you're sure it's been fixed, this issue status can be set to fixed or closed..?

Can someone please test issue against 11.x?
Also, do we still need tests for this?

Tested the scenario again 11
- Steps taken
-- Created a content type and added a custom field of type timestamp.
-- Created a view that displays the content type
-- Added a filter for the created timestamp field.
- Test Failed

Even after applying the change from this Drupal core commit, which sets the filter type to date, the mapping still does not work correctly for custom fields.
I am investigating further to resolve this issue.

Related issue: https://www.drupal.org/node/2337515

We can alter the numeric date field to actual date time field through drupal's hook_form_views_exposed_form_alter
below is the code using the hook

function views_form_views_exposed_form_alter(&$form, FormStateInterface $form_state, $form_id){
  if($form_id=="views_exposed_form"){
    $form["field_published_date_time_stamp_value"]["#type"]='datetime';
  }
}

Below are the screen shots of before and after applying the drupal hook

Before

After

I closed the old MR because the .inc file it was modifying has been changed into a service class. There's no point in rebasing that.

I started to write a test and then decided "There is no way I'm writing a Unit test that covers an entire, complicated, nearly 500 line function." So I split the offending code out into its own function in the same class. I tried to leave it as unmolested as possible - no arbitrary code formatting changes. That way it should be easier to verify that not much changed.

With UI changes need before/after screenshots added to the summary, depending how big the change may need UX sign off or a CR

Screenshots added.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. 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.

Rebased

Sorry, this was in NR status.

Left a comment on the MR

Left comments on the MR.

Feedback was addressed.

Feedback appears to be have been addressed thanks @dcam!

Posted some small stuff on the MR.

Meanwhile, is the IS up to date here? I didn't see anything in the patch that would result in the indicated UI. If it does, that's some serious magic. (I mean, it is Views, so maybe.)

Does this issue apply only to Views?

Finally, I think it would need a CR. Even if it's a bugfix, it may result in a behavior change in some circumstances.

defaultFieldImplementation() is too big as it is. If we want this code to be more testable, then it needs to be broken up. This is just one step toward doing that. No, it isn't strictly necessary from a functionality standpoint. But I will argue that it's necessary for sanity.

Should we have a followup to do the rest?

Meanwhile, is the IS up to date here? I didn't see anything in the patch that would result in the indicated UI.

Yes. The addition of the condition...

        elseif ($field_type == 'timestamp') {
          $filter = 'date';
        }

...enables the date filter for timestamps. I understand if that's hard to see because I moved all that code.

Does this issue apply only to Views?

I'm not sure what other part of Core this problem might apply to. If there is one, then I think that should be handled in a separate issue.

Finally, I think it would need a CR. Even if it's a bugfix, it may result in a behavior change in some circumstances.

I added a CR at https://www.drupal.org/node/3538264.

We ran into this when we used a timestamp field and had a surprising deficit of functionality.

I think it's confusing that relative dates work on Datetime fields, but not on Timestamps, so it would be great to get this over the line.

Can the follow up mentioned be created

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. 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.

The follow-up has been added at #3568536: Break up FieldViewsDataProvider::defaultFieldImplementation().

I should have moved this back to RTBC when I created the follow-up issue.

Adding a monster related issue, and also a minor concern on the MR.

I don't have an answer for the question of whether we should change it for the argument as well. It's understandable why this issue has only been about the filter plugin. This is more of a user-facing issue. For the record, I couldn't find an existing issue about the argument plugin.

Considering that changing the argument plugin would increase the potential for disruption to existing views I'm not willing to make that call unilaterally. Tagging for subsystem maintainer review due to the question on the MR.

#2544832: Views argument for the datetime module should use maths. is the closest I know of about the date argument question. Maybe we should indeed resurrect that from PMNMI and handle my concern over there.

Meanwhile, there have been a series of these "use a more useful filter plugin" issues. E.g. the linked one about dates, or #3347343: Add Views EntityReference filter to support better UX for exposed filters. There were all sorts of hassles with potential disruptions, what to do about existing views, etc, etc. I'm not clear why this issue can so easily change this, without similar concerns. 😅

Oh right, see #3517303: [PP-1] Use the new 'entity_reference' Views filter in EntityViewsData::processViewsDataForEntityReference() more directly about disruption and what to do about it. That proposes focusing on #3458099: Views handler loading should respect configuration as the way to truly avoid potential disruption.

A few nits plus I agree with @dww that we should also fix the argument plugin here as it's a tiny change and that also touches the UI. Unfortunately at the moment the date filter argument doesn't support any additional input options (offset) as the filter does so no UI changes there really but maybe eventually as it should really for consistency so better to cover it early.
Removing the "Needs subsystem maintainer review" tag, I can review again if needed, hopefully VBO D8+ and date_filter modules creator will be enough ;)