timezone_mismatch

Timezones cause a specific kind of silent error in Odoo: a working schedule, a leave request or a meeting is configured by someone sitting in one zone for a record that belongs to another. Everything saves, the times look right on screen, and the offset shows up later as an appointment an hour out or a shift starting at the wrong time.

This widget makes that visible at the moment of configuration. It renders the ordinary timezone dropdown and additionally compares the record's stored offset against the browser's own offset. If they differ, the field is flagged with an explanatory title on hover.

It goes one step further than a warning. When there is a mismatch, the currently selected option's label is rewritten to include the real current time in that zone. So instead of reading a zone name you may not have a feel for, you see what the clock actually says there right now.

Working schedules are the highest value place for this. A schedule defines when an employee is available, and it drives leave duration, timesheet validation and planning. Set it in the wrong zone and the errors are subtle: half day leaves that come out as a few hours off, shifts that appear to start before the working day.

The reason a plain warning is not enough is that most people cannot mentally convert a zone name into a time. Printing the current local time next to the zone turns an abstract mismatch into something anyone can check in a second: does that look like the middle of their working day or the middle of their night?

The empty case is the one worth building a habit around. A record with no timezone at all is treated as a mismatch, with a message asking for one to be set. That is deliberate: an unset timezone is more dangerous than a wrong one, because it silently falls back to something else.

The core usage

<field name="tz" widget="timezone_mismatch"
       options="{'tz_offset_field': 'tz_offset',
                  'mismatch_title': 'Timezone Mismatch : This timezone is different
                   from that of your browser.'}"/>

Core passes both options explicitly, even though the offset field name matches the default, and replaces the default message with schedule-specific advice.

Relying on the defaults

<field name="tz" widget="timezone_mismatch"/>

Valid on any model whose offset field is called tz_offset, which is the Odoo convention. The default warning text is used.

The companion field

# on the model
tz = fields.Selection(_tz_get, ...)
tz_offset = fields.Char(compute='_compute_tz_offset')
# produces a string like "+0530"

The offset must be formatted as a signed four digit string; the widget parses it with a regular expression.

The mismatch test builds the browser's offset by hand rather than using a library. It takes the browser's offset in minutes, flips the sign, formats the hours and minutes as two padded digits each, prefixes a sign, and compares the resulting string against the value in the offset field. String equality, not arithmetic.

Two behaviors follow. Because the comparison is on the formatted offset, two zones that happen to share an offset are treated as matching, which is usually what you want: a user in one zone configuring a record in another zone at the same offset has nothing to worry about right now. And because the offset is a moment-in-time value, a zone that observes daylight saving can match in summer and mismatch in winter.

The label rewriting is the part that makes the widget useful. When a mismatch is detected, the options list is rebuilt and the currently selected entry gets the local time appended. That time is computed by parsing the stored offset into minutes, subtracting the browser's own offset, and shifting the current time by the difference. Only the selected option is rewritten; the rest of the dropdown is untouched.

The empty case is handled separately and deliberately inverted. If the field itself has no value, the mismatch getter returns true regardless of offsets, and the title getter returns a different message asking the user to set a timezone. So the visual treatment is the same whether the zone is wrong or missing, which is the right emphasis.

Odoo 20 is expected at Odoo Experience in Brussels, 24 to 26 September 2026. The development branch is unstable and this may still change; we re-verify the page after release.

No behavior change. Both options, their defaults, the string comparison and the local time appended to the selected label are identical. The only difference is the migration to the new Owl props syntax, where the props are declared with the schema helpers and the selection widget's own props are inlined with a source comment noting that the base is not yet converted.