| Issue 2282: | gcal request parameter not contain ISO8601 time part at defaultView:'agendaDay' mode | |
| 1 person starred this issue and may be notified of changes. | Back to list |
Issue: Events at Google Calendar not showing between 0:00 - 9:00(GMT+9 Asia/Tokyo). To Reproduce: * Calendar timezone is Asia/Tokyo. see: http://jsfiddle.net/m6vs09yh/1/ I fugure out this issue stem from gcal api parameter requesting 'start-min' and 'start-max' without Time part. (e.g. set defaultDate: moment('2010-01-01T00:00:00+09:00') , expect start-min: 2010-01-01T00:00:00+09:00 , actual start-min: 2010-01-01 ) gcal API probably read 2010-01-01 for 2010-01-01T09:00:00+09:00. (2010-01-01 as 2010-01-01T00:00:00+00:00. Calendar timezone setting is Asia/Tokyo, this is 2010-01-01T09:00:00+09:00) Therefore, gcal api events response returns between 2010-01-01 09:00:00+09:00 and 2010-01-02 09:00:00+09:00, not 2010-01-01 00:00:00+09:00 and 2010-01-02 00:00:00+09:00 (and this is correct). Reason(may be...): https://github.com/arshaw/fullcalendar/blob/81e436cc0be82e54940e3e26d44c1eae51cfe7b1/src/Calendar.js#L522 arguments of fetchEvents(currentView.start, currentView.end) are ... https://github.com/arshaw/fullcalendar/blob/81e436cc0be82e54940e3e26d44c1eae51cfe7b1/src/agenda/AgendaDayView.js#L25 called stripTime(). This is ambiguous-timed parameter. So. format() is returne like YYYY-MM-DD. TODO: This (probably) affected agendaWeek. P.S.: I pathing my project that AgendaDayView#start and end field is not-ambiguously-timed. (not calling stripTime()) This patch's negative impact is not known, but seems running correctly
Nov 25, 2014
This is almost definitely fixed in v2.2.2 and v1.6.6 The new gcal api forced me to do things differently. Can you try the updates (keeping in mind the migration needed for v3 google calendar api) and let me know if there are any more problems? http://fullcalendar.io/docs/google_calendar/
Status:
Done
|
|
| ► Sign in to add a comment |
Labels: Type-Bug