CometVisu 2h in der Zukunft

[DonGyros]

Ich habe hier ein Problem mit der Darstellung von Zeitwerten in der CometVisu.
Meine Konstellation sieht folgendermaßen aus:

- Backend = openHAB
- Visu = CometVisu
- CometVisu PHP Plugins laufen auf einem PHP fähig Server (nicht auf dem Jetty von openHAB)

Jetzt ist es so das openHAB bei diversen Events die MySQL Tabelle für das rsslog Plugin befüllt. Wenn man sich dort die Datensätze anschaut dann sind die Uhrzeiten korrekt. Wenn ich direkt die rsslog_mysql.php Datei aufrufe dann erhalte ich auch die korrekten Zeiten. Schau ich mir aber das Ergebnis direkt in der CometVisu an dann ist es hier so das alle Uhrzeiten um 2h vor gehen.

Kann mir das jemand erklären? Kann ich in der CometVisu eventuell irgendwo eine Zeitzone konfigurieren?

Bin für jeglichen Hinweis dankbar!

[makki]

Naja, die Zeitzone ist das Problem wie du ja schon erkannt hast;

Das ist jetzt meine persönliche Meinung: in die DB gehört nunmal nur UTC, daraus hat die Anzeige das richtige zu machen (weil nur die kennt die TZ in der sich der betrachtende AW befindet)
Das passt m.W (ungeprüft!) beim rsslog..

Makki

[DonGyros]

Hmm, die Zeitzone auf dem Server wo openHAB läuft ist korrekt. Systemzeit in der Konsole und auch Zeiten die innerhalb von openHAB ermittelt werden sind korrekt. Lediglich die Zeiten aus der rssslog Tabelle werden falsch innerhalb der CometVisu angezeigt.

[makki]

Stehen sie denn mit UTC in der SQL-Tabelle?
Sonst ists klar..

Makki

[swiss]

Warscheinlich steht in der DB die Zeit als MESZ also UTC + 2 wegen der Sommerzeit. In die DB gehöhrte aber UTC rein und das Backend/der Client sollte dann aus der Angabe die korrekte Zeit berechnen.

[makki]

So wirds sein, jetzt muss man nur noch vermitteln warum (meine Meinung und die in jeglicher Doku) in der DB UTC zu stehen hat, auch wenn openHAB es lustiger findet Datum/ Uhrzeit mit einem Offset ohne Hinweis darauf zu speichern

Makki

Edit: Sorry das war sarkastisch.. Wollte sagen: dann zeigts die CV/rsslog auch richtig an

[DonGyros]

openHAB selbst schreibt keinen Datumswert in die Tabelle. Aus openHAB wird nur ein HTTP Request abgesetzt der die URL zur rsslog_mysql.php Datei aufruft und entsprechend Parameter mitgibt um einen neuen Eintrag generieren zu lassen.

Hab mir mal die PHP angeschaut. Beim INSERT wird da folgendes in die Datenbank geschrieben:

DATE_FORMAT(NOW(), '%Y-%m-%dT%T')

An sich ist doch dann die PHP-Datei aus dem rsslog Plugin der Grund warum hier keine UTC-Zeit in die DB geschrieben wird. Bzw. müsste man die Datenbank so konfigurieren das NOW() eine UTC Zeit liefert.

[DonGyros]

Verwende jetzt im INSERT anstatt NOW() nun UTC_TIMESTAMP().
Dies führt dazu das UTC in die Tabelle geschrieben wird (also MESZ-2).
CometVisu packt dann aber anstatt 2h nun 3h drauf was auch wieder falsch ist.

[derwolff2010]

@DonGyros
Hast du schon hier geschaut?
https://knx-user-forum.de/cometvisu/...mit-mysql.html

So muss die Zeit in der DB stehen damit das rsslog Plugin richtig anzeigt:
2014-06-11T16:33:55+02:00
MySQL kennt dieses Format meines wissen nicht, weshalb dort als Datentyp auch VARCHAR verwendet wird.

Gruß
Carsten

[DonGyros]

@derwolff2010

das war's, danke!
Hätte ich den Thread mal nur bis zum Ende gelesen :-(

[makki]

MySQL kennt sehr wohl auch datetime als Format und genau da liegt dann auch der Fehler: Datum/Uhrzeit als VARCHAR zu speichern ist

Makki

[derwolff2010]

Das rsslog-Plugin benötigt dieses PHP ATOM Date Format, da hängt an der Zeit noch die Zeitezone dran z.B. +02:00 . Dies gibt es in MySQL nicht, zumindest gibt es bei google zig Beiträge wie man dieses Format konvertieren kann.

Ich finde dieses Zeitformat vom Plugin mehr als unglücklich.
Ich persönlich finde auch, dass keinerlei Zeitzonenkonvertierung im Client bei der Anzeige stattfinden sollte. Auf Dienstreisen stört mich immer wenn im rsslog die Ereignisse nach Ortszeit angezeigt werden. Mich interessiert doch was in meinem Haus zu der dort gültigen Zeit passiert ist, oder?

Gruß
Carsten

[Chris M.]

Ich finde dieses Zeitformat vom Plugin mehr als unglücklich.
[...]
Auf Dienstreisen stört mich immer wenn im rsslog die Ereignisse nach Ortszeit angezeigt werden. Mich interessiert doch was in meinem Haus zu der dort gültigen Zeit passiert ist, oder?

Guter Punkt - allerdings ist der zu einseitig
Ich kann mir beides vorstellen - Infos die ich zur Ortszeit des Visu-Servers (= Haus) sehen möchte und andere, die ich in meiner aktuellen Zeitzone sehen möchte.

=> Das Problem ist nicht so sehr das aktuelle Handling der Zeitzone - sondern dass ich keine Wahl habe (und natürlich dass die dann passend umgerechnet wird)

Mein Vorschlag (an wen auch immer, der das gerade umsetzen möchte ):
Ein zusätzlicher Parameter namens timezone mit den möglichen Werten "client", "server" und "UTC" so wie evtl. auch noch Zahlen eines fixen Offsets.
(Sollte es dank einer Bibliothek noch billig und leichtgewichtig hergehen: Ortskürzel wären das I-Tüpfelchen, denn dann könnten alle obskuren Sommerzeit-Regelungen mit berücksichtigt werden...)

[derwolff2010]

Das klingt so gut. Wenn man dann noch der Meldung ein Icon für Info/Warnung/Alarm oder ähnlich mitgeben könnte, wäre es perfekt ;-) .

Gruß
Carsten

[XueSheng]

Da das Thema bzgl. Zeitzone nicht neu ist, kurzer Hinweis auf den existierenden Feature Request:
Open Automation / Feature Requests / #60 implement timezone support