Timepicker text-input is easier to break compared to date or datetime pickers

[stevelacey]

Hi, I wanted to report some issues I have run into when using text-input with the timepicker. I am not fully sure where the underlying problem is, but the behaviour is noticeably different from the date and datetime pickers, which handle text input in a more forgiving way.

1. Text input that is invalid often breaks the timepicker state

When text-input is enabled on a date or datetime picker, entering nonsense or partial input is mostly ignored. The user can delete the bad input, select a date manually, and continue normally. This works well.

With the timepicker, entering invalid or partial text seems to cause the picker state to break in a more severe way. In many cases:

• The start and end time (for range mode) snap to the current time.
• The picker enters a state that feels difficult to recover from without fully clearing the input field.
• Normal correction behaviour (delete the bad text, try again) does not work the same way as it does for dates.

2. Possibly related to startTime or internal handling of null values

I am not certain, but this brittle behaviour seems related to inconsistent use of the startTime prop or internal fallback logic. Sometimes clearing the input does not return the model to null or a blank state. Instead, the timepicker immediately resets to startTime or the current time.

This makes it hard to recover from invalid input, since the user cannot simply clear and re-enter the time.

3. Workarounds behave differently than with date pickers

I tried preventing bad input by capturing keydown and filtering out problematic patterns, but this does not solve the issue. The same approach works fine for date pickers, but the timepicker still behaves differently and ends up in a broken state after certain edits.

Summary

Overall, text input on the timepicker feels much less resilient than on the date or datetime pickers. Invalid input tends to push the timepicker into a state where values are reset unexpectedly and difficult to correct. The behaviour around startTime, clearing input, and fallback values seems inconsistent.

I am not sure what the intended behaviour is supposed to be, but I wanted to highlight these inconsistencies in case it helps improve the timepicker's robustness when text-input is enabled.