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.

This code seems to me to be simpler, more direct, accomplishes 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.
Merge pull request #333 from pavlovich/fix-calendar-retrieval-issue

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