Wrong value in graph with bars

Thanks for answering.
If I change to UTC in this Dashboard, time stamp for Bars will be stamped at 00:00 but for other graphs in same Dashboard will have wrong time stamp.
I checked raw data and data for bars is using data for 02:00 and not 00:00 as I want to use. Even with UTC it is using data from 02:00.
Maybe this snapshot can help. My local time was 13:54 when I created the snapshot. Sweden, summer time right now so UTC +2 otherwise UTC +1.
https://snapshot.raintank.io/dashboard/snapshot/35g2NOUN507NZlu2KZsobxQQ19mNxyKd?orgId=2

Query:
SELECT non_negative_derivative(last("value"), 1d) FROM "Usage" WHERE ("name" = 'Huset_V') AND $timeFilter GROUP BY time($Interval) fill(null)

When you are saving the data, are you saving it in UTC?

Currently Grafana is not very flexible when it comes to time zones and is built on the assumption that everyone saves their data in UTC. It then uses the browser settings to adjust to your timezone. This will be wrong if you are saving it in another timezone.

If this is the case, then you can offset the timezone in your InfluxDB query (think this got added in 1.3):

If this not the problem, can you explain more please.

I guess it must be in UTC, because when I choose UTC it will be 11.00 when my time is 13.00.
But I don’t know if it will send in UTC. I am using Domoticz to send data to InfluxDB.

So in InfluxDB, it is saved in UTC? (That’s the important part - is InfluxDB running on a server with time set to UTC?)

Influx is running on a Debian where I have set time zone to Sweden.
I cannot answer if the data is saved in UTC.
But when I choose “Local browser time” all other graphs are OK except when a graph is set to “GROUP BY time(1d)” then it will have wrong time stamp

The docs say this:

InfluxDB uses a host’s local time in UTC to assign timestamps to data and for coordination purposes.

So I’m not sure if it is saving in Swedish time or UTC time. Both InfluxDB and Grafana expect times to be saved in UTC. If the timestamps are not in UTC, you are going to have to offset the group by time with this advanced group by syntax.

To double check if your data is saved in UTC or not: create a table panel and write a simple select query. Are the values in the Time column UTC or local time? If the dashboard setting is UTC then it should be two hours behind, if the dashboard setting is local browser time then it should be the same as Swedish time.

(you can also use the Query Explorer on the Metrics tab to get the raw epoch values from InfluxDB and convert those to datetime using https://www.epochconverter.com/)

Thanks.

Then it is saved in UTC.
Table view with settings to UTC is two hours behind.

Just a thought but the panels in the dashboard that have the wrong time - do they have a “Min time interval” set (under Options in the top right corner)?

No, it is empty. I tried to put 1d and 1h but it didn’t make any difference still 02:00

You’ll have to help me out a bit here. It sounds strange that one panel is correct and other panels are wrong in the same dashboard. Can you provide more details about the queries and the raw data returned. What is the difference between these panels?

with timezone default, swedish time, summer time right now UTC+2 GMT+2

https://snapshot.raintank.io/dashboard/snapshot/Qay53akB086dDMteycMpzenS0EGk78G1

below is query for bottom graph with bars, showing timestamp 02:00

{
  "xhrStatus": "complete",
  "request": {
    "method": "GET",
    "url": "api/datasources/proxy/2/query",
    "params": {
      "db": "domoticz",
      "q": "SELECT difference(last(\"value\")) FROM \"Usage\" WHERE (\"name\" = 'Huset_V') AND time >= now() - 2d GROUP BY time(1d) fill(null)",
      "epoch": "ms"
    },
    "data": null,
    "precision": "ms"
  },
  "response": {
    "results": [
      {
        "statement_id": 0,
        "series": [
          {
            "name": "Usage",
            "columns": [
              "time",
              "difference"
            ],
            "values": [
              [
                1508803200000,
                58400
              ],
              [
                1508889600000,
                44640
              ],
              [
                1508976000000,
                30400
              ]
            ]
          }
        ]
      }
    ]
  }
}

with timezone UTC

https://snapshot.raintank.io/dashboard/snapshot/pvS4QU3sBkZakuEHnj2TAOXUcvkmFDxq

below is query for bottom graph with bars, showing timestamp 00:00 but look at top graph, now top graph is getting time stamp -2 hours from swedish time

{
  "xhrStatus": "complete",
  "request": {
    "method": "GET",
    "url": "api/datasources/proxy/2/query",
    "params": {
      "db": "domoticz",
      "q": "SELECT difference(last(\"value\")) FROM \"Usage\" WHERE (\"name\" = 'Huset_V') AND time >= now() - 2d GROUP BY time(1d) fill(null)",
      "epoch": "ms"
    },
    "data": null,
    "precision": "ms"
  },
  "response": {
    "results": [
      {
        "statement_id": 0,
        "series": [
          {
            "name": "Usage",
            "columns": [
              "time",
              "difference"
            ],
            "values": [
              [
                1508803200000,
                58400
              ],
              [
                1508889600000,
                44640
              ],
              [
                1508976000000,
                30992
              ]
            ]
          }
        ]
      }
    ]
  }
}

Not sure I see the problem? UTC is Swedish time - 2 hours so looks right to me?

Is the problem that you only want to change the timezone for one panel?

P.S. Great examples with the snapshots - much easier to understand than text.

Thanks.

Problem is that I want to use Swedish time for all dashboards and “bar-graph” should be timestamp 00:00, so Yes, only want to change to UTC for bar-graph(bottom graph).
I think this must be a bug when using bars and group-by time=1d or 24h.

I don’t understand why this is a bug. Looks to me like it works as intended.

There are timeshifting options if you want to change the time for one dashboard: http://docs.grafana.org/reference/timerange/#panel-time-overrides-timeshift

for me a 24h time stamp should start at 00:00 and not 01:00.
I tried with those settings and it doesn’t change the time stamp.

I’m struggling with the same issue.

Here’s an image to help explain it.
My line graphs are perfect. They are displaying the correct dates and times as they should be.

The problem is with the 24-hour bar graphs. They are offset by the amount of my timezone, which is +10 hours. As per what @flopp said, I would like these to start at 00:00 for the day. This would make it much easier to read. As it is, unless I hover over the top, it’s not apparent which bar is for which day.

I have my Dashboard timezone set to Local Browser, which, as mentioned earlier is correctly displaying for the line graphs.
The issue with the 24-hour bar graph looks like a bug.

Upon closer inspection, I wonder if it is the widths/spacings of the bars which is the problem?

Here are a few examples of different group intervals.

1 minute

2 hours

3 hours

And 6 hours

In the first two images (time intervals) they are spaced so that the beginning of the next day is right on 00:00.
But after that in the next two images, the spacings get weird and don’t display the correct intent.

If you hover over the first bar, what timestamp does the tooltip show?

Hi All,

I am having the same problem with a query grouping by 1 day.

I have attached a screenshot below which shows at the top the value I am trying to display (I am trying to select the maximum value that occurs on any one day).

The second row shows a query on the same data where the maximum grouped by 1d is selected.

What I was expecting is that the 1d grouping would start at 00:00, however as you can see by the tooltop it starts at 11:00.

I dont think its a coincidence that my timezone is GMT+11.

What this leads me to believe is that the grouping of 1d (or 24h) incorrectly starts (groups) from GMT 00:00 rather than the local timezone 00:00.

This all looks to be consistent with what @chadsmith has observed.

Is there a way to force the query when to start the grouping?