Incorrect minutes like 12:77 are allowed #27

kgorin opened this Issue Aug 27, 2012 · 1 comment


None yet

2 participants

kgorin commented Aug 27, 2012

One can enter 12:77 and it won't get corrected.

@wvega wvega was assigned May 3, 2013
wvega commented Jul 28, 2013

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 internal selected time will be set to null.
  • getTime() will return null.
  • but the value in the textfield won't be updated.

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).

@wvega wvega closed this Jul 28, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment