Added events on show and hide of Calendars
fix when editing a "last" time in the  input box. Reason 'split separator'
AMD version

avoid global use
Prevent infinite loop if notify callback triggers a click event
Fix: Provided parent element not set correctly

Fixes bug with parent element not being correctly set if provided in
options field.
Don't set endDate time to endOf('day') if timePicker is on

I was surprised that if a user selects an endDate from the calendar **and do not touch the hour/minutes** then they are automatically set to 23:59.

It seems you have forgotten to only run `endDate.endOf('day');` if timePicker is disabled.

Or maybe I'm missing something, am I ?
Merge pull request #313 from jerefrer/patch-1

Don't set endDate time to endOf('day') if timePicker is on
Merge pull request #310 from shezarkhani/master

Prevent infinite loop if notify callback triggers a click event
Merge pull request #302 from luarmr/master

fix when editing a "last" time in the  input box. Reason 'split separato...
Fix updating from control
Bump version
Merge pull request #311 from vitorhsb/master

Fix: Provided parent element not set correctly
Fix event unbind in multiple datepicker instances.

This commit creates a private copy of the datepicker proxy for
unbinding.  Now, .hide() will only remove this instance's event
handlers.
Switch document back to mousedown.

Switch the global hide listener back to mousedown.  This effect is nicer
when switching from one datepicker to another, as it won't temporarily
display both.  It also fixes problems where click starts another
datepicker input but ends somewhere outsideClick won't trigger.
Handle hiding when tabbing between controls.

Add a focusin event handler to close the datepicker when focus changes
to another input, such as when tabbing.  Previously, inputs would be
left open.
comparing dates instead of times on the calendar, so that maxDate can be selected
read locale.firstDay from momentjs config
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 #326 from mcurtis/master

Fix #321 Cannot select the 'MaxDate' in 'To' date form
Merge pull request #333 from pavlovich/fix-calendar-retrieval-issue

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