Meine Güte, 64 Bit...

[hotti]

... für ein Datum-Objekt.

Die Scaliger-Epoche (s. Anm.) geht vom 1.1.4713 BC bis 22.1.3268 mit dem fortlaufenden Tag 2914694 am Ende der Epoche, dafür reichen 22 Bit. Sollen die Sekunden eines Tages (86400) noch dazu, brauchen wir 6 Bit mehr, macht zusammen 28 Bit, das passt doch locker in eine 32-Bit-Architektur... womit jede Sekunde in dieser Epoche eindeutig bestimmt werden kann. Oder habe ich da einen Denkfehler?

Anm.: Die Berechnung der Julianischen Tage erfolgt nach Scaliger mit der Annahme, dass sich die Schaltjahresregelung bis 3268 gregorianisch erfolgt und sich nicht ändert.

Hotti

[Der Martin]

Hallo,

Die Scaliger-Epoche (s. Anm.) geht vom 1.1.4713 BC bis 22.1.3268 mit dem fortlaufenden Tag 2914694 am Ende der Epoche, dafür reichen 22 Bit. Sollen die Sekunden eines Tages (86400) noch dazu, brauchen wir 6 Bit mehr, macht zusammen 28 Bit, das passt doch locker in eine 32-Bit-Architektur... womit jede Sekunde in dieser Epoche eindeutig bestimmt werden kann. Oder habe ich da einen Denkfehler?

ich nähere mich der Frage mal von einer anderen Seite. Irregularitäten wie Schaltjahre mal vernachlässigend hat ein Jahr

365 * 24 * 60 * 60 = 31'536'000

Sekunden, das sind näherungsweise 2^25 Sekunden. Bleiben also im 32bit-Rahmen noch 7 Bit übrig, in denen man das Jahr zählen könnte. Also lässt sich gerade mal ein Bereich von etwas über 128 Jahren abdecken.

Dein Denkfehler ist an der Stelle, wo du annimmst, der Faktor 86400 bedeute 6bit mehr. Tatsächlich sind es mehr als 16bit, denn 16bit bedeuten einen Faktor von 65536.

Ciao,
 Martin

[hotti]

hi,

Dein Denkfehler ist an der Stelle, wo du annimmst, der Faktor 86400 bedeute 6bit mehr. Tatsächlich sind es mehr als 16bit, denn 16bit bedeuten einen Faktor von 65536.

Mist, ich hätte nachrechnen sollen ;)

Danke Dir!!!

Also brauchen wir 22 Bit + 17 Bit....

Zu Deiner Rechnung:

Also lässt sich gerade mal ein Bereich von etwas über 128 Jahren abdecken.

Ja, wenn Du für _jeden_ Tag die Sekunden mitschleppst. Tatsächlich reichts jedoch, die Sekunden nur für einen Tag mitzunehmen, denn die wiederholen sich ;)

Hotti

[Der Martin]

Hallo,

Zu Deiner Rechnung:

Also lässt sich gerade mal ein Bereich von etwas über 128 Jahren abdecken.
Ja, wenn Du für _jeden_ Tag die Sekunden mitschleppst. Tatsächlich reichts jedoch, die Sekunden nur für einen Tag mitzunehmen, denn die wiederholen sich ;)

ja, das hilft dir aber nichts. Du willst einen Zeitraum von knapp 8000 Jahren abdecken, das sind rund 3 Millionen Sekunden. Du brauchst also schon mal 22bit für die Tageszählung, und zusätzlich 17bit für die Sekunden des letzten Tages. Wenn du da was einsparen kannst, wäre das eine Revolution der Zahlensysteme. Damit würdest du groß rauskommen!

Nein, vergiss es - das ist mathematisch ein triviales Thema, da ist nichts zu machen.

Ciao,
 Martin

[MudGuard]

Hi,

Ja, wenn Du für _jeden_ Tag die Sekunden mitschleppst. Tatsächlich reichts jedoch, die Sekunden nur für einen Tag mitzunehmen, denn die wiederholen sich ;)

Hottis Zeit-Berechnung ist so hanebüchen wie seine OOP (Tisch erbt von Restaurant ...)

ja, das hilft dir aber nichts. Du willst einen Zeitraum von knapp 8000 Jahren abdecken, das sind rund 3 Millionen Sekunden.

365*24*3600 = 31536000, also bereits über 31 Millionen Sekunden (genauer: 31556952 bei einem Jahr mit 365,2425 Tagen)
365*24*3600 *8000 = 252 288 000 000, also rund 252 Milliarden Sekunden (genauer: 252455616000)

Nein, vergiss es - das ist mathematisch ein triviales Thema, da ist nichts zu machen.

Trivial ja, aber Hotti ist damit schon überfordert ...

cu,
Andreas

[Der Martin]

Hallo,

ja, das hilft dir aber nichts. Du willst einen Zeitraum von knapp 8000 Jahren abdecken, das sind rund 3 Millionen Sekunden.
365*24*3600 = 31536000, also bereits über 31 Millionen Sekunden (genauer: 31556952 bei einem Jahr mit 365,2425 Tagen)
365*24*3600 *8000 = 252 288 000 000, also rund 252 Milliarden Sekunden (genauer: 252455616000)

huch, jetzt komm ich auch schon ins Schleudern. Sorry, ich meinte natürlich 3 Millionen Tage!

Ciao,
 Martin

[Dummerchen]

Hallo,

365*24*3600 = 31536000, also bereits über 31 Millionen Sekunden (genauer: 31556952 bei einem Jahr mit 365,2425 Tagen)
365*24*3600 *8000 = 252 288 000 000, also rund 252 Milliarden Sekunden (genauer: 252455616000)

könnte mir das jemand genauer erklären bitte? Warum braucht man dazu 64 bit? Am besten einfach erklären, damit ich das auch verstehe. Ich habe nämlich keine Ahnung, bin aber sehr daran interessiert.

Danke!

[Der Martin]

Hi,

könnte mir das jemand genauer erklären bitte? Warum braucht man dazu 64 bit? Am besten einfach erklären, damit ich das auch verstehe. Ich habe nämlich keine Ahnung, bin aber sehr daran interessiert.

also pass auf:
Mit 1bit kann man 2 verschiedene Werte darstellen, 0 und 1.
Mit 2 bit kann man schon 2^2=4 verschiedene Werte darstellen, zum Beispiel 0, 1, 2, und 3.

Setze das logisch fort:

Mit 16bit kann man 2^16=65535 verschiedene Werte darstellen.
...
Mit 32bit kann man 2^32 verschiedene Werte darstellen (ungefähr 4 Milliarden).

Den Rest kriegst du selber hin.

Ciao,
 Martin

[Dummerchen]

Hallo Martin,

danke. Das verstehe ich schon. Aber mir geht es erstmal nur um die Sekunden. Es sind also 252455616000 Sekunden für den zeitraum von 8000 Jahren. Diese Zahl kann ich aber doch auch darstellen, wenn ich weniger als 64bit habe? Irgendwie denke ich wohl falsch. Aber wo genau liegt denn mein Denkfehler?

[Der Martin]

Hallo,

danke. Das verstehe ich schon. Aber mir geht es erstmal nur um die Sekunden. Es sind also 252455616000 Sekunden für den zeitraum von 8000 Jahren. Diese Zahl kann ich aber doch auch darstellen, wenn ich weniger als 64bit habe? Irgendwie denke ich wohl falsch. Aber wo genau liegt denn mein Denkfehler?

es gibt keinen Denkfehler. Dir fehlt nur die Information, dass es in der zeitgenössischen EDV zwischen 32 und 64bit nichts gibt. Die 252'455'616'000 Sekunden könnte man mit 38bit darstellen, aber es gibt Systeme, die 32bit auf einmal verarbeiten können, und es gibt Systeme, die 64bit auf einmal verarbeiten können. Alles dazwischen ist blanke Theorie.

Ciao,
 Martin

[Dummerchen]

Hallo Martin,

danke. Das verstehe ich schon. Aber mir geht es erstmal nur um die Sekunden. Es sind also 252455616000 Sekunden für den zeitraum von 8000 Jahren. Diese Zahl kann ich aber doch auch darstellen, wenn ich weniger als 64bit habe? Irgendwie denke ich wohl falsch. Aber wo genau liegt denn mein Denkfehler?

es gibt keinen Denkfehler. Dir fehlt nur die Information, dass es in der zeitgenössischen EDV zwischen 32 und 64bit nichts gibt. Die 252'455'616'000 Sekunden könnte man mit 38bit darstellen, aber es gibt Systeme, die 32bit auf einmal verarbeiten können, und es gibt Systeme, die 64bit auf einmal verarbeiten können. Alles dazwischen ist blanke Theorie.

ah, "auf einmal" ist vermutlich mein Denkfehler gewesen. Ich hatte gemeint, dass man die Zahl vielleicht irgendwie aufteilen kann oder sowas. Es gibt ja auch Digitaluhren mit vielleicht nur 4bit. vielen Dank, dann ist es einigermaßen klar.

[Matze]

Hallo!

ah, "auf einmal" ist vermutlich mein Denkfehler gewesen. Ich hatte gemeint, dass man die Zahl vielleicht irgendwie aufteilen kann oder sowas. Es gibt ja auch Digitaluhren mit vielleicht nur 4bit. vielen Dank, dann ist es einigermaßen klar.

Eine Uhr ist auch kein Kalender und mit 4Bit kommst du maximal auf 16. Damit kannst du nichtmal 1min bzw. 60sek berechnen. Binäruhren benutzen deshalb jeweils 4bit für jede Stelle oder direkt mindestens 6bit (bzw. 8 - siehe Der Martin).

Grüße, Matze

[hotti]

Moin,

ja, das hilft dir aber nichts. Du willst einen Zeitraum von knapp 8000 Jahren abdecken, das sind rund 3 Millionen Sekunden. Du brauchst also schon mal 22bit für die Tageszählung, und zusätzlich 17bit für die Sekunden des letzten Tages. Wenn du da was einsparen kannst, wäre das eine Revolution der Zahlensysteme. Damit würdest du groß rauskommen!

Hoch lebe die 64-Bit-Revolution! Für sekundengenaue Datum-Objekte in Webanwendungen, die mit PHP erstellt sind!

Also mal ehrlich, wenn tatsächlich Sekundengenauigkeit gebraucht wird, da würde ich mich auf einen Zeitraum beschränken, in denen Datierungen einigermaßen (!) zuverlässig sind, was nicht einmal auf die letzten 500 Jahre zutrifft. Was die Korrelation des Maya-Kalenders mit europäischen Kalendersystemen betrifft, da liegt der Streitwert bei einer Streuung von 800 Jahren und nicht im Sekundenbereich.

Wie auch immer, ich werde nun, nach meiner Perl-Epoche, zwei PHP-Klassen für den Gregorianischen/Julianischen und Maya-Kalender entwickeln, wofür 22 Bit völlig ausreichend sind ;)

Hotti

[dedlfix]

Tach!

Hoch lebe die 64-Bit-Revolution! Für sekundengenaue Datum-Objekte in Webanwendungen, die mit PHP erstellt sind!
Also mal ehrlich, wenn tatsächlich Sekundengenauigkeit gebraucht wird, da würde ich mich auf einen Zeitraum beschränken, in denen Datierungen einigermaßen (!) zuverlässig sind, was nicht einmal auf die letzten 500 Jahre zutrifft.

Zum einen passen in 32 Bit grad mal die Jahre 1970 bis 2037, was 500 Jahre lange nicht erreicht. Dieser Zeitraum ist also schon zu klein, selbst bei deinem großzügigen Zugeständnis von 500 Jahren (Vergangenheit, also noch nicht mal mit Zukunft). Und was kommt nun? Statt den computer-verarbeitungstechnisch am naheliegendsten 64 Bit willst du irgendetwas anderes nehmen, auf dass man es vor und nach der Verarbeitung mit den vorhandenen 64-Bit-Recheneinheiten erst noch umformen muss und bei 32 Bit mehrere Schritte braucht? Dann bevorzuge ich doch lieber die schwachsinnigen sekundengenauen 292 Milliarden Jahre, die in einem Zug verarbeitet werden können.

dedlfix.

[hotti]

Hi,

Stichwort: Register
Ein solches ist mit jeweils 32 Bit für Tag/Sekunde schon recht großzügig dimensioniert ;)

Für die Präsentation eines sekundengenauen Date-Time-Objekts brauchst Du mindestens 39 Bit, zum Rechnen jedoch reichen 32 Bit (om Register), dafür brauchts keine 64-Bit-Architektur.

Hotti

[dedlfix]

Tach!

Stichwort: Register

Stichwort: Unverständlichkeit

... dessen was du damit aussagen wilst.

Ein solches ist mit jeweils 32 Bit für Tag/Sekunde schon recht großzügig dimensioniert ;)

Ja, ja, ja. Warum führen wir dann überhaupt die Diskussion um 64 Bit? Sicherlich kann man mit viel weniger Speicher, dafür aber mit deutlich mehr Aufwand als einer simplen Sekundenzählung daselbe Ziel erreichen.

Für die Präsentation eines sekundengenauen Date-Time-Objekts brauchst Du mindestens 39 Bit, zum Rechnen jedoch reichen 32 Bit (om Register), dafür brauchts keine 64-Bit-Architektur.

Natürlich nicht, man kann das auch mit 8-Bit-Architekturen berechnen. Selbst die Turing-Maschine bekommt das hin ... Warum soll man da auch eine einfache Lösung nehmen, wenn es deutlich umständlicher auch geht? Wegen einer Handvoll gesparter Bits.

dedlfix.

[Matti Mäkitalo]

Hi,

Stichwort: Register

Stichwort: Unverständlichkeit

... dessen was du damit aussagen wilst.

scheint Rolfs neues Spiel zu sein. Ist mir zumindest in https://forum.selfhtml.org/?t=212537&m=1451897 schon aufgefallen. Einfach mal ein Wort reinwerfen ohne weitere Erklärung.

Bis die Tage,
Matti

[Matze]

Hallo!

scheint Rolfs neues Spiel zu sein. Ist mir zumindest in https://forum.selfhtml.org/?t=212537&m=1451897 schon aufgefallen. Einfach mal ein Wort reinwerfen ohne weitere Erklärung.

Spielt ihr hier alle gegen einen oder sind diese Seitenhiebe neuerdings gepflegter Teil der Forumskultur?

Grüße, Matze

[dedlfix]

Tach!

Spielt ihr hier alle gegen einen oder sind diese Seitenhiebe neuerdings gepflegter Teil der Forumskultur?

Schon wieder Extremismus und Gleichmacherei. So will ich nicht diskutieren.

Und nein, ich würde gern mit Rolf diskutieren, aber sein Diskussionstil und seine fachlichen Ansichten lassen das nicht zu. Ich habe auch nicht immer die Kraft, jede seine Aussagen nur rein fachlich zu korrigieren, zumal das um so aufwendiger ist, je falscher er mal wieder liegt oder sich ausdrückt.

dedlfix.

[Matze]

So will ich nicht diskutieren.

Soweit ich das beurteilen kann, wird keiner dazu gezwungen.

Und nein, ich würde gern mit Rolf diskutieren, aber sein Diskussionstil und seine fachlichen Ansichten lassen das nicht zu. Ich habe auch nicht immer die Kraft, jede seine Aussagen nur rein fachlich zu korrigieren, zumal das um so aufwendiger ist, je falscher er mal wieder liegt oder sich ausdrückt.

Das mag gut sein und ich will weder irgend jemanden in Schutz nehmen (das können wohl alle hier selbst) noch für oder gegen irgendwelche solche posts argumentieren. Nur frage ich mich ob es dem allgemeinen Frieden nicht dienlicher ist, wenn man manchmal einfach gar nichts schreibt. Als Aussenstehenden verstören mich solche postings und lassen das Forum dadurch insgesamt nicht besonders "reif" erscheinen. Auch wenn es nur ein paar Ausnahmen sind. Man muss nicht alles kommentieren :)

Oder um wieder mal aus der Charta zu zitieren...
´´Schreib keine Postings, deren einziges Ziel ist, Streit im Forum zu schüren.[..]``

Grüße, Matze

[Siri]

Hallo,

Oder um wieder mal aus der Charta zu zitieren...
´´Schreib keine Postings, deren einziges Ziel ist, Streit im Forum zu schüren.[..]``

Den Eindruck hatte ich ganz und gar nicht! Da geht's echt nicht um Böses Blut. Stell dir vor, dein Nachbar erzählt dir immer wieder die Erde ist eine Scheibe und argumentiert auch noch. Irgendwann wird's dir zu blöd, dann musst du dir das nicht mehr anhören. Wenn er aber versucht, das deinen Kindern weiß zu machen, dann kannst du ja schon auch mal aus der Haut fahren, oder?

Für mich ist's hilfreich, dass jemand fachlich gegen Unsinn anschreibt und argumentiert, wenn der Unsinn für mich nicht offensichtlich ist. Außerdem kannst du ja in der Forumssuche mal nach hotti "googeln" und dir ein paar Diskussionen mit ihm durchlesen.

Viele Grüße
Siri

[dedlfix]

Tach!

Nur frage ich mich ob es dem allgemeinen Frieden nicht dienlicher ist, wenn man manchmal einfach gar nichts schreibt.

Das ist auch kein Allheilmittel. Ich denke nicht, dass es dem Forum insgesamt besser tut, fachliche Fehler oder Verbesserungswürdigkeiten unkommentiert zu lassen, allein des Friedens willens.

Als Aussenstehenden verstören mich solche postings und lassen das Forum dadurch insgesamt nicht besonders "reif" erscheinen.

Ja, das kann ich gut verstehen. Aber wann ist "ein Forum", das doch aus einer Vielzahl so unterschiedlicher Individuen besteht als reif zu bezeichnen? Eine Friede-Freude-Eierkuchengesellschaft ist weder gesamtgesellschaftlich noch hier im Kleinen im Forum erreichbar.

Als ich jedenfalls hier neu war, gab es einen noch weitaus schlimmeren Störenfried. Rolf provoziert meist unwillentlich (das unterstell ich ihm mal) aufgrund fachlicher Mängel Streitgespräche. Diese andere Person provozierte jedoch willentlich mit ihrem Verhalten die Teilnehmer des Forums. Am Anfang war ich auch auf seiner Seite und empfand es ungerecht, dass so viele gegen ihn antraten, bis ich mitbekam, dass er "auf der falschen Seite" stand. Da trotz mehrfacher Warnungen keine gütliche Einigung möglich war, führte das irgendwann zum Platzverweis. Nunja, soweit ist es bei Rolf noch lange nicht, und ich sehe auch nicht, dass das auch nur annähernd in die Richtung geht.

Auch wenn es nur ein paar Ausnahmen sind. Man muss nicht alles kommentieren :)

Sicher nicht. Und man muss auch nicht alles durchgehen lassen. Zwischen diesen beiden Extremen liegt irgendwo die "Wahrheit".

Oder um wieder mal aus der Charta zu zitieren...
´´Schreib keine Postings, deren einziges Ziel ist, Streit im Forum zu schüren.[..]``

Das ist nicht mein Ziel. Die Charta verbietet aber auch keine Versuche, fachliche Korrekturen anzubringen.

dedlfix.

[Der Martin]

Hallo,

Als ich jedenfalls hier neu war, gab es einen noch weitaus schlimmeren Störenfried.

oh ja, ich erinnere mich noch gut an ihn. Das Gemeine an seiner Masche war, dass er rhetorisch sehr geschickt und oft durchaus schlüssig argumentiert hat, bis man schließlich merkte, dass er einen nur aus der Reserve locken wollte.

Da trotz mehrfacher Warnungen keine gütliche Einigung möglich war, führte das irgendwann zum Platzverweis.

Und trotzdem kommt immer wieder der Verdacht auf, dass diese Person unter ganz verschiedenen Namen fleißig weiter stänkert. Dagegen können wir aber leider nichts Wirksames unternehmen.

´´Schreib keine Postings, deren einziges Ziel ist, Streit im Forum zu schüren.[..]``
Das ist nicht mein Ziel. Die Charta verbietet aber auch keine Versuche, fachliche Korrekturen anzubringen.

Eben. Und manchmal sind die dringend angebracht.

Ciao,
 Martin

[Matze]

Das ist nicht mein Ziel. Die Charta verbietet aber auch keine Versuche, fachliche Korrekturen anzubringen.

Es ging mir auch nicht um dich sondern in die posts von Mudgard und Matti Mäkitalo.

Dass der OP nicht genau weiß was er tut, zeigt sich mir schon darin, dass er (in dem Fall; andere kann ich nicht beurteilen) als Fragender postet. Mir erschliest sich beim besten Willen nicht wieso man das noch extra hervorheben muss ohne, dass etwas zum eigentlichen Thema beigesteuert wird.

Oder anders ausgedrückt, wenn jemand ein Problem hat/eine Frage stellt, ist es offensichtlich, dass er sich irgendwo verrannt hat oder nicht weiß was er tut. Es ist niemandem geholfen wenn derjenige dann wegen fachlich falschen Antworten aus anderen Bereichen diffamiert wird. Das kann und sollte man dann auch in den jeweiligen threads klären und nicht quer durch das Forum treten.

Das ist nur mein Eindruck den ich durch die 2 angesprochenen posts bekommen habe. Daher die Kritik. Ich war halt ein wenig irritiert.

Grüße, Matze

[Encoder]

Tatsächlich reichts jedoch, die Sekunden nur für einen Tag mitzunehmen, denn die wiederholen sich ;)

Dann müsste man konsequenterweise auch die Tage nur für ein Jahr angeben, die wiederholen sich ja auch. An der Logik stimmt was nicht ;-)

[T-Rex]

Reichen 128 Jahre nicht (vorraus gesetzt man hat keine historischen Daten aus dem 14 Jahrhundert?
In Wirtschaftskrisen ausgedrückt sind das immerhin 30 ! Und in Lothar Mathäus Freundinnen Verbrauch sind das 252 + x.

Gruß
der Zahlenkünstler
T-Rex

[ichbinich]

Hallo,

Und in Lothar Mathäus Freundinnen Verbrauch sind das 252 + x.

ich glaube der steigt exponentiell...

vg ichbinich

[hotti]

hi ;)

Hab nun eine PHP-Klasse 'Date' für 32-Bit-Rechner erstellt, hier ist eine kleine Anwendung.

Sofern Operationen (Differenzen und Summen, Tage addieren) im Sekundenbereich erforderlich sind, dafür gibt es eine von Class 'Date' abgeleitete Klasse 'Date_Time' (ebenfalls 32 Bit).

Vorbestellung möglich, bei Bedarf bei mir melden ;)

Schöne Grüße!

[Sven Rautenberg]

Moin!

hi ;)

Hab nun eine PHP-Klasse 'Date' für 32-Bit-Rechner erstellt, hier ist eine kleine Anwendung.

Sofern Operationen (Differenzen und Summen, Tage addieren) im Sekundenbereich erforderlich sind, dafür gibt es eine von Class 'Date' abgeleitete Klasse 'Date_Time' (ebenfalls 32 Bit).

Warum?

Hast du dir die in PHP integrierte Klasse "DateTime" angeschaut und für unzureichend bewertet? Die unterstützt auch auf 32-Bit-Systemen 64-Bit-Sekunden-Timestamps.

Welche Operationen sind mit dem von PHP gelieferten Klassen denn nicht möglich?

- Sven Rautenberg

[hotti]

hi ;)

Hab nun eine PHP-Klasse 'Date' für 32-Bit-Rechner erstellt, hier ist eine kleine Anwendung.

Sofern Operationen (Differenzen und Summen, Tage addieren) im Sekundenbereich erforderlich sind, dafür gibt es eine von Class 'Date' abgeleitete Klasse 'Date_Time' (ebenfalls 32 Bit).

Warum?

Guck mal durch den Thread, da steht meine Antwort.

DateTime: Es gibt Abhängigkeiten, z.B.

cite:  Hinweis: Beachten Sie bitte, dass diese Funktionen von den lokalen Systemeinstellungen Ihres Servers abhängen. Ein besonderes Augenmerk sollten Sie auf Sommer- und Winterzeit (nutzen Sie z.B. $date = strtotime('+7 days', $date) und nicht $date += 7*24*60*60) und Schaltjahre haben.

Meine Klasse ist vom System unabhängig, auch das Berechnen der DST.

Welche Operationen sind mit dem von PHP gelieferten Klassen denn nicht möglich?

Keine Frage, die können sicher mehr als meine eigens entwickelten Klassen. Was ich da jedoch vermisse, ist die Kalenderwoche, für meine Klasse gibts das ;)

Hotti

[MudGuard]

Hi,

Keine Frage, die können sicher mehr als meine eigens entwickelten Klassen. Was ich da jedoch vermisse, ist die Kalenderwoche, für meine Klasse gibts das ;)

Wer lesen kann ...

DateTime::format("W")

cu,
Andreas

[hotti]

hi,

Keine Frage, die können sicher mehr als meine eigens entwickelten Klassen. Was ich da jedoch vermisse, ist die Kalenderwoche, für meine Klasse gibts das ;)

Wer lesen kann ...

DateTime::format("W")

OK ;)

Aber nochmal: In Datumsberechnungen die Sekunden mitzuschleifen ist Quatsch. Eine Sekundengenauigkeit (falls erforderlich, z.B. RFC-gerechte Datum-Angaben) würde ich auf Zeiträume beschränken, in denen Datierungen zuverlässig sind und da baue ich selbstverständlich auf konfektionierte Klassen.

Bezüglich Kalenderprogrammierung habe ich seit Jahren(!) ein anderes und auch bewährtes Konzept:
Subklassen für das was jeweils gebraucht wird. Z.B. eine Subklasse 'Maya' wofür in meiner Basisklasse die Umrechnung von Gregorianisch zu Julianisch u. umgekehrt bereits eingebaut ist, weil das ohnehin erforderlich ist, wenn in großen Zeiträumen operiert werden soll und da wird nur mit Tagen gerechnet.

Datum ist Datum, Zeit ist Zeit, Dienst ist Dienst und Schnaps ist Schnaps.

Hotti

[JürgenB]

Hallo Rolf,

wohin soll denn deine Reduktion auf 32bit führen? Ich habe vor über 20 Jahren mal versucht, eine Numerik durch Umstellung von 64bit (double precision) auf 32bit (single precision) zu beschleunigen. Danach war das Programm ein paar Prozent langsamer! Grund: meine Hardware konnte keine 32bit-Arithmetik mehr und musste ständig konvertieren. Also, was ist dein Ziel?

Gruß, Jürgen

[Der Martin]

Hallo,

wohin soll denn deine Reduktion auf 32bit führen?

das ist eine sehr gute Frage. Aber Rolf hat öfter mal so eigenartige Ideen, die er dann auch verbissen umsetzt - auch wenn sich einige Leute fragen, wozu das gut sein soll.

Ich habe vor über 20 Jahren mal versucht, eine Numerik durch Umstellung von 64bit (double precision) auf 32bit (single precision) zu beschleunigen. Danach war das Programm ein paar Prozent langsamer! Grund: meine Hardware konnte keine 32bit-Arithmetik mehr und musste ständig konvertieren.

Ja, seitdem FPUs hardwaremäßig vorhanden sind und nicht mehr emuliert werden müssen, also spätestens ab der ersten Pentium-Generation[*], bringen "kleine" Fließkommaformate keinen Vorteil mehr, von ein paar Bytes Speichereinsparung abgesehen.
In Prä-486-Zeiten, als FPUs meistens noch in Software emuliert wurden, sah das anders aus.

Ciao,
 Martin

[*] AFAIR gab es abseits der Intel-Linie (z.B. von Cyrix) auch während und nach der Pentium-Ära noch x86-kompatible Low-Cost-CPUs ohne integrierte FPU. Aber mittlerweile ist das wirklich Geschichte.

[MudGuard]

Hi,

wohin soll denn deine Reduktion auf 32bit führen?

Er spart ein paar Bytes pro Date-Objekt - verbrät aber erstmal viele Bytes dafür, daß seine Klasse geladen werden muß.

cu,
Andreas

[JürgenB]

Hallo Martin,

In Prä-486-Zeiten,

"mein" 32bit-Rechner mit 64bit Coprozessor war aus 1983 und belegte ein ganzes 19"-Rack. Wir haben ihn dann nach einem Defekt durch einen 386er mit Coprozessor ersetzt. Das war billiger als die Reparatur.

Gruß, Jürgen

[Der Martin]

Hi Jürgen,

In Prä-486-Zeiten,
"mein" 32bit-Rechner mit 64bit Coprozessor war aus 1983 und belegte ein ganzes 19"-Rack.

das war dann aber noch nicht die legendäre x86-Architektur, oder? AFAIK ist die erst mit dem 386er in die 32bit-Region vorgedrungen.

Wir haben ihn dann nach einem Defekt durch einen 386er mit Coprozessor ersetzt. Das war billiger als die Reparatur.

Das muss wohl Anfang der 90er Jahre gewesen sein. Ich erinnere mich, dass ich 1991 meinen ersten PC gekauft habe (bis dahin tat ein C64 gute Dienste), und da fiel mir die Entscheidung nicht leicht. Die 386er-Generation war verlockend, aber die Geräte für den Privatanwender noch sündhaft teuer. Am Ende wurde es dann doch eine 286er-Maschine, aber immerhin mit 16MHz anstatt der üblichen 12MHz, und mit einem ganzen MB RAM anstatt der immer noch weit verbreiteten 640kB. Und -man staune- mit einer riesigen 40MB-Festplatte! ;-)

Numerische Coprozessoren gab es bei Intel übrigens schon viel früher, auch wenn das Gespann 8086+8087 (oder auch 8088+8087) vermutlich eher selten war.

Ciao,
 Martin

[JürgenB]

Hallo Martin,

Hi Jürgen,

In Prä-486-Zeiten,
"mein" 32bit-Rechner mit 64bit Coprozessor war aus 1983 und belegte ein ganzes 19"-Rack.

das war dann aber noch nicht die legendäre x86-Architektur, oder? AFAIK ist die erst mit dem 386er in die 32bit-Region vorgedrungen.

nein. Das war ein diskret aufgebauter Rechner, auf Platinen groß wie Backbleche. Die 2 MB belegten alleine zwei davon, der Coprozessor ebenfalls. Ich habe nie wieder so viele 74er-Chips auf einem Haufen gesehen :). Die Klasse nannte sich damals Minicomputer und lag zwischen Workstation und Mainframe. Das Segment wurde dann Anfang der 90er durch leistungsstarke Workstations und später durch PCs übernommen.

Gruß, Jürgen

[hotti]

hi Jürgen,

wohin soll denn deine Reduktion auf 32bit führen? Ich habe vor über 20 Jahren mal versucht, eine Numerik durch Umstellung von 64bit (double precision) auf 32bit (single precision) zu beschleunigen. Danach war das Programm ein paar Prozent langsamer! Grund: meine Hardware konnte keine 32bit-Arithmetik mehr und musste ständig konvertieren. Also, was ist dein Ziel?

64 Bit <= meine Güte!
Sekundengenauigkeit für die Kalenderwoche, meine Güte!

Mein Ziel ist es, klare Verhältnisse mit flachen Klassenhierarchien in einer sinnvollen sowie übersichtlichen Codeverteilung zu haben. 64 Bit Rechengenauigkeit sind für Datumsberechnungen einfach nur lächerlich und DateTime passt nicht zu diesem Ziel.

Einer der Wege zu diesem/meinem Ziel habe ich heute beschritten und die Fehlerbehandlung für class 'Date' komplett überarbeitet, sowie die Methoden daysadd() und datediff() hinzugefügt.

Class 'Date' kann sich sehen lassen, auch wenn es keine eigene Exception-Class benutzt, sondern nur die SPL.

Viele Grüße,
Rolf

[JürgenB]

Hallo hotti,

... 64 Bit Rechengenauigkeit sind für Datumsberechnungen einfach nur lächerlich ...

und welcher Rechner rechnet deiner Meinung nach noch mit weniger als 64bit?

Gruß, Jürgen

[dedlfix]

Tach!

64 Bit Rechengenauigkeit sind für Datumsberechnungen einfach nur lächerlich und DateTime passt nicht zu diesem Ziel.

Die Differenz in Sekunden zu einem bestimmten Referenzzeitpunkt ist sicher nicht die beste Art, eine Zeitpunkt zu beschreiben. Aber es ist ein einfaches Prinzip und die Erweiterung auf 64 Bit naheliegend und vor allem kompatibel zum bisherigen Speicherformat. Warum also sollte man mit hohem Aufwand Bits sparen wollen und am Ende noch inkompatibel zu werden, mit dem entsprechenden Folgeaufwand um diese Inkomapatibilität auszugleichen?

Du kannst dir ja gern einen neue Umrechnungsklasse schreiben, wenn dir die Kalenderfunktionen nicht zusagen, aber ein neues Speicherformat dabei zu erfinden ist den Aufwand garantiert nicht wert.

dedlfix.

[Matti Mäkitalo]

Hi,

DateTime: Es gibt Abhängigkeiten, z.B.

cite:  Hinweis: Beachten Sie bitte, dass diese Funktionen von den lokalen Systemeinstellungen Ihres Servers abhängen. Ein besonderes Augenmerk sollten Sie auf Sommer- und Winterzeit (nutzen Sie z.B. $date = strtotime('+7 days', $date) und nicht $date += 7*24*60*60) und Schaltjahre haben.

das wurde an der Stelle einfach nur extrem schlecht übersetzt. Das englische Manual sagt an der gleichen Stelle:
"Please keep in mind that these functions are dependent on the locale settings of your server."

locale setting sind nicht die lokalen Einstellungen, sondern die Einstellung der Lokalität (localization). Wenn du einen DateTime-Konstruktor ohne Timezone-Argument nutzt, wird die lokale Zeitzone (eben diejenige des Servers) benutzt.

Das ist auch vollkommen verständlich: irgendeine muss ja benutzt werden, und es ist naheliegend, diejenige zu nutzen, in der der Server steht.

Der zweite von dir zitierte Satz sollte in jeder anständigen DateTime-Implementierung selbstverständlich sein. Eine Woche ist (dank Zeitumstellung/Schaltsekunden) eben nicht 7*24*60*60 Sekunden, sondern eben 7 Tage.

Bis die Tage,
Matti

[hotti]

hi,

Der zweite von dir zitierte Satz sollte in jeder anständigen DateTime-Implementierung selbstverständlich sein. Eine Woche ist (dank Zeitumstellung/Schaltsekunden) eben nicht 7*24*60*60 Sekunden, sondern eben 7 Tage.

Guck Dir mal die ISO-8601 (ehem. DIN1355) an, wie die Kalenderwoche definiert ist. Da wirst Du sehen, dass eine KW vom letzten Jahr in das neue Jahr fallen kann oder eine KW des neuen Jahres im alten Jahr beginnen kann. Ergo ist zusammen mit der KW _immer_ das Jahr mit anzugeben.

Und überhaupt: Scaliger-Tag ist nicht Julianischer Tag (auch wenn ich das manchmal so nenne), die Handhabe beim Rechnen mit aufeinanderfolgenden Tagen in der Scaliger-Epoche (ein anderer Rechenweg als der von JJ Scaliger ist mir nicht bekannt) erfordert es, stets mit beiden Kalendern, dem Julianischen und dem Gregorianischen K. nebeneinander zu operieren, sonst gibt es keine _aufeinanderfolgenden_ Tage.

Alle Kalender-Implementierungen, die mir bis heute untergekommen sind (in c, PHP, Perl), berücksichtigen diesen Sachverhalt nicht und auch nicht mit 64 Bit.

Hotti

[Matti Mäkitalo]

Hi,

Der zweite von dir zitierte Satz sollte in jeder anständigen DateTime-Implementierung selbstverständlich sein. Eine Woche ist (dank Zeitumstellung/Schaltsekunden) eben nicht 7*24*60*60 Sekunden, sondern eben 7 Tage.

Guck Dir mal die ISO-8601 (ehem. DIN1355) an, wie die Kalenderwoche definiert ist. Da wirst Du sehen, dass eine KW vom letzten Jahr in das neue Jahr fallen kann oder eine KW des neuen Jahres im alten Jahr beginnen kann. Ergo ist zusammen mit der KW _immer_ das Jahr mit anzugeben.

Die Berechnung, zu welcher Kalenderwoche ein Tag gehört (das ist, wovon du sprichst) hat doch wenig damit zu tun, wie lange eine Woche in Sekunden ist (das ist, wovon ich schreibe).

Anders gefragt: MudGuard hat dir gezeigt, dass man Kalenderwochen auch mit dem eingebauten DateTime berechnen kann. Im Vergleich deiner Klasse und der Standardklasse: hast du Unterschiede feststellen können? (Lass es doch z.B. mal über die letzten 500 Jahre iterieren und vergleiche die Ergebnisse). Wenn ja: liegt ein Fehler in der Standardklasse vor?

Du schreibst deine Klasse, weil du Speicher sparen willst(?): hast du durch irgendwelche Benchmarks Verbesserungen messen können?

Bis die Tage,
Matti

[hotti]

hi,

Du schreibst deine Klasse, weil du Speicher sparen willst(?)

Nein, ich schreibe eine Klasse die besser in mein Konzept passt, als Basisklasse 'Date' wo nur mit Tagen gerechnet wird, weil die kleinste Einheit für Datumsberechnungen der Tag ist und nicht die Sekunde und weil mein Konzept im Weiteren vorsieht, für Sekundenschärfe eine Subklasse zu bilden, wobei andere Subklassen zur jeweiligen Aufgabenstellung passen, wie z.B. Date_Maya, Date_Format, Date_HMS usw.

Meine PHP Basisklasse hat z.Z. 320 Zeilen Code und deckt die Scaliger-Epoche 1.1.4713 BC bis 22.1.3268 ab mit fortlaufend numerierten Tagen. Implementiert die Berechnung des numerischen Wochentages von 1-7, die Kalenderwoche nach DIN1355 (ISO/R 2015-1971) (deutsch), stellt fest, ob das Jahr ein Schaltjahr ist (auch die negativen Jahre) und bestimmt die Epoche (Julian/Gregorian) automatisch anhand des dem Konstruktor mitgegebenen Datums oder Julianischen Tages.

Von Perl nach PHP umsetzen muss ich noch die Möglichkeit der Vorgabe ob J oder G, das ist in Hinblick auf die Maya-Anbindung zwingend erforderlich, weil in den Fachbüchern der Hieroglyphenforscher sowohl der J.K. (Old Style) als auch der G.K. (new Style) Verwendung findet und das außerhalb von Europa und das heißt, dass die Gregorianische Reform eben nicht überall zur gleichen Zeit umgesetzt wurde.

Meine Basisklasse deckt allen möglichen, dem Konstruktor übergebenen Mist ab mit einer gezielt geworfenen Exception, Exception deshalb, weil es nicht mehr möglich ist, die Vielfalt der möglichen Eingabefehler über herkömmliche Kontrollstrukturen abzuwicklen. In das Basismodul kommt noch rein die Kalkulation der DST, auch hierzu wird nur mit ganzen Tagen gerechnet (sind nur ein paar Zeilen Code, mache ich morgen, danke der Nachfrage).

Ob die PHP-Lib fehlerhaft ist oder nicht, kann ich insgesamt nicht beurteilen, ich habe auch gar keine Zeit, da gezielt nach Fehlern zu suchen und offen gestanden auch keine Lust. Datumsberechnungen sind ein sehr komplexes Thema, ich habe Respekt vor Jedem Programmierer, der solche Herausforderungen annimmt.

Der Einbau der KW-Berechnung ist heute fertig geworden und funktioniert einwandfrei auf einem 32-Bit Rechner. Allerdings musste ich den Zeitraum einschränken, weil es die DIN1355, verglichen mit der Scaliger-Epoche, noch nicht allzulange gibt.

Schönes Wochenende,
danke für die Aufmerksamkeit!

[hotti]

hi,

Du schreibst deine Klasse, weil du Speicher sparen willst(?): hast du durch irgendwelche Benchmarks Verbesserungen messen können?

Bisher kein Benchmark. Aus Erfahrung heraus ist das Aufteilen in Subklassen jedoch CPU-freundlich, Beispiel:

  
	$date = new Date_Kirche(array('date' => array(  
		1,11,2013  
	)));  
  
	$kirchenjahr = $date->kirchenjahr();  
	ksort($kirchenjahr, SORT_NUMERIC);  
	foreach($kirchenjahr as $jd => $name){  
		$d = new Date(array('julianday' => $jd));  
		echo "$d $name\n";  
	}  

D.h., in der foreach wird das Objekt nicht über die Subklasse erstellt sondern über die 'kleinere' Basisklasse. Btw., ausgegeben werden die Feiertage des Kirchenjahres:

01.01.2013 Di 01/2013 Neujahr
06.01.2013 So 01/2013 Drei Königstag
07.02.2013 Do 06/2013 Weiberfastnacht
11.02.2013 Mo 07/2013 Rosenmontag
29.03.2013 Fr 13/2013 Karfreitag
31.03.2013 So 13/2013 Ostersonntag
01.04.2013 Mo 14/2013 Ostermontag
09.05.2013 Do 19/2013 Christi Himmelfahrt
19.05.2013 So 20/2013 Pfingstsonntag
20.05.2013 Mo 21/2013 Pfingstmontag
30.05.2013 Do 22/2013 Fronleichnam
15.08.2013 Do 33/2013 Maria Himmelfahrt
20.11.2013 Mi 47/2013 Buß- und Bettag
24.11.2013 So 47/2013 Totensonntag
01.12.2013 So 48/2013 Erster Advent
08.12.2013 So 49/2013 Zweiter Advent
15.12.2013 So 50/2013 Dritter Advent
22.12.2013 So 51/2013 Vierter Advent
24.12.2013 Di 52/2013 Heiligabend
25.12.2013 Mi 52/2013 Erster Weihnachtstag
26.12.2013 Do 52/2013 Zweiter Weihnachtstag

Und noch ein Blick hinter die Kulissen um die Arbeitsweise mal zu zeigen ;)

  
	// Array mit Scaligertagen und Namen der Feiertage  
	public function kirchenjahr(){  
		$jdo = $this->ostern();  
		$class = __CLASS__;  
		$meta = new $class (array('isa' => 'testobject', 'date' => array(15,8,$this->YEAR)));  
  
		$ft = array(  
			$jdo      => 'Ostersonntag',  
			$jdo + 1  => 'Ostermontag',  
			$jdo -2   => 'Karfreitag',  
			$jdo + 39 => 'Christi Himmelfahrt',  
			$jdo + 49 => 'Pfingstsonntag',  
			$jdo + 50 => 'Pfingstmontag',  
			$jdo + 60 => 'Fronleichnam',  
			$jdo - 48 => 'Rosenmontag',  
			$jdo - 52 => 'Weiberfastnacht',  
			$meta->JD => 'Maria Himmelfahrt',  
		);  
  
		// 1.1. Neujahr  
		$jd = $meta->EPOCH == 'G' ? $meta->jd_greg(1,1,$this->YEAR) : $meta->jd_juli(1,1,$this->YEAR);  
		$ft[$jd] = 'Neujahr';  
  
		// 6.1. Drei Könige  
		$ft[$jd+5] = 'Drei Königstag';  
  
		// 24.12. Heiligabend  
		$jd = $meta->EPOCH == 'G' ? $meta->jd_greg(24,12,$this->YEAR) : $meta->jd_juli(24,12,$this->YEAR);  
		$ft[$jd] = 'Heiligabend';  
		$ft[$jd+1] = 'Erster Weihnachtstag';  
		$ft[$jd+2] = 'Zweiter Weihnachtstag';  
  
		// Der erste Advent ist der Sonntag zwischen dem 27.11. und dem 03.12.  
		// Der erste Advent ist der erste Sonntag nach dem 26.11.  
		// Der vierte Advend ist der letzte Sonntag vor dem 25.12.  
		// Ergo, Rechenweg: Bestimme JD für 26.11. und den numerischen Wochentag  
		$jd2611 = $meta->EPOCH == 'G' ? $meta->jd_greg(26,11,$this->YEAR) : $meta->jd_juli(26,11,$this->YEAR);  
		$wochentag2611 = (1 + ($jd2611 % 7));  
		$advent1 = $jd2611 + 7 - $wochentag2611;  
		// fällt dieser Tag auf den 27.11. oder davor, ist der 1. Advent eine Woche später  
		if($advent1 <= ($jd2611 + 1)) $advent1 += 7;  
		$ft[$advent1]      = 'Erster Advent';  
		$ft[$advent1 + 7]  = 'Zweiter Advent';  
		$ft[$advent1 + 14] = 'Dritter Advent';  
		$ft[$advent1 + 21] = 'Vierter Advent';  
		$ft[$advent1 - 7]  = 'Totensonntag';  
		$ft[$advent1 - 11] = 'Buß- und Bettag';  
		return $ft;  
	}  

Schönes Wochenende!

[MudGuard]

Hi,

Btw., ausgegeben werden die Feiertage des Kirchenjahres:

01.01.2013 Di 01/2013 Neujahr
06.01.2013 So 01/2013 Drei Königstag

Das Ende der Weihnachtszeit fehlt: Mariä Lichtmeß.

07.02.2013 Do 06/2013 Weiberfastnacht

sehr kirchlich ...

11.02.2013 Mo 07/2013 Rosenmontag

auch sehr kirchlich ...

der wirklich kirchliche Feiertag Aschermittwoch (Beginn der Fastenzeit vor Ostern) fehlt.

29.03.2013 Fr 13/2013 Karfreitag
31.03.2013 So 13/2013 Ostersonntag
01.04.2013 Mo 14/2013 Ostermontag
09.05.2013 Do 19/2013 Christi Himmelfahrt
19.05.2013 So 20/2013 Pfingstsonntag
20.05.2013 Mo 21/2013 Pfingstmontag
30.05.2013 Do 22/2013 Fronleichnam
15.08.2013 Do 33/2013 Maria Himmelfahrt

Mariä Himmelfahrt.

20.11.2013 Mi 47/2013 Buß- und Bettag
24.11.2013 So 47/2013 Totensonntag

Der Reformationstag fehlt.
Allerheiligen fehlt.

01.12.2013 So 48/2013 Erster Advent
08.12.2013 So 49/2013 Zweiter Advent

Mariä Empfängnis fehlt. *)

15.12.2013 So 50/2013 Dritter Advent
22.12.2013 So 51/2013 Vierter Advent
24.12.2013 Di 52/2013 Heiligabend
25.12.2013 Mi 52/2013 Erster Weihnachtstag
26.12.2013 Do 52/2013 Zweiter Weihnachtstag

*) War Marias Schwangerschaft extrem kurz? Oder extrem lang? Von der Empfängnis bis zur Geburt war's entweder nur ein halber Monat oder aber es waren 12,5 Monate ...

cu,
Andreas

[hotti]

hi,

der wirklich kirchliche Feiertag Aschermittwoch (Beginn der Fastenzeit vor Ostern) fehlt.

Ok, danke, ja es fehlen noch ein paar... kein Problem, die noch einzubauen, aber das Wichtigste wäre geschafft, das ist die Oster- und Adventberechnung (da war auch noch ein Fehler, ist aber beseitigt), danach richtet sich alles.

Ich bin bereits am Überlegen, wie eine einfach zu konfigurierende API für benutzerdefinierte Feiertage aussehen könnte, am besten wäre eine Text-Datei, die zusammen mit der Klasse geladen wird. Da steht dann drin z.B. 'jeden letzten Sonntag im Main' oder 'jeden 13. August' oder sowas Ähnliches und dann sicher auch, wie die Marie mit richtigem Namen beißt und für die Tippfehler sind dann die Anderen zustendig ;)

Hotti

[hotti]

hast Du Lust, die englische Version 'Date_Kirche_en.php' zu schreiben, ist nur eine Methode, sind nur ein paar Zeilen, lass es mich wissen ;)

  
final class Date_Kirche_en extends Date_Kirche{  
  private function kirchenjahr(){}  
}  

[MudGuard]

Hi,

hast Du Lust, die englische Version 'Date_Kirche_en.php' zu schreiben, ist nur eine Methode, sind nur ein paar Zeilen, lass es mich wissen ;)

Nö, dazu müßte ich mich mit der anglikanischen Kirche auskennen - und ich hab keine Lust, mich da einzulesen.

Und die ganzen amerikanischen, australischen, neuseeländischen, ... Kirchen kenn ich auch nicht.

cu,
Andreas

[hotti]

Hi,

hast Du Lust, die englische Version 'Date_Kirche_en.php' zu schreiben, ist nur eine Methode, sind nur ein paar Zeilen, lass es mich wissen ;)

Nö, dazu müßte ich mich mit der anglikanischen Kirche auskennen - und ich hab keine Lust, mich da einzulesen.

Ich auch keine Lust, deswegen gefragt ;)

Aber Deine Hinweise habe ich heute dankbar umgesetzt, guckst Du hier...

Kalender haben mich schon immer fasziniert, es ist irgendwie eine Verbindung zum Kosmos und somit ist jeder Kalender ein verzweifelter Versuch der Menschheit, natürliche Vorgänge auf menschliche Vorgänge abzubilden und scheitert schon daran, dass es zwischen dem siderischen Jahr und einem Erdentag keinen ganzzahligen Zusammenhang gibt. Die Maya wussten das und haben die Tage einfach nur gezählt...

Hotti

[hotti]

Aber Deine Hinweise habe ich heute dankbar umgesetzt,

guckst Du hier...

Mist, die Gauss'sche Osterformel geht erst ab 1583 richtig ;)

[Jens Holzkämper]

Tach,

Aber Deine Hinweise habe ich heute dankbar umgesetzt,
guckst Du hier...

Mist, die Gauss'sche Osterformel geht erst ab 1583 richtig ;)

äh nö an der Formel liegt es nicht, höchstens an der Implementation: https://de.wikipedia.org/wiki/Gaußsche_Osterformel#G.C3.BCltigkeit.

mfg
Woodfighter

[Christian Kruse]

Moin MudGuard,

*) War Marias Schwangerschaft extrem kurz? Oder extrem lang? Von der Empfängnis bis zur Geburt war's entweder nur ein halber Monat oder aber es waren 12,5 Monate ...

Unser Religions-Lehrer damals in der Schule meinte dazu, dass die Kirche irgendwann mal die Feiertage ausgerichtet an Ostern und Weihnachten ziemlich willkürlich verteilt hat, damit alle Feiertage halbwegs gleichmässig über das Jahr verteilt sind.

LG,
 CK

[Der Martin]

Hallo,

*) War Marias Schwangerschaft extrem kurz? Oder extrem lang? Von der Empfängnis bis zur Geburt war's entweder nur ein halber Monat oder aber es waren 12,5 Monate ...

ach, die hat sich damals mächtig beeilt. Bei 12 Monaten wär's ja ein Esel geworden. ;-)

Unser Religions-Lehrer damals in der Schule meinte dazu, dass die Kirche irgendwann mal die Feiertage ausgerichtet an Ostern und Weihnachten ziemlich willkürlich verteilt hat, damit alle Feiertage halbwegs gleichmässig über das Jahr verteilt sind.

Das ist dann aber nicht besonders gut gelungen, wenn ich mir die Häufung der Feiertage im Frühjahr und dann die "Durststrecke" vom Sommeranfang bis Reformationstag bzw. Allerheiligen so ansehe, zumal Mariä Himmelfahrt AFAIK nur in überwiegend katholischen Gegenden als Feiertag gilt.

So long,
 Martin

[Christian Kruse]

Moin Martin,

Unser Religions-Lehrer damals in der Schule meinte dazu, dass die Kirche irgendwann mal die Feiertage ausgerichtet an Ostern und Weihnachten ziemlich willkürlich verteilt hat, damit alle Feiertage halbwegs gleichmässig über das Jahr verteilt sind.

Das ist dann aber nicht besonders gut gelungen, wenn ich mir die Häufung der Feiertage im Frühjahr und dann die "Durststrecke" vom Sommeranfang bis Reformationstag bzw. Allerheiligen so ansehe, zumal Mariä Himmelfahrt AFAIK nur in überwiegend katholischen Gegenden als Feiertag gilt.

Ich hab mich nie darum gekümmert, obs auch tatsächlich stimmt. Religion ist mir weitestgehend egal.

LG,
 CK