UnixTimestampDate und Sommerzeit

Moin Moin,

bin nun durch alle Höhen und Tiefen der PHP-Zeitberechnung gegangen, dachte es verstanden zu haben aber nun dies:

Eigentlich will ich nur im Frontend zwei Daten einstellen, Urlaub von, Urlaub bis, über welche eine Variable gesetzt wird
Urlaub (True/false). Dies macht ein Script zum Tageswechsel oder bei einer Veränderung der Daten. Alles gut, aber wir haben ja Sommerzeit…

Aufgefallen ist mir das Problem, als heute das Urlaubsflag nicht zurückgesetzt wurde:
Die Variable ist als UnixTimestampDate angelegt, zeigt aber das Datum + 1 Stunde an. Eine zweite Variable an einer
anderen Stelle im Objektbaum verhält sich meiner Erwartung nach richtig. Beide Vars sind via Web-Frontend auf 03.08.2019 eingestellt:

date_default_timezone_set('Europe/Berlin');

$von2 = GetValue(46071);
$von3 = GetValue(18121);

print "von2 ".$von2."--".date('Y-m-d H:i:s',$von2)."
";
print "von3 ".$von3."--".date('Y-m-d H:i:s',$von3)."
";
var_dump(IPS_GetVariable(46071));
var_dump(IPS_GetVariable(18121));
von2 1564786800--2019-08-03 01:00:00
von3 1564783200--2019-08-03 00:00:00
array(10) {
  ["VariableID"]=>
  int(46071)
  ["VariableProfile"]=>
  string(0) ""
  ["VariableAction"]=>
  int(0)
  ["VariableCustomProfile"]=>
  string(18) "~UnixTimestampDate"
  ["VariableCustomAction"]=>
  int(40623)
  ["VariableUpdated"]=>
  int(1564912144)
  ["VariableChanged"]=>
  int(1564912144)
  ["VariableType"]=>
  int(1)
  ["VariableValue"]=>
  int(1564786800)
  ["VariableIsLocked"]=>
  bool(false)
}
array(10) {
  ["VariableID"]=>
  int(18121)
  ["VariableProfile"]=>
  string(0) ""
  ["VariableAction"]=>
  int(0)
  ["VariableCustomProfile"]=>
  string(18) "~UnixTimestampDate"
  ["VariableCustomAction"]=>
  int(40623)
  ["VariableUpdated"]=>
  int(1564913861)
  ["VariableChanged"]=>
  int(1564913861)
  ["VariableType"]=>
  int(1)
  ["VariableValue"]=>
  int(1564783200)
  ["VariableIsLocked"]=>
  bool(false)
}

Das Script 40623 weist nur den via Web-Frontend eingestellten Wert zu.

<?php
//Script zum WERTEZUWEISEN aus dem Webfrontend 

if($_IPS["SENDER"] == "WebFront") 
{ 
    SetValue($_IPS["VARIABLE"], $_IPS["VALUE"]); 
} 

?>

Warum wird in der Variable mit dem Profil UnixTimestampDate einmal das Datum mit der Uhrzeit um 0:00 und in der anderen Variablen um 1:00 abgespeichert. Ich finde in der Variablen Konfiguration keinen Unterschied, außer, dass sich beide Vars in unterschiedlichen Zweigen des Objektbaums befinden.

Vielleicht kann jemand Licht min mein Dunkel bringen.

Danke

Detlev.

Hallo,

die Variablenwerte liegen 3600 (Sekunden) auseinander
Das ist kein Dastellungsproblem, sondern es geht beim Variablen setzen schief.

In einem Unix-Timestamp steht ja immer der Wert gemäß UTC / GMT drin und wird bei der Ausgabe in due lokale Zeitzone umgerechnet. Wäre also +1h Winter- und +2h Sommerzeit.

was mich etwas irritiert ist das:


date_default_timezone_set('Europe/Berlin'); 

Das ist überflüssig. Als Zeitzone wird ja die vom System verwendet. was steht da drin?

Wie setzt Du die Werte der Variablen?

Grus
demel

Hi,

die Zeitzone habe ich nur gesetzt um sicher zu gehen, dass es auch tatsächlich Europa/Berlin ist, Du hast recht, das Setzen der Zeitzone
ist in diesem Fall tatsächlich überflüssig:

$tz=date_default_timezone_get();
print "Timezone: $tz
";
date_default_timezone_set('Europe/Berlin');
$von2 = GetValue(46071);
$von3 = GetValue(18121);

print "von2 ".$von2."--".date('Y-m-d H:i:s',$von2)."
";
print "von3 ".$von3."--".date('Y-m-d H:i:s',$von3)."
";

liefert

Timezone: Europe/Berlin
von2 1564873200--2019-08-04 01:00:00
von3 1564869600--2019-08-04 00:00:00

Im Log finde ich die Werte bestätigt.

04.08.2019 17:36:13 | 18121 | MESSAGE | VariableManager      | [Server\utc-time] = 1564869600
04.08.2019 17:42:21 | 46071 | MESSAGE | VariableManager      | [Kalender\Urlaub von2] = 1564873200

Ich frage mich, wieso das Setzen des Wertes über das Web-Frontend einmal zum einem korrekten Wert bezogen auf meine Zeitzone kommt, und einmal nicht.
Ich vermute, dass bei Variable 46071 der Wert ohne Sommerzeitkorrektur abgespeichert wird und bei Variable 18121 die Sommerzeit berücksichtigt wird.
An der Kategorie im Objektbaum kann ich keine Konfigurationen vornehmen, oder?

Ich habe in der Kategorie, in welcher auch 46071 liegt eine weitere Variable mit UnixTimestampDate, diese verhält sich identisch zur 46071.

Bin etwas ratlos.

Hallo,
ich bin mir nicht sicher, aber würde vermuten, das der Webfront als Zeitzone die des PC’s (bzw. Endgerätes nimmt) … und wenn da was nicht stimmt?

Versuch:

setze mal über den Webfront eine solche Timestam-Variable und vergleich den Wert mal mit der akt. UTZ-Zeit. Den Integriert bekommst du ja, wenn du


echo time();

ausführst. Sollte also zwischen der Zeit, dir durch den Webfront gesetzt wurde und dem o.g Kommando mehr als ein paar Sekunden Differenz besteht, liegt es da im Argen.

demel

Ne,

das ist es nicht. Habe in beiden Kategorien eine Script eingebunden

$var =  time();

print "$var: ".date('Y-m-d H:i:s',$var)."
";

die zeigen beim Ausführen im Web-Frontend beide die korrekte Zeit an.
Ich glaube auch nicht, das es an der Zeitzone des Endgerätes liegt, dann würden sich ja beide Variablen identisch verhalten, was sie definitiv nicht machen. Ich glaube hier müssen die Jungs von Symcon mal einen Blick drauf werfen.

Gruß Detlev.

Moin,

hat jemand noch eine Idee wo das Problem liegen könnte?

Grüße Detlev.

Was passiert denn, wenn du die Variablen erneut per WebFront setzt? Würde sich dann die Ausgabe in eine der beiden „Richtungen“ anpassen?

paresy

Der Effekt beleibt der gleiche, eingestelltes Datum + 1 Std. in der Kategorie „Kalender“


in der Kategorie „Server“ ist alles ok

$von1 = GetValue(32156);
$von2 = GetValue(46071);
$von3 = GetValue(18121);
print "von ".$von1."--".date('Y-m-d H:i:s',$von1)."
";
print "von2 ".$von2."--".date('Y-m-d H:i:s',$von2)."
";
print "von3 ".$von3."--".date('Y-m-d H:i:s',$von3)."
";
von 1564873200--2019-08-04 01:00:00
von2 1562540400--2019-07-08 01:00:00
von3 1567548000--2019-09-04 00:00:00

Gruß Detlev

Ich habe mir das Problem jetzt näher angeschaut. An dieser Stelle ist es das gewollte verhalten, denn wir „fassen“ die Uhrzeit beim UnixTimestampDate Profil nicht an. Genauso wie wir das Datum beim UnixTimestampTime Profil nicht anfassen.

Die 1:00 kommt durch unsere Zeitverschiebung zu GMT und dem Startwert 0 einer Variable zustande die exakt 1.1.1970 01:00 bedeutet. Da wir die Uhrzeit nicht anfassen, schleifen wir diese Zeit einfach immer mit.

Da du ja nur das Datum willst, sollte es für deine Berechnung jedoch unerheblich sein bzw. musst du sicherstellen, dass du auch nur die Datumskomponente vergleichst.

paresy

Aber warum verhalten sich die Variablen in den zwei Kategorien Kalender und Server unterschiedlich?
Die müssten doch dann das gleiche Verhalten zeigen.

Ich vermute eher einen Zusammenhang mit der Sommerzeit, denn ich habe diese Funktion vor ein paar Monaten eingebaut und getestet, da hatten wir noch keine Sommerzeit.

Grüße Detlev.

Mit der Sommer-/Winterzeit müsste eher 2:00 daraus werden. Wir haben ja immer +1 und im Sommer +2

paresy