I’ve searched and searched, and haven’t been able to find a solution to this particular timezone problem. I don’t understand what’s wrong, or how to fix it.
Grafana version is v9.1.5
Here’s the setup:
I’ve got a mysql DB on the same VM grafana is installed on.
The timezone on the VM is GMT-7 (confirmed by running date)
The timezone in mysql is GMT-7 (confirmed by looking at configs and running select NOW())
The timezone in grafana is GMT-7 (confirmed by looking at configs both on the server side and in the browser UI)
The timezone in my browser is GMT-7 (confirmed by some random website that displays time on client side)
The table I’m looking at in the DB has a datetime datatype column (called date), which I’m using for a timeseries graph. My query is as follows:
SELECT
date AS "time",
weather_attribute,
measurement
FROM log_weather
WHERE
$__timeFilter(date)
and weather_attribute in ('Garage Temp', 'Outside Temp', 'Pumphouse Temp', 'Shop Temp')
ORDER BY date
The graph shows up to 7 hours ago, despite the database including values up to now (this is with the time range set to “last 2 days”:
All of time timezones everywhere I can find are configured correctly.
Why are these graphs not displaying the previous 7 hours when the timeFilter is correctly set to “now”?
Is there some timezone setting somewhere I’m missing?
Golden rule: save metrics into DB in the UTC timezone = metric must have saved time in the UTC timezone. (for advanced DB users only: or use timestamp with time zone)
Grafana queries in UTC timezone and then move in the browser to the dashboard timezone (by default browse timezone).
Yes, you can hack your current setup with some workaround, but you will very likely have still a problems: e.g. your collague in different timezone will have different time diff as you, you will have a problem with Daylight saving time, … The easiest solution is to follow mentioned golden rule.
This dashboard is the only thing that uses this DB, and I’m the only user that uses it.
Updating a day’s worth of rows for testing will be adequate, I think.
Hey, uhhh, I just got a chance to look at this, and I am saving metrics in the date column in UTC, so something else is wrong here.
In the table below, the date column is the one I’m using in the query above. The created_date column is mostly used for debugging, as sometimes there is a delay in when the sensor records the value and when it’s sent to the db. created_date is being recorded in the local timezone, date is being recorded in UTC
Also please note the two graphs in the original post. The data is correct in BOTH grahps, but the data being displayed is truncated by 7 hours in the first graph. This is not a matter of the data having the wrong timezone, it’s the dashboard not grabbing all of the data.
If I change that time zone setting to UTC, it shifts the time shown on the graph, but it still doesn’t show the last 7 hours:
Here’s with the timezone set to browser timezone (UTC-7) with the time range set to now+7h
Note that not only is the timestamp correct, but there is 7 hours additional data than the two previous graphs (you can see the difference in the lines)
This is what I expect to see when the time zone is set to browser time, and the date range is set to end at now
That appears to break it worse. Setting a relative time removes everything before that time (in this case, -7 hours, - the configured relative time), but doesn’t add the missing 7 hours.