How is the time interval calculated?

Just to answer my own question in case anyone else is wondering the same thing, the timer starts at node creation, so if a node is created a 1pm and notifications are set to hourly, it is supposed to aggregate all appropriate content for an hour after the first node is created, then send out the digest at the end of that hour. This worked *most* of the time in my tests, but it also sporadically sent messages before the timer had expired. I'll have to post a separate issue about it soon.

Thanks for getting back to me, this has been quite confusing. I gained a little clearer understanding of it today... I think. So does the timer start at the initial node creation, the way I described in my followup post, or is it strictly working off of the last time the user received a message? I think my tests may have been skewed because I was only sending the test messages to a single user with individual posts. I've read all the documentation and a lot of the code comments, but none of it is very clear on this issue. Any chance of adding a blurb about it with some clear examples into the documentation pages? I think it might be helpful to other users. Thanks again for a great module, BTW!

It's been a couple years since I last touched notifications, but I vaguely remember this issue. At the time I patched the module, but you could do it without a patch I think. It's a per user timer, as Jose said but, you should be able to do it with hook_notifications in a custom module though. This is called at certain events, like adding to the queue for processing and sending. Play with that and check out what it sends during queue processing (you might need to run cron to trigger it?). You can probably trick it into doing what you want there. I would think you could change the eid to something that will never return a result and kill any messages (or all messages) from being sent, unless your time interval condition was met. I'm pretty sure that the module would keep adding things to the queue unless marked as sent, so you don't lose anything if you don't send it when it expects to. Haven't tried it, but that's what I would try first, if I had to do it again. Just make sure you have a large enough window to send all the messages during whatever time frame you mark as open for sending. Messages that are created and marked for immediate sending would also get through during your open window so there's an aggregation gap as well (at least, I ran into that doing it the my other way anyway).

 // Modules can do cleanup operations or modify the queue
 493   notifications_module_invoke('event queued', $event, $query);
 494 
 495   // Now update event counter with rows in notifications_queue or delete if no rows
 496   if ($count = db_result(db_query('SELECT COUNT(*) FROM {notifications_queue} WHERE eid = %d', $event->eid))) {
 497     db_query('UPDATE {notifications_event} SET counter = %d WHERE eid = %d', $count, $event->eid);
 498     // If immediate sending enabled, store eid for sending on page exit.
 499     notifications_send_immediate($event->eid);
 500   }
 501   else {
 502     db_query('DELETE FROM {notifications_event} WHERE eid = %d', $event->eid);
 503   }