Autor Thema: Lösungen für Zeitumstellung  (Gelesen 409 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Lösungen für Zeitumstellung
« am: 02 November 2021, 09:15:15 »
Hallo zusammen,

nachdem diverse Module (teils wohl auch abhängig von der Hardware) Probleme mit der Zeitumstellung hatten und wir immer noch nicht wissen, wie lange uns das Thema noch erhalten bleibt, hier zwei Varianten für die Berechnung Zeiten für den Tageswechsel, die mAn. funktionieren.
Die eine stammt aus Twilight (in Twilight_midnight()):
my $now = time;
    my $midnight = $now - secondsSinceMidnight( $now ) + DAYSECONDS + 1;
    my $daylightsavingdelta = (localtime ( $now - 2 * HOURSECONDS ) )[2] - ( localtime( $now + 22 * HOURSECONDS ) )[2];
    $midnight -= 19 * HOURSECONDS if $daylightsavingdelta == 1 && (localtime)[2] < 2;
    $midnight -= 20 * HOURSECONDS if $daylightsavingdelta == -1 && (localtime)[2] < 3;
   
    return resetRegIntTimer( 'Midnight', $midnight, \&Twilight_Midnight, $hash, 0 );

Die andere (mAn. die elegantere) aus WeekdayTimer (_SetTimerForMidnightUpdate()), das intern dann timelocal_nocheck aufruft (bzw. aufrufen kann, weil die Gültigkeit der Argumente vorab geprüft wurde):
my $midnightPlus5Seconds = getSwitchtimeEpoch  ($now, 0, 0, 5, 1);mit der aufgerufenen Funktion
sub getSwitchtimeEpoch {
  my ($now, $hour, $min, $sec, $days) = @_;

  my @jetzt_arr = localtime($now);
  #Stunden               Minuten               Sekunden
  $jetzt_arr[2]  = $hour; $jetzt_arr[1] = $min; $jetzt_arr[0] = $sec;
  $jetzt_arr[3] += $days;
  my $next = timelocal_nocheck(@jetzt_arr);
  return $next;
}

EDIT: Die aktuelle Variante bei Astro scheint nun zu funktionieren, daher auch diese hier:
if ( $comp eq 'NewDay' ) {
        my @dch = localtime($now + 86400 + 3600*((localtime($now))[8] - (localtime($now + 86400.))[8]));
        push @next,
          _timelocal_modern( 0, 0, 0, $dch[3], $dch[4], $dch[5]+1900. );
        next;
    }
« Letzte Änderung: 02 November 2021, 17:48:15 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 17568
  • s/fhem\.cfg/configDB/g
Antw:Lösungen für Zeitumstellung
« Antwort #1 am: 02 November 2021, 09:25:07 »
Und was willst Du uns nun damit eigentlich sagen?

Die Zeitumstellung an sich ist das Eine. Aber dieses Mal hatten wir die recht selten vorkommende Situation, dass die Zeitumstellung auch noch mit dem letzten Tag eines Monats zusammenfiel und das offenbar in Kombination zusätzliche Probleme bereitete.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16372
Antw:Lösungen für Zeitumstellung
« Antwort #2 am: 02 November 2021, 09:39:59 »
Es mag ja sein, dass das Problem dadurch komplexer wurde, dass auch noch der Monatswechsel dazukam. Zumindest in einem Fall (statistics) scheint aber das Problem die zu dem Umstellungstermin jeweils falsch berechnete Tageswechselzeit gewesen zu sein (eine Stunde zu früh), weswegen dann in der Folge auch der Monatswechsel entfallen ist.

Es gab dann noch den einen oder anderen, der von den Entwicklern zurückgemeldet hatte, dass er "keine Zeit" hat, für diese Zeitumstellungs-Problematik eine Lösung zu entwickeln bzw. schon länger nicht mehr mit Perl gearbeitet zu haben.

Jetzt kann jeder anfangen, das Rad wieder neu zu erfinden oder das ganze so lassen, wie es ist (mit der Konsequenz, dass es wieder "überraschend" alle halbe Jahre wieder an diversen Stellen User gibt, die sich die Augen reiben).

Daher hier die Schnippsel, die man entweder fachlich kritisieren darf oder eben übernehmen kann, wenn man möchte. Kann ja durchaus sein, dass die zwei Module, die am häufigsten Thema waren, nicht die einzigen sind...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}
Zustimmung Zustimmung x 1 Liste anzeigen