Date ranges on custom reports is not from the beginning of the month

This 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)

TR 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.

samekind 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 :(

@janton: Are you in GMT+1 (CET?) but also in summer time? In which case, GMT +0200 is correct.

Mmh.. 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!

Subscribe.

@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.

I 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:

01/01/2011 - 01/31/2011
02/01/2011 - 03/03/2011
03/04/2011 - 04/03/2011
04/03/2011 - 05/03/2011
05/03/2011 - 06/03/2011
06/03/2011 - 07/03/2011
07/03/2011 - 08/03/2011
08/03/2011 - 09/03/2011
09/03/2011 - 10/03/2011
10/03/2011 - 11/03/2011
11/03/2011 - 12/03/2011
12/04/2011 - 01/03/2012
01/04/2012 - 02/03/2012
02/04/2012 - 03/03/2012
03/04/2012 - 04/03/2012
04/03/2012 - 05/03/2012
05/03/2012 - 06/03/2012
06/03/2012 - 07/03/2012
07/03/2012 - 08/03/2012
08/03/2012 - 08/31/2012

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:

01/01/2011 - 01/31/2011
02/01/2011 - 02/28/2011
03/01/2011 - 03/31/2011
04/01/2011 - 04/30/2011
05/01/2011 - 05/31/2011
06/01/2011 - 06/30/2011
07/01/2011 - 07/31/2011
08/01/2011 - 08/31/2011
09/01/2011 - 09/30/2011
10/01/2011 - 10/31/2011
11/01/2011 - 11/30/2011
12/01/2011 - 12/31/2011
01/01/2012 - 01/31/2012
02/01/2012 - 02/29/2012
03/01/2012 - 03/31/2012
04/01/2012 - 04/30/2012
05/01/2012 - 05/31/2012
06/01/2012 - 06/30/2012
07/01/2012 - 07/31/2012
08/01/2012 - 08/31/2012

Notes:

• Edge cases not specifically tested, but with TZ set to GMT+1 correct date ranges were produced. Debugging _uc_reports_subreport_intervals() indicated that the timezones did not cause invalid date ranges (this bug)
• Due to normalization, a start day >= 28 will still produce and offset. This is expected, as January 30 + 1 month is in March, February only has 28 days. That said, I don't think many users expected January 27 + 1 month to return a day in March as strtotime() does... It should be February 27.
• Reading on the +1 month bug: http://www.24k.com.sg/blog-60.html

(setting status)

Is there a way of fixing this without using DateTime::createFromFormat()? The DateTime classes are only available in PHP 5.3 and up.

I 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.

Same concern as in #13 applies to Drupal 7.