bug(datepicker): Time Zone transformation applied when it shouldn't

[thardy]

According to ISO 8601, "If no UTC relation information is given with a time representation, the time is assumed to be in local time". The UI-Bootstrap datepicker is not honoring that specification.

Dates in the following formats are coming back from the webapi we're using - 2013-09-01T00:00:0. This is standard format for a date that has no time or time zone information. Notice the lack of a "Z" or "+00" at the end.

Start with your own plunker for the datepicker (on docs page) and paste this time into the input box - 2013-09-04T00:00:00.000. It's obviously a date representation for September 4th, but notice the datepicker popup shows September 3 as the date. You're applying time zone transformation to a date that according to spec should be assumed to be in the same time zone (i.e. DON'T MESS WITH IT).

This is a big problem, causing every date to display as the prior day. I'm amazed no one has used the datepicker with an api, or this would be seen. Perhaps you're apis are explicity specifying the time zone. I'm not sure we can get that changed, but regardless it should work according to ISO.

[bekos]

@thardy You are right about the ISO, but the datepicker does not perform any kind of parsing in the dates you provide as strings, other than your browser's implementation of Date.parse. You can read some info here.

So, since Date does not play well with ISO8601, I suggest to use your own $parser to fix this or return a format that has the same Date representation no matter the local time zone.

[pkozlowski-opensource]

@bekos I guess we could prepare a WIKI page about it or something. Or create a directive where people could specify a function responsible for string->Date mapping. In any case this one can be closed, I guess.

[dotcom9]

I have also hit up against this issue. How can I override this behaviour so that the datepicker no longer adjusts the date provided in the model. It treats all dates as if they were UTC and converts them for the local timezone.

I can't see any call to Date.parse() in the code.

[thoughtpunch]

Looking for a fix for this as well. +1

[pisaacs]

+1 for an enhancement.

Couldn't the datepicker directive strip out time/timezone information? Is there a value to keeping this information?

I haven't tested the below but I imagine there's an opportunity to apply a date filter to the model's date value, something along the lines of:

//from
return viewValue;

//to
return $filter('date')(viewValue, dateFormat)

[nsilvah]

Directive to fix issues with negative timezones:

https://gist.github.com/nsilvah/a7a31f017de098a79f38