datetime

Delivery dates, meeting starts, deadlines with a time component: every fields.Datetime renders through this widget by default. It shows a formatted value in the user's timezone and language, and opens a combined calendar and time picker on focus. The time selector proposes minutes in configurable steps, five by default.

The widget shares one source file and one component with date and daterange. That matters practically: the three registrations differ mainly in their declared options and supported types, and some abilities documented only for one of them actually work on the others. The range pairing covered below is the prime example.

In list views it also brings sizing intelligence: column width adapts depending on whether the field shows time and whether the numeric format is on, and a separate list.datetime registration autoresizes the input.

Datetime fields are where timezone and precision decisions quietly shape operations. A warehouse that schedules in 15-minute waves wants the picker stepping in quarters, not fives. An HR team reviewing requests does not need seconds on approval timestamps, and a logistics coordinator entering e-waybill deadlines benefits from a warning icon when the date lands in the future by mistake.

All of that is configuration on this one widget, and, unusually for Odoo, nearly all of it is exposed in Studio's property panel. That makes datetime tuning one of the few polish passes a functional consultant can do end to end without a developer: set sensible time intervals, hide time where it is noise in list views, add accepted-date limits where users routinely mistype years. Teams notice this kind of polish immediately because they touch these fields dozens of times a day.

The one decision to make deliberately at rollout is seconds. If your processes compare timestamps to the second, switch show_seconds on where it matters and remember that Odoo 19 hides them by default where Odoo 18 showed them.

Odoo Studio (Enterprise) exposes this widget more completely than almost any other.

1. Open the form or list in Studio.

2. From the Add tab, drag a Date & Time field onto the view. The datetime widget is the default rendering.

3. Open Properties. Beyond the general properties, Date & Time fields get a dedicated set: Minimal precision and Maximal precision for the picker's navigation depth, Warning for future dates, Date format for the numeric style, Show time and Show seconds, Time interval for the minute steps, and Earliest accepted date and Latest accepted date, which accept an ISO date or the word today.

4. Click Close when done. Every one of these maps directly to a widget option in the table below.

Two things stay out of Studio's reach. Pairing two fields into a single range input on the plain datetime widget, via start_date_field and end_date_field, is XML-only; Studio offers the separate Date Range widget for the standard version of that pattern. And the accepted-date limits are static: an ISO date or today. A limit that depends on another field on the record, such as "no earlier than the order date", needs a developer, either through an onchange, a constraint, or a custom widget.

Quarter-hour scheduling

<field name="appointment_start"
       options="{'rounding': 15}"/>

The time selector proposes :00, :15, :30, :45. Users can still type any time; rounding shapes the proposals, it does not constrain input.

Date-only display of a datetime in lists

<field name="deadline"
       options="{'show_time': False}"/>

Keeps storage as datetime while decluttering the column; the list width logic also narrows the column accordingly.

Guard rails on input

<field name="expected_date"
       options="{'min_date': 'today', 'warn_future': True}"/>

Past dates gray out in the picker, and a warning icon appears when the chosen date is in the future, useful when future dates are legal but unusual.

The undocumented range pairing

<field name="stop_datetime"
       options="{'start_date_field': 'start_datetime'}"/>

The plain datetime widget renders both fields as one range input, exactly like daterange, because extractProps reads the pairing options regardless of which of the three registrations is active. The paired field is auto-loaded and forced editable through fieldDependencies; declaring both start_date_field and end_date_field on one field logs a console warning and the start field wins.

Three formatting behaviors in the source explain most "why does it display like that" questions.

Same-day end dates drop their date part. When a range's two values fall on the same day, the second value renders time-only. That is the showDate computation in getFormattedValue, and it is intentional compression, not data loss.

The numeric option switches format families. Default formatting is the readable style (Jan 31), numeric switches to the locale's numeric style (01/31), and the option also drives which width preset list views allocate to the column. Both the option and the Studio property behind it are new in 19.0.

Seconds are display-layer. show_seconds affects the readable format and the picker granularity; the stored value always carries full precision. Odoo 18 defaulted the component to showing seconds, 19 defaults to hiding them, which is why migrated screens suddenly look cleaner, or, for audit-minded teams, suddenly hide information they relied on.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The notes below read the public development branch, which remains unstable until release; we re-verify this page against the shipped version.

The datetime widget's option set is unchanged on the development branch: same ten declared options, same undocumented range pairing, same registrations including list.datetime. The component itself is rewritten onto the new Owl props and signals system, and some option value coercion is simplified in the process (19.0 ran boolean options through an expression parser; master reads them more directly). If you patched DateTimeField or its picker hook, plan a review; if you only configure it from XML, expect no changes.