Infinite loop due to clock changes (daylight savings time)

There have been repeated issues about crashes and infinite loops caused by changing the date, especially due to daylight savings time changes. See #11, #131, #132, #214, #208. This issue is aimed to be a consolidation of those issues and a final solution. It would be good if we could avoid closing this until we absolutely sure that this is fixed for good.

This issue has caused downtime for us two years running now (when the clocks go forward at the end of March in the UK), with 0.1.13 and 0.1.16, and I’ve only just worked out that node-schedule is the cause.

Most of the issues above point to the while (true) loop in nextInvocationDate(), which can get stuck when Date either doesn’t increment or jumps back unexpectedly. For example, it will increment one minute at a time… 00:58:00, 00:59:00… but then jumps back to 00:00:00 because 01:00:00 does not exist on the night of daylight savings time.

This has been reported for 0.1.8, 0.1.13, 0.1.16. Apparently it’s fixed every time, only to find a new report against the next version that it’s still similarly broken. One comment said there was a complete overhaul of this to fix it once and for all in 1.0.0, but I’ve just upgraded to 1.1.0 and it’s _STILL_ broken! Daylight savings time… the endless source of bugs 😦

To reproduce:

var sinon = require('sinon');
var clock = sinon.useFakeTimers(+new Date(2016, 2, 26, 23, 59, 55), 'Date', 'setTimeout');
console.log('NEW DATE', new Date());
var schedule = require('node-schedule');
setInterval(function () {
    clock.tick(1000);
    console.log('NEW DATE', new Date());
}, 1000);

schedule.scheduleJob({ minute: 0 }, function () {
    console.log('MARK ' + new Date());
});

Run the above with version 0.1.16 or 1.1.0 and it will go into an infinite loop when reaching 01:00:00. Depending on the version it will may be running the job repeatedly or just constantly trying to work out the next job time.

It seems there are two variations of this bug:

1. nextInvocationDate going into an infinite loop trying to work out the date of the next instance
2. Running an event at 00:00:00, working out the next event is at 00:00:00 (because 01:00:00 got changed back to 00:00:00), running the event again, working out the next event is at 00:00:00 again, etc.
3. Any others?

What can be done to finally fix this for good? How might it be rewritten if we start with the assumption that Date is malicious and will actively try to cause an infinite loop if it can?

Thanks.

[breel007]

Confirmed this is still an issue: Following code results in an infinite loop in nextInvocationDate, starting one week before DST starts. I believe it would start to work fine again after DST switch-over passes.

var ruleReboot = new schedule.RecurrenceRule(); ruleReboot.dayOfWeek=0; ruleReboot.hour = 3; ruleReboot.minute= 30; schedule.scheduleJob(ruleReboot, function(){
piReboot(); });

[santigimeno]

@SystemParadox sorry for the delayed response.

There are so many packages that have already dropped support for it that this probably isn’t worth making a workaround for What do you think?

I think I agree with you. I don’t think making a workaround is worth it.

Thanks!