The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.The code below causes the statistics day timestamp to drift by the time it takes to execute the db operation to clear all the daycount fields. A small site will never notice but with 10's of thousands of nodes it becomes noticeable.
if ((time() - $statistics_timestamp) >= 86400) {
// Reset day counts.
db_query('UPDATE {node_counter} SET daycount = 0');
variable_set('statistics_day_timestamp', time());
}
It should say something like
if ((time() - $statistics_timestamp) >= 86400) {
// Reset day counts.
db_query('UPDATE {node_counter} SET daycount = 0');
variable_set('statistics_day_timestamp', $statistics_timestamp+86400);
}
| Comment | File | Size | Author |
|---|---|---|---|
| #31 | 521858-31.patch | 1.14 KB | dimKarp |
| #21 | 521858-21.patch | 1.27 KB | wim leers |
Comments
Comment #1
bryrock commentedThis is actually noticeable on small sites as well. It was after I noticed my daycount stats were reseting in the late afternoon that I started looking into it and found this (http://drupal.org/node/521858).
This is also somewhat beyond "drift." Even if the db operation takes only a second or two, with cron running hourly, the first test (if ((time() - $statistics_timestamp) >= 86400)) generally won't pass until the 25th hour because in the 24th hour it will be just a few seconds shy of 86400, so statistics_day_timestamp gains an hour a day.
Comment #2
jpp commentedHere is the code I'm using now - it's needs to be made timezone aware (the 3600*8 is a hack for pacific time) and I've commented out the log delete because I keep all my logs.
Comment #3
bryrock commentedThanks for this. I'll give it a whirl. I've been going into the db and resetting this manually about every two weeks.
Two questions:
1 - Then Central time zone would be "$t = $t + (3600*6);" ?
2 - What is "$t = $t - ($t % 86400);" doing? (I'm not clear on the "%" operator in this context)
One thing I've been curious about and have not been able to find documented, when and how does statistics_day_timestamp get initialized the very first time? One might assume that daycounts are meant to start over at midnight, local time, but would it not depend on what time of day an instance of Drupal was fired up for the first time?
Comment #4
jpp commentedThe % operator is modulo so $t = $t - ($t % 86400) will give you number of seconds at the last whole multiple of 86400 (IE midnight UTC) then add the fidge for the local timezone to get local midnight.
At the end of it all $t == last midnight in seconds since the unix epoch, then you just need to see if 86400 seconds have elapsed and if so we've hit midnight so do our thing. The other optimization is to set day count only on the records where it's not already zero in sites like mine with 30K+ modes that makes a big difference.
Comment #5
andypostThis issue should be fixed in 7.x first!
Marked as duplicate #733636: Statistics cron does not reset the day-count properly
Comment #6
andypostDay statistics used only at block http://api.drupal.org/api/function/statistics_block_view/7
And because cron are rinning every 3 hours for D7 by default so we should only change setting to variable to take into account a site's time zone.
Comment #7
marcingy commentedMoving to d8
Comment #8
koppie commentedI have tested this code with D6 and seems to work well. Any love for the old-timers?
Comment #9
webchickFixing tags.
Comment #10
andypostThere's a 2 different problems:
1 - statistics reset caused by statistics_cron()
2 - statistics display that does not take into account a site's timezone
Comment #11
andypostThis is functionality bogus at storage and display levels
Comment #12
catchRight that makes it a bug, but I don't think it's major in the slightest. Statistics counts are not anywhere in the critical path, and this only affects accuracy not anything else.
Comment #13
iamEAP commentedIs this actually still an issue now that those instances of time() have been replaced with REQUEST_TIME? This is true even for 7.x.
Comment #14
andypostYes, because cron running is unpredictable
Comment #15
andypostComment #21
wim leersI think something as simple as this is all we need?
Comment #22
andypost@Wim this is only half of problem, because cron run randomly by default, so some drift will exists
Comment #27
ressaFixing title.
Comment #31
dimKarp commentedI'm not sure if it is the right issue to mention that if someone views the node after the day change but before the cron run then the views of the previous day will be transferred to the current day. I used this as a temp solution. I am not very familiar with PHP. What do you guys think? or should I create a new issue for that?
Comment #35
quietone commentedStatistics is approved for removal. See #3266457: [Policy] Deprecate Statistics module in D10 and move to contrib in D11
This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
It will be moved to a contributed Statistics project once the project is created and the Drupal 11 branch is open.
Comment #37
quietone commented