Skip to content
This repository was archived by the owner on May 29, 2019. It is now read-only.

Datepicker UTC Timezone issue #5759

Closed
msosa opened this issue Apr 6, 2016 · 12 comments
Closed

Datepicker UTC Timezone issue #5759

msosa opened this issue Apr 6, 2016 · 12 comments

Comments

@msosa
Copy link

msosa commented Apr 6, 2016

Bug description:
I am using the datepicker to handle dates all in the UTC timezone. I am using the .config to set the ng-model-options to be UTC for all datepickers. However I noticed that when my timezone is minus UTC timezone the date that shows on the input is actually the day before. The date is correct on the actual datepicker though. However if I explicitly put the ng-model-options on the input the date show up correct. Is this the expected behavior?

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

Version of Angular, UIBS, and Bootstrap

Angular: 1.5.3

UIBS: 1.3.1

Bootstrap: 3.3.6

@wesleycho
Copy link
Contributor

@RobJacobs I think this is exactly what we were talking about just earlier - we'll likely have this addressed by the next release @msosa.

@msosa
Copy link
Author

msosa commented Apr 6, 2016

great thank you! If it helps this was working in 1.2.5

@RobJacobs
Copy link
Contributor

This is turning into a tricky issue. You will notice in the plunk, it's the date displayed in the input element that is off, the datepicker popup has the correct date displayed. The datepicker directive tries to handle the timezone correction and does so correctly for the activeDate property. When I try and move the timezone correction to the datepickerPopup directive, both directives apply the timezone offset resulting in a double timezone shift for the ngModel value. I'm still trying to figure out what the model-options attribute is doing differently than the config object modelOptions property.

@msosa
Copy link
Author

msosa commented Apr 8, 2016

i feel like the problem is here:

https://github.com/angular-ui/bootstrap/blob/master/src/datepickerPopup/popup.js#L36

if you look at datepicker it uses the config:

https://github.com/angular-ui/bootstrap/blob/master/src/datepicker/datepicker.js#L159

the popup doesn't seem to. If i manually set the timezone in the popup.js to UTC everything seems to work.

@wesleycho
Copy link
Contributor

This is probably right, and I sort of suspect it's a one line change necessary - let me see about opening a PR.

@RobJacobs
Copy link
Contributor

The fix is more complex than that. My initial change was to modify the line mentioned above to be like the datepicker, but that causes the time zone offset to be added twice.

@wesleycho
Copy link
Contributor

I realized that after heh. This requires some more investigation.

@msosa
Copy link
Author

msosa commented Apr 11, 2016

Hmm doesn't that mean if we set the ng model options on the input that this will also cause the zone offset to be added twice?

@RobJacobs
Copy link
Contributor

No, see my comment above, using the model-options works correctly.

@wesleycho wesleycho modified the milestones: 1.3.2, 1.3.3 Apr 14, 2016
@JonCognioDigital
Copy link

I'm not sure if this is any help or not but I put a comment on #5752 about the fact that correcting this issue using ng-model-options timezone seems to be a bit of a hack over the underlying issue. I don't know what conversations you've had internally but judging by this thread I think you're trying to fix the underlying issue with datepickers selecting the wrong date due to timezone issues.

@msosa
Copy link
Author

msosa commented Apr 22, 2016

So I have an updated plunk that formats the dates to include the full time as well as timezone, and it still seems that even using ng-model-options on the input we are not getting the dates we want. I would expect the timezone to be 0 when using a UTC date with a UTC filter just the way the angular filter does so(2016-04-01T00:00:00+0000). But it seems like it still has the timezone in it(2016-04-01T00:00:00-0400). Maybe this is by design but here is the plunk

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

@wesleycho
Copy link
Contributor

Going to close this in favor of #5825 - going to schedule for 2.0.0, as it requires a significant breaking change to correctly fix.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants