incorrect time like (6666) is allowed #33

ruchikatechie opened this Issue May 15, 2013 · 4 comments


None yet

2 participants


incorrect time like (6666) is allowed
any time greater than 6666 is allowed

wvega commented May 15, 2013

Hi @ruchikatechie,

What do you mean with is allowed?. I tried with one of the timepickers available here: When I type 666 or 6666, the timepicker does nothing; it leaves the value as it was typed. That means the value couldn't be parsed and converted into a valid time entry. The value is left as typed to give the user the opportunity to change it without having to type all the number again.

Is that the problem your are seeing? If so, what behavior where you expecting in this scenario? I think make some improvements and I would like to know your feedback. if the above is not the problem you are seeing, would you please give me more details about the situation?


Yes, this is the problem that it leaves it as is when user enters 6666 it should be converted in 06:06 or may be some other value.
what do you suggest?

wvega commented May 20, 2013

Currently the plugin stops parsing and returns false if it parses a number of hours greater than 24 and the number of minutes or seconds is 60 or more. 6666 is initially parsed as 66 hours and 66 minutes, which matches the stop condition.

I think I can relax the stop condition and parse 6666 as 66660, which is then parsed as 6 hours, 66 minutes and 60 seconds, which would be converted to 7:07 AM. How that works? well, if you wait for 6 hours, 66 minutes and 60 seconds, you will wait a total of 7 hours and 7minutes. That's also the value you would get if you do:

var time = new Date();
time.setHours(6, 66, 60);
time.toTimeString() // gives me "07:07:00 GMT-0500 (COT)"

You may be curious about what returns time.setHours(66, 66); (the original string without adding a zero at the end). It returns 19:07:00 GMT -0500 (COT), a similar value (7:07 PM vs 7:07 AM). However, time.setHours(67, 66); returns 20:07:00 GMT -0500 (COT) which seems confusing because if you started typing a 6 I assume you want to get 6 hours or the closest value. For that reason I prefer to add a zero to the end first, instead of passing the parsed values directly to setHours.

The above behaviour is compatible with how timepicker works right now, because if you type 46, that gets parsed as 5:00 AM, using exactly the same logic.

Are you comfortable with parsing 6666 as 7:07:00 AM?


yes. It should behave like this way only :) 👍

@wvega wvega added a commit that referenced this issue Jul 28, 2013
@wvega Add unit test for new parse rules (#33).
Also add unit test for minTime option behavior.
@wvega wvega was assigned Jul 28, 2013
@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