Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent Behavior in PrimeReact DataTable Filters for "Date is before" and "Date is after" #7543

Closed
the-pratik opened this issue Jan 2, 2025 · 6 comments
Labels
Resolution: By Design The behavior in the issue is by design and the component exhibits the expected behavior

Comments

@the-pratik
Copy link

Describe the bug

When using the filtering feature in PrimeReact's DataTable, there is an inconsistency in how the "Date is before" and "Date is after" conditions handle the selected date:

"Date is before" Filter:

The filter excludes the selected date.

For example, if the selected date is 09/15/2020, the filter only shows rows with dates before 09/15/2020 (i.e., 09/14/2020 and earlier).

DateIsBefore

"Date is after" Filter:

The filter includes the selected date.

For example, if the selected date is 09/15/2020, the filter shows rows with dates on or after 09/15/2020 (i.e., including 09/15/2020).

DateIsAfter

This inconsistency in handling inclusivity can confuse users, as they might expect both filters to either include or exclude the selected date consistently.

Reproducer

https://stackblitz.com/edit/vitejs-vite-y5nolsku?file=src%2FAdvancedDataTable.jsx

System Information

System: 
  OS: Windows 11 10.0.22621 
  CPU: (8) x64 11th Gen Intel(R) Core(TM) i5-1145G7 @ 2.60GHz 
  Memory: 3.78 GB / 15.69 GB 

Binaries: 
  Node: 14.17.5 - C:\Program Files\nodejs\node.EXE 
  npm: 6.14.14 - C:\Program Files\nodejs\npm.CMD 

Browsers: 
  Edge: Chromium (130.0.2849.80) 
  Internet Explorer: 11.0.22621.3527 

npmPackages: 
  primereact: ^10.6.6 => 10.6.6 
  react: ^18.3.1 => 18.3.1

Steps to reproduce the behavior

  1. Open a DataTable with a "Date" column and enable filtering.
  2. Apply the "Date is before" filter with a specific date (e.g., 09/15/2020).
  3. Observe that rows with dates earlier than 09/15/2020 are displayed, and 09/15/2020 is excluded.
  4. Apply the "Date is after" filter with the same date (e.g., 09/15/2020).
  5. Observe that rows with dates on or after 09/15/2020 are displayed, and 09/15/2020 is included.

Expected behavior

Both "Date is before" and "Date is after" filters should handle the selected date consistently.

For example:
If "Date is before" excludes the selected date, then "Date is after" should also exclude it.
Alternatively, if one includes the selected date, the other should include it as well.

Current Behavior:

"Date is before" excludes the selected date.
"Date is after" includes the selected date.

@the-pratik the-pratik added the Status: Needs Triage Issue will be reviewed by Core Team and a relevant label will be added as soon as possible label Jan 2, 2025
@melloware
Copy link
Member

@the-pratik you can see the code is properly doing < and > logic.

dateBefore(value, filter) {
if (filter === undefined || filter === null) {
return true;
}
if (value === undefined || value === null) {
return false;
}
return value.getTime() < filter.getTime();
},
dateAfter(value, filter) {
if (filter === undefined || filter === null) {
return true;
}
if (value === undefined || value === null) {
return false;
}
return value.getTime() > filter.getTime();
}
},

If I had to guess the underlying Date object its time in milliseconds is possibly off by Browser Timezone vs UTC? It should be easy for you to debug in your debugger and see in the debugger the values of return value.getTime() > filter.getTime();

@melloware melloware added Resolution: By Design The behavior in the issue is by design and the component exhibits the expected behavior and removed Status: Needs Triage Issue will be reviewed by Core Team and a relevant label will be added as soon as possible labels Jan 2, 2025
@melloware
Copy link
Member

melloware commented Jan 2, 2025

When I debug its exactly what I see here is Date Before and After in code

Date Sat Sep 12 2015 20:00:00 GMT-0400 (Eastern Daylight Time)
 
Date Sat Sep 12 2015 00:00:00 GMT-0400 (Eastern Daylight Time)

Notice one is 20:00:00 mightnight in my timezone with UTC (offset) and the other is 00:00:00 midnight in my timezone (no offset)

Date Sat Sep 12 2015 20:00:00 GMT-0400 (Eastern Daylight Time) IS BEFORE Date Sat Sep 12 2015 00:00:00 GMT-0400 (Eastern Daylight Time) = FALSE

Date Sat Sep 12 2015 20:00:00 GMT-0400 (Eastern Daylight Time) IS AFTER Date Sat Sep 12 2015 00:00:00 GMT-0400 (Eastern Daylight Time) = TRUE

@melloware
Copy link
Member

The reason is the Showcase is converting JSON date: '2015-09-13', to new Date('2015-09-13') which my browser is making Date Sat Sep 12 2015 20:00:00 GMT-0400 (Eastern Daylight Time) with the four hour offset for my Timezone.

@the-pratik
Copy link
Author

the-pratik commented Jan 2, 2025

The reason is the Showcase is converting JSON date: '2015-09-13', to new Date('2015-09-13') which my browser is making Date Sat Sep 12 2015 20:00:00 GMT-0400 (Eastern Daylight Time) with the four hour offset for my Timezone.

I see, need to consider time as well when comparing the two dates. Thanks for your explanation and help!

@melloware
Copy link
Member

melloware commented Jan 2, 2025

Yep i try not to use STrings in my JSON for dates I always make it a full timestamp or Date object or Epoch Long. It can never be wrong then! Even if you mean a simple date like 2015-09-13 always be explicit about its point in time.

@melloware melloware closed this as not planned Won't fix, can't repro, duplicate, stale Jan 2, 2025
@the-pratik
Copy link
Author

Yep i try not to use STrings in my JSON for dates I always make it a full timestamp or Date object or Epoch Long. It can never be wrong then! Even if you mean a simple date like 2015-09-13 always be explicit about its point in time.

Yes I'll keep in mind. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: By Design The behavior in the issue is by design and the component exhibits the expected behavior
Projects
None yet
Development

No branches or pull requests

2 participants