|
|
||||||
|
|
|||
|
|||
|
I couldn't reproduce this here. Is it a big forum that has the problem, or quite small?
Oh, I did just realize something though -- is MySQL on a separate server? If so, what is the time zone on the MySQL server vs the web server? |
|
|
|||
|
|||
|
I have this issue on both my main forum, which is big, and test forum, which is small.
In both cases mysql is local (ie on the same server). |
|
|
|||
|
|||
|
A different timezone is what I think would cause this. Can you run this query from the ACP or phpMyAdmin? (Rather than the command line -- there are options that might change the value there.)
Code:
SELECT @@global.time_zone, @@session.time_zone; I'm also curious what your system time zone actually is. |
|
|
|||
|
|||
|
Both display as SYSTEM.
Server TZ information ; [root@server3 ~]# zdump -v /etc/localtime | grep 2009 /etc/localtime Sun Mar 29 00:59:59 2009 UTC = Sun Mar 29 00:59:59 2009 GMT isdst=0 gmtoff=0 /etc/localtime Sun Mar 29 01:00:00 2009 UTC = Sun Mar 29 02:00:00 2009 BST isdst=1 gmtoff=3600 /etc/localtime Sun Oct 25 00:59:59 2009 UTC = Sun Oct 25 01:59:59 2009 BST isdst=1 gmtoff=3600 /etc/localtime Sun Oct 25 01:00:00 2009 UTC = Sun Oct 25 01:00:00 2009 GMT isdst=0 gmtoff=0 In otherwords, currently BST. |
|
|
|||
|
|||
|
What months are duplicated/skipped? I'm wondering if there's something with DST going on there.
Do you think you can post the raw output from the stats query that's being run? (It's line 170 of admincp/stats.php.) |
|
|
|||
|
|||
|
Ok, I ran the stats on my test forum (3.8.2)
(For April 04 2008 to April 23 2009) For the Daily option ; Code:
April 04, 2008 1 April 17, 2008 3 April 18, 2008 1 April 19, 2008 2 April 20, 2008 1 May 04, 2008 1 May 05, 2008 1 May 09, 2008 4 June 24, 2008 357 June 25, 2008 202 June 26, 2008 158 June 27, 2008 120 June 28, 2008 27 June 29, 2008 17 June 30, 2008 1 July 01, 2008 1 July 07, 2008 3 August 23, 2008 78 August 24, 2008 88 August 25, 2008 44 October 01, 2008 17 October 02, 2008 2 October 04, 2008 1 October 06, 2008 3 October 19, 2008 11 January 09, 2009 4 January 10, 2009 1 January 30, 2009 1 February 14, 2009 1 February 17, 2009 2 February 19, 2009 1 March 15, 2009 22 March 16, 2009 1 March 17, 2009 8 March 18, 2009 2 Monthly I get ; Code:
April 2008 8 May 2008 6 July 2008 883 August 2008 3 September 2008 210 October 2008 17 October 2008 17 January 2009 6 February 2009 4 April 2009 33 In the actual Database ; dateline nuser nthread npost ausers Code:
1207263600 0 0 1 5 1208386800 0 0 3 2 1208473200 0 1 1 2 1208559600 0 1 2 6 1208646000 0 1 1 7 1209855600 0 0 1 2 1209942000 0 0 1 2 1210287600 0 1 4 3 1214262000 10 90 357 28 1214348400 1 33 202 24 1214434800 3 24 158 23 1214521200 0 17 120 21 1214607600 0 1 27 12 1214694000 0 1 17 12 1214780400 1 1 1 10 1214866800 0 0 1 7 1215385200 1 1 3 18 1219446000 13 2 78 37 1219532400 7 4 88 45 1219618800 0 0 44 26 1222815600 1 5 17 9 1222902000 0 1 2 2 1223074800 0 1 1 3 1223247600 1 2 3 3 1224370800 1 2 11 15 1231459200 0 2 4 4 1231545600 0 0 1 1 1233273600 0 1 1 2 1234569600 0 0 1 1 1234828800 0 0 2 2 1235001600 0 0 1 2 1237075200 0 1 22 10 1237161600 0 0 1 1 1237248000 1 0 8 7 |
|
|
|||
|
|||
|
I also just noticed that there is no data in the monthly list for June 2008 - it all seems to have been lumped into July - making that total completely wrong.
August/September also look totally mucked up (there is no September data in the daily list). |
|
|
|||
|
|||
|
When I pop those records into a test script and run some queries on them, I get:
April 2008 - 8
May 2008 - 6 June 2008 - 882 July 2008 - 4 August 2008 - 210 October 2008 - 34 January 2009 - 6 February 2009 - 4 March 2009 - 31 Some of the numbers seem to be messed up by stats that were generated on the 1st of the month (the 2 Octobers are 17 from oct 1st and 17 from the rest), but I have no idea why various other entire months are off by one (all of June). I don't know how to debug this now short of getting access to the server to run some code on it. Is that possible? |
|
|
|||
|
|||
|
Drop me a PM with what access you need exactly and I'll arange it.
|
|
|
|||
|
|||
|
Right, this appears to be a time zone issue. The server is switching between GMT and BST, and the stats all sit on the midnight line so they get affected by this. More importantly, PHP and MySQL were doing slightly different things -- perhaps because PHP has a more up to date time zone file.
To workaround this, I changed the "MAX(dateline) AS dateline" to "AVG(dateline) AS dateline". This pulls a value from the middle of a group and will be more resilient. |
|
|
|||
|
|||
|
Just after reading this I tested on my own forum:
Code:
October 2008 4182 November 2008 4244 December 2008 3783 January 2009 5696 February 2009 6217 March 2009 4947 May 2009 3970 May 2009 1301 |
|