Date for Order Revenue Chart In Admin is off by 1

[hahnzilla]

Description

Pretty sure this stems from the difference of UTC vs whatever is defined in the commerce settings. For instance, if you set the dates to be 9/27 - 10/4 the graph actually shows 9/26 - 10/3. Would expect that chart data's date to match with the timezone in the settings.

Steps to reproduce

1. Go to /admin/commerce/orders
2. Select any date combo
3. Look at dot for the first date and last in the graph.

Additional info

• Craft version: 3.0.25
• PHP version: 7.0.28
• Database driver & version: mysql 5.7.22
• Plugins & versions: Commerce 2.0.0-beta.8

[engram-design]

I can confirm this is an issue, maybe not offset by 1, but it'd likely match the timezone. See the attached screenshot that shows a few orders. The current date/time in Australia AEST is 28/11 8:00AM, and I'm highlighting the 28/11 tick which reports $0. You can clearly see we've captured orders for that date, early in the morning.

Of course, as dates are captured in UTC, the database records them as 2018-11-27 20:39:25, which would point to why there's plenty of orders for the 27/11. Maybe it's not converting to locale time?

[engram-design]

@benjamindavid Hate to be annoying and bump this - but I'm going to 😄

[engram-design]

@lukeholder Still looking for a resolution to this. Is no one else seeing this sort of issue?

[mklishevych]

I have the same issue. I've looked at Craft 2 version, here is the code for the dates range

$startDate = DateTime::createFromString($startDateParam, craft()->timezone);
$endDate = DateTime::createFromString($endDateParam, craft()->timezone);

And here is the code for Craft 3 version

$startDate = DateTimeHelper::toDateTime($startDateParam);
$endDate = DateTimeHelper::toDateTime($endDateParam);

Definition of the DateTimeHelper::toDateTime in Craft 3 looks like this:

public static function toDateTime($value, bool $assumeSystemTimeZone = false, bool $setToSystemTimeZone = true)

I'm pretty sure that the problem is that system timezone is ignored due to $assumeSystemTimeZone = false and UTC is used instead. My store is in NY time zone. So as of March 12 for the end date instead of 2019-03-13 00:00:00 I get 2019-03-12 20:00:00 and obviously that's not an expected result.

[andrewcgregory]

Our clients are seeing this same issue. Looks like it is not off by exactly 1 day, but more like 20 hours in our case (time zone = UTC-4). Tough to explain to clients that they cannot rely on the data from the admin area of the website.

[bfopma]

Our clients have mentioned the same issue. Per @mklishevych above, can we pass the time zone to resolve this? E.g. something like:

$startDate = DateTimeHelper::toDateTime($startDateParam, Craft::$app->timezone);
$endDate = DateTimeHelper::toDateTime($endDateParam, Craft::$app->timezone);

Or are there other reasons why this is in place? It would be great to get a resolution or update on this issue.

@lukeholder

[mediabeastnz]

We're seeing the same issue on our production sites also. Clients seem to use this quite a bit.

[bossanova808]

While you're in there maybe look at the borked currency issue that has been there for ages too...all these should be $s:

[engram-design]

@bossanova808 Possibly related to #792?

[bossanova808]

So Josh fixed my currency issue by telling me to add to config general.php:

        // Set the language to Aussie
        'defaultCpLanguage' => 'en_au',

Then, English (Australia) becomes an option in the preferences for Craft Users. Save this for your account, and like magic those pounds are gone...

Ta Josh!

[engram-design]

@bossanova808 That'll teach you for hijacking the thread 😘

[bfopma]

@lukeholder any update on this issue? Is it more complicated than simply passing the time zone as the second parameter? Thank you.

[lukeholder]

Will look at it first thing tomorrow. Thanks.

[lukeholder]

Thanks everyone for your patience. The date range issue has been fixed on the develop branch, will be in the next release. Working on the #792 next.