Umgang mit Jahresangaben kleiner Jahr 1000 in MySQL

[Auge]

Hallo

Die MySQL-Doku zu Datums- und Zeitfunktionen sagt, dass das System Datumsangaben im Format Y-m-d (2014-09-21; hey, übermorgen ist Herbstanfang) ab dem Jahr 1000 akzeptiert. Ich habe in ein DATE-Feld testweise Jahreszahlen unterhalb 1000 eingetragen (Beispiel: 0793-06-08) und diese werden komischerweise, im Gegensatz zu den Angaben in der Doku, auch akzeptiert.

In einer Stackoverflow-Diskussion zu diesem Thema wurde meine Beobachtung von einem Benutzer bestätigt (Beitrag von Holly, 10.08.2012). Weiterhin wurden mehrere Lösungsansätze benannt. So wurde empfohlen, beim eintragen eine feststehende vierstellige Zahl zur Jahresangabe zu addieren, um über 1000 zu kommen, und diese bei der Ausgabe wieder zu subtrahieren. Ein weiterer Benutzer schlägt vor, das Datum in drei Felder mit passendem Wertebereich für Jahr, Monat und Tag aufzuteilen.

Ansatz 1 bedürfte genauer Planung, um den Fixwert genau auf den Bereich, den man nutzen will, abzustimmen. Im Jahr 9999 ist ja auch wieder Schluss. Der Ansatz 2 mit den drei Feldern beraubt der Möglichkeiten der Datums- und Zeitfunktionen von MySQL. Die brauche ich bei dem anvisierten Einsatz *voraussichtlich* nur zur Differenzbildung, aber man weiß ja nie.

Hat hier jemand Ideen, wie ich geschichtliche Daten inklusive Datum abspeichern kann?

Tschö, Auge

[hotti]

hi,

Hat hier jemand Ideen, wie ich geschichtliche Daten inklusive Datum abspeichern kann?

Speichern kannst Du wie Du willst, zum Rechnen mit dem Datum nimmt MySQL den Gregorianischen Kalender an, der jedoch erst im Oktober 1582 eingeführt wurde. Zum Berechnen von Tagesdifferenzen über die Greg. Reform hinweg muss sowohl der Julianische als auch der Greg. Kalender herangezogen werden und aufgrund der Reform beträgt die Differenz  zwischen 4.10.1582 und 15.10.1582 nicht 11 Tage sondern nur einen Tag.

Die Differenz zw. J. und G. Kalender ist abhängig vom Datum, untenstehend ein Beispiel.

Informationen zum eingegebenen Datum

Das Datum ist gueltig

Schaltjahr: Das Jahr ist ein Schaltjahr
                Wochentag: Montag
             Scaliger-Tag: 2086308
                 Kalender: Julianischer Kalender
 Datum nach Jul. Kalender: 1.1.1000
Datum nach Greg. Kalender: 6.1.1000

Und noch ein Beispiel über die Reform:
D:>cli.pl Date -d 4.10.1582

Informationen zum eingegebenen Datum

Das Datum ist gueltig

Schaltjahr: Kein Schaltjahr
                Wochentag: Donnerstag
             Scaliger-Tag: 2299160
                 Kalender: Julianischer Kalender
 Datum nach Jul. Kalender: 4.10.1582
Datum nach Greg. Kalender: 14.10.1582

Der Scaliger-Tag ist der fortlaufende Tag ab 1.1.-4713

D:>
D:>
D:>cli.pl Date -d 15.10.1582

Informationen zum eingegebenen Datum

Das Datum ist gueltig

Schaltjahr: Kein Schaltjahr
                Wochentag: Freitag
             Scaliger-Tag: 2299161
                 Kalender: Gregorianischer Kalender
 Datum nach Jul. Kalender: 5.10.1582
Datum nach Greg. Kalender: 15.10.1582

Der Scaliger-Tag ist der fortlaufende Tag ab 1.1.-4713

Mehr dazu auf meinen Kalenderseiten, auch eine Lib für Perl und eine für JS.

MfG

[Auge]

Hallo

Speichern kannst Du wie Du willst, …

Aber, soweit ich das überblicke, nicht als Datum.

… zum Rechnen mit dem Datum nimmt MySQL den Gregorianischen Kalender an, der jedoch erst im Oktober 1582 eingeführt wurde.

Das weiß ich. Einen Thread aus dem Jahr 2011, wo auf deine Frage hin genau das diskutiert wurde, habe ich im Archiv gefunden. :-)

Darum geht es mir aber nicht (vordergründig). Ich bin primär an der Frage interessiert, ob und wenn ja welche Möglichkeiten es gibt, Datumsangaben von vor dem Jahr 1000 u.Z. in MySQL als Datumsfeld zu speichern. Um die Umrechnungen kann ich mich – ihre Notwendigkeit im Hinterkopf behaltend – bei Bedarf auch noch später kümmern.

Tschö, Auge

[hotti]

Moin,

fürne Chronik bietet sich das astronomische Datum an, dezimal ist das "Scaligertag.Uhrzeit" und welcher Kalender verwendet wurde, wäre auch zu festzuhalten. So gäbe es für eine Datierung 5.10.1582 mindestens drei Möglichkeiten:

1. das Datum ist ungültig aufgrund der Reform
2. G. Kalender
3. J. Kalender
4. andere

Damit hast Du bei geringstem Aufwand den größten Komfort: Sortieren, intCast (falls die Uhrzeit keine Rolle spielt), Umrechnung zwischen Kalendern und formatierte Ausgabe. Fürs Umrechnen von Datierungen zu anderen Kalendern wäre noch die Korrelationszahl festzuhalten. Beachte evnt., dass es auch Kalender gibt, die nach dem Mond gehen.

MfG

[Auge]

Hallo

fürne Chronik bietet sich das astronomische Datum an, dezimal ist das "Scaligertag.Uhrzeit" und welcher Kalender verwendet wurde, wäre auch zu festzuhalten.

Ob ich das, was ich vorhabe, bis auf Uhrzeit herunterbrechen will, kann ich mir nicht vorstellen.

So gäbe es für eine Datierung 5.10.1582 mindestens drei Möglichkeiten:

1. das Datum ist ungültig aufgrund der Reform
2. G. Kalender
3. J. Kalender
4. andere

Damit hast Du bei geringstem Aufwand den größten Komfort: Sortieren, intCast (falls die Uhrzeit keine Rolle spielt), Umrechnung zwischen Kalendern und formatierte Ausgabe.

Hört sich gut an. Ich brauche ja nur hoch oder herunter zu zählen und in einen gültigen Kalender umzurechnen.

Fürs Umrechnen von Datierungen zu anderen Kalendern wäre noch die Korrelationszahl festzuhalten.

Was bedeutet hier „Korrelationszahl“?

Beachte evnt., dass es auch Kalender gibt, die nach dem Mond gehen.

Ah, wie meine erste Armbanduhr aus der Schultüte. ;-)

Die mondbasierten Kalender sollten doch auch über Formeln auf das Julianische Datum abbildbar sein. Andererseits ist es, auch wenn es eurozentrisch klingt, wohl einfacher, die Daten einmalig in den hier jeweils gültigen Kalender (julianisch oder gregorianisch) umzurechnen und die originale Angabe in einem Textfeld zu speichern.

Tschö, Auge

[hotti]

hi,

Damit hast Du bei geringstem Aufwand den größten Komfort: Sortieren, intCast (falls die Uhrzeit keine Rolle spielt), Umrechnung zwischen Kalendern und formatierte Ausgabe.

Hört sich gut an. Ich brauche ja nur hoch oder herunter zu zählen und in einen gültigen Kalender umzurechnen.

Genau ;)

Fürs Umrechnen von Datierungen zu anderen Kalendern wäre noch die Korrelationszahl festzuhalten.
Was bedeutet hier „Korrelationszahl“?

Die Differenz in Tagen zwischen zwei Kalendern. Z.B. wird nach Thompson eine Korrelationszahl von 584283 angenommen für die Umrechnung vom Maya-Kalender zum J. Kalender. So ergibt das Maya-Datum Longcount 0.0.0.0.0 den 6.9.3114 BC (J. Kalender) bzw. 11.8.3114 BC (G. Kalender).

Die Korrelation zw. J. und G. Kalender ist abhängig vom Datum, so ist am 1.1.300 die Korrelationszahl 0, am 1.1.4713 BC betrug sie -38 Tage, am 4.10.1582 10 Tage und heute sind es 13 Tage.

Beachte evnt., dass es auch Kalender gibt, die nach dem Mond gehen.
Ah, wie meine erste Armbanduhr aus der Schultüte. ;-)

Die mondbasierten Kalender sollten doch auch über Formeln auf das Julianische Datum abbildbar sein.

Wäre möglich.

Andererseits ist es, auch wenn es eurozentrisch klingt, wohl einfacher, die Daten einmalig in den hier jeweils gültigen Kalender (julianisch oder gregorianisch) umzurechnen und die originale Angabe in einem Textfeld zu speichern.

Ach wie einfach wäre es, wenn wir den Maya-Kalender hätten. Der Beziehung zwischen Darstellung als LongCount und fortlaufenden Tagen genügt eine einfache Regel und einen 7-Tage-Zyklus da einzubauen, ist überhaupt kein Problem (Heute: 13.0.1.14.0 Montag [#2456923]). Schwierig wirds nur mit den Monaten ;)

MfG

[Auge]

Hallo

Fürs Umrechnen von Datierungen zu anderen Kalendern wäre noch die Korrelationszahl festzuhalten.
Was bedeutet hier „Korrelationszahl“?

Die Differenz in Tagen zwischen zwei Kalendern.

Ah ja, dann handelt es sich also um Korrelationszahl*en*.

Ach wie einfach wäre es, wenn wir den Maya-Kalender hätten. Der Beziehung zwischen Darstellung als LongCount und fortlaufenden Tagen genügt eine einfache Regel und einen 7-Tage-Zyklus da einzubauen, ist überhaupt kein Problem (Heute: 13.0.1.14.0 Montag [#2456923]).

Es mag daran liegen, dass mir das System des Mayakalenders bis auf die in TV-Dokumentationen vermittelten Grundzüge nicht bekannt ist, aber *das* brauche ich nun doch nicht. :-)

Schwierig wirds nur mit den Monaten ;)

Mit deren oder unseren?

Tschö, Auge

[hotti]

hi,

Schwierig wirds nur mit den Monaten ;)
Mit deren oder unseren?

Die Maya kannten keine Monate in unserem Sinne. Die haben einfach nur die Tage durchnumeriert. Dass es zwischen dem Sternenjahr (siderisches Jahr, Erdumlauf) und einem Tag keinen ganzzahligen Zusammenhang gibt, wussten die Maya und hatten für das Haab (365 Tage) eine Schaltjahresregel.

Quelle

Den Satz da über Bishop Landa: "Jedoch macht de Landa keine Angaben darüber, wie dabei der parallele Lauf von Haab und Tzolkin erhalten blieb".

Deute ich als Mißverständnis, denn der Tzolkin (260 Tage) ist kein Jahr, sondern einfach nur ein Tageszyklus, vergleichbar mit unserer 7-Woche Mo..So.

Nachdem ich selbst viel über die Maya gelesen haben u.a. Originalschriften von Thompson, der sich ebenfalls auf Landa's Aufzeichnungen stützt, komme ich (und andere Maya-Forscher auch, siehe Thompson Hieroglyphic Writing) zu dem Schluss, dass der Tzolkin den Kern des Maya-Kalenders darstellt und dass das Haab als Verwaltungsjahr (von Amts wegen) für die Maya unbedeutend war. Denn der Tzolkin ist ein sich wiederholender Zyklus, der sich unabhängig von der Tageszählung wiederholt (genauso wie unsere Wochentage).

Programmiertechnisch ist der Maya-Kalender recht einfach umzusetzen und alles andere als ein Mythos.

MfG

[1UnitedPower]

Meine Herren!

Die MySQL-Doku zu Datums- und Zeitfunktionen sagt, dass das System Datumsangaben im Format Y-m-d (2014-09-21; hey, übermorgen ist Herbstanfang) ab dem Jahr 1000 akzeptiert. Ich habe in ein DATE-Feld testweise Jahreszahlen unterhalb 1000 eingetragen (Beispiel: 0793-06-08) und diese werden komischerweise, im Gegensatz zu den Angaben in der Doku, auch akzeptiert.

In der Dokumentation wird auch darauf hingewiesen, dass frühere Daten unterstützt werden könnten, aber dass das eben nicht unter Garantie so sein muss. Aber selbst wenn der Datenbank-Server damit zurecht kommt, könnten höhere Software-Schichten ihre Probleme damit haben. Man könnte etwa den MySQL-Treiber fürs PHPs Datenbank-Abstraktionsschicht PDO als Beispiel für eine solche Software heranziehen. Ob es jetzt mit genau diesem Treiber ein Porblem gibt, weiß ich nicht. In den Nutzerkommentaren äußert ein Nutzer jedenfalls Probleme mit dem MySQL-Treiber für ODBC. Dieser scheint die strikte Einhaltung des Wertebereichs obligatorisch zu machen. Vielleicht verhalten sich verschiedene Storage-Engines in diesem Punkt auch unterschiedlich. Der Punkt den ich hier markieren will: Wenn du dich auf die korrekte Handhabung verlassen musst, dann verlass dich nicht nur auf den MySQL-Server.

Hat hier jemand Ideen, wie ich geschichtliche Daten inklusive Datum abspeichern kann?

Jedenfalls nichts schöneres, als die Möglichkeiten, die du selber schon recherchiert hast. Du könntest aber auch ein int-Feld nehmen und dort einen tagesgenauen Zeitstempel speichern. Dann bietet sich natürlich eine renommierte Tageszählung an.

Alle drei Methoden, die jetzt im Raum schweben, sind eher Hacks, als saubere Lösungen. Vielleicht solltest du es künstlich erschweren, mit diesen Hack zu arbeiten, damit nicht zu leichtfertig fahrlässige Fehler passieren. Du könntest z.B. Blobs statt näher bestimmten Typen benutzen. Du könntest auch das Datum von der eigentliche Tabelle trennen und einen View bauen, der die die Datensätze wieder zusammenführt. So ist das Auslesen über den View recht bequem, aber es ist schwieriger Datensätzen einzufügen oder zu manipulieren. Außerdem kannst du Spalten-Kommentare nutzen, um eine Hilfestellung zu geben, wie mit dem Hack zu arbeiten ist, bzw. an dieser Stelle auf die Dokumentation des Hacks verweisen. Für wiederkehrende Funktionalität, wie die Differenzbildung, könntest du eigene MySQL-Funktionen schreiben.

[Auge]

Hallo

Die MySQL-Doku zu Datums- und Zeitfunktionen sagt, dass das System Datumsangaben im Format Y-m-d (2014-09-21; hey, übermorgen ist Herbstanfang) ab dem Jahr 1000 akzeptiert. Ich habe in ein DATE-Feld testweise Jahreszahlen unterhalb 1000 eingetragen (Beispiel: 0793-06-08) und diese werden komischerweise, im Gegensatz zu den Angaben in der Doku, auch akzeptiert.

In der Dokumentation wird auch darauf hingewiesen, dass frühere Daten unterstützt werden könnten, aber dass das eben nicht unter Garantie so sein muss.

Deshalb will ich mich ja auch nicht darauf verlassen. Mag sein, dass der MySQL-Server auf meinem Webspace das hinnimmt, woanders muss das nicht so sein. Von Datumsangaben v.u.Z. will ich schon garnicht reden, die passen wegen des Minus definitiv nicht in ein normales Datumsfeld.

Hat hier jemand Ideen, wie ich geschichtliche Daten inklusive Datum abspeichern kann?

Jedenfalls nichts schöneres, als die Möglichkeiten, die du selber schon recherchiert hast. Du könntest aber auch ein int-Feld nehmen und dort einen tagesgenauen Zeitstempel speichern. Dann bietet sich natürlich eine renommierte Tageszählung an.

Moment mal, da bringst du mich auf … da war doch was … <rumkram /> Julianischer Kalender … nee, … „nicht zu verwechseln mit …“ … ah, da isses: das Julianische Datum.

Zitat aus dem Wikipedia-Artikel:
„Es gibt die Zeit in Tagen an, die seit dem 1. Januar −4712 (4713 v. Chr.) 12:00 Uhr vergangen ist.“

Minuswerte, um vor den Tag 1 zu kommen, werden da wohl erlaubt sein, oder? Der Artikel ist für diese Uhrzeit zu umfangreich, aber definitiv ein Ansatzpunkt.

Alle drei Methoden, die jetzt im Raum schweben, sind eher Hacks, als saubere Lösungen. Vielleicht solltest du es künstlich erschweren, mit diesen Hack zu arbeiten, damit nicht zu leichtfertig fahrlässige Fehler passieren. Du könntest z.B. Blobs statt näher bestimmten Typen benutzen.

Wofür ich mich auch immer entscheide, das ist noch Zukunftsmusik.

Du könntest auch das Datum von der eigentliche Tabelle trennen und einen View bauen, der die die Datensätze wieder zusammenführt. So ist das Auslesen über den View recht bequem, aber es ist schwieriger Datensätzen einzufügen oder zu manipulieren.

Naja, abspeichern muss ich das Datum so oder so. Da sehe *ich* jetzt keinen Einsatzzweck für einen View.

Für wiederkehrende Funktionalität, wie die Differenzbildung, könntest du eigene MySQL-Funktionen schreiben.

Herrje, gleich die nächste Baustelle. :-)

Tschö, Auge

[Matthias Apsel]

Om nah hoo pez nyeetz, Auge!

Nur mal interessehalber: Welche taggenauen Fakten vor dem Jahr 1000 kennst du, abgesehen von astronomischen Ereignissen, die sich nach irgendeinem Kalender zurückrechnen lassen?

PS: Das julianische Datum ist genau(?) das, was Hotti mit dem Scaliger-Tag meint.

Matthias

[Auge]

Hallo

Nur mal interessehalber: Welche taggenauen Fakten vor dem Jahr 1000 kennst du, abgesehen von astronomischen Ereignissen, die sich nach irgendeinem Kalender zurückrechnen lassen?

Ich möchte eine Datenbankstruktur erstellen, in der sich geschichtliche Ereignisse abspeichern lassen. Die sind natürlich, je länger zurückliegend, desto öfter nur mit der Jahreszahl oder z.B. mit „um 785 u.Z. passierte dies oder das“ statt mit dem genauen Datum bekannt. Dennoch finden sich, gerade in den antiken Hochkulturen, Ereignisse, die aufgrund der ausgebildeten Bürokratie genau datierbar sind. Also möchte ich auch für diese Epoche(n) ein genau festlegbares Datum speichern können.

PS: Das julianische Datum ist genau(?) das, was Hotti mit dem Scaliger-Tag meint.

Da das in der Wikipedia nur mit einem Satz gewürdigt wurde, habe ich überlesen, dass Julianisches Datum und Scaliger-Tag identisch sind.

Tschö, Auge

[hotti]

hi,

Nur mal interessehalber: Welche taggenauen Fakten vor dem Jahr 1000 kennst du, abgesehen von astronomischen Ereignissen, die sich nach irgendeinem Kalender zurückrechnen lassen?

Pakal

PS: Das julianische Datum ist genau(?) das, was Hotti mit dem Scaliger-Tag meint.

Es wird nach J.J. Scaliger berechnet.

MfG

[Alexander (HH)]

Moin Moin!

Die MySQL-Doku zu Datums- und Zeitfunktionen sagt, dass das System Datumsangaben im Format Y-m-d (2014-09-21; hey, übermorgen ist Herbstanfang) ab dem Jahr 1000 akzeptiert.

Hat hier jemand Ideen, wie ich geschichtliche Daten inklusive Datum abspeichern kann?

Warum muß es unbedingt MySQL mit seinen gefühlten 1000 "Besonderheiten" sein? MySQL wäre so ziemlich das letzte, was mir einfällt, um Daten strukturiert abzulegen.

PostgreSQL ist Open Source, kostenlos, schnell, und hat nicht annähernd so viele Macken wie MySQL. Speziell für Dein Problem mit Datumsangaben bietet Pg eine gute Auswahl an Datentypen. Wenn Dir tagesgenaue Angaben reichen, kannst Du mit dem Typ DATE von 4713 BC bis 5874897 AD arbeiten, mit Mikrosekundenauflösung kannst Du einen der beiden TIMESTAMP-Typen benutzen, die reichen von 4713 BC bis 294276 AD, wahlweise mit oder ohne Zeitzone.

Alexander

[Auge]

Moin Moin!

Morjen

Warum muß es unbedingt MySQL mit seinen gefühlten 1000 "Besonderheiten" sein? MySQL wäre so ziemlich das letzte, was mir einfällt, um Daten strukturiert abzulegen.

Es ist das DB-System, dass mir ohne weitere Umstände auf meinem Webspace zur Verfügung steht. Nur wegen des DB-Systems möchte ich nun keinen Umzug machen.

PostgreSQL ist Open Source, kostenlos, schnell, und hat nicht annähernd so viele Macken wie MySQL.

Für einen eigenen Server ist das definitiv *die* Alternative. Das hieße zwar, sich einen weiteren SQL-Dialekt drauf zu schaffen, aber was soll's.

Speziell für Dein Problem mit Datumsangaben bietet Pg eine gute Auswahl an Datentypen. Wenn Dir tagesgenaue Angaben reichen, kannst Du mit dem Typ DATE von 4713 BC bis 5874897 AD arbeiten, mit Mikrosekundenauflösung kannst Du einen der beiden TIMESTAMP-Typen benutzen, die reichen von 4713 BC bis 294276 AD, wahlweise mit oder ohne Zeitzone.

Oder ich nutze gleich den Typ interval, der, wenn ich mich bei den Nullen nicht verzählt habe, von 178 Mio. Jahren in der Vergangenheit bis 178 Mio. Jahren in der Zukunft reicht. Das reicht zwar nicht bis zur Kambrischen Explosion, aber da will ich eh nicht hin. :-)

Ich werde mir zuhause mal 'nen PostgreSQL-Server installieren und ein wenig herumspielen. Für die Webseite nutze ich vorläufig dennoch MySQL, weil es eben da ist. Über einen Hosterwechsel möchte ich momentan nicht nachdenken müssen.

Tschö, Auge