Repository navigation
[6.x] Compare date query params against UTC-stored values - #19963
Open
nfourtythree wants to merge 1 commit into
Open
nfourtythree wants to merge 1 commit into
nfourtythree wants to merge 1 commit into
Conversation
nfourtythree
requested review from
riasvdv
and
a balanced review from Copilot
October 13, 2026 17:30
riasvdv
approved these changes
Oct 13, 2026
riasvdv
left a comment
Contributor
There was a problem hiding this comment.
I knew in my heart that I missed one or more of these 😅 let's hope it's one
📚 Storybook previews@craftcms/ui — open Storybook No changed components detected in this Storybook. resources/js — open Storybook No changed components detected in this Storybook. |
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused normalization change is consistent with UTC persistence behavior and has appropriate regression coverage.
0 open findings
What changed in this PR
Normalizes date-query parameters to UTC before comparison with UTC-stored database values.
Changes:
- Converts parsed date parameters using
Query::prepareDateForDb(). - Updates fixtures to persist UTC values.
- Adds timezone-offset regression coverage.
| File | Description |
|---|---|
src/Support/Query.php |
Normalizes date filters to UTC. |
tests/Feature/Support/QueryTest.php |
Covers local-day boundaries and zoned values. |
tests/Feature/Element/Queries/Concerns/User/QueriesUserPropertiesTest.php |
Uses UTC login-date fixtures. |
tests/Feature/Element/Queries/Concerns/QueriesFieldsTest.php |
Uses UTC element timestamp fixtures. |
tests/Feature/Element/Queries/Concerns/Entry/QueriesEntryDatesTest.php |
Uses UTC entry-date fixtures. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Query::whereDateParam()parsed the param in the system time zone and cast the Carbon instance straight to a string, but date columns are stored in UTC. So date filters were off by the time zone offset. WithAmerica/Los_Angeles,postDate('>= today')compared against00:00:00instead of07:00:00. This affects every element query date param (postDate,before/after,dateCreated,lastLoginDate, Date fields, etc.) and the Filter panel's date condition rules.The value now goes through
Query::prepareDateForDb()after parsing. Strings without a zone are still read as system time, then converted to UTC.The existing tests only passed because their factories wrote local-time values through Eloquent, which matched the bug. They now write via
Query::prepareDateForDb(), as entry, asset and login saves do.QueryTestalso gets a row at 11pm the previous day (local), plus aDateTimepassed in another zone, to cover the offset.