Timestamp field type uses numeric filter plugin rather than date filter plugin

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.

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

dcam → changed the visibility of the branch 3204558-timestamp-field-type to hidden.

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 → .