date

The Date widget is the workhorse nobody names: any fields.Date in any view renders through it automatically, which is why explicit widget="date" appears only three times in core, in views that spell it out for clarity, while the widget itself runs on practically every screen in Odoo. Since Odoo 17 it lives in the same source file as datetime and daterange, one component with three registrations, differing in options and supported types.

In editing state it is a text input plus the calendar overlay; readonly, it prints the formatted date. Two formats exist, the localized long form, Jan 31, 2026, and the numeric form, 31/01/2026, switched by the numeric option. In Odoo 19 list views the widget also declares fixed column widths, one per format, which is why date columns stopped jittering between renders in 19.

What makes the widget worth a reference page is its option surface: seven declared options, three more that only exist in the code, and a picker whose granularity is configurable from days to decades.

Date fields are where silent data errors breed. A delivery promised for 2062 because someone fat-fingered a year, a birthday in the future, a contract start before the company existed: all of them are one min_date, max_date or warn_future away from impossible. Those three options are the cheapest data validation in Odoo, they live entirely in the view, need no server constraint, and stop the error at the keyboard.

The precision options solve a different business problem: fields that are conceptually a month or a year but stored as dates. A reporting period, a budget year, a planning month. Setting min_precision="months" gives users a month grid instead of a day grid, so nobody has to explain that the day part does not matter.

Worth budgeting a thought for the difference between view-level and database-level rules: min_date guards the picker, not the ORM. Imports, API writes and server code bypass it. When a date rule is a business rule, mirror it in a Python constraint; when it is an entry aid, the widget option alone is the right weight.

Date fields are fully at home in Odoo Studio, and unusually, most of this widget's options are editable there because Odoo declares them with labels and help texts that Studio's properties panel renders directly.

1. Open the form in Studio.

2. Drag a Date field from the Add a field panel onto the form, or select an existing date field.

3. In the Properties panel, the widget is already Date. The panel lists the option set: Earliest accepted date, Latest accepted date, Warning for future dates, Minimal precision, Maximal precision and Date Format.

4. Type ISO dates or the word today into the accepted-date limits, and pick precisions from the dropdowns. Changes apply to this view immediately.

Three things stay outside Studio's reach on this widget.

Range pairing. The undocumented start_date_field, end_date_field and always_range options that link two date fields into one range editor are not in the properties panel; they are XML-only, and mostly the territory of the daterange widget.

Dynamic limits. min_date and max_date accept a fixed date or today, nothing record-dependent. A rule like "delivery date after order date" needs a Python constraint or an onchange, not a widget option.

Hard enforcement. Studio edits the view, and view options only guard interactive entry. Data arriving by import, API or automation ignores them, which is the point where a customization adds the matching server-side constraint.

Guarded entry: no past dates, warn on far future

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

Past dates become unpickable and unparseable; future dates work but carry the warning icon with "This date is in the future".

A month selector on a date field

<field name="period_start" widget="date"
       options="{'min_precision': 'months'}"/>

The picker opens on the month grid and never descends to days.

Compact numeric display for dense lists

<field name="invoice_date" widget="date" options="{'numeric': True}"/>

The hidden range pairing

<field name="date_start" widget="date"
       options="{'end_date_field': 'date_end'}"/>

One widget now edits both fields as a range, with the paired field pulled into the view automatically. This is the same machinery daterange formalizes, exposed here through options the documentation does not list.

What "today" really does. The limit parser special-cases the literal string today and passes it through to the picker, which resolves it at open time. Any other value goes through date deserialization, so a typo like 2026-13-01 is an invalid limit, not a fallback to no limit. Keep limits ISO-formatted or literal today.

The future warning is day-based. warn_future compares the value against today, so tomorrow already warns. The message and icon render per input, and on a paired range each side is checked independently.

Precision is a picker constraint, not a storage change. With min_precision="months" the user picks a month and Odoo stores the first day of it; the field remains a full date. Reports grouping by exact date will show the 1st of each month, which is usually what you want for period fields but worth saying out loud.

One dead knob. extractProps also parses a rounding option, but it configures the time selector, so on a pure date field it changes nothing; it exists here because date, datetime and daterange share one extractProps. If you need it, you are looking for the datetime page.

Dirty-state plumbing. The widget reports dirtiness over the model bus on every render, comparing against the record value with date-aware equality. That is why abandoning an unchanged picker does not trigger the unsaved-changes banner, while typing one character does.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. What follows reads the public development branch, which is unstable until release; we re-verify against the shipped version before touching the option table above.

The option set is unchanged on master: all seven declared options, the three undocumented range options, and all three registrations carry over as they are today.

Typing gains relative operations. The input runs through a new date operation parser: typing +=7 moves the date seven days forward, -=2w two weeks back, with the smart-date units and days as the default unit. It is the same idea the float widget's +=10 operations introduced in 19, extended to dates, and it lands exactly where power users live, in list-view bulk editing.

Internals are rewritten on the new signals and props system, the placeholder formatting helper is gone, and patches against the 19 component will need review. XML views should carry over untouched.