-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Fixed date filter #15214
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
Fixed date filter #15214
Conversation
| setInternalDate(newDate); | ||
|
|
||
| const newFilterValue = newDate?.toISOString() ?? ''; | ||
|
|
||
| const formattedDateTime = formatDateTimeString({ | ||
| value: newDate?.toISOString(), | ||
| timeZone, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: The date filter value is created with newDate.toISOString(), which can cause the date to shift by a day for users in non-UTC timezones, leading to incorrect filtering.
(Severity: High 0.70 | Confidence: 0.95)
🔍 Detailed Analysis
When a user in a non-UTC timezone selects a date for a filter, the value is generated using newDate.toISOString(). This converts the locally constructed Date object to a UTC string, which can shift the date by one day (e.g., January 1st becomes December 31st). This leads to incorrect filter results, as the backend receives a different date than the one selected by the user. Other parts of the application correctly handle this by constructing the date with new Date(Date.UTC(...)) to prevent such timezone-related mismatches.
💡 Suggested Fix
To ensure the date is not affected by the user's local timezone, construct the date value using Date.UTC. Replace newDate?.toISOString() with newDate ? new Date(Date.UTC(newDate.getFullYear(), newDate.getMonth(), newDate.getDate())).toISOString() : ''.
🤖 Prompt for AI Agent
Fix this bug. In
packages/twenty-front/src/modules/object-record/object-filter-dropdown/components/ObjectFilterDropdownDateInput.tsx
at lines 54-60: When a user in a non-UTC timezone selects a date for a filter, the value
is generated using `newDate.toISOString()`. This converts the locally constructed `Date`
object to a UTC string, which can shift the date by one day (e.g., January 1st becomes
December 31st). This leads to incorrect filter results, as the backend receives a
different date than the one selected by the user. Other parts of the application
correctly handle this by constructing the date with `new Date(Date.UTC(...))` to prevent
such timezone-related mismatches.
Did we get this right? 👍 / 👎 to inform future reviews.
|
Greptile encountered an error while reviewing this PR. Please reach out to [email protected] for assistance. |
|
🚀 Preview Environment Ready! Your preview environment is available at: http://bore.pub:9510 This environment will automatically shut down when the PR is closed or after 5 hours. |
|
@lucasbordeau, I have tested and the behavior on DATE_TIME is correct! Regarding DATE, it does not seems right:
|
95ba979 to
1d0dd66
Compare
1d0dd66 to
9cbb17e
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
📊 API Changes ReportGraphQL Schema ChangesGraphQL Schema Changes[log] [log] ✖ Input field ObjectRecordFilterInput.createdAt changed type from DateFilter to DateTimeFilter GraphQL Metadata Schema ChangesGraphQL Metadata Schema Changes[log] [log] ✖ Type Date was removed
|
7648d98 to
07a8af7
Compare
07a8af7 to
d25a4ac
Compare
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
This PR fixes a bug with date filters that behave differently when the timezone of the server changes.
Fixes #14689