There seems to be a bug with recurring events and daylight savings time.
Let’s say I have an event which occurs at 00:30 and repeats weekly on Thursdays.
I was just looking at the calendar in week view and with DST coming up on March 10th, I noticed that the event that should occur on Thursday March 14th is showing up on Wednesday March 13th. The times are correct, but the date is not.
This only happens if the recurring event starts before 01:00
This issue also affects the collision extension. Collisions are detected even though there really isn’t a collision.
How do I resolve these issues? Is there a way to ignore DST?
Let me know how I can help.
This only seems to happen in week view.
In all other views, all events are on the correct day, but in week view, it first recurring event after DST is on the wrong day.
Which TimeZone is set on your PC ?
This only seems to affect the first occurrence of a recurring event after DST
The recreate, try the following:
- Use week view
- Go to the week of March 10-16 (Sunday as start of week)
- Create a weekly recurring event on Thursday (March 14) from 2:00 and 4:00
Issue the following command from the console:
scheduler.getEvents(new Date('Mon Mar 11 2013 00:30:00 GMT-0400 (EST)'), new Date('Sat Mar 16 2013 23:45:00 GMT-0400 (EST)'))
Look at the start_date and end_date for the event instance the above command returns. You should notice that it listed as 01:00 and 03:00
Something is definitely wrong here.
This issue is in here:
this.date[f] = function(nd, td) {
var delta = Math.floor((td.valueOf() - nd.valueOf()) / (day * step));
if (delta > 0)
nd.setDate(nd.getDate() + delta * step);
if (days)
scheduler.transpose_day_week(nd, days, 1, step);
};
Check this out:
d = new Date('Sun Feb 24 2013 02:00:00 GMT-0500 (EST)')
d.setDate(d.getDate() +14)
d
Look at the new value of d
Can’t reconstruct it locally 
I have changed timezone and have repeated the same steps - still problem does not occur
Can you try the same steps from different PC and check is problem occurs or not
I just duplicated this issue from two other computers.
I see that the instructions I gave were not correct. Step number 2 was not correct. Do not go to the week of March 10-16. Just make sure you are in week view of the current week. And then do the following:
- Use week view (Sunday is start of the week)
- Create a weekly recurring event on Thursday (Feb 28) from 2:00 and 4:00. The key is the recurring event is created prior to DST and that it start at 02:00.
Now if I move my view forward 2 week so that I am looking at the week of March 10-16, the event actually displays correctly on Thursday the 14 at the correct time of 02:00. This is because if you execute the following command which generates a list of events for the current week’s view:
scheduler.getEvents(new Date('Sun Mar 10 2013 00:00:00 GMT-0500 (EST)'), new Date('Sun Mar 17 2013 00:00:00 GMT-0400 (EDT)'))
The start date is before DST and the scheduler code does the correct math. But if you change the start date in the above command like so, you will see that start_date of the event returned is off by an hour:
scheduler.getEvents(new Date('Sun Mar 10 2013 03:00:00 GMT-0500 (EST)'), new Date('Sun Mar 17 2013 00:00:00 GMT-0400 (EDT)'))
This is a problem because this can easily be run into when using the collisions extension. The collisions extension gets list of recurring dates for the new event to be created and then looks at each of those dates and gets a list of events that occur between the start and end time of that recurrence. This is where the wrongly-timed events are appearing and resulting in false collision detections.
I believe part of the problem is that the hours of 02:00 to 02:59 on Sunday March 10th do not exist. Try executing this in the console:
new Date('Sun Mar 10 2013 02:00 GMT-500 (EST)')
Thoughts?
Were you able to reproduce based on my updated instructions?
Hello,
yes we’ve reproduced the bug, thanks for the instructions. Currently the bug is being investigated, I’ll try to post hotfix in this topic later today
Try the attached version of recurring extension.
Please let us know if the issue still appears or if the fix had broken something
dhtmlxscheduler_recurring_130305_1.zip (6.69 KB)
I will check it out as soon as I get into the office.
Over the weekend I came up with the following work around. In “onEventCollision” is look at each of the “supposed” collisions and compare each one’s start_time hour to that of it parent (event_pid) and if they are not the same, then this is not really a collision. This will work for me because all of my event are recurring so if this was really a collision, the rest of the instances in the series would be too.
scheduler.attachEvent('onEventCollision', function (ev, evs) {
var collisionDetected = 0,
e,
parentEvent = null,
len = evs.length;
// Iterate over the supposed collisions. I say supposed because due to DST, the scheduler finds false positives
// when there is a weekly recurring event scheduled between 02:00 and 02:59. It will usually find these fakes during
// the week of DST (usually in early-mid March)
for(var i=0; i<len; i++) {
e = evs[i];
// If the event has a parent, get the parent so we can compare start times
if(e.event_pid) {
parentEvent = scheduler.getEvent(e.event_pid);
// Check to make sure the potential collision and it's parent have the same start hour. If they don't then
// it is the result of a DST bad math error and we can disregard it as an error
if(e.start_date.getHours() === parentEvent.start_date.getHours()) {
// We've found a bonafide collision
collisionDetected = 1;
break;
}
}
}
// Returning true will keep the event from being created
return collisionDetected;
});
Did you add a function _currentDate() to scheduler?
I am getting an error that this function doesn’t exist.
Please disregard my last post. I didn’t have the latest dhtmlxscheduler.js
Ok, so it seems like your hotfix solves my issue. But, it doesn’t resolve a different, related issue.
Here are the instructions for reproducing:
- EST, America/New_York timezone
- Set scheduler to weekly with Sunday at the start of the week
- Make sure you are in the current week (Sun March 3 - Sat March 9)
- Create a weekly recurring event on Thursday March 7 between 00:45 and 02:45 to recur on Thursdays
- After saving the event, move the scheduler forward to the next week and you will see that the event is now being shown on Wednesday
The key is that the event’s start time is before 01:00. This will actually happen for any event scheduled Mon-Sat during that week when the start time is before 01:00
If you try and create an event on Sunday, March 10 at 02:15, it automatically moves it to 01:15
Thought?
Confirmed. Scheduler calculates day index incorrectly when the min_date of the view and the start_date of event are in different timezones.
min_date of the view is 10th March, 00:00:00(UTC -05:00), all events after DST are in UTC -04:00. Incorrect placement of the events was caused by the resulting timeshift.
Please try the attached version of the component, issue should be fixed now
dhtmlxScheduler_130306.zip (228 KB)
This fix resolves the issue with the event showing on the wrong day.
I think I may have found another related issue.
If you try and create a weekly recurring event during the week of March 10-16 with a start time between
02:00 and 03:00, the event ends up scheduled to start an hour early. So an event you are trying to schedule for 02:30 on Monday March 11th gets saved with a start time of 01:30.
This happens in week, day and month views. And then all of the recurring events also have the wrong start time.
Were you able to confirm the issue with trying to create an event during the week of March 10-16 with a start time between 02:00 and 03:00?
Hello,
as you’ve said before, in Eastern Time hour between 02:00 and 03:00 on 10th March does not exist. So event’s start_date(which is javascript Date) can’t have such value. It will also true for DST shifts in other timezones.
So such behavior seems correct.
However it would be clearer if hour selector in details form won’t contain that hour
