Zeitroutinen in fhem.pl

[Rudolf Koenig]

Da ich gerade die Zeitroutinen in fhem.pl angeschaut habe, Fragen an
Boris:

- Warum wollen wir fhemTimeGm verwenden und nicht mktime (wie in
99_Utils/time_str2num) ?

- fhemTimeLocal kann nicht richtig sein, oder ich verstehe die Welt
nicht :)

- wozu braucht man fhemTimeLocal?

[Dr. Boris Neubert]

Am 02.07.2012 12:19, schrieb Rudolf Koenig:
> Da ich gerade die Zeitroutinen in fhem.pl angeschaut habe, Fragen an
> Boris:
>
> - Warum wollen wir fhemTimeGm verwenden und nicht mktime (wie in
> 99_Utils/time_str2num) ?

Ich wollte keine Abhängigkeit zu POSIX.

>
> - fhemTimeLocal kann nicht richtig sein, oder ich verstehe die Welt
> nicht :)

Es funktioniert. Was fällt Dir daran auf?

> - wozu braucht man fhemTimeLocal?

Im ICal-Format sind Zeitangaben mit einer Genauigkeit von besser als 1
Tag immer in UTC, was für Zeiten seit dem Schreiben des Moduls gleich
GMT ist.

20120623T190302Z ist 23.06.2012 19:03 GMT oder 21:03 CET DST.

Für diese Übersetzung brauche ich fhemTimeGm.

Allerdings sind Zeitangaben mit einer Genauigkeit von 1 Tag so zu
interpretieren, daß es der Tagesanfang ist:

20120623 ist 23.06.2012 00:00 GMT und 00:00 CET DST

Für diese Übersetzung brauche ich fhemTimeLocal.

... und das kann natürlich alles nach TimeUtils.pm oder
FhemUtils/TimeUtils.pm.

Viele Grüße
Boris

[Rudolf Koenig]

> Es funktioniert. Was f�llt Dir daran auf?

tzOffsset muesste doch addiert und nicht substrachiert werden.
Ich dache MEZ = UTC+1 (bzw. UTC+2) und nicht UTC-1


> F�r diese �bersetzung brauche ich fhemTimeLocal.

Ich stehe immer noch auf der Leitung. Fuer mich gibt es ein Darstellungesformat
(HH:MM:SS) fuer die Menschen zum lesen, das kann/sollte die lokalen Gewohneiten
(TZ) beruecksichtigen, und eine interne Darstellung zum rechnen (Sekunden seit
1970), dieser ist UTC. Wozu braucht man Sekunden mit TZ Offset?


> ... und das kann nat�rlich alles nach TimeUtils.pm oder
> FhemUtils/TimeUtils.pm.

Von mir aus sehr gerne.

[Dr. Boris Neubert]

Am 03.07.2012 08:14, schrieb Rudolf Koenig:
>> Es funktioniert. Was fällt Dir daran auf?

>
> tzOffsset muesste doch addiert und nicht substrachiert werden.
> Ich dache MEZ = UTC+1 (bzw. UTC+2) und nicht UTC-1

Beispiel 1:

{ fhemTimeLocal(0,0,20,3,6,112) }
1341338400

{ localtime(1341338400) }
Tue Jul 3 20:00:00 2012

{ gmtime(1341338400) }
Tue Jul 3 18:00:00 2012

MESZ ist UTC um 7200 voraus. Und 20 Uhr MESZ kommt daher 7200 Sekunden
_vor_ 20 Uhr UTC und zwar um 18 Uhr UTC.


Beispiel 2:

{ fhemTimeGm(0,0,20,3,6,112) }
1341345600

{ gmtime(1341345600) }
Tue Jul 3 20:00:00 2012

{ localtime(1341345600) }
Tue Jul 3 22:00:00 2012

20 Uhr UTC kommt 7200 _nach_ 20 Uhr MESZ und zwar um 22 Uhr MESZ.


>> Für diese Übersetzung brauche ich fhemTimeLocal.

>
> Ich stehe immer noch auf der Leitung. Fuer mich gibt es ein Darstellungesformat
> (HH:MM:SS) fuer die Menschen zum lesen, das kann/sollte die lokalen Gewohneiten
> (TZ) beruecksichtigen, und eine interne Darstellung zum rechnen (Sekunden seit
> 1970), dieser ist UTC. Wozu braucht man Sekunden mit TZ Offset?

In ICal sind alle sekundengenau angegebenen Zeiten in UTC und werden
daher mit fhemTimeGm in die Sekunden seit der Epoche umgerechnet.

In ICal nur tagesgenau angegebene Zeiten bedeuten immer den jeweiligen
Tag von 00:00:00 Uhr bis 24:00:00 Uhr und zwar in der Zeitzone des
Betrachters (empirisch ermittelt, indem ich im Google-Kalender ein
ganztägiges Ereignis eingestellt habe, welches dann nur tagegenau
angegeben wird). Das Ereignis wird also nicht, wie man es vielleicht
erwarten würde, von 02:00:00 bis 02:00:00 am nächsten Tag UTC
eingestellt. Daher wird also 03.08.2012 als 03.08.2012 00:00 MESZ in
Sekunden seit der Epoche umgerechnet und dafür benötigen wir fhemTimeLocal.


>> ... und das kann natürlich alles nach TimeUtils.pm oder

>> FhemUtils/TimeUtils.pm.
>
> Von mir aus sehr gerne.

Also inklusive time_str2num() und abstim2rel() aus 99_Utils.pm.

Grüße
Boris