There is a problem with the behaviour of the series of events that have one instance (except the first) starting in the DST shift.
I am in EET, so for 2016, the DST shift will take place at 03:00, that is after 02:59, the clock will jump to 04:00. The first problem is that browser interpret the shift differently, so Chrome and IE will interpret
new Date(2016,2,27,3,0)
as Sun Mar 27 2016 04:00:00 GMT+0300 (EEST), whereas FF or Safari will take it as Sun Mar 27 2016 02:00:00 GMT+0200. According to specs, I would assume Chrome is doing it correctly but this is not the main point of the issue.
Start by creating a daily series from March 26, 2016, from 03:00 to 07:00. Since you are probably in a different timezone, please change the start time to the one for your location. The outcome is that the first instance is correctly assigned from 3 to 7, the second is shifted from 4 to 8 on Chrome/IE or 2 to 6 on FF/Safari and all subsequent instances are shifted. Of course, if the start time does not fall in the shift interval, the start/end times are respected with the exception that is the end time falls in the DST shift, the instance for Mar 27 will be extended in Chrome/IE or shortened in FF/Safari.
Consistency for Mar 27, 2016 is hard to achieve due to the browser differences but I assume that:
- even on Mar 27, the end time should not be affected
- from Mar 28 on, the events should respect the start/end times of the series.
My guess is that it is enough to fix scheduler.repeat_date and scheduler.getRecDates in dhtmlxscheduler.js.
scheduler.repeat_date = function(ev, stack, non_render, from, to) {
....
var td = new Date(ev.start_date.valueOf());
var sh = td.getHours();
var eh = new Date(td.valueOf() + ev.event_length * 1000).getHours();
....
if (!ch) { // unmodified element of series
td.setHours(sh);
var ted = new Date(td.valueOf() + ev.event_length * 1000);
ted.setHours(eh);
....
};
Eventually, create the instance only if td < ted.