Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Attached is a screenshot with the problem.
The date ranges start off from the 30th to the 30th, and then move to being from the 2nd to the 2nd.
They should be, and used to be, from the first to last day of each month.
Is there a setting somewhere that might be messed up? This wasn't broken until I upgraded from 2.4 to 2.7
Comment | File | Size | Author |
---|---|---|---|
#10 | ubercart-uc_reports-fix-date-ranges-1373910-10.patch | 579 bytes | stewart.adam |
ubercart-report-problem.png | 60.14 KB | msumme |
Comments
Comment #1
longwaveThis was changed in #740296: Sales & Product Reports - big problem with dates causing incorrect & inaccurate data because the timezone handling code was confirmed to be broken in 2.4.
What does it say at the top of the page regarding timezones, and what timezone are you in? (You need the "help" module enabled to see this information)
Comment #2
msumme CreditAttribution: msumme commented"All sales reports are GMT -0600 (Default site timezone)"
The site is in Central Time.
Any suggestions?
Comment #3
TR CreditAttribution: TR commentedComment #4
stockliasteroid CreditAttribution: stockliasteroid commentedTR indicated I should move my comments here, I originally had them on #740296: Sales & Product Reports - big problem with dates causing incorrect & inaccurate data.
I had a client on 2.7 tell me that there was a duplicated day in their reports. It turned out that it was caused by Daylight Savings, and that the custom sales report was outputting two subsequent days as the same day in the custom sales report, as well as when building the intervals it's adding a full extra day to the end. So if I ask for 3/10/2012 - 3/12/2012 with a daily breakdown it's returning reports for the 10th, the 11th, the 12th, and the 13th.
One thing I noticed is that in uc_reports_sales_custom_form_submit the start and end dates are being offset based on the site time zone, but then they are getting offset again when output:
$date = format_date($subreport['start'], 'custom', $format .' - D', $timezone);
When I zeroed the $timezone value: format_date($subreport['start'], 'custom', $format .' - D', 0), the dates output as expected. However, _uc_reports_subreport_intervals is still returning one greater interval (one extra day) than it should, so even though my range ended on the 12th it still shows sales for the 13th. This seems to be because _uc_reports_subreport_intervals is generating one extra interval when the range provided straddles daylight savings.
Comment #5
janton CreditAttribution: janton commentedsamekind of issue Sales Summery is saying: "GMT +0200" when my site is +1 and also my php.ini is +1
I'm afraid my sales summery report is now also incorrect and so my thought about my business grow :(
Comment #6
longwave@janton: Are you in GMT+1 (CET?) but also in summer time? In which case, GMT +0200 is correct.
Comment #7
janton CreditAttribution: janton commentedMmh.. yes I'm (Amsterdam Time). I never knew this! Lucky me.. i was afraid my sales reports had doubles in it..
Sorry for the misunderstanding, very confusing... but I woudn't make this mistake anymore!
Comment #8
rakun CreditAttribution: rakun commentedSubscribe.
Comment #9
longwave@rakun: Please don't just "Subscribe" without telling us more info. Screenshots, details of your site timezone, actual timezone, whether you are in DST, etc. will help us debug this.
Comment #10
stewart.adam CreditAttribution: stewart.adam commentedI ran into a similar bug, but I believe them to be related. The issue I was having was that the reported date intervals were incorrect; a monthly report starting from the first of the month would work correctly up until February. Below is an example of the date ranges returned from a monthly report between Jan. 1 2011 and last month:
February's breakdown includes the first few days of March and the offset is carried through for the rest of the report. The call to strtotime() in _uc_reports_end_interval() seems to have issues with +1 month in February, particularly on leap years. Attached patch changes strtotime() to DateTime::modify() which resolves this problem and returns the expected results:
Notes:
Comment #11
stewart.adam CreditAttribution: stewart.adam commented(setting status)
Comment #13
longwaveIs there a way of fixing this without using DateTime::createFromFormat()? The DateTime classes are only available in PHP 5.3 and up.
Comment #14
stewart.adam CreditAttribution: stewart.adam commentedI don't know of any, most of the alternatives suggested use strtotime() & family but those are the ones with the Feburary bug that caused this in the first place though. I may get back to this eventually, but at the moment I can't devote the time required to backport this to 5.2.
Comment #15
TR CreditAttribution: TR commentedSame concern as in #13 applies to Drupal 7.