time_hour_uom

The entire widget is one getter:

export class TimeHourField extends FloatTimeField {
    get formattedValue() {
        const unitAmount = super.formattedValue;
        const [hourStr, minuteStr] = unitAmount.split(":");
        const hours = parseInt(hourStr, 10);
        const minutes = parseInt(minuteStr, 10);
        return minutes ? _t("%(hours)sh%(minutes)s", { hours, minutes })
                       : _t("%(hours)sh", { hours });
    }
}

It lets float_time do the formatting, then takes the HH:MM string back apart and reassembles it in the 7h30 style. Because it parses with parseInt, the leading zeros disappear: 07:30 becomes 7h30, and 08:00 becomes 8h.

Both output forms go through the translation system, so a localization can change the separator.

This is a small readability decision with a real effect on timesheet screens. 07:30 reads like a clock time, which is exactly wrong for a duration: people glance at it and think half past seven rather than seven and a half hours. 7h30 cannot be misread that way.

On a weekly timesheet grid full of durations, that distinction removes a whole category of confused questions. If your team regularly asks whether a number is a time or a length, this is the change.

On a timesheet duration field:

<field name="unit_amount" widget="time_hour_uom"/>

This is ignored, because the descriptor does not carry float_time's options:

<!-- show_seconds is a float_time option and is not inherited here -->
<field name="unit_amount" widget="time_hour_uom"
       options="{'show_seconds': True}"/>

This widget is a clean illustration of a distinction that catches people writing their own.

There are two separate things: the component, which is the OWL class doing the rendering, and the descriptor, the object registered in the fields registry that tells Odoo which options and types the widget supports.

Subclassing the component inherits rendering behavior. It does not inherit the descriptor. Here, TimeHourField extends FloatTimeField gives you all of float_time's rendering, but the descriptor is written fresh:

export const timeHourField = {
    component: TimeHourField,
};

Compare that with how float_factor does the same job:

export const floatFactorField = {
    ...floatField,
    component: FloatFactorField,
    supportedOptions: [ ...floatField.supportedOptions, ... ],
};

The spread is what carries the options across. Without it, the widget silently supports nothing, and there is no warning: an unknown option is parsed by the view and discarded.

If you are writing a widget by extending an existing one, spread the descriptor as well as extending the class, or you will ship a widget whose documented options do not work.

No change to this widget. Diffing the registration between the 19.0 and 20.0 branches shows the same single-key descriptor.

The widget it extends did change, which matters indirectly. In Odoo 20 float_time renames display_seconds to show_seconds and gains numeric and unit. Since this descriptor never inherited those options, none of that reaches it, but the underlying formattedValue it reparses comes from the updated component.