Hola, en mi base de datos uso timestamp buenos aires donde son las 10am y mi base de datos indica 10am, lo cual esta perfectamente bien, ahora levanto los datos con grafana, los genios de los dashboards, y mi dato ahora dice que son los 7am, increible!. OK cambio la base de gafana a UTC+0 lo cual soluciona el problema, lo malo que ahora se rompe el filtro horario propio de grafana, pongo que filtre entre las 0hs del dia de hoy a las 23:59 del dia de hoy y me devuelve datos corridos en -3hs.
Increible que este teniendo este problema, es totalmente basico y al parecer no hay solucion, tengo que convertir mis datos de mi base a UTC+0 para que los levante grafana.
Muy malo todo
Now english
Hi, in my database I use Buenos Aires timestamps — for example, it’s 10am here and the database correctly shows 10am. Perfect. Now, I load the data into Grafana (the “dashboard geniuses”) and suddenly the timestamp shows 7am. Incredible! OK, I change Grafana’s time zone setting to UTC+0, which fixes that issue. But now the built-in Grafana time filter breaks. If I filter for data between 00:00 and 23:59 of today, I get results that are offset by -3 hours.
It’s unbelievable that I’m dealing with this — it’s such a basic issue and apparently there’s no solution. I would have to convert all my timestamps in the database to UTC+0 just so Grafana displays them correctly.
Very poor experience.
Hola, en mi base de datos uso timestamp buenos aires
Hi, in my database I use Buenos Aires timestamps
This is very bad idea, partly for reasons you’ve already discussed, and partly
because:
local time is not unique - you have timestamps in Buenos Aires local time,
but suppose you had to extend your monitoring to include systems which were
located in another timezone? They should not be given Buenos Aires
timestamps, because that’s incorrect, but if you give them local (to those
servers) timestamps, simultaneous entries in the database would not match.
suppose you weren’t based in Argentina, but in Brazil - that has four
different timezones across the country - the only sensible choice for what
timezone to store data from across all four zones in is UTC.
local time gets duplicated for an hour when clocks go back for daylight
saving time, and have an artificial one hour gap when clocks go forward again.
Argentina may not currently change clocks for this reason, but it would be
silly to have one rule for database timestamps in some countries and a
different rule in others.
calculating differences between timestamps on different servers gets over-
complicated
Basically, you should always store timestamps in machine-readable form (eg:
in a database) as UTC, and only convert to “local time” representation when
displaying to humans.
Muy malo todo
Very poor experience.
I agree, but it is definitely not Grafana’s fault.
Now, imagine that you work with users who are in different time zones/countries, and they might have different daylight saving time options, … Their Grafana experience will be terrible when you save data into DB in the local timezone.
Stick with the best practice: data in the DB must be saved in UTC timezone and then the client (e.g. Grafana in your case) is responsible for projecting data in the user time zone (e.g. Grafana uses browser timezone by default = any user can see data in their own timezone)
