One can enter 12:77 and it won't get corrected.
This issue is related to #33. The solution I implemented for that issue was to interpret ill-formed date strings like 12:77 or 6666, in the same way the Date constructor would interpret the equivalent times:
> new Date(0, 0, 0, 12, 77)
Sun Dec 31 1899 13:17:00 GMT-0500 (COT)
> new Date(0, 0, 0, 6, 66, 6)
Sun Dec 31 1899 07:06:06 GMT-0500 (COT)
The string 12:77 will be interpreted as 12 hours plus 77 minutes, which is the same as 13 hours plus 17 minutes o 13:17. If the parsed time is not valid according to the Timepicker minTime and maxTime settings, a couple of things will happen:
The reason to avoid updating the textfield's value is to allow the user to correct what they typed without having to start from scratch.
Timepicker goal is to allow users to select time entries easily, reducing errors by constraining the values that can be set and showing a set of predefined options. However, the timepicker is not validation plugin, if the user types something that can't be understood as a time entry, there is nothing the plugin can do (except returning null if you use the getTime() method).
Add unit test for time string '12:77', interpreted as 13:17 (#27).