Everything below is using FullCalendar v1.4.9, and have set ignoreTimezone to false. My events come back from the ajax call as ISO8601 dates, specified as UTC (a 'Z' at the end). From my understanding, if the 'Z' is at the end, the string should be treated as UTC time, and the resulting date should then be converted into the time zone. From what I can see, the 'Z' is being ignored in the parseISO8601(s, ignoreTimezone) function, and the resulting date/time is off. I have tried to explain below:

Ex1: "2010-11-30T15:00:00.0000000Z" Tue Nov 30 2010 15:00:00 GMT-0700 (Mountain Standard Time) {}

Ex2: "2010-11-30T15:00:00.0000000" Tue Nov 30 2010 15:00:00 GMT-0700 (Mountain Standard Time) {}

Ex3: "2010-11-30T15:00:00.0000000-07:00" Tue Nov 30 2010 15:00:00 GMT-0700 (Mountain Standard Time) {}

Currently, Ex2 and Ex3 behave as I would expect (Ex2 is implied local time, Ex3 has an express offset). Ex1 however comes back as local time.

I made a change to try to fix my issue, changing the if statement on line 4327 from: if (ignoreTimezone || !m[14]) { to: if (ignoreTimezone || (!m[14] && m[13] != 'Z')) {

and wrapping lines 4364, 4365, 4366 in an if statment: if (m[13] != 'Z') {

Ex4: "2010-11-30T15:00:00.0000000Z" Tue Nov 30 2010 08:00:00 GMT-0700 (Mountain Standard Time) {}

Ex5: "2010-11-30T15:00:00.0000000" Tue Nov 30 2010 09:00:00 GMT-0700 (Mountain Standard Time) {}

Ex6: "2010-11-30T15:00:00.0000000-07:00" Tue Nov 30 2010 15:00:00 GMT-0700 (Mountain Standard Time) {}

This solved my problems, as Ex4, specified as UTC, now comes back as I would expect. Ex5 (with an implied local offset) is now wrong, which I need to take a look at. Ex6 is also still correct.

So this "fix" isn't quite correct, but I wanted to get this in before leaving for the day to see if I am missing something, or if this is truly a bug.

Thanks.

Brian

It's definitely broken with the current implementation. I'd suggest a simple fix:

Add the following code in front of the "if (ignoreTimezone || !m[14]) {":

 if (m[13] == "Z")
 {
   m[13] = m[14] = "+00:00";
   m[15] = "+";
   m[16] = m[17] = "00";
 }

Simple. ^^

thanks althaus.

yeah, i agree with the premise, an explicit Z in the string should make the date parsing happen in UTC.

won't probably make this change in the next 1.4.* release, because of backward compatibility reasons, but will get this in 1.5

When I upgraded to 1.4.10, I used althaus.it's solution and it works much better than how I originally did it.

Comment deleted

I solved this problem this way:

4339c4339

< if (ignoreTimezone || !m[14]) {

if (ignoreTimezone ) { 4375,4377c4375,4379 < var offset = Number(m[16]) * 60 + Number(m[17]); < offset *= m[15] == '-' ? 1 : -1;

< date = new Date(+date + (offset * 60 * 1000));

    if (m[14]){
        var offset = Number(m[16]) * 60 + Number(m[17]);
        offset *= m[15] == '-' ? 1 : -1;
        date = new Date(+date + (offset * 60 * 1000));
    }

4820c4822

<

Issue 923 has been merged into this issue.

Issue 953 has been merged into this issue.

Hi Adam, just checking in on this bug. Anything I can do to help?

Thanks, Mike

There's already a patch on Github ready for merging. :)

this lame bug is fixed and released as 1.5.2.

'Z' is considered a timezone, so you'll need to set the ignoreTimezone option to false to get things to work the way you want.

thanks!