On every cron execution the statistics.module checks if the time between now and the last day-count reset is bigger than (or equal to) 24 hours. If so, it will reset again. After that the module updates the statistics_day_timestamp variable, which indicates the time of the last reset - and here the problem begins... If the db update takes at least one second, the time-stamp moves forward and tomorrows reset is performed one cron execution later (because of the 24h-condition). This behavior repeats every day and results in resets on senseless daytimes (like 10am or 2pm). In my opinion the reset should be performed ONLY on midnight, because it's a DAY-count!

I discovered this issue on drupal-5, where it depends on the db update runtime. Drupal-7 fixes this problem by using the REQUEST_TIME constant. But no version of drupal initially sets the daytime for the first execution to midnight, which defines the base of all following resets.

My solution is to force a midnight-time-stamp when updating the statistics_day_timestamp variable. This can be done very easily be using php's getdate() and mktime() functions. See attached patch-files...

Please let me know what you guys think about that...

If you want to check the reset time of your drupal install, you can use this mysql statement (should work from drupal 5 to 7, but maybe you have to add table prefixes):

SELECT *, SUBSTR(`value`,3 ,10), FROM_UNIXTIME(SUBSTR(`value`,3 ,10)), NOW(), UNIX_TIMESTAMP()
FROM `variable` WHERE `name` LIKE '%statistics_day_timestamp%'

.

Comments

svenb’s picture

Title: Statistics cron does not reset the daycount properly » Statistics cron does not reset the day-count properly
svenb’s picture

Status: Active » Needs review
svenb’s picture

Priority: Normal » Minor
andypost’s picture

Version: 7.0-alpha2 » 7.x-dev
Priority: Minor » Normal
Status: Needs review » Closed (duplicate)