On Fri, 29 Mar 2013 22:54:41 +0100 Rainer Gauweiler <volkszaeh...@moppl.inka.de> wrote: > ich glaube dass sowohl der vzlogger als auch die middleware an den > Zeitstempeln falsch drehen. > Vzlogger: > [Mar 29 21:46:44][chn0] Adding reading to queue (value=6545.03 > ts=1364590003.991) > [Mar 29 21:46:44][chn0] ==> number of tuples: 1 > [Mar 29 21:46:44][chn0] compare: 0 1364590003991 1364590003991.138916 > [Mar 29 21:46:44][chn0] JSON request body: [ [ 1364590003991.138916, > 6545.034668 ] ] > Man sieht, der Zeitstempel beim Request ist nicht der gleiche wie zum > Zeitpunkt der Wertmessung. Ich vermute, der Stempel wird neu ermittelt, > wenn der Request zusammengebaut wird - ist das möglich? > Das wäre nicht *sooo* tragisch, aber wird vermutlich ziemliche > Verschiebungen erzeugen, wenn ein Request temporär nicht durch geht. > Middleware: > In der Datenbank steht 1364590003990 als Zeitstempel. Übernimmt hier die > Middleware nicht den Wert aus dem Request, sondern ermittelt ihn neu selbst? > Kann jemand mit Codekenntnissen da bitte mal einen prüfenden Blick an > die entsprechenden Stellen werfen?
sorry, aber das ist jedesmal (fast) genau der gleiche timestamp, nur mit anderer komma-position, und wohl mit leichten abweichungen durch speicherung als float: > 1364590003.991 > 1364590003 991 > 1364590003 991.13891 > 1364590003 991.138916 > 1364590003 990 man konnte vlt. mal durchgehend ausreichend grosse (int/fixed-point?) typen benutzen um's sauberer zu haben, die abweichung um 1ms am ende ist etwas merkwuerdig, aber auch nicht weiter tragisch... > Gruss > Rainer - Thorben
