Die Gregorianische Kalender-Reform richtig verstehen
Horst
- programmiertechnik
0 Der Martin
0 Horst0 Horst0 Der Martin
0 Horst
0 MudGuard
Hallo Mitstreiter,
in den letzten Tagen seit Ostern habe ich mich sehr intensiv mit Kalenderberechnungen befasst und bei Recherchen diese oder jene Formel zur Berechnung nach Julianischen Kalender und Gregorianischen Kalender gefunden.
Bisher dachte ich, dass unter Papst Gregor VIII einfach nur so auf den 4.10.1582 der 15.10.1582 folgte. Das ist formal schon richtig, aber schauen wir einmal genauer hin:
01.10.1582 Montag
02.10.1582 Dienstag
03.10.1582 Mittwoch
04.10.1582 Donnerstag
15.10.1582 Freitag
16.10.1582 Samstag
17.10.1582 Sonntag
Diese Erkenntnis führt zu wichtigen Schlussfolgerungen für Programmierer der Kalendertechnik im europäischen Raum:
Die Tage zwischen 4.10.1582 und 15.10.1582 sind ungültig.
Für Berechnungen:
Sofern Du diesen Regeln folgst, ist jeder Tag ab dem 1.1.-4713 (Julianischer Tag ist hier gleich 0) bis heute eindeutig adressierbar mit der Nummer des Julianischen Tages und dem Literal des Wochentages (Montag, Dienstag...).
Zurück zu Gregor VIII und seiner Reform: Bis 4.10. galt der Julianische Kalender und der 4.10. war ein Donnerstag!
Wer den Wochentag für den 4.10.1582 nach dem Gregorianischen Kalender ausrechnen sollte, kommt auf einen "Montag" und das ist falsch. Der Dreh- und Angelpunkt der Gregorianischen Kalenderreform ist der Wochentag, nicht das Datum.
Mit dem bisher Geasgtem kann der Wochentag (0 Sonntag, 1 Montag, usw.) wie folgt ganz einfach aus dem Julianischen Tag berechnet werden:
wochentag = 1 + (juliantag modulo 7);
wenn wochentag ist 7, setze ihn zurück auf 0
Programmieren macht Spaß :-)
Viele Grüße,
Hotte
Hallo,
Bisher dachte ich, dass unter Papst Gregor VIII einfach nur so auf den 4.10.1582 der 15.10.1582 folgte.
richtig, die Gregorianische Kalenderreform.
01.10.1582 Montag
02.10.1582 Dienstag
03.10.1582 Mittwoch
04.10.1582 Donnerstag
15.10.1582 Freitag
16.10.1582 Samstag
17.10.1582 Sonntag
Gut, und das Intervall vom 05. bis 14.10.1582 hat es nie gegeben.
- 4.10.1582 hat den Julianischen Tag 2299160
- 15.10.1582 hat den Julianischen Tag 2299161
- der 1.1.-4713 war ein Montag (Julianischer Tag == 0)
Bingo.
Für Berechnungen:
- Rechne Julianisch, wenn der Tag vor dem 4.10.1582 liegt oder mit diesem Tag gleich ist
- Rechne Gregorianisch, wenn der Tag nach dem 4.10.1582 liegt.
Noch besser: Rechne *immer* mit dem Julianischen Datum, also der fortlaufenden Tageszählung seit 4713 BC. Das tun die Astronomen schon immer, und es hat sich bewährt.
Es spricht nichts dagegen, auch heutige Zeitangaben als Julianisches Datum auszudrücken - im Gegenteil, damit wird die Berechnung von Zeitabständen zum Kinderspiel, eine einfache Subtraktion genügt.
Sofern Du diesen Regeln folgst, ist jeder Tag ab dem 1.1.-4713 (Julianischer Tag ist hier gleich 0) bis heute eindeutig adressierbar mit der Nummer des Julianischen Tages und dem Literal des Wochentages (Montag, Dienstag...).
Sag ich doch. ;-)
Der Dreh- und Angelpunkt der Gregorianischen Kalenderreform ist der Wochentag, nicht das Datum.
Das ist falsch.
wochentag = 1 + (juliantag modulo 7);
wenn wochentag ist 7, setze ihn zurück auf 0
Um die Fallunterscheidung zu vermeiden, kann man das vereinfachen:
wochentag = (juliantag+1 modulo 7);
Programmieren macht Spaß :-)
Full ACK.
Erst recht, wenn man die Zusammenhänge begreift.
Schönen Abend noch,
Martin
Hallo,
Der Dreh- und Angelpunkt der Gregorianischen Kalenderreform ist der Wochentag, nicht das Datum.
Das ist falsch.
Zumindest ist das für _mein_ Verständnis richtig, weil:
ich dachte bis heute, dass der 4.10.1582 ein Montag war. Indes: der 4.10.1582 war ein Donnerstag, definitiv.
Es würde ja auch von der Logik her keinen Sinn machen, auf einen Montag den Freitag folgen zu lassen. Was eher geht (für mein Verständnis), ist, dem Donnerstag einen Freitag folgen zu lassen, diesem jedoch ein anderes Datum zu geben. Und so wird es auch gelaufen sein damals zu Papst Gregor VIII... was Berechnungen des Wochentages bestätigen.
Wie auch immer, meine julian-lib.o (Library für Kalenderberechnungen, in c geschrieben, aber auch in Perl habe ich die als julian-lib.pm) stimmt jetzt :-)
Viele Grüße aus der Anstalt,
Horst Haselhuhn
Hello,
Wie auch immer, meine julian-lib.o (Library für Kalenderberechnungen, in c geschrieben, aber auch in Perl habe ich die als julian-lib.pm) stimmt jetzt :-)
Hattest Du denn auch schon mit der PTB kontakt wegen der Schaltsekunden?
Wenn schon, denn schon?
Ein harzliches Glückauf
Tom vom Berg
http://bergpost.annerschbarrich.de
Hallo Tom,
Hattest Du denn auch schon mit der PTB kontakt wegen der Schaltsekunden?
Wieso die PTB? Die schreibt doch auch nur vom IERS ab. ;-)
Und die haben eine Übersicht über Zeitkorrekturen (die Schaltsekunden beginnen Juli 1972, die 11 Jahre vorher waren die Anpassungen ziemlich konfus, was man heutzutage eher ignoriert).
Viele Grüße,
Christian
(Hallo|Hi(ho)|Tag) Horst,
Der Dreh- und Angelpunkt der Gregorianischen Kalenderreform ist der Wochentag, nicht das Datum.
Das einzige stabile Element, das sich in den (uns|mir) bekannten Kalendersystemen meistens wiederfindet, ist die 7-Tage-Woche.
Zumindest ist das für _mein_ Verständnis richtig, weil:
ich dachte bis heute, dass der 4.10.1582 ein Montag war. Indes: der 4.10.1582 war ein Donnerstag, definitiv.
Naja, das hättest du an Hand seriöser Quellen[1] sicher auch feststellen können, ohne gleich eine Kalenderberechnungsbibliothek programmieren zu müssen. ;-)
Es würde ja auch von der Logik her keinen Sinn machen, ...
Es würde höchstwahrscheinlich auch keinen Sinn __ergeben__ (*SCNR*).
..., auf einen Montag den Freitag folgen zu lassen.
Um Gottes Willen! Man bedenke den volkswirtschaftlichen Schaden durch den Arbeitsausfall infolge einer um drei Tage verkürzten Arbeitswoche! Der damals amtierende Arbeitgeberpräsident[2] hätte sicherlich rebelliert.
Was eher geht (für mein Verständnis), ist, dem Donnerstag einen Freitag folgen zu lassen, diesem jedoch ein anderes Datum zu geben.
Wie schon oben erwähnt, ist die 7-Tage-Woche das einzig langfristig stabile Element. Und darauf baut ja auch die Julianische Tagesnummer (gerne auch mal Julianisches Datum genannt) auf. Wenn man (Tages-)Abstände zwischen zwei Daten in womöglich noch zwei unterschiedlichen Kalendersystemen berechnen will, ist die JDN die brauchbarste Lösung. Leider gibts auch wieder mehrere Arten der JDN-Berechung, die sich nicht immer ganz einig darüber sind, wann ein Tag beginnt und wann er endet.
Und so wird es auch gelaufen sein damals zu Papst Gregor VIII... was Berechnungen des Wochentages bestätigen.
Ich war nicht dabei, und so lange deine Kalenderbibliothek nicht Gesetzeskraft hat, verlasse ich mich lieber auf andere Berechnungen. Man stelle sich nur folgendes Telefongespräch vor:
Ausbeuter: Meyer[3], wieso sind sie heute nicht zur Arbeit erschienen?
Lohnabhängiger: Also Chef, laut Haselhuhn'schem(TM) Kalender ist heute (Oster-)Sonntag!
Ausbeuter: Haselhuhnscher Kalender? Nach julian-lib.o oder julian-lib.pm?
Wie auch immer, meine julian-lib.o (Library für Kalenderberechnungen, in c geschrieben, aber auch in Perl habe ich die als julian-lib.pm) ...
Wozu sowas in Perl selbst schreiben? Reichen dir die fertigen Kalender-Libraries nicht aus? ;-) Und für c hätte ich dir die datelib empfehlen können.
... stimmt jetzt :-)
Mag sein, dass sie oft richtig rechnet. Aber wenn du wirklich Daten exakt berechnen willst, wirst du Schwierigkeiten bekommen, sobald du den vatikanischen/katholischen Blickwinkel mal verlassen musst. Zu den unterschiedlichen Einführungszeiten des Gregorianischen Kalenders in Nationalstaaten kommen noch so Sachen wie die Unterscheidung zwischen katholischen und evangelischen Schweizer Kantonen, doppelte Kalenderführung mit missverständlichen Datumsangaben in Großbritannien, andere Berechnung des Osterdatums im Einflussbereich der orthodoxen (oströmischen) Kirche und schließlich als Krönung des Ganzen die verhauene Kalenderumstellung in Schweden, die dort zu einem 30. Februar (1712) führte. B-)
Das ist das eine Problem. Das andere ist, dass dein "Julianischer Kalender" wahrscheinlich nur ein "synthetischer" Kalender ist, der nachträglich rückwärts gerechnet wird. So wurden in der Anfangszeit des "echten" Julianischen Kalenders die Schaltjahre eher willkürlich gewählt (Was aber nicht so schlimm ist, wenn man den vorherigen Wirrwarr betrachtet). Außerdem stimmen seine Jahreszahlen nicht, die wurden erst einige hundert Jahre nach der Einführung des Julianischen Kalenders so angepasst[4], wie wir sie heute kennen.
Viele Grüße aus der Anstalt,
Viele Grüße zurück, und wenn du sie treffen solltest, dann grüße auch die Herren Priol und Dombrowski von mir. ;-)
MffG
EisFuX
[1] *hust* Es soll auch noch seriösere Quellen geben ...
[2] ... und der ifo-Präsident sicher auch.
[3] Name von der Redaktion anonymisiert.
[4] Damit das Jahr 1 auf das Geburtsjahr eines Mannes fällt, der wahrscheinlich sieben Jahre vor seiner Geburt geboren wurde.
--
Nichts ist dem Zuwachs an Wissen förderlicher, als nach einer Antwort korrigiert zu werden.
Hi Martin,
Programmieren macht Spaß :-)
Full ACK.
Erst recht, wenn man die Zusammenhänge begreift.
Ich hab sogar das mit den Pointern und structs verstanden ;-)
Stück für Stück kommt mein altes, mir seit 1995 angedichtetes Verständnis für c wieder.
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. Da lohnt es sich schonmal ein struct in c zu bauen, meins sieht so aus:
// Prototyp der Struktur für einen eindeutig bestimmten Tag
struct tagx {
int julianday; // Julianischer Tag
int day; // Tag zum Datum
int month; // Monat zum Datum
int year; // Jahr zum Datum
int numweekday; // Wochentag numerisch 1 Montag.. 0 Sonntag
int leapyear; // Schaltjahr 0 oder 1
int weeksyear; // Anzahl der Wochen zum Jahr
int kw; // Kalenderwoche numerisch
int kwyear; // Das Jahr zur Kalenderwoche
char skw[10]; // Kalenderwoche like "14.2008"
char wotag[20]; // "Montag", "Dienstag" usw.
char monat[20]; // "Januar", "Februar" usw.
int elapsed; // Seit Jahresbeginn abgelaufene Tage
int ydays; // Die Anzahl der Tage des Jahres
int restd; // Die Verbleibenden Tage bis zum Jahresende
int sommerzeit; // Sommerzeit 0 oder 1
int begin_summertime; // Beginn der Sommerzeit, Julianischer Tag
int end_summertime; // Ende der Sommerzeit, Julianischer Tag
char date[15]; // Das Datum like "31.03.2008"
};
Das struct vereinfacht den Quellqode ungemein.
Wie schon gesagt, Programmieren macht viel Freude ;-)
Viele Grüße an Alle,
Hotte
Hi,
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.
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.
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:
[...]
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.
Viel interessanter als die Datenstruktur ist aber die Implementierung der Umwandlung von "normalem" Gregorianischem Datum in das Julianische Datum (Tageszählung) und umgekehrt.
Das struct vereinfacht den Quellqode ungemein.
Hmm. Ich finde, es bläht die Sache auf, weil so viel Unnötiges drinsteht.
Wie schon gesagt, Programmieren macht viel Freude ;-)
Yo, immer wieder gern.
Schönes Wochenende auch,
Martin
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 :)
Hallo Rolf,
ääh, Julian, ... nee, Horst ... ach, egal!
Hmm, ich glaube, dass ich in Pointern denken kann.
Ich auch.
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.
Gerade deshalb finde ich es viiiel leichter, "in C zu denken". Mir machen eher die abstrakten Konzepte von Javascript oder PHP, teilweise auch schon C++ Schwierigkeiten.
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. [...]
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
Moment: Ich meinte nicht den Julianischen Kalender, sondern das Julianische Datum, also die fortlaufende Tageszählung.
Auf jeden Fall danke für den Tipp, das kommt noch hinein in mein struct:
int diff_julian_gregor;
Wozu?
So long,
Martin
hi Martin,
Moment: Ich meinte nicht den Julianischen Kalender, sondern das Julianische Datum, also die fortlaufende Tageszählung.
Auf jeden Fall danke für den Tipp, das kommt noch hinein in mein struct:
int diff_julian_gregor;Wozu?
Done :-)
Hierzu (siehe die letzten 3 Zeilen):
d:>xdate
Samstag, 5. April 2008 Anno Domini
nach dem Gregorianischen Kalender
Kurzdatum ························ 05.04.2008
Kalenderwoche ···················· 14.2008
Anzahl der Kalenderwochen ········ 52
Schaltjahr ······················· Ja
Tage seit Jahresbeginn ··········· 96
Tage bis Jahresende ·············· 270
Tage des ganzen Jahres ··········· 366
Sommerzeit ······················· Ja
Beginn der Sommerzeit ············ 30.03.2008
Ende der Sommerzeit ·············· 26.10.2008
Julianischer Tag ················· 2454562
Julianische Zaehlung ············· 2454549
Korrektur zum Julianischem Datum · 13 Tage
Julianisches Datum ··············· 23.03.2008
Options: d:/_c/exe/fertig/xdate.exe [Tag] [Monat] [±Jahr]
Wie ich schon einmal schrieb, der Unterschied zw. Gregorianischer Zählung und Julianischer Zählung beträgt derzeit 13 Tage.
Die fortlaufende Tageszählung geht vom 1.1.4713 BC bis dato AD, wir haben also heute den Tag mit der laufenden Nr. 2454562.
Es ist evntl. verwirrend, dass nach Julianischer Zählung diese Zahl heute um 13 verringert ist, aber das ist eine Frage des Standpunktes zur Gregorianischen Kalenderreform vom 4.10 zum 15.10.1582: der aus dem Jul. Kalender geborene Greg. Kalender wurde um 10 Tage nach vorne gesetzt, somit ist aus der Sicht des Greg. Kal. der Jul. Kalender um 10 Tage zurückgeblieben.
Der Betrag der Greg. Kalender-Korrektur:
9 Tage waren es vom 1.3.1400 bis 1.3.1500, danach 10 Tage bis 1.3.1700.
Ab 1.3.1700 waren es 11 Tage bis zum 1.3.1800 und ab dem 1.3.1800 waren es 12 Tage bis zum 1.3.1900.
Ab dem 1.3.2100 beträgt die Korrektur 14 Tage, aber wer weiß, ob mich das dann noch interessiert...
Btw. c, mein struct tagx{} sieht jetzt ungefär so aus wie es die Ausgabe von xdate braucht, siehe oben. In der main() erstelle ich eine Kopie des Prototypes und einen Pointer. Pointer und Datum werden an die Funktion übergeben, welche das struct mit Werten belebt. c Is scho geil ;-)
Viele Grüße,
Hotte
D:\_c\exe>xdate 4 10 1582
Donnerstag, 4. Oktober 1582 Anno Domini
nach dem Julianischen Kalender
Kurzdatum ························ 04.10.1582
Kalenderwoche ···················· 40.1582
Anzahl der Kalenderwochen ········ 52
Schaltjahr ······················· Nein
Tage seit Jahresbeginn ··········· 277
Tage bis Jahresende ·············· 78
Tage des ganzen Jahres ··········· 355
Sommerzeit ······················· Ja
Beginn der Sommerzeit ············ 25.03.1582
Ende der Sommerzeit ·············· 31.10.1582
Julianischer Tag ················· 2299160
Julianische Zaehlung ············· 2299160
Korrektur zum Julianischem Datum · 0 Tage
Julianisches Datum ··············· 04.10.1582
Options: d:/_c/exe/fertig/xdate.exe [Tag] [Monat] [±Jahr]
D:\_c\exe>xdate 15 10 1582
Freitag, 15. Oktober 1582 Anno Domini
nach dem Gregorianischen Kalender
Kurzdatum ························ 15.10.1582
Kalenderwoche ···················· 40.1582
Anzahl der Kalenderwochen ········ 52
Schaltjahr ······················· Nein
Tage seit Jahresbeginn ··········· 278
Tage bis Jahresende ·············· 77
Tage des ganzen Jahres ··········· 355
Sommerzeit ······················· Ja
Beginn der Sommerzeit ············ 25.03.1582
Ende der Sommerzeit ·············· 31.10.1582
Julianischer Tag ················· 2299161
Julianische Zaehlung ············· 2299151
Korrektur zum Julianischem Datum · 10 Tage
Julianisches Datum ··············· 25.09.1582
Options: d:/_c/exe/fertig/xdate.exe [Tag] [Monat] [±Jahr]
hi Martin und Kalender-Fans,
Hier noch eine kleine Ergänzung für eigene Berechnungen.
Die Korrektur "Ko" in Tagen zwischen Gregorianischen und Julianischen Kalender. Bitte beachten, dass es den Gregorianischen Kalender erst seit dem 15.10.1582 gibt. Untenstehende Tabelle hat, je nach Datum also lediglich rein rechnierischen Character.
Ko ab Datum
-4 1.3.301 B.C.
-3 1.3.201 B.C.
-2 1.3.101 B.C.
-1 1.3.100
0 1.3.200
1 1.3.300
2 1.3.500
3 1.3.600
4 1.3.700
5 1.3.900
6 1.3.1000
7 1.3.1100
8 1.3.1300
9 1.3.1400
10 1.3.1500
11 1.3.1700
12 1.3.1800
13 1.3.1900
14 1.3.2100
15 1.3.2200
16 1.3.2300
Bezogen auf den Kalender nach Julian oder Gregorian gibt es folgerichtig zwei Formeln zum Berechnen des Julianischen Tages (Julianisch oder Gregorianisch). Obenstehende Tabelle ergibt sich aus der Anwendung beider Formeln rein rechnerisch.
Praktisch ist es so, dass der Julianische Kalender im alt-Römischen Reich bis 4.10.1582 (Donnerstag) gültig war, ab dem 15.10.1582 (Freitag) gilt der Gregorianische Kalender (bis heute auch in Latin-Europa). In Fakt: Ein Datum 4.10.1582 und davor gibt es nicht nach dem Gregorianischen Kalender.
Zum Programmieren von Kalenderberechnungen ist es daher empfehlenswert, bis 4.10.1582 den Julianischen Kalender anzunehmen und ab dem 15.10.1582 den Gregorianischen Kalender.
Die Tage 5,6,7,8,9,10,11,12,13,14 Oktober 1582 gibt es praktisch nicht, daher wird vom 4.10.1582 mit dem Julianischen Tag 2299160 auf dem 15.10.1582 der Julianische Tag 2299161 gezählt.
Vom Standpunkt des Gregorianischen Kalenders aus fällt die Julianische Zählung, die bis zum 4.10.1582 (2299160) bei beiden Kalendern gleich war am 15.10.1582 auf den Julianischen Tag 2299151 mit dem Julianischen Datum 25.09.1582 zurück.
D:>xdate 4 10 1582
Donnerstag, 4. Oktober 1582 Anno Domini
nach dem Julianischen Kalender
Kurzdatum ························ 04.10.1582
Kalenderwoche ···················· 40.1582
Anzahl der Kalenderwochen ········ 52
Schaltjahr ······················· Nein
Tage seit Jahresbeginn ··········· 277
Tage bis Jahresende ·············· 78
Tage des ganzen Jahres ··········· 355
Sommerzeit ······················· Ja
Beginn der Sommerzeit ············ 25.03.1582
Ende der Sommerzeit ·············· 31.10.1582
Julianischer Tag ················· 2299160
Julianische Zaehlung ············· 2299160
Korrektur zum Julianischem Datum · 0 Tage
Julianisches Datum ··············· 04.10.1582
Options: d:/_c/exe/fertig/xdate.exe [Tag] [Monat] [±Jahr]
D:>xdate 15 10 1582
Freitag, 15. Oktober 1582 Anno Domini
nach dem Gregorianischen Kalender
Kurzdatum ························ 15.10.1582
Kalenderwoche ···················· 40.1582
Anzahl der Kalenderwochen ········ 52
Schaltjahr ······················· Nein
Tage seit Jahresbeginn ··········· 278
Tage bis Jahresende ·············· 77
Tage des ganzen Jahres ··········· 355
Sommerzeit ······················· Ja
Beginn der Sommerzeit ············ 25.03.1582
Ende der Sommerzeit ·············· 31.10.1582
Julianischer Tag ················· 2299161
Julianische Zaehlung ············· 2299151
Korrektur zum Julianischem Datum · 10 Tage
Julianisches Datum ··············· 25.09.1582
Options: d:/_c/exe/fertig/xdate.exe [Tag] [Monat] [±Jahr]
Viele Grüße an Alle,
Horst Haselhuhn
Hi,
- Die Reform besagt, dass der auf den 4.10.1582 folgende Freitag das Datum 15.10.1582 bekommt (nunmehr Gregorianischer Kalender).
So simpel ist das nur für den Vatikan.
In anderen Ländern erfolgte die Umstellung zu anderen Zeitpunkten (in Rußland z.B. erst im Jahr 1918). Die russische Oktober-Revolution 1917 fand nach dortigem Kalender im November statt.
Ob der Starttermin des Münchner Oktoberfests mitten im September auch mit den Unterschieden zwischen julianischem und gregorianischem Kalender zusammenhängt, weiß ich nicht ...
cu,
Andreas
@@MudGuard:
Die russische Oktober-Revolution 1917 fand nach dortigem Kalender im November statt.
Nein, nach unserem. (1917-11-07) Nach dortigem im Oktober, deshalb ja Oktoberrevolution.
Ob der Starttermin des Münchner Oktoberfests mitten im September auch mit den Unterschieden zwischen julianischem und gregorianischem Kalender zusammenhängt, weiß ich nicht ...
Ob die Verwechslung Folge des letzten Oktoberfests (oder gar noch der vorangegangenen) ist, weiß ich nicht ...
Live long and prosper,
Gunnar
Hi,
Ob die Verwechslung Folge des letzten Oktoberfests (oder gar noch der vorangegangenen) ist, weiß ich nicht ...
Kann nicht sein. Ich lebe zwar in München (leider auch in Hörweite der Wiesn), aber wenn ich es irgendwie vermeiden kann, bleibe ich dem Oktoberfest fern.
cu,
Andreas
Hallo MudGuard!
Ob der Starttermin des Münchner Oktoberfests mitten im September auch mit den Unterschieden zwischen julianischem und gregorianischem Kalender zusammenhängt, weiß ich nicht ...
Wie Bayern rechnen, who cares?
JMIKNW, S [1]
[1] Jomei, i konnt net widersteha, Sakra
Viele Grüße aus Frankfurt/Main,
Patrick