All cron jobs defined in cronapi run together and immediately

I'm not sure i've undestood correctly the problem.

When you enable for the first time a module, it has no "previous runs" of cron jobs, so the normal behaviour is to run all cron jobs for the first time.
After that, next runs will follow cron rules specified.

Omg that sucks !

If I have plan one task at 9am, I don't want that execute at 10pm just because it haven't last time execution.

When you enable for the first time a module, it has no "previous runs" of cron jobs, so the normal behaviour is to run all cron jobs for the first time.
After that, next runs will follow cron rules specified.

I am shocked because that mean that a cron task can be executed at any time even if this is programmed at 9am for example without user's validation.

This is important problem because for determine the next time in the futur that each task is to be run this module is based on last execution time and there are many reason for which this date can be bad.

$date = __cronDecodeDate($conf['last_run'], 1);
...
some traitement
look file elysia_cron_scheduler.inc for more details
...
return __cronEncodeDate($date);

In the code itself author try to limit this problem with a large conditional
return $now >= $next_run;

But to put things into perspective this module works perfectly in a lot of use case : blog, content publication, session close, ...

Yet I would have apreciated to find something about it in comment, or readme instead spending to much time on it.

Thanks for reading me.

This is a HUGE issue. Either there needs to be a big red warning on the Cron settings page, or this needs to be remedied.

One of our live sites just sent out 5,000 emails and completely altered all of the user accounts because there were zero warnings that cron would run automatically the first time instead of on the scheduled date.

Would it be an acceptable solution to have the last executed time set to the time the line was added? This would prevent it running the first time cron runs, but would also technically show inaccurate information on the dashboard.

I suppose this could be worked around by setting the execution count to 0, and if the execution count is zero, do not show the last executed time on the dashboard.

Should be a pretty simple patch, but I'd like to get some other opinions on the approach before moving forward.

@jmking I think your aproach is a good solution

@jmking's suggestion is interesting.