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:
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.
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?
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:
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.
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.
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.
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.
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.