DataViews: use local time in summary filter and default render for datetime fields #72756

oandregal · 2025-10-28T19:16:36Z

What?

Displays the datetime field using the local timezone.

Why?

There is a discrepancy in how we displayed datetime fields:

the Edit control used the local timezone
the filter summary displays the datetime as it is (no transformation to local timezone)
the default render function for the datetime type displays the datetime as it is (no transformation to local timezone)

How?

This switches both the filter summary and the default render function for the datetime to using the local timezone as well.

Testing Instructions

Visit the storybook (npm run storybook:dev).
Open the story at "DataViews > Field Types > Datetime".
Verify that the filter, the default render, and the Edit control for the field "Datetime" all display the same time (in your local timezone).

oandregal · 2025-10-28T19:21:46Z

packages/dataviews/src/field-types/datetime.tsx

 			<RenderFromElements item={ item } field={ field } />
 		) : (
-			field.getValue( { item } )
+			new Date( field.getValue( { item } ) ).toLocaleString()


Perhaps this should be done in the default getValue generated for the field type: by doing that, it won't interfere with the getValue provided by the field authors that may have already dealt with this.

This is okay as it is: field authors can provide its own render. getValue is focused on data retrieval and render on data display. By doing this, we enable field authors to provide its own getValue to retrieve the data from whenever it is, but they still benefit from the default render in local time.

oandregal · 2025-10-28T19:24:23Z

packages/dataviews/src/components/dataviews-filters/filter.tsx

 			return filterInView?.value?.includes( element.value );
 		} );
 	} else if ( filterInView?.value !== undefined ) {
+		// Find the field to check its type


This is a proof of concept. Consider using getValue from the field (see note below) instead. Note the filter's input-widget prepares the field in a specific way (because it doesn't have access to any item).

This is good as it is, see #72756 (comment)

github-actions · 2025-10-29T08:08:37Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: oandregal <[email protected]>
Co-authored-by: jorgefilipecosta <[email protected]>
Co-authored-by: jimjasson <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

oandregal · 2025-10-29T08:09:39Z

This is a good first step to provide good defaults. We need to work on enabling field authors to provide their own timezone, in case they want to use settings from the environment (WordPress, etc.) — that should be used by the filter summary, render, and Edit functions.

github-actions · 2025-10-29T08:37:50Z

Flaky tests detected in 5ae96ea.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18901222701
📝 Reported issues:

[Flaky Test] correctly applies dynamic allowed blocks restrictions #51220 in /test/e2e/specs/editor/plugins/inner-blocks-allowed-blocks.spec.js

jorgefilipecosta

Left some comments for consideration but non blockers, things tested well for me 👍

jorgefilipecosta · 2025-10-30T09:28:12Z

packages/dataviews/src/field-types/datetime.tsx

 			<RenderFromElements item={ item } field={ field } />
 		) : (
-			field.getValue( { item } )
+			new Date( field.getValue( { item } ) ).toLocaleString()


Here we creating a date without any try catch, while above we have a try catch, I guess we should also add one here.

Right now, if an invalid data is returned by field.getValue( { item } ), I see "invalid date" as the field's value. This is the same for the date field too. If we add a try-catch here to return field.getValue( { item } ) in case it is not a date, then let's make this consistent in the date field too.

jorgefilipecosta · 2025-10-30T09:30:45Z

packages/dataviews/src/components/dataviews-filters/filter.tsx

+
+		if ( field?.type === 'datetime' && typeof label === 'string' ) {
+			try {
+				label = new Date( label ).toLocaleString();


If label is null it will return the epoch (Jan 1, 1970), not sure if we want to handle this case as we are using ts and label is not expected to be null.

Yeah, label won't be null at this point because we check for its type above (type of null would be object so it won't go into this conditional).

jorgefilipecosta · 2025-10-30T09:32:28Z

packages/dataviews/src/field-types/datetime.tsx

 			<RenderFromElements item={ item } field={ field } />
 		) : (
-			field.getValue( { item } )
+			new Date( field.getValue( { item } ) ).toLocaleString()


If the date is undefined we will render "Invalid date" not sure if we want to render an empty string instead?

When the date is empty it is not that it is invalid, it may even be expected, but I guess we can also leave to the consumers the decision on how to handle this case, as they are the ones who know the meaning of an empty date.

I agree -- an empty date could be used to represent the TBA/TBD state.

jimjasson · 2025-10-30T13:23:31Z

Looking good @oandregal !

I tested this on Storybook while being in a UTC + 2 timezone and confirmed that date/time values are now consistent:

and filtered results are returned correctly:

I had some thoughts around the "invalid date" state, but @jorgefilipecosta had already raised all of them so I followed-up on the existing comments.

I also ran the PR changes by Cursor for an extra 👀 and the only thing that came up was adding a try/catch block here, which was already mentioned.

oandregal · 2025-10-31T10:26:39Z

Thanks for the reviews @jimjasson and @jorgefilipecosta

I've pushed 94465de to better handle invalid dates, and the render method displays empty for them. I think this was all, so I'll set this to auto-merge when tests pass. Please, be welcome to leave a review if there's something you'd like me to address — even if it's post-merge.

oandregal self-assigned this Oct 28, 2025

oandregal added [Type] Bug An existing feature does not function as intended [Feature] DataViews Work surrounding upgrading and evolving views in the site editor and beyond labels Oct 28, 2025

oandregal commented Oct 28, 2025

View reviewed changes

oandregal mentioned this pull request Oct 28, 2025

datetime DataViews field shows inconsistent values for non-UTC users #72659

Closed

6 tasks

oandregal added 3 commits October 29, 2025 09:07

Datetime: by default, display in the local timezone

8fe158b

Filter: display local timezone

047688f

Add changelog

e63c659

oandregal force-pushed the fix/datetime-timezone branch from 5036924 to e63c659 Compare October 29, 2025 08:08

oandregal marked this pull request as ready for review October 29, 2025 08:08

Fix changelog

5ae96ea

oandregal changed the title ~~Fix/datetime timezone~~ DataViews: use local time in summary filter and default render for datetime fields Oct 29, 2025

jorgefilipecosta approved these changes Oct 30, 2025

View reviewed changes

Better handling of invalid dates

94465de

oandregal enabled auto-merge (squash) October 31, 2025 10:26

oandregal merged commit 504db92 into trunk Oct 31, 2025
34 checks passed

oandregal deleted the fix/datetime-timezone branch October 31, 2025 11:01

github-actions bot added this to the Gutenberg 22.1 milestone Oct 31, 2025

DataViews: use local time in summary filter and default render for datetime fields #72756

DataViews: use local time in summary filter and default render for datetime fields #72756

Conversation

oandregal commented Oct 28, 2025

What?

Why?

How?

Testing Instructions

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oandregal commented Oct 29, 2025

Uh oh!

github-actions bot commented Oct 29, 2025

Uh oh!

jorgefilipecosta left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jimjasson commented Oct 30, 2025

Uh oh!

oandregal commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

github-actions bot commented Oct 29, 2025 •

edited

Loading