Horst: Die Gregorianische Kalender-Reform richtig verstehen

Beitrag lesen

Hi Martin,

Programmieren macht Spaß :-)
Ich hab sogar das mit den Pointern und structs verstanden ;-)

ist ja auch nicht wirklich schwierig. Aber viele tun sich einfach schwer mit der Vorstellung dessen, was "da drinnen" wirklich passiert.

Hmm, ich glaube, dass ich in Pointern denken kann. Jahrelang habe ich in Perl programmiert und sehe jetzt, wo ich seit Ostern mein c wieder auffrische: Zwischen Perl und c liegen Welten. Von c nach Perl umzudenken ist einfach, aber umgekehrt ist es nicht. c ist viel näher dran am System.

Stück für Stück kommt mein altes, mir seit 1995 angedichtetes Verständnis für c wieder.

Oh. Ich habe während des Studiums so um 1990/91 C gelernt, habe es zunächst gehasst und viele Aspekte noch nicht verstanden (Pascal gefiel mir viel besser); erst rund zwei Jahre später habe ich so langsam begriffen, wie mächtig C ist (vor allem, wenn man es hier und da mit ein wenig Assembler aufpeppen kann) und es fing an, mich zu begeistern.
Seither hat mich keine Programmiersprache mehr so sehr angesprochen wie C, wenn man mal von spezialisierten Sprachen mit eingeschränktem Anwendungsbereich absieht.

Mit Pascal habe ich auch mal angefangen und mit Delphi einen CD-Player geschrieben...

Zurück zur Kalenderberechnung: Es ist so, dass mit den richtigen Formeln jeder einzelne Tag von Tag 0 am 1.1. 4712 B.C. bis heute (Julianischer Tag 2454561) eindeutig bestimmbar ist.

Selbstverständlich. Die Astronomen dehnen die Julianische Tageszählung sogar in den Bereich negativer Tagesnummern aus. Um die Umrechnung in ein vor fast 7000 Jahren möglicherweise verwendetes Kalenderdatum braucht man sich wohl keine Gedanken zu machen. ;-)

Da lohnt es sich schonmal ein struct in c zu bauen, meins sieht so aus:
[...]

Tippfehler von mir: 4712 muss 4713 heißen. 4713 B.C. => -4713
Was davor lag ist tatsächlich schwer berechenbar und praktisch wahrscheinlich uninteressant.

Du hast da eine Menge Werte in der Struktur, von denen ich nie auf die Idee käme, dass man sie brauchen könnte und die ich deswegen nicht speichern würde. Außerdem würde ich auch die Textdarstellung von Wochentag, Monat oder des gesamten ausgeschriebenen Datums nicht speichern, sondern diese Werte erst bei der Ausgabe eines Datums generieren. Dann tut man sich auch leichter, sprachliche Unterschiede einzupflegen.

Du hast Recht, hab auch schon wieder einige Werte rausgeschmissen ;-)

Viel interessanter als die Datenstruktur ist aber die Implementierung der Umwandlung von "normalem" Gregorianischem Datum in das Julianische Datum (Tageszählung) und umgekehrt.

Beide Kalender stimmen überein im Zeitraum vom 1.3.200 - 28.2.300

Ich habe bei meinen Recherchen einige WebFrontends zu Kalenderberechnungen gesehen, auf denen der User aufgefordert ist, ob nach Julianischen oder Gregorianischen Kalender gerechnet werden soll.

Genau DAS hat mich auf die Idee gebracht, eine Lib zu schreiben, die automatisch erkennt, ob nach dem Julianischen oder Gregorianischen Kalender gerechnet werden muss.

Meine Lib nimmt automatisch
jeden Tag vor dem 4.10.1582
jeden JD kleiner 2299160
als Anlass, Julianisch zu rechnen, ansonsten Gregorianisch.

Die von Dir angesprochene Tageszählung beider Kalender kann ich mit meinen Formelchen natürlich auch berechnen, derzeit haben wir 13 Tage Differenz ;-)

Auf jeden Fall danke für den Tipp, das kommt noch hinein in mein struct:

int diff_julian_gregor;

Viele Grüße an Alle,
Julian äähhh, Rolf, ähhhh ach was soll der Name :)