Expiration Dates being set

I'm unable to duplicate this. I added a text ad and an image ad, but in neither case was the expiration date set. What steps did you go through to create your ad? Did you enter anything at all in the scheduling section?

Do you have any other non-core modules enabled? Perhaps one that provides scheduling or workflow for nodes? (I'm wondering if there's a namespace collision with node->autoexpire, though it seems like a stretch.)

When you go back to set the image ad as "active", is the scheduling fieldset collapsed or expanded? Is there actually a date in the expired section?

If you go back and re-enable the ad, being sure to remove any values in "automatically expire ad", does the ad automatically expire again on the next cron run?

If you set a real expire date some time in the future, does this value get saved and does the ad then say "ad will expire in n days", and not expire on the next cron run?

I've reviewed all the autoexpire logic, and I don't see any reason for your problem. I'm starting to be more and more suspicious of namespace collision. Can you execute the following query in your database and send the output?

         SELECT name FROM system WHERE type = 'module' AND status = 1;

Thanks for your help debugging this! I wish I could duplicate it locally...

In addition to the above information, which OS are you using?

I do not see any suspects in your list of enabled modules, and grepping through their code does not reveal any namespace collision. There must be something funky with my expiration logic. I'm out of time for debugging this now, but will look at it again as soon as I can -- for now I recommend setting your expire dates way in the future, as you have.

I was unable to duplicate this bug, or to spot the logical fault. I will leave this issue open to remind myself to continue looking into it, and hopefully to collect more information as to what is causing this problem on your installation. If anyone else is experiencing this problem, please speak up.

This bug is very low priority for me, but I thought I'd share my experience as an additional data point.

I am also seeing this issue (with beta5). In my case, the activate and expire times are always set to 10PM when I save an ad with blank schedule fields. It happens on newly created nodes or when I manually delete the fields on an existing node.

I doubt it makes any difference, but I tested with both IE7 and FF2 and saw the same results.

If my current local time is before 10PM, the date set is yesterday. If my local time is between 10PM and midnight, the date set is today (but the time is obviously still in the past).

One idea that comes to mind is that my user's timezone setting (under my profile / edit / locale settings) is 2 hours before the web server's timezone setting. So the localized display time (10PM) is 2 hours before midnight (start of the current day) on the server.

I wonder if the differences between user timezone, server timezone, and GMT could be confusing the default date/time calculation for these fields.

(In any case, the easy work-around is to edit the node and set the expire date to some time in the future.)

JM

Which version of the module are you using? I'm still unable to duplicate, though I recall this happened to me once long ago -- perhaps you're using an outdated version of the module? Please download -beta7 and try again.

This has been fixed in the DRUPAL-5 version. Jeremy, you'll need to backport:

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/ad/ad.module?...

In short: strtotime('') or strtotime(0) will use the current timestamp - thus, if a user DID NOT set the autoexpiration date, it'd be set immediately in insert/update nodeapi (since the value wouldn't exist). I just added a ternary check.

Thanks Morbus, fix backported to the 4.7 branch.