Datepicker not selecting correct date in calendar using ng-model on load

[jonricaurte]

If you go to the github page here:

https://angular-ui.github.io/bootstrap/#/datepicker

If you select the button that says 2009-08-24, the calendar opens with the date selected to 2009-08-23. Going back to 0.12.1 fixes this issue. However, both versions set the day to be the day earlier for both min-date and max-date.

Thanks.

[wesleycho]

This works properly for me - it sounds like something else might be going on.

[jonricaurte]

If you go to the link (https://angular-ui.github.io/bootstrap/#/datepicker), it fails on OS X chrome, firefox, and safari. Hit this button:

And on the calendar it will show:

It should highlight August 24, but it is highlighting August 23.

Thanks.

[wesleycho]

I am not seeing this on my Chrome at all on OS X. I need more detailed information that would allow me to pinpoint the difference.

[jonricaurte]

That is very bizarre. I'm on Yosemite. Just tried VirtualBox and it also fails on IE11 in Windows 7:

[jonricaurte]

Above everything is showing 24-August-2009, 2009-08-24, and Monday, August 24, 2009, however on the calendar it highlights 23.

[wesleycho]

I wonder if this is a timezone related bug potentially. I am on Pacific Time (GMT -8 I believe?)

[jonricaurte]

I'm also on Pacific Time. I think it is a calendar related issue because the selected time is correct everywhere else so the calendar should also be correct.

[jonricaurte]

If I click a date on the calendar, everything syncs correctly. It is when you assign the selected date by not clicking on the calendar, which is what I did when clicking this button:

https://cloud.githubusercontent.com/assets/1715240/9000964/31f461aa-3705-11e5-86ee-bdc983783b29.png

That is when it fails.

[wesleycho]

Right, I get what you're saying - I'm not sure what would cause this discrepancy, and it worries me that I cannot reproduce this at all, even while residing on the same timezone (Mountain View here).

[RobJacobs]

I was seeing this issue this morning at 7:45 EST. The problem is with how in the demo the click event is setting the scope.dt to a string instead of a date object. This updated plunk demonstrates calling a function with a date string as a parameter and setting scope.dt to a new Date(string) object and it seems to work correctly.

[wesleycho]

We should probably then strip out the new Date fallback present in the datepicker then...I'll investigate properly removing it and updating the demo to only set a new date JS object instead of the date string to the model.

I will schedule that for 0.13.3 then.

[jonricaurte]

@RobJacobs I think you may have figured it out, but its not because you are passing a new Date object. After looking at your plunk, I noticed you changed the date format to be 2009/08/24 instead of 2009-08-24 so I tried setting it here in this plunk without having a date object and it works:

http://plnkr.co/edit/jjbLElyLb8wQZVxg0TnT?p=preview

Then I tried setting min/max date to use 2009/08/24 format instead of 2009-08-24 format and it works everywhere:

http://plnkr.co/edit/9C0gSZhh8eMDHSfQkIfF?p=preview

Apparently javascript date objects are initialized differently for the format that is being passed in. I wrote console.logs for the two different versions in the last plunk and you can see they are different.

[wesleycho]

Yuck...

Also, found out this is a duplicate of #3071, so that one will be fixed along with this one when it is patched up.

[wesleycho]

Also duplicate of #2628

[zlailari]

Probably also a duplicate of #1872

[eckersalld]

@wesleycho - can I suggest looking into changing datepicker.js, so that $scope.select is no longer using:

dt.setFullYear(date.getFullYear(), date.getMonth(), date.getDate());

and instead uses:

dt.setUTCFullYear(date.getFullYear(), date.getMonth(), date.getDate());

This should fix the timezone issue. IMO the picker should be using UTC as standard anyway as it picks dates, not datetimes, so timezone data is immaterial, and in several cases is proving actively problematic.

It'd mean the slightly hacky fixTimeZone function could be retired too :)

[wesleycho]

I took a quick look at using UTC there, and it caused a time issue where the time was off by an hour in a unit test.

This requires a hard look, which unfortunately, I haven't been able to give its due due to lots of distracting small issues. There is certainly something very wrong with how timezones are being handled though, and that is likely one of the areas - I suspect there is more than one culprit here.

[wesleycho]

I'm closing as this should be fixed in 0.14.3 - the datepicker will default to the timezone of the initial model, or the local time & retain the timezone throughout the datepicker's lifetime.