I have a an application built with the jQuery based fullCalendar
http://arshaw.com/fullcalendar/
My calendars events are loaded by an Ajax call that outputs JSON, it is configured to have Monday as the first day of the week and the default view is week.
It has been working fine, but I noticed that if I go forward to week 13 (beginning March 26th) the events are not loading properly. I figured straight away this must have something to do with daylight savings time changing which happens March 25th.
When I use the click on the next/prev buttons the calendar makes an ajax call using automatically generated start and end times, my php script on the background takes the start date calculates the week no and calls all the events in my database for that week.
For example on week 12 teh following variables are passed:
?start=1332115200&end=1332716400&_=1331237729591
PHP script:
$week_no = date('W', $_GET['start']);
Which works out as week no 12.
However the following week the variables passed are:
?start=1332716400&end=1333321200&_=1331238038820
$week_no = date('W',$_GET['start']); == 12 // same as last week
Nn further examination
echo date("C",1332115200); // == 2012-03-19T00:00:00+00:00
echo date("C",1332716400); //2012-03-25T23:00:00+00:00 (1 hour short of being in week 13)
So obviously teh daylight change is causing the problem.
My question is, is this a problem with fullcalander or my PHP logic?
First of all: I don’t know your code and your settings, so all I’m saying is pretty much a guess.
If you’re systems are both set to UTC, there wouldn’t (shouldn’t) be a problem. The same goes for the correct usage of the JavaScript functions date.getUTC* (the fullCalendar does not use those) with a server set to UTC. But I think that only your server is actually set to UTC, while your computer is set to “Europe/London” or anything like that (that looks right now like UTC, because it is UTC+0 in the winter).
That all results in the following situation: fullCalendar tries to calculate the timestamp for e.g. 1st July 2012 00:00:00 – because the computer is set to a timezone where at that date a DST applies (UTC+0 in the winter, UTC+1 in the summer -> 1st of July = UTC+1) you will get a timestamp for that moment in time where it is 00:00:00 on the 1st of July IN LONDON. Because their time is one hour in front of the UTC, you will get 23:00:00 if you interpret that timestamp relative to UTC – and that is, what the server does.
A solution can be as simple as this:
That way, the server should interpret the timestamp relative to UTC+0 if the corresponding date is in the winter and relative to UTC+1 if it is in the summer.
However, if the visitors timezone is set to something different e.g. “America/Los_Angeles”, your application is still messed up and won’t work as expected. The best way is usually to use UTC timestamps everywhere, but fullCalendar does not support that currently.