[99_SUNRISE_EL.pm] Zeitumstellung

[mackshot]

Hallo zusammen,

jedes halbe Jahr scheinen hier im Forum ja Fehlermeldung aufzutauchen wg. der Zeitumstellung und SUNRISE_EL aufzukommen. Insbesondere für die Kombination von SUNRISE_EL mit DOIF etwa für die Rolladensteuerung.

Das Problem liegt darin, dass beim Ausführen des DoIf der nächste Zeitpunkt der Ausführung bestimmt wird. Dieser wird als Timespec bestimmt, der meinem Verständnis nach aus zwei Summanden besteht. Der erste gibt ab, dass die nächste Ausführung am nächsten Tag stattfindet sprich 24:00:00 und der zweite Summand legt dann die Uhrzeit an diesem Tag fest, beispielsweise 18:30:12. In der Summe erhalten wir dann 31:30:12. Wenn nun aber Zeitumstellung ist, ist plötzlich nicht mehr 18:30:12 korrekt sondern 17:30:12 (respektive 30:30:12) oder 19:30:12 (respektive 32:30:12) korrekt. Mit anderen Worten: Um das Problem zu korrigieren muss man eine Stunde abziehen oder addieren, wenn zwischen Bestimmungszeitpunkt und nächstem Ausführungszeitpunkt eine Zeitumstellung liegt.

Ich habe das Problem bei mir wie folgt gelöst:

Ich habe in meiner "99_myUtils.pm" die folgende Methode eingebaut:

Code Auswählen Erweitern

sub adjustTime {
  my $val = shift;
  my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);

  my @parts = split(/:/, $val);
  my ($sec2,$min2,$hour2,$mday2,$mon2,$year2,$wday2,$yday2,$isdst2) = localtime(time + ($parts[0] - 24) * 60 * 60 + $parts[1] * 60 + $parts[2]);

  my $h = $parts[0];
  if ($isdst2 == 1 && $isdst == 0) { # CET -> CEST
    $h = $h - 1;
  } elsif ($isdst2 == 0 && $isdst == 1) { # CEST -> CET
    $h = $h + 1;
  }

  return $h . ":" . $parts[1] . ":" . $parts[2];
}

Und nutzen diese dann in einem  DoIf wie folgt:

Code Auswählen Erweitern

([{adjustTime(sunset(-900,"17:00","22:30"))}]) ( set Rolladen night )

Ich übergebe also den Zeitpunkt in meine Methode und erhalte dann den (möglicherweise adjustierten) Zeitpunkt.

Vielleicht kann man die Logik ja in 99_SUNRISE_EL.pm einbauen.

Markus

Edit: Wenn gewünscht bringe ich mich bei einem solchen Einbau auch gerne aktiv (d.h. mit Quellcode^^) ein!

[rudolfkoenig]

jedes halbe Jahr scheinen hier im Forum ja Fehlermeldung aufzutauchen wg. der Zeitumstellung und SUNRISE_EL aufzukommen.

Solche Probleme im Zusammenhang mit at wurden mW vor ca 10 Jahren gefixt.

Ich habe jetzt in einem VM die Uhrzeit auf 26.10, 18:47 gestellt, und ein at definiert: define x at *{sunset()} Blub
- x loest um 18:47:42 aus.
- sunset() liefert den Wert 41:45:46, also 24+17:45:56, meinend: am naechsten Tag, um 17:45
- at.pm ruft mit diesen Wert (41:45:46) und dem aktuellen Datum mktime auf, was die richtige Zeit berechnet
- at.pm plant damit die naechste Ausfuehrung fuer den 27. 10 um 17:45:56 ein, also etwa eine Stunde frueher als am 26.10.
=> ich sehe kein Problem.

Eine aehnliche Funktion (plus Caching) gibt es in at.pm unter dem Namen at_SecondsTillTomorrow, allerdings kam sie hier gar nicht zum Zugriff.

Falls DOIF das Problem nicht selbst fixen will, dann bin ich bereit die Funktion in 99_Utils aufzunehmen, allerdings muss der Name so gewaehlt werden, dass weder at noch DOIF Benutzer verwirrt werden.

[CoolTux]

Was ich nicht verstehe Rudi, warum soll eine Funktion aufgenommen werden welche ein nicht existierendes Problem fixt? Laut Deiner Aussage hat die Funktion sunset() dieses benannte Problem ja nicht. DOIFs eigene Zeitberechnungsroutine soll das Problem auch nicht haben. Also wo zu? Einzig sunset_abs hätte das Problem da es keine +24h macht.


Grüße

[rudolfkoenig]

Laut Thread-Ersteller gibts ein Problem, und ich wollte es nicht wegwischen, nur weil _ich_ (mit at) kein Problem habe.

[CoolTux]

Wegwischen will ich es auch nicht. Dennoch sollte man sich die Tiefe der Analyse des Users näher beschreiben lassen. Sichelic macht es keinen großen Aufwand die Funktion zu übernehmen. Es wäre aber eine 99er welche immer geladen wird. Hier sollten wir meine ich genauer hin schauen nach "wird gebraucht". Es gibt meines Wissens aktuell keine User die Probleme gemeldet haben in der Richtung. Und wenn ich mir die alten Sachen so anschaue haben viele ein at mit sunrise() und sunset().

[Damian]

Hier mal zur Information:

Ich konnte gerade einen Fehler im DOIF bei Angaben über 24-Stunden, wie z. B. 41:45:46, bei der Zeitumstellung reproduzieren. Unabhängig davon wurde die Zeitumstellung im DOIF immer schon berücksichtigt.

Da sunset die korrekte Zeit am Folgetag nach der Zeitumstellung bestimmt, wird ein gefixes DOIF auch die korrekte Zeit des Folgetags bestimmen. Damit erübrigt sich die adjustTime-Funktion (zumindest in Verbindung mit DOIF oder at).

Die adjustTime-Funktion entstand offensichtlich aufgrund falscher Annahme, dass sunset bzw. DOIF die Zeitumstellung nicht berücksichtigen würden.

[CoolTux]

Vielen Dank für Deine Anmerkung.

[Damian]

DST-Problem wurde im DOIF behoben.

[mackshot]

DST-Problem wurde im DOIF behoben.

Das klingt doch gut. Danke Dann kann ich die Funktion ja wegwerfen . Danke allen Beteiligten.