Fixed retrieval of the current calendar when a time control is clicked.

The old implementation actually found two (2) calendar objects and assigned the collection of these two calendars to the 'cal' variable. The weird thing was that the two calendars it found were either both left calendars or both right calendars. In both cases, either left or right, the two calendars that were found by the old code were: The first one being a calendar reflecting the state of that calendar (the one clicked on) BEFORE the state change (before you changed the time controls) and the second calendar was the same calendar AFTER the state change. When the 'find the hours control given the calendar in the cal variable' part of the code was hit, the result was a collection of the hours controls from both calendars in the 'cal' variable. Unfortunately, the first one in the list was the one reflecting the state of the calendar BEFORE the event happened so ... the end result was that the code just set the state of the calendar's time controls back to what it was before you interacted with them. Very odd. But I believe that this behavior is actually predictable because, in my app, your widget was being wrapped in an Angular directive. Although I can explain the behavior, it is still not desirable and there was no easy work-around.

While hunting for a fix, I discovered that if you used 'closest' (starting from the time control that was clicked) rather than using 'find' (coming from within the element containing the calendar), you always end up with the correct calendar element with the updated values in it.

In summary, this pull request seems, to me, to provide a simpler, more direct version of the code which still seems to accomplish the intended purpose of the original code (I think) and has the added benefit of not exhibiting the bad behavior that I observed in which you could not change the time via this widget/control. Admittedly, this bad behavior may only appear when your code is used from within Angular but, considering the popularity of Angular, if you agree that the new version of the code preserves your original intended behavior, it would be worth merging this change in.