9 replies [Last post]
myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
Was this information Helpful?

The sales per year seems to be off by one month, it's showing all of July's sales under August..

Can anyone provide me with a fix?

Thanks
-Myke

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: Sales Per Year Report Off by 1 Month?

Hmm... I'm not getting this behavior on the Livetest. Could it be a timezone or DST issue? (Also, are you running the latest UC?)

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
Versions used

It's in the latest, Version 1.0.. Drupal 5.8.. All of tje July sales are showing up under August 2008, is there any more info you need to help diagnose this?

Thanks
-Myke

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
Sales Summary vs. Sales Per Year

It seems to have the amounts under the correct month in Sales Summary, but not when you click the Sales Per Year tab..

-Myke

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
And oddly enough..

And oddly enough, when you click the August 2008 month which has totals besides it, no orders show up, but clicking the July 2008 column, the July orders show up.. it's just on the Sales Per Year page I'm seeing this behavior..

-Myke

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
What the cause was..

Turns out, the default time zone in Drupal wasn't set on this site, no idea why that was causing sales to be off by a month for that one report though..

-Myke

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15438
Re: What the cause was..

Aye, that is weird... seems it should've been off uniformly. Honestly, there's some strange code-fu going on in the reports module. Evil I have a hunch the way data is collected and organized needs to be reworked during the D6 development. I am glad you got to the bottom of this issue, though.

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
Ryan wrote:Aye, that is
Ryan wrote:

Aye, that is weird... seems it should've been off uniformly. Honestly, there's some strange code-fu going on in the reports module. Evil I have a hunch the way data is collected and organized needs to be reworked during the D6 development. I am glad you got to the bottom of this issue, though.

The voodoo code from the reports.module file, from the uc_reports_sales_year callback function:

for ($i = 1; $i <= 12; $i++) {
// Calculate the start and end timestamps for the month in local time.
$month_start = gmmktime(0, 0, 0, $i, 1, $year) - $timezone_offset;
$month_end = gmmktime(23, 59, 59, $i + 1, 0, $year) - $timezone_offset;

// Get the sales report for the month.
$month_sales = _uc_reports_get_sales($month_start, 'month');

// Calculate the average order total for the month.
if ($month_sales['total'] != 0) {
$month_average = round($month_sales['income'] / $month_sales['total'], 2);
}
else {
$month_average = 0;
}

// Add the month's row to the report table.
$rows[] = array(
l(gmdate('M Y', $month_start), 'admin/store/orders/search/results/0/0/0/0/0/0/'. $month_start .'/'. $month_end),
$month_sales['total'],
uc_currency_format($month_sales['income']),
uc_currency_format($month_average),
);

// Add the data to the CSV export.
$csv_rows[] = array(
gmdate('M Y', $month_start),
$month_sales['total'],
uc_currency_format($month_sales['income']),
uc_currency_format($month_average),
);
}

===================
I suspect the glitch comes about from these lines:

$month_start = gmmktime(0, 0, 0, $i, 1, $year) - $timezone_offset;
$month_end = gmmktime(23, 59, 59, $i + 1, 0, $year) - $timezone_offset;

the 2nd line seems to reference a day 0 on the next monh (which could be month 13 when the $month_start is in December..) so what does gmmktime do with a 0 day and a 13th month, would be the question here.. =)

Would the 13th month show the first month of the next year..?

Since the time zone not being set DID cause things to display in the next month, is there a better way we can call those functions so things don't jump a whole month if the time zone isn't set? =)

-Myke

myke@drupal.org's picture
Offline
Joined: 04/12/2008
Juice: 189
myke@drupal.org wrote: I
myke@drupal.org wrote:

I suspect the glitch comes about from these lines:

$month_start = gmmktime(0, 0, 0, $i, 1, $year) - $timezone_offset;
$month_end = gmmktime(23, 59, 59, $i + 1, 0, $year) - $timezone_offset;

Would the 13th month show the first month of the next year..?

Just found this while googling the functions, in the php manual:

mktime() is useful for doing date arithmetic and validation, as it will automatically calculate the correct value for out-of-range input. For example, each of the following lines produces the string "Jan-01-1998".

<?php
echo date("M-d-Y", mktime(0, 0, 0, 12, 32, 1997));
echo
date("M-d-Y", mktime(0, 0, 0, 13, 1, 1997));
echo
date("M-d-Y", mktime(0, 0, 0, 1, 1, 1998));
echo
date("M-d-Y", mktime(0, 0, 0, 1, 1, 98));
?>

"The last day of any given month can be expressed as the "0" day of the next month, not the -1 day. Both of the following will produce the string "The last day in Feb 2000 is: 29".

<?php
$lastday
= mktime(0, 0, 0, 3, 0, 2000);
echo
strftime("Last day in Feb 2000 is: %d", $lastday);
$lastday = mktime(0, 0, 0, 4, -31, 2000);
echo
strftime("Last day in Feb 2000 is: %d", $lastday);
?>

According to what I've read, the 0th day of the next month is the last day of the month.. so the could SHOULD be working as far as I can tell.. Any ideas?

-Myke

royerd's picture
Offline
Joined: 01/22/2008
Juice: 293
off by one

I'm seeing my reports off by one. My Month to Date label shows November (and this is December). Below that line it says Daily Average for November and it and should say December.

The sales dates are also off by a number of hours that I have not yet discerned the pattern to.

I'm seeing nearly all the issues reported above. I'm in 5.19. Are you all sure this is fixed? I tried to look in the demo but that site is down.

Dan