|<< Back to previous view|
[OX-5801] Logic Flaw In Campaign Activation/expiration In 2.8.2 Created: 23/Oct/09 Updated: 08/Jan/10
|Project:||OpenX Ad Server|
|Component/s:||OXP: Core, OXP: Maintenance Engine|
|Affects Version/s:||OpenX 2.8.2|
|Fix Version/s:||OpenX 2.8.4|
|Security Level:||Public (All users can see these issues)|
|Reporter:||Michal Czosnyka||Assignee:||Miguel Correa|
|Original Estimate:||Not Specified|
There is a major problem with campaigns activiating before their start date that exists in 2.8.2. The problem is that the campaign activiation does not compare date/time's within the same timezone and thus there is room for campaigns starting and ending early or late depending on your timezone.
The server has the timezone set to Australia/Sydney, for example if we use "dpkg-reconfigure tzdata" on Debian to confirm the timezone.
Just to confirm that the server is reporting the correct date/time.
The php.ini configuration file has the timezone set to Australia/Sydney, as you can see below.
The timezone within OpenX is currently set to Australia/Sydney as well, as you can see below.
So we can now safely assume that our OpenX installation is configured correctly and there is no chance that a misconfiguration could be causing the premature campaign activations.
I created a campaign with a start date of Saturday the 24th of October on the afternoon of Friday the 23rd of October and with the default OpenX 2.8.2 code the campaign activates immediately as if today was the 24th.
Within the database, which OpenX has activation and expiration date/time's saved in UTC, we can see that OpenX has saved the following activation date in the oa_campaigns table for this test campaign.
The current UTC time is approximately 2009-10-23 05:30:00 as previously seen at the start of writing this. Therefore this campaign should not activate upon saving the activation date but it does activate immediately.
I've identified that code within lib/max/Dal/DataObjects/Campaigns.php in the _isAwaiting() and _isExpired() functions is the cause of this, which I'll now explain in more detail.
The original code, for _isAwaiting(), is as follows:
The general gist of this is that we get the current date/time in the $oNow object and then compare the date/time in the $oActivate object to see if we have reached the activation date/time. $oNow contains the current date/time in the timezone that has been set on the server, which is correct. $oActivate contains the activation date/time that comes from what is saved in the database, which is also correct, but the timezone on this object is not set to UTC even though the value of $this->activate_time is in UTC.
This is a var_dump of $oNow, notice that the date/time is correct for the timezone that the server, PHP and OpenX is configured for.
This is a var_dump of $oActivate, notice that the date/time is the same UTC date/time as what is saved in the database (see the MySQL query above) but the timezone is set to that of the server, PHP and OpenX. It is not set to UTC.
Therefore when we perform a comparison between these two objects the result will be incorrect. The $oActivate object needs to have the timezone set to UTC in order for the Date PEAR library to correctly compare the dates when using before() and after(). There is a simple solution for this which is to call setTZ('UTC') on the $oActivate and $oExpire objects after creating them. I've implemented these changes in lib/max/Dal/DataObjects/Campaigns.php, as you can see below on 220 and 246, and now the campaign activation and expiry is working 100% correct.
|Comment by Michal Czosnyka [ 23/Oct/09 12:36 PM ]|
|It looks like the issue is related to the new feature which hasn't been implemented yet.|
|Comment by Matteo Beccati [ 24/Oct/09 11:19 AM ]|
|Most likely something I overlooked when making the activation/expiry UTC changes.|
|Comment by Joanna Mazgaj [ 10/Nov/09 03:35 PM ]|
|verifying. passing for developer's investigation.|
|Comment by Miguel Correa [ 01/Dec/09 06:45 PM ]|
Fixed bug on OpenX v2.8.3-rc5 (it will be working on OpenX v2.8.3-rc6 or greater)
(Thanks to the user for reporting this bug, the patch applied differs a little bit to the user's patch)
|Comment by Joanna Mazgaj [ 08/Jan/10 09:03 PM ]|
|Haven't had a problem with campaign's activation time during tests. Closing.|