Datepicker choose day and timezone offset

[isimonov]

If Datepicker field empty and we choose a date, then creates a new date object with the given timezone offset (depends on locale), i.e. if I choose an empty field 2015-01-02, it turns out the date 2015-01-01 21:00:00 (if the timezone offset is +3 hours), i.e. yesterday, unless you consider time. This is not quite correct when sent to the server, if there is not taken into account the timezone offset or it works with UTC. Maybe there could be something to do?

[isimonov]

If a server is using UTC (timezone offset is 0 hours), and the browser's local timezone (timezone offset is +3 hours) may occur such a situation: all dates are returned from the server is correct, for example 2015-01-02 00:00:00, and if the date entered for the first time the datepicker will create you same date as 2015-01-01 21:00:00 When I pass this 2 dstes on server, this is will be different dates from his point of view. It is very inconvenient to use, but it's a feature of Javascript works with dates in the browser.

[nipec]

+1
I have the same problem in my project. It's a really nasty bug.

[isimonov]

Possible solution to this problem https://github.com/isimonov/note/commit/9190c253a7e354c22afbfa4a58386677ba522e0d It seems to me that this should be made optional. For most cases this could be the solution, but there may be exceptions.

[nipec]

Hi Ivan,

thank you, I think this could be the right approach. One line below I had to add:
dt.setUTCFullYear( date.getFullYear(), date.getMonth(), date.getDate() );

Now it works for me, but I do not know, if there could be any side effects.

Cheers,
Nikola

[nipec]

Hi Ivan,

is this reproducing your error?

http://plnkr.co/edit/RkByqVhCrcSCXWGXGkWo

Cheers,
Nikola

[isimonov]

Hi, Nikola! A little different, see below, I will try to explain in pictures
http://plnkr.co/edit/gMyC6ZEPaL0HGak0ksFO

[wesleycho]

This is actually a duplicate of a few open issues.

[wesleycho]

Closing this in favor of #4837 - the ngModelOptions directive provides a hook where we can wire in specification of custom timezones

[cmlenz]

@wesleycho So this issue is closed in favor of, ehem, this issue? And #2952 is also closed in favor of this issue.

[ired]

@cmlenz +1

[icfantv]

@cmlenz, this is how we maintain some sense of control and understanding of outstanding issues and feature requests - by consolidating. Otherwise, it's so easy to lose track of what needs to be done to what component. Take a look at #4762 and #4772 and see how many issues were closed by consolidating everything (41). I seriously doubt anyone would say managing 41 separate issues and PRs is better than managing two. The onus is on us to ensure that the consolidated issue captures everything from those closed issues. We're totally open to suggestions if you have a better way. Thanks.

@ired, please do not add just +1 to issues. It does nothing to add to the discussion and just clutters up the thread. Thanks.

[icfantv]

@cmlenz, I should add that less than 6 weeks ago, we had over 230 open, outstanding issues and @wesleycho has worked insanely hard in fixing and closing items in preparation for the 1.0 release. We are currently at 86.

[cmlenz]

@icfantv I was in no way complaining about issues being consolidated in general, the problem is that this issue was closed in favor of no other open issue AFAICT, but in favor of itself.

[icfantv]

Ah, understood. Thanks for the clarification. I see now. I've updated the issue number so that it's correct.

[wesleycho]

That was my fault - I linked the wrong issue. #4837 is what was meant to be linked.

[cmlenz]

Thanks @wesleycho and @icfantv