Mehrtagesübersicht: Uhrzeit für "Datumswechsel"

[koend]

Moin,

schon längere Zeit wundere ich mich warum flot für das Ziehen einer Datumslinie in den Grafiken 02:00 verwendet und nicht 00:00. (siehe screenshot)
Uhrzeit.jpg

        <diagram width="1850px" height="400px" series="day" period="90" popup="false" previewlabels="true" legend="none" timeformat="%d-%m&lt;br&gt;%H:%M" tooltip="true" timeformatTooltip="%d-%m-%Y %H:%M">
          <label>electricity, meter reading</label>
          <axis unit="kWh"/>
          <rrd datasourceIndex="0" consolidationFunction="AVERAGE">ElectricityInputMeterReading</rrd>
        </diagram>

Habe ein wenig im plugin Code geschaut, konnte aber nichts finden.

Gibt es ein da einen Parameter mit dem man die Uhrzeit für den "Datumwechsel" kontrollieren kann?

Vielen Dank und viele Grüße

[makki]

Nun, die Ursache ist klar: UTC vs. MEST/MESZ (=UTC+2), Lösungsvorschläge sind willkommen. Seinerzeit (ist ewig her) hab ich in JS/jQuery keine Möglichkeit gefunden das abhängig von der TimeZone auf dem Client anzuzeigen (was ja eigentlich da richtige wäre)
Oder man zeigt es immer mit der TZ des Servers an? (was gehen würde, aber genauso verwirrend ist, wenn man sich in einer anderen TZ befindet)

Makki

[koend]

Danke für die Antwort Makki, so etwas befürchtete ich schon.

Werde mich im Sommer mal einen Tag durch Code/Doku wühlen, vielleicht hat flot ja mittlerweile dazu gelernt. Werde dann rapportieren.

Was mich noch wundert: hat bisher niemand anders dieses Problem gehabt?

[koend]

Flot hat mittlerweile dazugelernt: https://github.com/flot/flot/blob/ma...izing-the-axes

Habe mir plugins/diagram/structure_plugin.js vorgenommen und um Zeile 259 den timezone Parameter zugefügt:

        yaxes  : $.extend( true, [], data.content.axes ), // copy to prevent side effects
        xaxes  : [{
          mode       : "time",
          timeformat : data.timeformat,
          timezone   : "browser"
        }], 

Resultat ist wie gewünscht: die Tage werden nun um 0:00 Uhr "umgebrochen", die Messwerte die vorher für z.B. 02:00 angezeigt wurden sind immer noch die für 02:00. Ergo erscheint die einzige Konsequenz die sauberere Anzeige des Diagrams.

Noch Ideen was weiter getestet werden müsste?


Als schneller Fix reicht diese Änderung, aber ein upstream-Parameter für <diagram> à la timeformat wäre wohl sauberer, oder?

[Chris M.]

Muss dazu Flot aktuallisiert werden oder reicht die Version die aktuell schon im Git ist?

Ansonsten kenne ich die Parameter nicht wirklich (generell hab ich beim diagram-Plugin ziemlich wenige Aktien drinnen...), rein vom Code-Schnipsel her könnte ich mir vorstellen, dass es interssant sein könnte eine Timezone per Config festlegen zu können. Und Default sollte am besten der Server sein - wenn ich im fernen Ausland per VPN auf die Visu zu Hause zugreife möchte ich die Diagramme wohl nicht in der lokalen Zeitzone sondern in der des Hauses sehen.

[koend]

Ich habe die Flot aus der aktuellen Git Version genommen, wenn ich richtig geschaut habe 0.8.2. (Hatte gestern das Zip von Git runtergeladen und nichts geändert.)

Urlaubs/Reise-Zugriff hast vollkommen Recht... Heimatzeit ist besser als Browser.

In der structure_plugin.js steht im Beginn ja u.a.

        legendposition    : $e.attr("legendposition") || "ne",
        timeformat        : $e.attr("timeformat") || null,
        timeformatTooltip : $e.attr("timeformatTooltip") || "%d.%m.%Y %H:%M", 

So was ähnliches für timezone wäre praktisch, aber dann nicht auf default "null" (das interpretiert Flot als UTC), sondern eine Config Timezone oder im ersten Ansatz "Europe/Berlin" (JS kann nicht die Zeitzone des Servers rauskriegen, oder?).

[Chris M.]

So was ähnliches für timezone wäre praktisch, aber dann nicht auf default "null" (das interpretiert Flot als UTC), sondern eine Config Timezone oder im ersten Ansatz "Europe/Berlin" (JS kann nicht die Zeitzone des Servers rauskriegen, oder?).

Stimmt, für die Server Zeitzone muss man vermutlich PHP bemühen. Für den ersten Ansatz sollte "Europe/Berlin" als Default und per Attribut übersteuerbar eine ganz gute Lösung sein.