datetime-picker

Most entries in this reference are field widgets: components you activate with widget="..." in a backend view. datetime-picker is the exception. If you write widget="datetime-picker" on a form view field, nothing happens, because the name is never registered in the fields registry.

What ships under this name is a frontend interaction in the web module. On public website pages, Odoo scans the DOM for elements matching the selector [data-widget='datetime-picker'] and mounts the same calendar picker service the backend uses (datetime_picker) onto each match. The element's existing value is parsed with the user's locale (parseDate or parseDateTime), and optional minimum and maximum bounds are deserialized from data attributes.

In Odoo core you meet it on survey pages, where deadline inputs carry data-widget="datetime-picker" data-widget-type="date", and in the partner assignment portal.

For anyone building customer facing forms on an Odoo website, this is the zero JavaScript way to get a proper date picker: one data attribute on the input and visitors get the same polished calendar employees see in the backend, localized to their language and date format.

The practical win is consistency. Portal deadline forms, event registration extras and custom snippet forms all pick dates the same way, and the values arrive in formats the server side parsing already understands, which kills a whole class of my customer typed 13/02/2026 bugs.

A date only input as the survey templates ship it:

<input type="text" data-widget="datetime-picker" data-widget-type="date"
       name="date_deadline" class="datetimepicker-input form-control"/>

A full datetime input with bounds, in a custom QWeb template:

<input type="text" data-widget="datetime-picker"
       data-min-date="2026-01-01 00:00:00"
       data-max-date="2026-12-31 23:59:59"/>

Omitting data-widget-type gives the datetime behavior; there is no time only mode.

The 19.0 rewrite matters if you maintain website customizations:

17 and 18: the feature lived in datetime_picker_widget.js as a legacy PublicWidget named DateTimePickerWidget, with the same selector and the same three data attributes. It also declared disabledInEditableMode: true, so the picker stayed inert while editing the page in the website builder.

19: the file became public/datetime_picker.js and the class now extends Interaction, registered as web.datetime_picker in the public.interactions registry. Cleanup is handled through registerCleanup instead of a destroy override. If your code inherited or patched DateTimePickerWidget, that hook point is gone in 19 and you patch the interaction instead.

16: neither file exists; frontend date inputs in 16 relied on per module implementations.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The changes below are read from the public development branch and are not final until release.

The interaction survives with the same selector and the same three data attributes. The only diff is internal: the cleanup callback registers the picker's destroy handle directly instead of the enable wrapper. No template changes are expected. We will re verify this page against the released branch after the launch.