Verständnisproblem Profil ~UnixTimestampTime, oder Bug?

IP-Symcon Skripte, PHP, SQL (Fragen)
1

Hallo
Bis dato hatte ich Datums und Uhrzeiteingfaben im WF immer über mehr oder weniger umständliche Kombinationen aus Stringvariabeln gebaut.

Jetzt wollte ich mal das ~UnixTimestampTime Profil probieren.
Wenn ich eine Variable mit dem Profil versehe, so krieg ich im WF auch brav das entsprechende Control.

Der an ein Script rückgelieferte Wert ist aber um 82800 Sekunden zu hoch.
Bsp:
Ich stelle im WF 00:00:00 ein, es wird als Integer aber 82800 rückgeliefert.
Ich stelle Im WF 01:00:00 ein, so wird 86400 rückgeliefert.

Wie kommt das ?
Testcase:
image

date_default_timezone_set(‚Europe/Berlin‘);
IPS_LogMessage(„WF Eingabe“,$_IPS[‚VALUE‘] );
$test = date(„d.m.Y - H:i“, $_IPS[‚VALUE‘]);
IPS_LogMessage(„Unix Time“, $test);

image
image1135×67 4.33 KB

2

Hi,
vielleicht wird Sommerzeit nicht berücksichtigt.

Ralf

3

Da es sich um eine Uhrzeit handelt würd ich mir für 00:00:00 entweder „0“ oder wegen Sommerzeit „3600“ oder meinetwegen „-3600“ erwarten aber nicht 82800.

bb

4

Das sind Unix Timestamps. Die Werte passen, was dein Test mit Konvertierung auf date ja auch bestätigt, oder verstehe ich deinen Testfall falsch?

5

Hmm. Irgendwie steh ich am Schlauch.

Ich habe 00:00:00 eingestellt. Das sollte als Integer doch „0“ sein.
Also dem UnixTimestamp 01.01.1970 00:00:00 entsprechen.

IPS gibt mir aber nicht „0“ sondern „82800“ welches dem 02.01.1970 00:00:00 entspricht.

Edit: Nochmal nachgedacht hab ich vielleicht die Antwort. Der Unix Timestamp ist uINT, kann also nicht negativ werden. Der Versatz um einen Tag ist notwendig um 00:00:00 in den östlichen Zeitzonen abbilden zu können.

bb

6

Ganz genau, 0 wäre 0:00:00 Uhr UTC. Die 82800 sind die Anpassung auf 0:00 Uhr für deine Zeitzone.

7

Das verstehe ich aber auch nicht. Weil bei UTC>=1 wäre man mit 82800 schon am nächsten Tag was bei uns ja nicht stimmt.

8

Das stimmt, es ist 00:00 Uhr am 2.1.1970. Der Tag welcher beim ~UnixTimestampTime verwendet wird ist nicht fest der 1.1.1970, das kann beliebig sein.

9

Das würde mich sehr wundern :astonished: .

The Unix epoch is 00:00:00 [UTC] on 1 January 1970.

Wenn es nicht fest definiert wäre, dann kann es nicht über alle Systeme und Zeitzonen hinweg funktionieren.

10

Ich vermute die Aussage von Dr.Niels bezieht sich auf die Implementierung in IPS für ~UnixTimestampTime, wenn keine Datumskomponente, sondern nur die Zeit enthalten ist?!

11

Ich vermute, in ~UnixTimestampTime ist ausschließlich die Uhrzeit enthalten, wobei das Datum vollständig egal ist. In ~UnixTimestampDate ist nur das Datum enthalten und die Zeit ist egal. Und wer beides möchte, nutzt ~UnixTimestamp.

Ich aber nur eine schnell geschriebene Vermutung, ohne es zu testen. Ich interpretiere die Aussagen von @Dr.Niels dahingehend.

12

Klar, das geht ja schon aus dem Namen und der Doku hervor.
Die Ausgangsfrage war doch warum IPS für 00:00:00 ein „82800“ als Integer zurückliefert. es wäre doch eher „0“ oder wegen Sommerzeit ein „3600“ zu erwarten.

Vermutung: sonst würde es beim Wechsel eine östliche Zeitzone einen negativen Wert geben, und denn will man wohl wegen INT vs. uINT vermeiden.

gruß
bb

13

Das hat @DerStandart genau richtig interpretiert :slight_smile:

0 wäre in den meisten Zeitzonen aber einfach nicht 00:00 Uhr und damit falsch. In meiner deutschen Zeitzone wäre der UnixTimestamp 0 beispielsweise 1:00 Uhr am 1.1.1970. Somit ist es also 82800, was in meiner Zeitzone 00:00 Uhr am 2.1.1970 ist. Da die Tageskomponente wie gesagt irrelevant ist, passt das auch. Ich vermute implementationsseitig wird der erste nicht negative Timestamp gewählt. Ich würde euch eigentlich empfehlen, die genauen Zahlen hier zu ignorieren und einfach mit tollen PHP-Befehlen wie date die für euch relevanten Zahlen da rauszuholen.

1 „Gefällt mir“