Preset time-frames broken - shows 'no data points' - date is 5 hours ahead

Grafana v5.3.0-beta1 (commit: e05033a)

The preset time frame (Quick Ranges) is generating an incorrect date in the query, 5 hours into the future.

The timezone on my PC, and MySQL db and Grafana (browser tz) is correct. Yet I must use ‘last 6 hours’ to see any data.

Setting preset to 5 minutes causes ‘no data points’

Evidence:

Data Exists:
data_exists_correct_time

**Setting preset @ 5 minutes - generates the following query **

It’s showing: BETWEEN ‘2018-09-22T04:28:23Z’ AND ‘2018-09-22T04:33:23Z’

Instead of: BETWEEN ‘2018-09-22T021:28:23Z’ AND ‘2018-09-21T23:33:23Z’

Generated Query

sql:“SELECT UNIX_TIMESTAMP(log_datetime) as time_sec, cpu_used_percent as value, ‘Percent Used’ as metric FROM host_information WHERE log_datetime BETWEEN ‘2018-09-22T04:28:23Z’ AND ‘2018-09-22T04:33:23Z’ ORDER BY log_datetime,host ASC”

Anyone run into this before or have any ideas?

Make sure your time is synced across your computer and server. And that your MySQL date field is stored in UTC

Hey @torkel,

Thanks for the prompt reply!

The MySQL server, my PC, and Grafana server are synced.

Fwiw, I use a practically identical setup elsewhere and I don’t have any issues.

Do you think it’s possibly just a bug in the version I’m using? Grafana v5.3.0-beta1 (commit: e05033a) If so, could you provide me some documentation for downgrading?

The date sent over the wire shown in query inspector is in UTC. You cannot compare that to the tooltip date as that is showin in local browser time.

How should or can I remedy this? To me this still appears to be a bug with the latest version. I’m fine with downgrading, I just can’t find the proper documentation on how to do that.

Reasoning:
I’ve confirmed the other setup, which is working properly, is identical to this one; same timezone, data, etc. The only difference is the version of Grafana. I’ve gone as far as adding the same datasource and query to another working properly grafana and the 5 minute now works properly. So why not in the latest version?

I am unable to replicate this, last 5min generates the correct SQL time range filter. Are you sure you convert the UTC time you see to your local time?

The timefilter you see in the query is in UTC and the tooltip you see in the timepicker is local time.

All are running UTC?

Hi, I have the same problem, in the previous versions everything worked fine, but in version 5.3 it does not. maybe I have something wrong configured, but I would like to know how to remedy it and thus be able to use version 5.3.
This is reported in #13205

Could you give us some more information about what version worked before 5.3?

Update: I think you get the following behavior due to the following changes: https://github.com/grafana/grafana/issues/11619

Our intention have never been to support anything else than UTC on Grafana and UTC in database/storing timestamps in actual UTC time in database. Unfortunately this have worked for you unintentionally before. Hopefully we can find a way to manage multiple timezones in dashboard/datasource in the future.

–Before–

Grafana: V5.2.4
Mysql:

  • @@version: 5.7.19
  • @@system_time_zone: UTC
  • @@global.time_zone: America/Bogota
    Dashboards timezone: Default

–After–

Grafana: V5.3.beta1
Mysql:

  • @@version: 5.7.19
  • @@system_time_zone: UTC
  • @@global.time_zone: America/Bogota
    Dashboards timezone: Default

If you can help me make this work, it would be great and I would greatly appreciate it.

If you write your timestamps in your database either using column of datetime with timezone support type, datetime type (value written in UTC) or epoch milliseconds (UTC by design) it should work as expected.

Hola Daniel gran saludo, Estuve mirando algo de este foro y tengo el mismo problemas tengo una atraso de 6h en la visualizacion de GRAFANA * v6.7.3 uso como motor de base de datos SQLSERVER2012

Si me puedes dar unas pautas quedaria completamente agradecido

Gracias

Hola Nicolas,

La verdad es dificil darte una solucion unica, ya que depende de tu caso de uso.
mis recomiendaciones generales son:

  • almacenar todo en UTC.
  • preferir formato Unix/epoch sobre formatos como date.
  • asegurarse que todos los componentes del sistema tienen la tz adecuada.
  • es facil sumar un intervalo de 6 horas para solucionar el problema.

Creo que no soy muy util, pero cualquier cosa que yo pueda ayudarte, lo hare con gusto.

UN saludo.

Hola daniel muy formal despeus de tanto insistir logramos corregir los tiempos sincronizando los timpos todo en UTC

Gracias muy formal