Fix cron timeout

[tjokimie]

Closes #8.

If cronTimeout is 0 or negative, the runner has already been invoked. Instead of setting cronTimeout to 1 (one millisecond) we should get the next time from the iterator.

[tjokimie]

I did not write a test case for this one as I couldn't reproduce the issue with every second cron expression. If I would write a test with the every minute expression it would slow down the tests significantly 😞

[coveralls]

Coverage remained the same at 100.0% when pulling 0630676 on tjokimie:fix-cron-timeout into 022a786 on airbnb:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 0630676 on tjokimie:fix-cron-timeout into 022a786 on airbnb:master.

[kesne]

Instead of replicating the same iterator code twice, could we just wrap this into a function we can call?

[tjokimie]

👍 Extracted nextCronTimeout.

[kesne]

This is great, thanks for fixing this bug. I'm curious when the time returned from the iterator would be negative. 0 seems possible although unlikely.

[tjokimie]

The time returned from the iterator is not be negative, but cronTimeout (the result of iterator.next().getTime() - Date.now()) can be negative as iterator.next().getTime() can return current time and after that Date.now() will be subtracted from it.

[kesne]

Ah fair, I confirmed that this can happen in my console too:

for (var i = 0; i < 10000; i++) console.log(Date.now() - Date.now())

This sometimes prints negative numbers.

[coveralls]

Coverage remained the same at 100.0% when pulling 839679c on tjokimie:fix-cron-timeout into decbf21 on airbnb:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 839679c on tjokimie:fix-cron-timeout into decbf21 on airbnb:master.

[coveralls]

Coverage remained the same at 100.0% when pulling 839679c on tjokimie:fix-cron-timeout into decbf21 on airbnb:master.

[kesne]

Published as bossbat@1.1.1. Thank you so much for finding this and contributing!