bug(datepicker): Time zone gets changed automagically, resulting in invalid dates

[ochrons]

This is related to #1031

To demonstrate, use this plunker http://plnkr.co/edit/9zw41D?p=preview

At first the date value is "2013-09-23T13:12:24.742Z" (I'm UTC+3, so my local time is actually 16:13)

Clicking another date button changes the date value to "2013-09-24T13:12:24.742Z", all fine so far.

Now, editing the date value directly (to 25-September-2013) in the Input box results in a date value like "2013-09-24T21:00:00.000Z"

Finally, clicking Clear in the popup and selecting a new date (26th), results in "2013-09-25T23:00:00.000Z"

The problem is that when the application doesn't care about the timezoned date value but the date part itself, this creates a lot of problems. The date picker should NOT adjust the time part of the date at all, especially in a way that causes invalid dates due to unnecessary timezone conversions.

[bekos]

First off all, there is actually a bug in the process you described above, and this is the date you get after you hit "Clear". In your case this should be "2013-09-25T21:00:00.000Z". I believe this is an easy fix, but the rest is a matter of behavior.

I mean that the datepicker is supposed to leave the time part of the Date object that you "feed" it, untouched.

As you said, initially you pass a date value "2013-09-23T13:12:24.742Z" (UTC+3) and this does not alter as you click another date button. Instead, when you alter the input value, you "feed" the datepicker with a string, that has no time information. As a convention, the datepicker adjusts the time to '00:00:00' meaning that when you change to 25-September-2013, it is actually 'Sep 25, 2013 12:00:00 AM' and since you are UTC+3 you get "2013-09-24T21:00:00.000Z".

As mentioned earlier, when you clear the value and click the 26th it should be "2013-09-25T21:00:00.000Z" (UTC+3) for the same reason. You actually select 'Sep 26, 2013 12:00:00 AM' in local time.

@ochrons That being said, do you still believe there is bug and what should change in the behavior described?

[easierbycode]

I'm seeing the same issue with Rails Date attributes:
http://plnkr.co/edit/1e732M?p=preview

when date is '2013-09-15':

• initial calendar date is 9/14
• picking 9/25 sets value to 9/26

when date is null:

• picking 9/25 sets value to 9/26

however, if I setup my API to skip null attributes (i.e. date is undefined):

• picking 9/25 sets value to 9/25

[pkozlowski-opensource]

@easierbycode what do you mean exactly by "sets value" in your examples? From I can see that model value is set correctly but when model is displayed (converted to string) it is displayed in the UTC time-zone while your data object is (as all the objects in JavaScript) carries time-zone information in the local time zone. In other words: when a date is selected a corresponding date object is created in the local (based on browser / OS settings) time zone.

So, the question here is this: how do you convert your JavaScript date objects to strings sent to a backend? I'm not familiar with Rails so "Rails Date attributes". doesn't tell me much, unfortunately....

[ochrons]

@bekos of course it's a bug, if a user selects date 25-09-2013 and the server is being sent a date 24-09-2013 due to the timezone problem (since the server doesn't know user's timezone). Some other date pickers (http://mgcrea.github.io/angular-strap/#/datepicker) handle this by reseting the time component to zero, without getting disoriented by the current timezone.

It would be more predictable if the time component would always remain at 00:00:00 with UTC timezone, and the developers would be instructed to ignore the time in their own code. This is, after all, about picking a date, not a full date-time.

[bekos]

@ochrons Let's go with one issue at a time, so you can help me understand the behavior you expect. I am not a timezone expert anyway :-) and would appreciate any insight to this problem.

I will use an example to make it easier.
Let's say that you use as model a new Date() object and it happens when your local time is 1st October 01:00.
If you display the model as string, since you are UTC+3, you get 2013-09-30T22:00:00.000Z.

1. If the user has no interaction with the datepicker and just sends this model to server how do you handle it?

Since the local date is 1st October you expect the datepicker to have selected the October 1st, although the string representation of the current date object is 2013-09-30T22:00:00.000Z.

2. When user clicks on the next date object the datepicker is supposed not to touch the time part, so you expect to see the 2nd October selected and the object as string to be 2013-10-01T22:00:00.000Z. Right?

3. If there is no unexpected behavior until now and you are able to handle these differences between selected date and string representation, what is the difference when the model is null and you select the October 2nd, as convention 00:00 local time, meaning 2013-10-01T21:00:00.000Z in your timezone. Why this value is any different from the previous ones?

---

Probably the real issue is that we have to work with Date objects instead of strings. This may seem like a problem but being able to use the same model in a datepicker and timepicker, for example to arrange an event without combining strings, I think is powerful. A solution to this case would be to use a $parser to convert with a dateFilter the model value to the desired string. For example dateFilter('2013-10-01T21:00:00.000Z', 'yyyy/MM/dd') = '2013/10/02'

[ochrons]

@bekos, you are right that the system would not work if it's being initialized with the raw Date() call, due to the timezone adjustment.

And I agree, like you said, that the underlying problem is the use of Date objects, with implicit timezone adjustment, which is not part of the "model" per se and needs to be accounted for separately.

These timezone issues are really tough, trying to match user expectation to whatever the server might require, not to even mention when the calendar switches from summer time to normal time and back :)

I suppose the correct solution in this case is, like you said, to convert the full datetime representation into a timezone-corrected date on the client side before sending it to the server. Would suggest the documentation reflected this as well :) Having a real example that uses current Date() and produces a correct string version for the server at the end would be quite helpful.

For now, let's reduce this bug-report to the one where the "Clear" messes up with the timezone and consider the rest of the problem being of "conventions and documentation".

[smojtabai]

What about having an option to set the timezone? I am also dealing with this tricky situation where I want to have a datepicker set times using the timezone passed from the server however, manually typing changes this.