| Issue 750: | Z in ISO8601 dates (should parse as UTC) | |
| 8 people starred this issue and may be notified of changes. | Back to list |
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
Dec 26, 2010
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
Summary:
Z in ISO8601 dates (should parse as UTC)
Status: Accepted Labels: Type-Defect
Jan 7, 2011
When I upgraded to 1.4.10, I used althaus.it's solution and it works much better than how I originally did it.
Mar 11, 2011
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
<
---
>
May 8, 2011
Issue 923 has been merged into this issue.
May 18, 2011
Issue 953 has been merged into this issue.
Jun 11, 2011
Hi Adam, just checking in on this bug. Anything I can do to help? Thanks, Mike
Jun 23, 2011
There's already a patch on Github ready for merging. :)
Status:
Started
Aug 21, 2011
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!
Status:
Done
|
|
| ► Sign in to add a comment |
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. ^^