More reminders than set, each received 2 or 3 times

OK, now, this is very strange. I wish I knew how to reproduce this.

First question: What do you have "Cron Frequency in minutes" set to? That's under admin/settings/datereminder.

Then, what can you tell me about poormanscron? (I take it you don't have the ability to use "real" cron to do regular processing?) I'm looking at the project page. You're using version 2.x, I hope?

Another question: Is this a one-time event, or repeating? How often does it repeat?

Do you know if poormancron guarantees that cron will only be invoked at most once each 60 minutes (say)? I suppose it's possible that if datereminder_cron() got called several times concurrently, it would probably break.

I also suppose it's possible that something funny is happening with timezones. Does your site use UTC? It shouldn't make a difference, but I don't know at this point.

I'll do some head scratching looking at code. Feel free to do the same.

One other thing: I'm a bit confused about your setup. Something doesn't seem to line up right. You say that you created an event at 8am to occur at 8am, and then created three reminders to go off before that? That doesn't sound right, unless it's a repeating event. Datereminder shouldn't let you schedule a reminder for after the event.

Could you perhaps dump out what you find at admin/settings/datereminder/view right after you scheduled your reminders, and then after each set of reminders goes out?

You can't edit the issue? Isn't there an "Edit" button up under the title, next to "View?" I see that on issues I've submitted to other projects. But anyway, I corrected the time to avoid further confusion.

1. The fact that you get several reminder messages when there should only be one. (Just to clarify, you did mean one user with three reminders scheduled, right?)
2. The fact that there are extra reminders when not expected.

The first issue could be explained of hook_cron() can be called several times concurrently. That's not an issue with multiple cores. Even on a uniprocessor, process scheduling can cause multiple processes to interleave time on the processor. The question is whether Drupal or poormanscron have logic to prevent multiple concurrent runs, or is a cron hook expected to deal with that? Research needed.

The second issue, could, possibly, be due to "inconsistent" default values in the code. I think that in at least some releases, different routines had different defaults, assuming that the system administrator would actually set a value. That could lead to strange behavior. I thought that was fixed in beta1, but I'm not sure. Could you please check and be sure that the frequency is explicitly set to 60 in the admin menu?

And again, if you could report what you see in admin/settings/datereminder/view, especially after the last reminder when you keep getting them, it would be a help.

Hmm. A couple of interesting things I found:

https://drupal.org/node/119094
http://drupal.org/node/361071
drupal_cron_run()

Apparently, others have had similar problems in the past, but it's unclear to me what was fixed. Need to read more. But not now.

In particular, others had problems with concurrent calls to their cron hook when using poormanscron. It appears that drupal_cron_run() is intended to eliminate the concurrent calls. What's unclear to me is whether poormanscron uses drupal_cron_run().

Studying history a bit more, it appears that poormanscron was chagned to use drupal_cron_run() quite a while ago, and version 6.x-2.2 should definitely have that fix. So I'm guessing this may have something to do with computation of when reminders should next be sent rather than concurrent calls to datereminder_cron().

So, we need to figure out what's "different" with your site.

I'm still wracking my brain over this. I just can't get it to break. Some possibilities, maybe you could check:

1. What database are you using? Something other than mysql? Maybe we're running into something that behaves differently with something other than mysql.
2. Could we be running into a problem with a failed update? I wasn't always good at providing update routines in the original sandbox code. It's conceivable that your update from one of the old sandbox versions to the current "beta1" version left you with an incorrect database. Maybe you could post a schema dump of the datereminder table?

I may just have to try using poormanscron instead of "real" cron, though I don't know how well that will work given that my site has pretty light traffic.

Rats. That all looks correct.

Well, maybe if you could dump the date datereminder table after you initially request the events, and after you get the first set of reminders (but expected only one), maybe that will tell something.

Thanks for your help in diagnosing this.

I don't know if anyone else is actually using this, yet. It would be nice to know if others have seen this, or it's something peculiar to your setup.

This isn't related to poormanscron. (Though note that poormanscron won't run more often than once per hour, and the timing is unpredictable unless your site has a lot of traffic. That's fine, as long as you understand that.

An update...

It sounds like this is related to tying Date Reminder to a "Date" field in the node instead of "DateTime" or "Datestamp." That makes sense; since "Date" stores only the date, Date Reminder will probably get confused about the time of the event. It's not quite as simple as saying that the field has no time, but there must be some difference in how the date APIs represent time. Date Reminder seems to know the time, but some of the calculations just don't work right.

Further study needed. But at least this is something I can try in my development environment. Possible solutions:

Figure out how to include time for "Date" CCK fields.
The preferred solution, but I don't know what it will take.

Restrict "lead times" to one day or more for Date fields.
If the above doesn't work, this is a reasonable fall-back.

Don't allow Date Reminder for Date-only fields.
I don't like this, but if nothing else works...

Aha. I think we're getting somewhere.

I notice that "Date" is format "YYYY-MM-DDTHH:MM:SS", but Datetime is in the database native format "YYYY-MM-DD HH:MM:SS". No, I don't access the database directly, but I do use the datefield data. It's probable that the "T" appears in the internal data structures.

And that could certainly confuse things when it comes to comparing date strings, for example in the routine that looks for the next event occurrence after a given datetime. That routine doesn't understand the two formats.

Unfortunately, as far as I know, there isn't an api function for something like "Give me the next instance of this repeating date after this given time." That's what's needed.

Yes, I've confirmed that the problem is the "DDTHH" (Datetime) instead of "DD HH" (Date). It should be a relatively simple fix. But not tonight.

Fix checked in. Working on making a dev release.

So I only get one notice per reminder, and they sopped as they should.

So it sounds like (except for the below, a very separate issue) it now works for you. Thanks!

The last reminder was late certainly because my server does all backup at midnight, lasting about one hour.
I just wonder why the 8pm reminder was early...

Since reminders can (theoretically) be scheduled for any time, but cron runs only periodically, Date Reminder can't guarantee that reminders will be sent exactly on time. Date Reminder tries to minimize the time error by sending any reminders that are pending between "now" and half way to the next anticipated cron run. That's why the setting is there to say how often cron runs.

So, for example, if cron is expected to run each hour, and it runs at 6:00, any reminders scheduled before 6:30 will be sent. (That might include reminders that were scheduled for 5:45, say.)

You're using Poormanscron, which doesn't run on a regular schedule. There will be at least an hour between cron runs, but it could be more depending on traffic.

It looks like, in this case, there was a cron run at about 6:13, and then about 7:38. At the 7:38 run, the 8:00 reminder was sent because that would be closer than the expected next run at 8:38.

With cron running regularly once/hour, the reminder times can be off by as much as a half hour. With Poormanscron adding extra delays, the variation can be even more.

So, basically, this is expected behavior, given the configuration.

And thanks for bearing with me through all of this.

Corrected time of the event. Per submitter, event for 8pm was created at 8am.