daterange

The daterange widget displays a period, start date to end date, on a single line and edits both ends in one calendar popover. Time off requests in hr_holidays, event dates, and planned task dates all use it.

The mechanic that confuses most people: the widget sits on one field and is told where its partner is. Put it on the start field and set options="{'end_date_field': 'date_end'}", or put it on the end field and set start_date_field. The source then injects the partner field into the view automatically as an editable dependency, so you do not need a second visible field element.

It is defined in datetime_field.js in the web module, in the same registry chain as date and datetime, and inherits everything those widgets can do: precision limits, min and max dates, minute rounding, future date warnings. On top it adds the range pairing, a range toggler for optional ranges, and cross-field validation.

Anywhere your team schedules something with a beginning and an end, a rental, an intervention, a leave, a campaign, two separate date fields make people scroll and make invalid pairs possible. The range widget removes both problems: one line, one popover, and the picker itself makes an end date before the start date impossible to select in a single motion.

The subtle win is the optional range. A field service visit may have a confirmed start and an open end. With daterange the end date stays hidden behind a toggler until someone needs it, which keeps forms clean without losing the ability to record a full period.

The equally subtle trap is validation. If the end field is required and someone fills only the start, the record refuses to save with a message pointing at a field that is not visibly on the form. That is the widget's cross-field check doing its job; it belongs in your user training.

Studio documents this widget by name, with its own flow (see the Date Range section of the Studio fields docs).

1. Identify or create the underlying second field: an existing Date or Date & Time field that will act as the start or end.

2. Add a Date & Time field, then in its properties set Widget to Date Range.

3. Enter the label, then pick the partner field in the Start date field or End date field dropdown.

4. Enable Always range if both dates must always be filled.

5. Optionally set the Date & Time properties Studio exposes: precision, time interval, future date warning, accepted date limits.

Studio's tip is worth repeating: make the underlying partner field invisible or remove it from the view, otherwise the same date appears twice.

Studio covers this widget unusually well. What still needs XML is anything conditional: a range whose end field becomes required only in certain states, domain-dependent min and max dates, or applying the widget inside embedded list views of a one2many. The option set itself is fully reachable from Studio's properties panel.

Start field paired with an end field

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

The date_end field does not need its own element; the widget injects it as an editable view dependency.

Mandatory full range

<field name="date_start" widget="daterange"
       options="{'end_date_field': 'date_end', 'always_range': True}"/>

Both inputs are always displayed, even while empty, and the range toggler disappears.

Quarter-hour datetime range with limits

<field name="booking_start" widget="daterange"
       options="{'end_date_field': 'booking_end', 'rounding': 15, 'min_date': 'today'}"/>

The time selector moves in 15 minute steps and past dates are grayed out.

Numeric display format

<field name="date_start" widget="daterange"
       options="{'end_date_field': 'date_end', 'numeric': True}"/>

Dates render as 12/31/2026 style instead of Dec 31, 2026; in list views the column also gets the narrower numeric width.

Four behaviors in the source explain most of what users see.

The partner field is auto-injected. fieldDependencies adds the field named in start_date_field or end_date_field to the view model with readonly: false. This is why the second date saves even though it has no visible field element of its own.

The range toggler only shows when the range is optional. The picker offers the toggle arrow only if a partner field exists and the field is neither required nor always_range. Toggling on seeds the missing date one hour after the start (or one hour before the end); if both are empty it starts from now.

Validation is cross-field. isValid rejects the record when one end of the range is set, the other is empty, and that other field is required. The error names the injected field, which may not be visible on the form.

Display width and same-day rendering. In lists the column reserves twice the single-date width plus 30 pixels for the arrow. On datetime ranges that start and end the same day, the end value drops the date part and shows only the time.

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 option surface is unchanged. We compared every option name and every options.* read in datetime_field.js between 19.0 and the development branch: identical, and the date / daterange / datetime registrations are untouched. The file is being rewritten internally for the new Owl framework (signals, useProps), so JavaScript patches that extend the class will need review, but view XML should carry over untouched. We re-verify this page after release.