We also have had a problem with date/time issues in DayPilot. The confusion lies in the fact that the server side code and what is rendered assumes on the calendar is local time (i.e in our case BST/GMT+1), but daypilots client/javascripttimes get calculated with the localtime with the timezone offset removed (i.e. modified to UTC - +0000), but without adjusting the time for UTC. This makes all actions (like timerangeselect) pass the wrong date/time, offset by the difference between server time and the clients local time.
i.e. during BST/GMT+1, our calendar starts atmidnightor 12AM BST, which is 11PM UTC/GMT the prevous day, the way daypilot calculates it's dates for client side code uses 00:00:00 +0000 as the start, so selecting a timerange say from midnight to 1am, will pass a range of 00:00:00 +0000 to 01:00:00 +0000. This is wrong. When Javascript parses the date and converts it to a date object, it willbe converted to the clients local time zone .. 00:00:00 +0000 on my machine (in BST) will convert to the Date(01:00:00 +0100) .. I didn't select 1am BST, I selected midnight BST.
In order to correct this, I've modified the DOM after day pilot renders. I've updated the columns/event dates in the DOM to use +0100 (or the offset on our server) instead of +0000.I've done this by using a javascript framework (ExtJs) to find the calendars column headers (where thestarting date/time seem to be calculated from), and simply replacing the +0000 with +0100 (or whatever your data/server/users local time is), using a regex. I've also done the same across all client-side dates/times which also have the incorrect time (right time, wrong timezone). DayPilot now works perfectly, and as we'd expect - all client-side code works with the correct/local time, and we can work happily with local date/times on the server.
After a long time looking at this issue I think as I have it it's the correct behaviour -is there any chance that this might get fixed in a release?