DatetimeWidget: whole_day events lose one day due to date-only value discarding safe noon time before serialization

[wesleybl]

Describe the bug
When creating or editing an Event content type with the whole_day option enabled, the date selected in the calendar can be persisted as the previous day, depending on the user's timezone (specifically, timezones behind UTC, such as Brazil - UTC-3).

This happens because DatetimeWidget's onDateChange handler builds an internal moment object with a safe default time of noon (defaultTimeDateOnly = { hour: 12, minute: 0, second: 0 }) specifically to avoid timezone rollover issues, but then discards that time when isDateOnly is true, serializing only base.format('YYYY-MM-DD') (e.g. "2026-07-08") instead of a full ISO string.

Since this date-only string has no timezone information, the backend normalizes it assuming UTC midnight (2026-07-08T00:00:00Z). When the frontend later reads this value back and converts it to the user's local timezone (e.g. UTC-3), it rolls back to the previous day (2026-07-07T21:00:00-03:00), so the UI displays the wrong date.

To Reproduce
Steps to reproduce the behavior:

1. Set your browser/OS timezone to one behind UTC (e.g. America/Sao_Paulo, UTC-3).
2. Go to an Event content type add/edit form in Volto.
3. Enable the "Whole day" option.
4. Set the Start (or End) date to any date, e.g. July 8, 2026.
5. Save the item.
6. See that the date field now shows July 7, 2026 instead of July 8, 2026.

Expected behavior
The date selected by the user for a whole-day event should be preserved regardless of the browser's timezone, and should not shift by one day when reloaded.

Screenshots
N/A

Software (please complete the following information):

• OS: any
• Browser: any
• Volto Version: 19
• Plone Version: 6.2
• Plone REST API Version: 10

Additional context
The relevant code is in DatetimeWidget's onDateChange handler:

const onDateChange = (date) => {
    if (date) {
      const isDateOnly = getDateOnly();
      const base = (getInternalValue() || moment.default()).set({
        year: date.year(),
        month: date.month(),
        date: date.date(),
        ...(isDateOnly ? defaultTimeDateOnly : {}),
      });
      const dateValue = isDateOnly
        ? base.format('YYYY-MM-DD')   // <- discards the safe noon time set above
        : base.toISOString();
      onChange(id, dateValue);
    }
    setIsDefault(false);
  };

volto/packages/volto/src/components/manage/Widgets/DatetimeWidget.jsx

Lines 137 to 140 in 8b576ce

	const dateValue = isDateOnly
	? base.format('YYYY-MM-DD')
	: base.toISOString();
	onChange(id, dateValue);

The defaultTimeDateOnly object (noon local time) appears to have been introduced precisely to avoid date rollover when converting to/from UTC, but the isDateOnly branch bypasses it by formatting only the date portion. A possible fix is to always serialize with base.toISOString(), keeping the whole_day flag purely as a UI concern (hiding the time picker) rather than changing what is sent to the backend:

const dateValue = base.toISOString();
onChange(id, dateValue);

This preserves the calendar day across virtually all timezones, since noon ± any realistic UTC offset (up to ±12h) does not cross a day boundary.

[stevepiercy]

This preserves the calendar day across virtually all timezones, since noon ± any realistic UTC offset (up to ±12h) does not cross a day boundary.

There are timezones of +13 and +14 in the south Pacific Ocean.

I also see in there the following with moment, which can cause unexpected behavior. I don't know if it actually does, because I didn't check for the presence of getInternalValue.

      const base = (getInternalValue() || moment.default()).set({

See also:

• Hide date/time fields when whole_day or open_end is checked in Event form #7662
• Event: "whole day" and "open end" have no effect #3243
• PLIP: Event end date should comply with RFC 5545 iCalendar Products.CMFPlone#4310
• PLIP #4115: Enhance timezone support in UI for plone.app.event based types Products.CMFPlone#4115

[davisagli]

Note: there's work in progress from the Buschenschank Sprint to store a timezone for the event start and end fields (see plone/plone.restapi#2018, #8304). It's not implemented yet but a remaining requirement of that work will be updating event views to display the values in the selected timezone.

I expect that work will solve this because the deserializer will then have the necessary information to deserialize in the intended timezone.

[wesleybl]

There are timezones of +13 and +14 in the south Pacific Ocean.

Even if we don't have a solution for that, we can solve 99% of the problems by sending the timezone to the backend.

[wesleybl]

Note: there's work in progress from the Buschenschank Sprint to store a timezone for the event start and end fields (see plone/plone.restapi#2018, #8304). It's not implemented yet but a remaining requirement of that work will be updating event views to display the values in the selected timezone.

@davisagli Great! But until we have an implementation, the solution proposed here is simple and can solve the problem temporarily.

[davisagli]

@wesleybl It would be a regression if there are cases where this widget is used where only a date with no time is accepted. (I know the deserializer for the start and end fields will handle the change, but the widget can also be used in other places.)

[wesleybl]

@davisagli But what about the whole_day case? It doesn't require the user to select a time. However, we still need to send the time, including the timezone.

[wesleybl]

Could it be another widget?

[stevepiercy]

I firmly believe that we should all get into agreement on how to address this matter for all of Plone in a consistent manner in the discussion in plone/Products.CMFPlone#4310.

In the meanwhile, an add-on that implements a custom "all day" widget is an option.

[wesleybl]

@stevepiercy I agree that it would be good to evolve the way Plone handles event dates. However, that is a broad proposal that might take a long time to implement and could possibly only be applied in Plone 6.3 (or perhaps even Plone 7). What I am proposing here is simply a straightforward solution to a problem with the current way event dates are handled.

[davisagli]

@wesleybl My point is: currently if someone has a field with widget: "date" or if they pass the dateOnly prop to the widget, they can expect to get a value in the format YYYY-MM-DD. Your proposed change would change it to include the time, so it would be a breaking change. So even if we decide we want that change, it can happen at the earliest in Volto 20.

On the other hand the changes I have in progress can be backwards compatible: the timezone is used if it's there, otherwise it does nothing different than before.

I would also be open to a solution like yours that restricts itself to changing the serialization only for the event start and end fields, because we know they are Datetime fields in the backend with a deserializer that can handle the time value.

I'll comment on plone/Products.CMFPlone#4310 separately since it only partially overlaps with the topic here.

[wesleybl]

On the other hand the changes I have in progress can be backwards compatible: the timezone is used if it's there, otherwise it does nothing different than before.

@davisagli Yes, I saw that your solution has the same problem reported here.

[wesleybl]

My point is: currently if someone has a field with widget: "date" or if they pass the dateOnly prop to the widget, they can expect to get a value in the format YYYY-MM-DD

@davisagli And if we run the test on the view:

if whole_day{
Do not apply the browser's time zone
}

[wesleybl]

@davisagli And if we run the test on the view:

if whole_day{
Do not apply the browser's time zone
}

@davisagli That wouldn't help much, because the date is also incorrect on the edit form. We would have to modify the widget as well.