EDITED!
I can confirm I have had this exact issue. Took me forever to find as I’m new to Grafana (which I just love so far otherwise 
)
From my testing the issue appears to be in the parsing of the variables when generating the SQL to query the DB. And also how returned dates are expected to be encoded (time zone wise) Here’s some debugging recreation info:
Ad the following to any Query on any panel:
/*
DEBUG: FROM = ${__from:date:YYYY-MM-DD HH+mm+ss}
DEBUG: TO = ${__to:date:YYYY-MM-DD HH+mm+ss}
*/
Note: I did not use capital HH for hours and got the US standard 12h time. Took me some time to get past that 
Note2: Since : is not allowed by Grafana luckily + can be used in MariaDB to partition the time part. For some reason I ran into issues if I omit them
Save and use your dashboard.
Select a time interval. for example:
When the panel has reloaded click the title and in the menu select inspect > query
(had to remove image as I’m not allowed more that two images per post 
)
You can now see what the parser has parsed as values for your selected interval. In my case:
/*
DEBUG: FROM = 2022-04-28 00+00+00
DEBUG: TO = 2022-04-28 23+59+59
*/
So far so good (hopefully) you get the correct dates to the parser and you can use them in your query.
Now, when the datetimes are returned in a recordset from the server, the datetimes are, in my case based on the system time zone, i.e. Europe/Stockholm. But it appears Grafana is expecting datetimes to be in UTC time zone and thus “converts” the raw datetimes in the recordset from UTC to [insert your selected time zone here]… I can somehow see this making sense as you would need it to be this way if you have several locations in several time zones looking at the same data. But, since my data is already in the local time format I need to convert the datetime to UTC before returning it to Grafana.
In MariaDB this is done with the CONVERT_TZ() function
https://mariadb.com/kb/en/convert_tz/
On my system I use Europe/Stockholm as default so I can use the SYSTEM time zone for conversion. I set up an example like this:
SELECT
CAST(MIN(time_info) AS VARCHAR(255)) as time_min_char
, CAST(MAX(time_info) AS VARCHAR(255)) as time_max_char
, MIN(time_info) time_min_date
, MAX(time_info) time_max_date
, CONVERT_TZ(MIN(time_info), 'SYSTEM', 'UTC') time_min_date_UTC
, CONVERT_TZ(MAX(time_info), 'SYSTEM', 'UTC') time_max_date_UTC
- The first two rows shows the “raw” returned date from the DB, since it is explicitly cast as a VARCHAR it is not handled as a date by Grafana (apparently).
- The third and forth row shows what happens if we simply return a date right out of the DB. Apparently Grafana “expects” all dates be UTC thus it converts the date to match the selected time zone as if they were UTC datetimes.
- So since we have datetimes in Europe/Stockholm time, we need to convert them in the recordset to UTC before returning them to Grafana using CONVERT_TZ()
That way I get the following results, which I’m good with
System info:
Grafana 8.4.4 as an addon installation to Home Assistant on a raspberryPi 4
- System Time Zone: Europe/Stockholm
MariaDB 10.4.19
- Default Time Zone: SYSTEM
Browser: Chrome (several incl, dev on a Chromebook all the same)
Note: Since the time zone data is not included from the start in MariaDB, you’ll need to populate those tables. If you, like me, are running MariaDB in a Docker container on a Home Assistant Raspberry Pi, here are some instructions since it took me forever to figure out how to do it https://community.home-assistant.io/t/time-zones-in-mariadb-add-on-in-container
