Reproduction demo with workaround.

Well.. I wonder if it is a bug we can tackle with massaging TS types or is it just IDE getting confused. All parts (hour/minute/second/period) are emit-only as stated in the API docs, but autocomplete suggests 2-way binding.

@kschwedler, could you share if you were just mislead by IDE or is there any real-life use case where you'd like to set individual pieces instead of updating the full time value string?

Thanks for the quick response, but unfortunately this is not what I meant. I have to use the time picker separately for design reasons. The time picker control component can emit ‘update:selecting’, but the time picker itself cannot be controlled with this value.
It would be cool if the picker gets a prop ‘selecting’ or something, so that you can adjust the clock accordingly on the clicks of the buttons (hour/minute/second) of the control.

@kschwedler, did you consider using <v-time-picker-clock> instead? Pickers (in general) try to force users to go through all the modes to produce valid date or time. So even if the PR gets merged and the prop would let you control the state - selecting hour switches mode to minutes - you would need to make the picker unclickable with inert or pointer-events none in order to force the selection mode from outside.

The mode switching to minute/second when selecting hour/minute is fine. The only problem was that the v-time-picker-control is useless because it couldn't update the time picker (e. g. you selected hour in the clock and it switches to minutes but want to change the hour again by clicking on the hour button of the time-picker-control without entering minutes), which hopefully works with the pr you created.

@kschwedler , I don't get the last part. It clearly works in the most basic example in the docs. I can go back to selecting hours without selecting minutes.

As I already mentioned, I need the clock and the control to be seperated. I know that the main component itself is working. I made a small example of what I mean.

Consider these 2 playgrounds: one that works today, and the one that would work after merging the PR.

• 1st one is based on <v-time-picker-clock> and has different API, but I took it all from the sources
• 2nd one would still progress to minutes after selecting an hour - forcing user to fight against it

Would you pick the first today or still wait for the 2nd one to accept selecting prop?

I think I'll wait for the PR. It's not urgent for us, just a bit annoying at the moment. Thanks for your help so far, I hope the PR will be merged soon :)