I’ve made some changes to the installer and upgrade script. But more importantly the schedules should now rely completely on WordPress times making ad selection and time restrictions more reliable.

This change in usage of time is a result of various reports that newly created adverts would not display. These changes likely resolve these issues but it needs to be tested on more websites than just my 3 servers to be sure.

Download here.

Temporary workaround for non-beta users!

The way AdRotate works is that this issue likely has been in existence since the very first version of AdRotate, 4 years ago, but never became really visible because the start and end dates were based on full days instead of  to-the-minute precision. Therefor downgrading to older versions will not actually resolve the issue but merely mask it.
Additionally; re-installing the same version, removing all ads and starting over will NOT solve the issue. A larger margin on start and end dates will temporarily make ads work. For instance, If you want an advert to start to display on July 25th, set the schedule for the 24th. While inaccurate, the advert will show on the 25th with an overlap to the 24th. Apply the same rule to the end date, except have it stop a day later than intended.

So what’s actually wrong then – Time is time, right?

You can skip the rest of this post as it only explains my findings and where i think the issue lies with the websites AdRotate is installed on.

Over the past days I’ve discovered that the server (Apache, Nginx, etc.), PHP and WordPress each use their own measure of time.
WordPress relies on PHP and your timezone settings from what I could find.
PHP relies on settings made by the admins and the reported time by the OS.
Apache (or whatever webserver you use) relies on the system clock or OS time.
A lot of links in a chain that shouldn’t be necessary at all. In my opinion everything should rely on the same source. Either a system clock or other central source. But that’s not important right now.

Important is that AdRotate uses WordPress features for certain time notations, for example the translation of month names and am/pm settings.
For other more invisible functions, such as ad selection, AdRotate relies on the PHP times using functions like mktime() (gmmktime()) and date(‘U’).

apparently these times differ in some cases causing the schedules to work unreliable for some people. Even when applying timezone rules vs. using WordPress’ current_time() function the dates can be off by several hours. Even if the system time, PHP time AND WordPress time are in the same timezone.

For example; My development server which stands right here next to me is off by 14 minutes even though ALL reported times throughout the entire machine are exactly the same as my iMac and an analog clock. Both machines are on the same physical desk and internet connection synchronizing to the same time servers. Using the same times and file sharing between the 2 DOES report the right time. This means that PHP is wrong somehow. WordPress is right and the OS is right too, as far as i can tell.

Over the past days I’ve been reading up on all this mumbo jumbo and found all this kind of confusing. Therefor I decided to drop using PHP and System time entirely and have WordPress figure that part out. This will require some trial and error and some rewriting of routines. But at least AdRotate will be in “sync” with WordPress so there can be no conflict there.

I think I’ve covered most of it in this beta3 and this should lead to a more reliable AdRotate where time makes sense again.