Sommerzeitumstellung (Funktion von jurs)

Das glaube ich auch.
Wenn Schaltjahre falsch berechnet werden dann berechnet das Programm den Zeitintervall der gültigen Sommerzeit falsch und die Sommerzeit fängt nicht mehr am richtigen Sonntag an.
Die Schaltjahre bis 2099 müßten richtig berechnet werden und der Umschalttag.
laut Wikipedia.de:
"Die mitteleuropäische Sommerzeit beginnt am letzten Sonntag im März um 2:00 Uhr MEZ, indem die Stundenzählung um eine Stunde von 2:00 Uhr auf 3:00 Uhr vorgestellt wird. Sie endet jeweils am letzten Sonntag im Oktober um 3:00 Uhr MESZ, indem die Stundenzählung um eine Stunde von 3:00 Uhr auf 2:00 Uhr zurückgestellt wird."

Wenn sich durch den zuviel eingeschobenen Tag im Februar 2100 der letzte Sonntag um eine Woche verschiebt wird die Sommerzeit um eine Woche falsch angefangen und oder beendet. Das ist dann nicht für alle Jahre falsch sondern kommt auf die Kombination Woche und Wochentag im März / Oktober an. Der Fehler ist dann nicht immer vorhanden sondern sporadisch. Ich kann jetzt nicht berechnen wann das passiert. Ich schätze es passiert nur einigem male in dem Jahrhundert 2100 bis 2199.

Grüeß Uwe

Das gilt nicht nur für das Ende, sondern auch für den Anfang der Sommerzeit, da der auch nach dem 29.02.2100 ist.

Gruß Tommy

Edit: Eigentlich fehlt ab 2100 ja jeweils ein Tag, also wahrscheinlich quick & dirty

if (year >= 2100) {
  x1 += 24; 
  x2 += 24;
}

Hallo,

man muss ganz klar unterscheiden von was die Rede ist und was wovon abhängt.

jurs "summertime" Funktion arbeitet für sich gesehen völlig unabhängig von irgendeinem Schaltjahr. Geht gar nicht anders. Die Daten dafür kommen allerdings von einer RTC und diese berechnet das Schaltjahr selbstständig. Die RTCs berechnen soweit bekannt nur bis 2100 das Schaltjahr richtig. Damit muss zwangsweise alles andere was die RTC Daten verwendet falsch gehen wenn die RTC ab 2100 falsch geht.

Das ist ein großer Unterschied in der Betrachtung des eigentlichen Problems. Leider können wir jurs nicht mehr fragen bezüglich seiner Aussage wie er das meinte und worauf er sich bezog. Die Antwort steht und fällt wie gesagt mit dem Bezugspunkt der Daten.

Man müßte einen Code schreiben der selbst nochmal prüft ob es ein Schaltjahr ist oder nicht. Der entweder den 29.2. künstlich einfügt und damit die RTC Daten überschreibt oder den 29.2. unterdrückt falls der von der RTC fälschlicherweise kommen sollte. Nach dieser möglichen Korrektur gehen die Daten weiter zur summertime Funktion.

Bis dahin denke ich sollte es neue RTC Bausteine geben und das Problem ist sowieso gelöst.

Hallo Tommy,

mit deiner Ergänzung wird die Sommerzeit Erkennung auch im Jahr 2100 korrekt vorgenommen.

Ich lese mich gerade in die Wochentagsberechnung nach Christian Zeller ein. Ich vermute das die Berechnung aus der Funktion hierher kommt.

Dort gibt es eine Formel mit der man den Wochentag aus einen gegeben Datum berechnen kann, die das gesamte 21. Jahrhundert gültig ist und auch das Schaltjahr berücksichtig:

w = (d + [2,6 m - 0,2] - 2 + y +[y/4] + 2) mod 7

Jurs hat in seiner Funktion eine ganz ähnliche Berechnung mit mod 7

x1 = 1 + tzHours + 24 * (31 - (5 * year / 4 + 4) % 7); // Ergebnis in Stunden

Jetzt muss ich nur noch den Algorithmus verstehen, wie er hergeleitet wurde.

Gruß,
Björn

Ist nicht einer zuviel da 2100 kein Schaltjahr ist aber der Allogaritmus einen alle 4 Jahre annimmt?

Dieser Betrachtung kann ich auch viel abgewinnen.

Grüße Uwe

Die Schaltjahr-Berechnung wird falsch, ab 01.03.2100 (der 29.02. 2100, also ein Tag zuwenig)
Aber die Wochentage zählen richtig weiter.
Falls die Umschalt-Regel ( letzte Nacht von Sa auf So im März / Oktober ) im Jahr 2100 noch gilt, würde diese theoretisch fast immer richtig rechnen, aber die Uhr zeigt ab dem 29.02.2100, den es gar nicht gibt, ein falsches Datum an. Sobald man das richtig stellt (ein Tag mehr) ist allerdings der Wochentag nach obiger Formel falsch :slight_smile:
... und die Ur-Urenkel haben eine Knobel-Aufgabe.
Vielleicht erinnern sie sich noch an alte Erzählungen aus 2038, (62 Jahre früher) als bei ihren Großeltern rauskam, wo überall uralte 32bit-"Unixtime" Uhren schlummerten, die damals überliefen.

In diesem Thread schreibt jurs es ist nur eine kleine Veränderung nötig um die Funktion im nächsten Jahrhundert zu nutzen.

Ich habe die Berechnung von x1 und x2 wie folgt angepasst:

x1 = 1 + tzHours + 24 * (31 - ((5 * year / 4 + 3) % 7));    // + 3 anstatt + 4
x2 = 1 + tzHours + 24 * ( 31 - ((5 * year / 4 + 0) % 7) );  // + 0 anstatt + 1

Und habe den Sommerzeitbeginn der Jahre 2100 - 2103 getestet und damit wird bei mir zumindest seriell die Umstellung richtig angezeigt.

Ich konnte allerdings noch keine Erklärung zur Berechnung selbst finden. Hatte vermutet, dass ich durch meine Änderung den Wochentag verändere - finde aber keine Quelle mit der ich das zweifelsfrei bestätigen kann.

Gruß,
Björn

Klammer- vor Punkt- vor Strichrechnung
year=2103:

x1 = 1 + tzHours + 24 * (31 - ((5 * 2103 / 4 + 3) % 7));
                               ^                ^
x1 = 1 + tzHours + 24 * (31 - ((10515 / 4 + 3) % 7));
                               ^             ^
x1 = 1 + tzHours + 24 * (31 - ((2628,75 + 3) % 7));
                               ^           ^
x1 = 1 + tzHours + 24 * (31 - ((2628 + 3) % 7));
                               ^           ^
x1 = 1 + tzHours + 24 * (31 - (2631 % 7));
                              ^        ^
x1 = 1 + tzHours + 24 * (31 - (6));
                              ^ ^
x1 = 1 + tzHours + 24 * (31 - 6);
                        ^      ^
x1 = 1 + tzHours + 24 * (25);
                        ^  ^
x1 = 1 + tzHours + 24 * 25;
                   ^    ^
x1 = 1 + tzHours + 600;

Jetzt nur addieren.....

Der Wochentag wird aus der (RTC)-Uhrzeit errechnet / ausgelesen. Datenblatt z.B. für die DS3231 Tabelle 2: https://datasheets.maximintegrated.com/en/ds/DS3231M.pdf

1 Like

Vielen Dank für deine Antwort :slight_smile:

Bei dem Rechenschritt:

x1 = 1 + tzHours + 24 * (31 - (2631 % 7));

müsste das Ergebnis dort nicht 6 sein? Dann würde am Ende als letzter Sonntag im März 2103 der 25. raus kommen.

Ich werde mir das Datasheet morgen genauer anschauen, muss morgen leider wieder früh raus.. und seh' den Wald vor lauter Bäumen glaube ich nicht mehr.

Was mir noch nicht ganz in den Kopf will wieso bekomme ich mit

(31 - ((5 * 2103 / 4 + 3) % 7))

den letzten Sonntag im März (der 25.) raus, an dem die Umstellung passiert. Mir ist klar, dass das mit Kalenderrechnen zusammen hängt - mag das nur gerne nachvollziehen können. Auch wieso ich für das nächste Jahrhundert anstatt +4 am Ende +3 addieren muss.

Bis morgen und Gruß,
Björn

31 - ((5 * 2103 / 4 + 3) % 7))
Erst Klammern auflösen:
10515 / 4 = 2628 +3 = 2631 %7 = 6
31-6 = 25

Ja. Danke.

ändere ich....

Weil Dir der Schalttag fehlt?....