MaxMem

This is probably a duplicate of my issue from a couple years ago: https://github.com/bunkat/later/issues/90 There is a built-in buffer of one second because the timer often fires early, but over...

The reason appears to be that it's a fudge factor to combat the issue with the function executing earlier than expected: https://github.com/bunkat/later/issues/90#issuecomment-101754640 However, sometimes 1 second is not enough, causing...

This just happened again, this time after less than one day. Process started at [2015-02-16 16:16:31.114] Double executions in tasks a,b,c,d,e,f,g,k,l,n,o the next morning: [2015-02-17 07:59:53.862] [DEBUG] a - Perform...

Do you think it could make any difference if the next task is scheduled before the current on is executed? (swap lines 822 and 833 in later.js)

It looks to me like setInterval uses infinite recursive functional calls to schedule each successive timeout. Do I have that right?

My experiements show that "now" routinely comes up earlier than it was scheduled to. In just a few iterations I've seen up to 879ms early. It look like you knew...

I captured a double execution: ``` [2015-02-19 07:59:58.443] [DEBUG] server - Running task f Diff: 1557ms (i.e. 1.557 seconds, 0.025949999999999997 minutes.) [2015-02-19 07:59:58.450] [DEBUG] server - Running task a Diff:...

I'm willing to test it but it is not obvious to me how one would track the next expected execution time in order to try the above fix.

bunkat, If the finest resolution is meant to be one second, then why does later.schedule(sched).next() produce times which are not on even seconds? Instead, they seem to be anchored to...

It would be helpful to have documentation of how later.schedule(sched).next() is intended to work. This would assist in re-designing the timer functionality which relies on it.