In jedem Fall ist’s so, daß influxdb seinen eigenen Zeitstempel in UTC beim Speichern der message vergibt. @Andreas, wie war das: - außer, es kommt in der Nachricht explizit ein ts mit, dann wird dieser ‘bevorzugt’ ? (letzteres wäre mal wieder zu überprüfen, ich weiß gerade nicht, ob das noch jemand hier macht und ob es aktuell funktioniert). Insofern also Entwarnung, es klappt in jedem Fall: es geht mindestens durch daylight saving time-Mist nichts extra verloren.
Nein, wir haben zwei Stunden lang ‘einfache Werte’ - insofern fehlen auch keine im Frühjahr, da es influxdb als time series database egal ist, wie wir die Marken am Zeitstrahl benennen
(hier exemplarisch @mois Beute am 29.10.17) :
Und hier das ganze, wenn man dieses dashboard auf UTC umstellt (was grafana oben rechts im Zeitbereich auch vermerkt) :
In den time options bei Grafana (pro dashboard und organization) lassen sich bislang nur default , local browser time und UTC auswählen, das ist nicht viel - aber mit UTC und browser time ist alles dabei, was man braucht. Ganz generell kennst Du meine Meinung: die Datenbank selbst schreibt mit UTC timestamps, und die lokale Zeitzone (und damit auch DST-Aspekte) wird erst bei der Anzeige/Ausgabe hereingebracht - ganz so, wie es jetzt schon ist! :)
Man kann zwar im query eine tz übergeben und merkt, wenn man sich dabei verschreibt, daß das geparsed und als tz erkannt wird - aber es bleibt ohne Wirkung:
SELECT ... WHERE $timeFilter GROUP BY time($__interval) tz('Europe/Berlin')
Insgesamt wünschen sich viele die komplette Einbindung der Zeitzonen in Grafana, da sind sie für ElasticSearch als backend etwas weiter, man findet etliche feature requests dazu, den hier z.B.. Mit UTC kann ich gut leben: die db speichert ohnehin ‘nur’ in UTC, und bei der Anzeige ist die lokale Zeit eine Modalität der client-Seite ;) , durch EInstellung auf meine local time des browsers die ‘richtige Zeit’ im Grafana anzuzeigen.
Und wenn Du mit Grafana (nicht Export per kotori-API ) unter ‘more’ im Titel eines Panel einen csv-dump machst, dann wird auch in jedem Fall die Zeitzone als offset zu UTC angegeben (das ist beim export das Z
des time format am Ende) :
2018-03-25T01:59:50+01:00;
2018-03-25T03:00:00+02:00;
und im Herbst entsprechend
2017-10-29T02:59:55+02:00;
2017-10-29T02:00:00+01:00;
Da passen dann auch Zeitzonen mit Teilen von ganzen Stunden, sowas wie z.B. Kabul mit UTC+04:30 …
Für das backend und Visualisierung bin ich zufrieden mit dem Zeitzonen-betreffenden Zustand, ein einzelner node ohne RTC ist damit hinreichend versorgt. Die RTC muß nicht präzise wie eine DS3231 sein, wenn sie nur zum Aufwecken des Prozessors zu dienen braucht und die Daten nach Erhebung gleich verschickt werden (können). In anderen Fällen (keine Verbindung/kein upload möglich … oder auch ein lokales gateway für kleine nodes ohne WWAN), bei denen kein zeitlich vertretbarer Abstand zwischen Erheben und Versenden möglich ist, muß mit lokalem Zeitstempel am gate oder node gespeichert werden … anderes Thema ;)
Achja, und die in Deinem Browser eingestellten Sprachen entscheiden darüber, wann im panel die Woche losgeht bei Zeiträumen z.B. von “this week so far” , siehe bei uns: Grafana: Woche von Montag bis Sonntag?