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

Datepicker choose day and timezone offset #4113

Closed
isimonov opened this issue Aug 5, 2015 · 16 comments
Closed

Datepicker choose day and timezone offset #4113

isimonov opened this issue Aug 5, 2015 · 16 comments

Comments

@isimonov
Copy link

isimonov commented Aug 5, 2015

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
Copy link
Author

isimonov commented Aug 6, 2015

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
Copy link

nipec commented Aug 6, 2015

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

@isimonov
Copy link
Author

isimonov commented Aug 6, 2015

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
Copy link

nipec commented Aug 7, 2015

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
Copy link

nipec commented Aug 11, 2015

Hi Ivan,

is this reproducing your error?

http://plnkr.co/edit/RkByqVhCrcSCXWGXGkWo

Cheers,
Nikola

@isimonov
Copy link
Author

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

@wesleycho
Copy link
Contributor

This is actually a duplicate of a few open issues.

@wesleycho
Copy link
Contributor

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

@cmlenz
Copy link

cmlenz commented Nov 17, 2015

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

@ired
Copy link

ired commented Nov 17, 2015

@cmlenz +1

@icfantv
Copy link
Contributor

icfantv commented Nov 17, 2015

@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
Copy link
Contributor

icfantv commented Nov 17, 2015

@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
Copy link

cmlenz commented Nov 17, 2015

@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
Copy link
Contributor

icfantv commented Nov 17, 2015

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

@wesleycho
Copy link
Contributor

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

@cmlenz
Copy link

cmlenz commented Nov 17, 2015

Thanks @wesleycho and @icfantv

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

6 participants