[Bug] Round system.datetime grid filter to whole day#1864
Merged
Conversation
Not up to standards ⛔
|
markus-moser
force-pushed
the
fix/issue-1055-system-date-filter-naive-tz
branch
3 times, most recently
from
260c4a9 to
5411acf
Compare
markus-moser
changed the title
`DateTimeFilter::apply` passed `roundToDay=false` to the trait, which makes GDI's `DateFilter` collapse `gte` and `lte` to the same instant for `on` queries — never matching a stored datetime with a non-zero time component. The filter UI is date-only, so whole-day match is the right semantic. `DateFilter` (for `system.date`) already passes `true`; this aligns `DateTimeFilter`.
markus-moser
force-pushed
the
fix/issue-1055-system-date-filter-naive-tz
branch
from
5411acf to
dcd7d31
Compare
markus-moser
changed the title
|
markus-moser
added a commit
to pimcore/studio-ui-bundle
that referenced
this pull request
May 29, 2026
…e semantics
Pimcore date/datetime fields have two timezone modes:
- respectTimezone=true → absolute instant, displayed in the browser timezone
- respectTimezone=false → wall-clock anchored to the configured server timezone
Studio was reading respect=false fields with dayjs.unix() in browser-local time,
so the displayed wall-clock drifted by the browser↔server offset on reload. The
respect=true path already behaved correctly.
This wires useSettings().timezone + the field's respect-timezone semantics through
every surface where these fields are rendered or edited:
- DatePicker.tsx: new respectTimezone prop; toDayJs(value, _, {respectTimezone,
timezone}) anchors the input to the server wall-clock via dayjs.tz()
- date-picker-utils.ts: toServerWallClock helper; formatFilterDate(timestamp,
respectTimezone) emits ISO+offset for respect=true, UTC ISO of the picked
calendar day for respect=false (aligns with the generic-data-index pipeline,
which indexes naive date strings as UTC)
- abstract/date/datetime object-data types: propagate respectTimezone; new
DateGridCellPreview / DatetimeGridCellPreview render the grid cell with the
server timezone when respect=false; fix datetime columnType union
- date-time.ts: optional timeZone passed through to Intl
- field-filter date component: reads field config via useDynamicFilter and
uses formatFilterDate
- batch-edit datetime component: reads field config from batchEdit and forwards
respectTimezone + outputFormat + showTime to the shared DatePicker; same
component handles both date and datetime since the backend FrontendType enum
has a single DATETIME entry
Tests: 20 new Jest cases in date-picker-utils.test.ts (toServerWallClock /
toDayJs / fromDayJs / formatFilterDate) and 5 in date-time.test.ts (timeZone
forwarding to Intl). All pure-function tests, fast and host-tz-independent.
Companion PR in studio-backend-bundle: pimcore/studio-backend-bundle#1864.
markus-moser
added a commit
to pimcore/studio-ui-bundle
that referenced
this pull request
May 29, 2026
…e semantics
Pimcore date/datetime fields have two timezone modes:
- respectTimezone=true → absolute instant, displayed in the browser timezone
- respectTimezone=false → wall-clock anchored to the configured server timezone
Studio was reading respect=false fields with dayjs.unix() in browser-local time,
so the displayed wall-clock drifted by the browser↔server offset on reload. The
respect=true path already behaved correctly.
This wires useSettings().timezone + the field's respect-timezone semantics through
every surface where these fields are rendered or edited:
- DatePicker.tsx: new respectTimezone prop; toDayJs(value, _, {respectTimezone,
timezone}) anchors the input to the server wall-clock via dayjs.tz()
- date-picker-utils.ts: toServerWallClock helper; formatFilterDate(timestamp,
respectTimezone) emits ISO+offset for respect=true, UTC ISO of the picked
calendar day for respect=false (aligns with the generic-data-index pipeline,
which indexes naive date strings as UTC)
- abstract/date/datetime object-data types: propagate respectTimezone; new
DateGridCellPreview / DatetimeGridCellPreview render the grid cell with the
server timezone when respect=false; fix datetime columnType union
- date-time.ts: optional timeZone passed through to Intl
- field-filter date component: reads field config via useDynamicFilter and
uses formatFilterDate
- batch-edit datetime component: reads field config from batchEdit and forwards
respectTimezone + outputFormat + showTime to the shared DatePicker; same
component handles both date and datetime since the backend FrontendType enum
has a single DATETIME entry
Tests: 20 new Jest cases in date-picker-utils.test.ts (toServerWallClock /
toDayJs / fromDayJs / formatFilterDate) and 5 in date-time.test.ts (timeZone
forwarding to Intl). All pure-function tests, fast and host-tz-independent.
Companion PR in studio-backend-bundle: pimcore/studio-backend-bundle#1864.
markus-moser
added a commit
to pimcore/studio-ui-bundle
that referenced
this pull request
May 29, 2026
…e semantics
Pimcore date/datetime fields have two timezone modes:
- respectTimezone=true → absolute instant, displayed in the browser timezone
- respectTimezone=false → wall-clock anchored to the configured server timezone
Studio was reading respect=false fields with dayjs.unix() in browser-local time,
so the displayed wall-clock drifted by the browser↔server offset on reload. The
respect=true path already behaved correctly.
This wires useSettings().timezone + the field's respect-timezone semantics through
every surface where these fields are rendered or edited:
- DatePicker.tsx: new respectTimezone prop; toDayJs(value, _, {respectTimezone,
timezone}) anchors the input to the server wall-clock via dayjs.tz()
- date-picker-utils.ts: toServerWallClock helper; formatFilterDate(timestamp,
respectTimezone) emits ISO+offset for respect=true, UTC ISO of the picked
calendar day for respect=false (aligns with the generic-data-index pipeline,
which indexes naive date strings as UTC)
- abstract/date/datetime object-data types: propagate respectTimezone; new
DateGridCellPreview / DatetimeGridCellPreview render the grid cell with the
server timezone when respect=false; fix datetime columnType union
- date-time.ts: optional timeZone passed through to Intl
- field-filter date component: reads field config via useDynamicFilter and
uses formatFilterDate
- batch-edit datetime component: reads field config from batchEdit and forwards
respectTimezone + outputFormat + showTime to the shared DatePicker; same
component handles both date and datetime since the backend FrontendType enum
has a single DATETIME entry
Tests: 20 new Jest cases in date-picker-utils.test.ts (toServerWallClock /
toDayJs / fromDayJs / formatFilterDate) and 5 in date-time.test.ts (timeZone
forwarding to Intl). All pure-function tests, fast and host-tz-independent.
Companion PR in studio-backend-bundle: pimcore/studio-backend-bundle#1864.
markus-moser
added a commit
to pimcore/studio-ui-bundle
that referenced
this pull request
May 29, 2026
…e semantics
Pimcore date/datetime fields have two timezone modes:
- respectTimezone=true → absolute instant, displayed in the browser timezone
- respectTimezone=false → wall-clock anchored to the configured server timezone
Studio was reading respect=false fields with dayjs.unix() in browser-local time,
so the displayed wall-clock drifted by the browser↔server offset on reload. The
respect=true path already behaved correctly.
This wires useSettings().timezone + the field's respect-timezone semantics through
every surface where these fields are rendered or edited:
- DatePicker.tsx: new respectTimezone prop; toDayJs(value, _, {respectTimezone,
timezone}) anchors the input to the server wall-clock via dayjs.tz()
- date-picker-utils.ts: toServerWallClock helper; formatFilterDate(timestamp,
respectTimezone) emits ISO+offset for respect=true, UTC ISO of the picked
calendar day for respect=false (aligns with the generic-data-index pipeline,
which indexes naive date strings as UTC)
- abstract/date/datetime object-data types: propagate respectTimezone; new
DateGridCellPreview / DatetimeGridCellPreview render the grid cell with the
server timezone when respect=false; fix datetime columnType union
- date-time.ts: optional timeZone passed through to Intl
- field-filter date component: reads field config via useDynamicFilter and
uses formatFilterDate
- batch-edit datetime component: reads field config from batchEdit and forwards
respectTimezone + outputFormat + showTime to the shared DatePicker; same
component handles both date and datetime since the backend FrontendType enum
has a single DATETIME entry
Tests: 20 new Jest cases in date-picker-utils.test.ts (toServerWallClock /
toDayJs / fromDayJs / formatFilterDate) and 5 in date-time.test.ts (timeZone
forwarding to Intl). All pure-function tests, fast and host-tz-independent.
Companion PR in studio-backend-bundle: pimcore/studio-backend-bundle#1864.
markus-moser
added a commit
to pimcore/studio-ui-bundle
that referenced
this pull request
May 29, 2026
…ickers Fixes #1055 and #1056. #1055 — Date/datetime fields with respectTimezone=false (or date columnType:'date') are wall-clock values anchored to the configured server timezone. Studio was reading them as browser-local instants, so the displayed wall-clock drifted by the browser↔server offset on every reload. Wires useSettings().timezone and the respectTimezone semantics through the detail editor, grid cell preview, grid filter, inline edit, and batch edit (the latter via getBatchEditComponent on the data-object date/datetime abstract type). #1056 — Grid filter date pickers displayed values in hardcoded 'YYYY-MM-DD' format regardless of the user's locale. Replaced the explicit format prop with a formatDisplayValue fallback (Intl, locale-aware) for both DatePicker and DateRangePicker, so the filter inputs now follow the user's locale like the editor already does. Backend companion: pimcore/studio-backend-bundle#1864.
lukmzig
approved these changes
Jun 3, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
DateTimeFilter::applypassesroundToDay=false, so GDI collapsesgte/lteto the same instant foronqueries and never matches a stored datetime with a non-zero time component. The filter UI is date-only, so whole-day match is the right semantic —DateFilter(forsystem.date) already does this.Companion to the timezone-handling fix in pimcore/studio-ui-bundle#3646.