format should be preserved and not removed.

Should we just pass the timezone in dateI18n? Not sure what's the expected to show: the timezone based on the WP installation or the browser one?

@Mustafabharmal this is what format is used for:

This is an important bugfix to address in time for WordPress 7.0 (schedule (we've entered the "beta period" today). Mustafa, let us know if you'll have the availability to work on this.

Fixed this in 60d0161

Still not sure about the proper way to solve this. If I'm not wrong everything around WP works around a set timezone from the settings and here in DataForm controls it seems we have the only case where we use type="datetime-local".

We already use DateCalendar in which we pass the timezone from the settings and not the local timezone from the browser. Should we consider using TimePicker component and remove type="datetime-local", like publish dates do etc..?

@aduth I think you recently worked for some date/timezone issues and you might have some feedback. I'll also ping @tyxla for thoughts.

Thanks for the ping @ntsekouras 🙌

I'm actually not sure we should be using datetime-local at all.

AFAIK, datetime-local is timezone-agnostic; it doesn't really care about the timezone. Why can this be an issue? Because in WordPress, there are potentially three different time zones in play:

• The WordPress site timezone - configured in Settings > General (e.g., America/New_York, or a UTC offset like UTC-5).
• UTC - WordPress stores dates in both local and GMT (post_date vs post_date_gmt).
• The user's browser timezone - the OS/browser timezone of the person editing, which may differ from the site timezone.

The concrete issue can be that when you put a datetime string like 2026-02-22T14:00 into a datetime-local input, there's no way to communicate which timezone that value represents. If the REST API returns a date in UTC, but the site is configured for Europe/Berlin (UTC+1), and the user's browser is in America/Los_Angeles (UTC-8), the displayed time is ambiguous, the user has no indication of what timezone the value refers to, and the browser doesn't adjust it. And it gets even worse if the site's timezone gets changed. Not to mention that DST transitions can't be accounted for correctly, because those also depend on specific time zones.

In some instances, this won't matter (when the user and site timezone are the same, or when the field actually has no relation to the site's timezone), but I can imagine plenty of cases where this will actually cause subtle bugs and user confusion.

Ideally, we don't have to mess with timezones, or we just don't care about timezones (hopefully this is the case here). However, if we do care about the timezone, we might have to use a component that actually understands timezones. It is a bit unfortunate that we don't really have an alternative to datetime-local in the components library that just gives you a single field out of the box.

On the contrary, it's worth mentioning that after @mirka's recent changes in #74815 we actually advise folks to use the time & date components with caution, encouraging usage of the native date or datetime-local inputs.

I know @aduth's mind has been in this area a lot these days, so I'm curious what he can add to this discussion.

I'm actually not sure we should be using datetime-local at all.

there's no way to communicate which timezone

If it's ambiguous in context, I think the label or description could be used to communicate the time zone the control is showing. Or even the prefix slot or something. But in any case, I don't think it's technically necessary for the datetime-local itself to understand time zones — the conversion can happen outside as long as we choose intentionally which time zone to use, and keep things consistent end to end.

What's actually a problem sometimes is the time format aspect of it, where <input> types can show either 12-hour or 24-hour format, depending on the browser implementation, and there's no way to change or detect that reliably. @mtias and I discussed this recently, and agreed that we may eventually need a custom time picker component and a new WP user preference for 12/24-hour formatting. But that's not really a time zone problem, like we have here.

Yeah, I think the thing that's confusing for me (and users?) here is that it's unclear what time this is actually following: is it the site time, my local time, or something else (e.g. UTC)? The DateTimePicker component follows the timezone as configured in @wordpress/date (the site time) and explicitly displays this as a label (see screenshot). As @mirka mentioned, this happens outside the time control itself to provide the context that's missing in the input field itself.

In this case, judging by the bug described in #75511 (out-of-sync with the shown chip value) and how this was previously fixed in #72756, I guess it's supposed to represent local time, and that's how the data itself is filtered (unconfirmed). In that framing, it makes sense to me to address the regression specifically by converting the value to local time. Though I would strongly encourage some regression test coverage that asserts this expected behavior.

Separately from the regression, I'm sure there's some improvements we could make to address the ambiguity of timezone, like showing timezone labels with the time field, making timezone configuration on DataViews or following @wordpress/date setting (if reasonable), internal refactoring to consider timezoneless times via Temporal (with polyfill), etc.

So how do we move forward with this? One of the main reasons I suggested TimePicker above, was about showing the UTC to help users reason with what they see. As others suggested we could have this info in the label of the field and align the input value with the filter value to show local times, which I agree with (not use TimePicker).

I'm wondering if by using local time for the input and filter chip (without a timezone label) we could end up with results that could be hard to reason with, when using fields that do not show local time. If I'm not wrong, that's the case for date field.

I agree that the current datetime field is confusing in that the user does not know the timezone. I've created #76194 to track this to completion (but it's not something we need to land in beta).