Zeitumstellung bei sunset()

[saft6luck]

Die automatische Zeitumstellung wird bei sunset() (andere Funktionen habe ich nicht geprüft) nicht beachtet -> erst nach einem Neustart des Programms wird deren Zeit wieder richtig berechnet.

[enertegus]

Die automatische Zeitumstellung wird bei sunset() (andere Funktionen habe ich nicht geprüft) nicht beachtet -> erst nach einem Neustart des Programms wird deren Zeit wieder richtig berechnet.

Wurde schon gefixt - diese Woche gibt es ein Patchupdate.

[saft6luck]

Die ganzen Sonnenauf- und -untergangsfunktionen werden "nur" um 0:00 neu gesetzt -> am Tag des Sommer-/Winterzeitwechsels stimmt die entsprechende Zeit nicht. Gibt es hierfür einen Fix?

[enertegus]

Die ganzen Sonnenauf- und -untergangsfunktionen werden "nur" um 0:00 neu gesetzt -> am Tag des Sommer-/Winterzeitwechsels stimmt die entsprechende Zeit nicht. Gibt es hierfür einen Fix?

Bei mir hat das gestern (sun()) gepasst, sodass ich davon ausgehe, dass die aktuelle Beta das wohl richtig macht.

[saft6luck]

Bei mir hat das gestern (sun()) gepasst, sodass ich davon ausgehe, dass die aktuelle Beta das wohl richtig macht.

Wenn alle diese Funktionen gleich behandelt werden könnte es passen.
Ich hab die 2.210 mit Patch 2.114 drauf, und da stimmt es erst heute wieder.

[Tessi]

Bekomme ich dann wie sonst auch ab 00:00 die jeweils "neue" Zeit oder erst ab der Umstellung?

[swiss]

Normalerweise erfolgt die Zeitumstellung um 2 Uhr in der Nacht. Alle Geräte die über NTP also das Internet die Zeit erhalten machen dies auch genau so.

Hier liegt der Hase im Pfeffer. Würde die Zeit für die Astrofunktion erst nach 2 Uhr berechnet, wäre das Problem gelöst. Auch eine Möglichkeit wäre das Datum der Umstellung -1 zu nehmen. Aber nur als Workarround.

[emax]

Würde die Zeit für die Astrofunktion erst nach 2 Uhr berechnet, wäre das Problem gelöst.

Naja. Wenn z.B. um 2:15 Uhr berechnet werden soll, wird im Frühjahr gar nichts berechnet.

Im Herbst dafür doppelt. ;-)

[enertegus]

Ich hab die 2.210 mit Patch 2.114 drauf, und da stimmt es erst heute wieder.

Böser Patch. Bitte 2.120 upgraden.

[Tessi]

Normalerweise erfolgt die Zeitumstellung um 2 Uhr in der Nacht. Alle Geräte die über NTP also das Internet die Zeit erhalten machen dies auch genau so.

An sich sollen alle Geräte mit automatischer Zeitumstellung das genau so tun, egal woher sie die Zeit bekommen.

Hier liegt der Hase im Pfeffer. Würde die Zeit für die Astrofunktion erst nach 2 Uhr berechnet, wäre das Problem gelöst.

Dafür weicht man dann von der korrekten Vorgehensweise ab, zwischen 00:00 und 02:00 würde fälschlich noch die Zeit vom Vortag verwendet werden, und das immer, nicht nur am Tag der Umstellung. Wobei die meisten von uns wohl damit leben könnten, so groß sind die Unterschiede ja nicht und mir fällt auch nichts Zeitkritisches ein, was unbedingt zwischen 00:00 und 02:00 in Abhängigkeit vom Sonnenauf- oder Untergang erledigt werden müsste.
Dennoch wäre der sicherste und formal auch korrekte Weg wohl, die Zeiten am Tag der Umstellung Winter/Sommer zusätzlich noch um/ab 03:00, am Tag der Umstellung Sommer/Winter zusätzlich noch um/ab 02B:00 (also das zweite Mal 02:00) erneut zu berechnen - und somit auch alle davon abhängenden Aktionen.

BTW:
Am Tag der Sommer/Winterzeitumstellung gibt es die Stunde zwischen 02:00 und 03:00 ja zweimal, offiziell (z.B. in Fahr- oder Flugplänen) dann 02A und 02B genannt. Gibt es im EibPC irgendeine Möglichkeit, das bei Zeitfunktionen zu berücksichtigen?

Auch eine Möglichkeit wäre das Datum der Umstellung -1 zu nehmen.

Das verstehe ich jetzt irgendwie nicht....

BTW:
Fall dieser volkswirtschaftliche Unsinn eines Tages wieder mal abgeschafft werden sollte (es gab ja immer wieder mal Zeiten ohne), braucht der EibPC dann neue Software? Oder kann ich das mit der Zeitumstellung irgendwo konfigurieren?

[emax]

Am Tag der Sommer/Winterzeitumstellung gibt es die Stunde zwischen 02:00 und 03:00 ja zweimal

So isses:

Naja. Wenn z.B. um 2:15 Uhr berechnet werden soll, wird im Frühjahr gar nichts berechnet.

Im Herbst dafür doppelt. ;-)

Fall dieser volkswirtschaftliche Unsinn eines Tages wieder mal abgeschafft werden sollte (es gab ja immer wieder mal Zeiten ohne), braucht der EibPC dann neue Software?

Trotz Unkenntnis der Software: ein locatime bzw. dessen Equivalent sollte immer die korrekte Uhrzeit liefern, ob mit oder ohne Sommerzeit. Ich kenne allerdings wie gesagt die Grundlagen des EibPC nicht.

[Tessi]

ein locatime bzw. dessen Equivalent sollte immer die korrekte Uhrzeit liefern, ob mit oder ohne Sommerzeit.

Das Problem ist nicht, auf Anfrage eine korrekte lokale Zeit zu liefern. Das Problem ist, tägliche Zeitpunkte korrekt einzuordnen. 03:00 Sommerzeit ist eben nicht die selbe Tageszeit wie 03:00 Winterzeit. Bei Vergleichen muss irgendwie sichergestellt werden, das da korrekt "interpretiert" wird. Meine ich jeden Tag den selben Zeitpunkt oder dieselbe Zeitangabe? Darüber denkt kaum jemand nach.

[emax]

Das habe ich durchaus verstanden. Aber die Diskussion wie ich sie begriffen habe dreht sich um die technische Frage, ob die gelieferte Uhrzeit korrekt im Sinne lokaler Zeit ist oder nicht. Das ist bei localtime immer der Fall, egal ob die Sommerzeit abgeschafft wird oder nicht. Dei Frage war ja, ob eine Abschaffung der Sommerzeit eine neue Software erfordert.

Die Frage, ob jemand dagegen einen Zeitpunkt nach astronomischen Maßstäben, meint, also nicht lokal korrigiert, ist aber genau so einfach zu beantworten: Man muss ja nicht die lokale Zeit nehmen, die tatsächlich ja eine rein 'amtliche' Zeit darstellt. Gängige System liefern i.d.R. auch die uninterpretierte Systemzeit (also ohne Sommerzeit Aufschlag), oder auch Zulu-Time (Greenwich), von der ausgehend man einen immer gleichen Zeitpunkt ungeachtet einer Sommerzeitregelung erhält.

[Tessi]

Das habe ich durchaus verstanden. Aber die Diskussion wie ich sie begriffen habe dreht sich um die technische Frage, ob die gelieferte Uhrzeit korrekt im Sinne lokaler Zeit ist oder nicht.

Ja, stimmt.

Das ist bei localtime immer der Fall, egal ob die Sommerzeit abgeschafft wird oder nicht.

Aber dazu muss localtime ja irgend woher wissen, ob es eine Sommerzeit gibt, oder nicht.

Dei Frage war ja, ob eine Abschaffung der Sommerzeit eine neue Software erfordert.

Ja, Hintergrund ist dabei, das sich das sicherlich irgendwo im OS konfigurieren lässt, nur hat der EibPC-User darauf meines Wissens nach keinen Zugriff. Daher die Frage, ob bei Abschaffung der Sommerzeit dann ein Patch oder Update von Enertex notwendig wäre, damit das System dann zukünftig eben nicht mehr umschaltet.

Die Frage, ob jemand dagegen einen Zeitpunkt nach astronomischen Maßstäben, meint, also nicht lokal korrigiert, ist aber genau so einfach zu beantworten: Man muss ja nicht die lokale Zeit nehmen, die tatsächlich ja eine rein 'amtliche' Zeit darstellt. Gängige System liefern i.d.R. auch die uninterpretierte Systemzeit (also ohne Sommerzeit Aufschlag), oder auch Zulu-Time (Greenwich), von der ausgehend man einen immer gleichen Zeitpunkt ungeachtet einer Sommerzeitregelung erhält.

Gängige Systeme wohl schon, beim EibPC gibt es aber nur eine Zeit für den User, die lokale eben. An sich auch kein Problem. Wenn ich eine Schaltuhr auf Sonnenuntergang+30min setze, sollte das passen, egal ob Sommer- oder Winterzeit. Aber anscheinend verwendet der EibPC bis jetzt eben nicht UTC für die interne Berechnung und localtime, um die ermittelte Zeit dann korrekt umzurechnen. Und der User hat keine Möglichkeit, darauf Einfluss zu nehmen.

[emax]

Aber dazu muss localtime ja irgend woher wissen, ob es eine Sommerzeit gibt, oder nicht.

Tja, vermutlich gehe ich von den falschen Voraussetzungen aus, ich kenne ja den EibPc wie gesagt nicht. Ich bin halt Linuxer. 'localtime' kennt die lokale Zeit (unter Ubuntu) aus /etc/localtime, ein Datensatz der Auskunft über die Zeitzone gibt. Dieser liegt eine Regel zugrunde, nach der Sommer- bzw. Winterzeit ermittelt wird. Andere *ix Systeme wiederum machen das über die 'TZ' Umgebungsvariable. Alle diese Regeln leiten die korrekte Zeit aus der Systemzeit ab.

Da aber der EibPc ein embedded System ist, bin ich von den falschen Voraussetzungen ausgegangen. Die Frage nach dem Software Update ist so betrachtet tatsächlich relevant.