mui-x [data grid] column type "dateTime" and built in operator after is not filtering properly.

Steps to reproduce

Steps:

Open this link to live example: (required)
Visit https://v6.mui.com/x/react-data-grid/filtering/
Make visible "Updated on" by Column selector panel
Sort "Updated on" by descending
Apply filter with same date, hour, minutes as the top sorted row

Current behavior

Rows that match the same hour and minute are excluded from the results.

I’ve attached a screen recording to illustrate the issue more clearly.

Thanks for taking a look!

Expected behavior

Rows with the same hour and minute as the filter value should be visible in the filtered results.

Context

No response

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

System:
    OS: macOS 26.0
  Binaries:
    Node: 22.16.0 - /Users/juseonghyeok/.local/state/fnm_multishells/3161_1760577476637/bin/node
    npm: 10.9.2 - /Users/juseonghyeok/.local/state/fnm_multishells/3161_1760577476637/bin/npm
    pnpm: 10.13.1 - /Users/juseonghyeok/.local/state/fnm_multishells/3161_1760577476637/bin/pnpm (we use pnpm)
  Browsers:
    Chrome: 141.0.7390.108
  npmPackages:
    @emotion/react: ^11.11.4 => 11.14.0 
    @emotion/styled: ^11.11.0 => 11.14.1 
    @mui/lab: ^5.0.0-alpha.140 => 5.0.0-alpha.177 
    @mui/material: ^5.15.14 => 5.18.0 
    @mui/x-data-grid-premium: ^6.19.4 => 6.19.4 
    @mui/x-date-pickers: ^6.19.4 => 6.19.4 
    @mui/x-license-pro: ^6.10.2 => 6.10.2 
    @mui/x-tree-view: ^6.0.0-alpha.1 => 6.17.0 
    @types/react: ^18.2.14 => 18.3.24 
    react: ^18.2.0 => 18.3.1 
    react-dom: ^18.2.0 => 18.3.1 
    typescript: ^5.0.2 => 5.9.2

Search keywords: "after" filedOperator on type of dateTime column incorrect comparison

Oct 16 '25 05:10 shrewdact

@shrewdact In the given example, since the "Updated on" column is sorted in descending order, which means that the highest value is at the top.

Then, when we apply a filter of "Updated on" "is after" "date in first row", it does correctly filter out all the values because the date in the first row is actually the latest date and there is no date after it.

Did I understand the example correctly?

Oct 26 '25 23:10 MBilalShafi

Let me clear the issue.

Description When applying a filter using “Updated on” → “is after” → 2025-10-16 02:09 PM, records updated later than that time (including seconds) are incorrectly excluded from the filtered results.

Based on the filter condition, 02:09 PM should be interpreted as 02:09:00 PM, and rows with timestamps greater than that value should remain visible. However, rows updated after that timestamp (with seconds included) are being filtered out.

Steps to Reproduce 1. Apply a filter: • Column: Updated on • Condition: is after • Value: 2025-10-16 02:09 PM 2. Inspect the filtered result list.

Expected Behavior Rows with timestamps later than 2025-10-16 02:09:00 PM, such as those including seconds (e.g., 02:09:56 PM), should appear in the filtered results.

Actual Behavior Rows updated after 02:09 PM with seconds (e.g., 02:09:56 PM) are excluded from the results.

Example Row Being Filtered Out

Name Updated On Kyle Jones 10/16/2025 02:09:56 PM

Screenshots / References

(Previously attached screenshot showing the row and filter condition)

Environment • Platform: GitHub (or internal system — adjust as needed) • Browser: (e.g., Chrome 129.0.x) • Timezone settings: (if relevant)

Additional Notes It seems the filter may be ignoring seconds precision when evaluating the is after condition.

Oct 29 '25 00:10 shrewdact

All right ... I can confirm that the isAfter operator does not filter by second, but since there is the onOrAfter operator as well this would actually make sense. There currently is no way of adding seconds to the datetime input manually, so the only way to allow for this detailed filtering is by providing a custom input that is capable of handling seconds

cc @MBilalShafi

Oct 30 '25 14:10 michelengelen

@joserodolfofreitas considering that there is the onOrAfter operator isn't this behavior expected?

Nov 05 '25 15:11 michelengelen

I think I've found the root cause of the issue, it appears to be:

https://github.com/mui/mui-x/blob/2423e2fd491c837ce5d30fbf6c34913c15ac2cb9/packages/x-data-grid/src/colDef/gridDateOperators.ts#L44-L46

The seconds are being truncated from both the filter value (should be OK) and row values (causes the issue).

So when you filter with "is after 02:09 PM":

// Filter value gets truncated (this should be fine since we can't select seconds in filter input anyways)
date.setSeconds(0, 0);  // "02:09" → "02:09:00"

// But row values also get truncated (this is the bug!)
dateCopy.setSeconds(0, 0);  // "02:09:56" → "02:09:00"

// So we're comparing: 02:09:00 > 02:09:00 → false ❌
// When we should compare: 02:09:56 > 02:09:00 → true ✅

Possible Fix

We could simply remove the row value truncation (line 45) for datetime comparisons. This keeps the filter interpretation at :00 seconds while preserving the actual row timestamps.

One Concern

This would change how the is and not operators work:

Current: is 02:09 matches anything from 02:09:00 to 02:09:59
After fix: is 02:09 would only match exactly 02:09:00

So probably we should we keep the truncation only for equality operators and remove from the others. WDYT @michelengelen?

Nov 05 '25 21:11 MBilalShafi