Datum berechnen

[WernerK]

Hallo

in einer DB SPalte (date) liegt ein Datum in der Form 2014-09-03.
Dies wird mit Ajax ausgelesen.

Ich würde gerne eine Javascript Abfrage machen in der Art:

Wenn Datum kleiner 5 Tage zum aktuellen Datum dann Meldung "Bla Bla kleiner 5 Tage"
Wenn Datum kleiner 10 Tage zum aktuellen Datum dann Meldung "Bla Bla kleiner 10 Tage"
Wenn Datum größer 10 Tage zum Aktuellen Datum dann Meldung "Bla Bla Alles OK"

Wie könnte man diese Berechnung am besten hinbekommen?
Sollte man das Datum wie unten mit Tag, Monat und Jahr zusammensetzen und dann mit der DB vergleichen?

var d = new Date();
var curr_date = ('0' + (d.getDate())).slice(-2);
var curr_month = ('0' + (d.getMonth()+1)).slice(-2);
var curr_year = d.getFullYear();

Oder könnte man es über einen Zeitstempel besser hinbekommen?

Bin für jede Idee dankbar.

Gruss
Werner

[ChrisB]

Hi,

Wie könnte man diese Berechnung am besten hinbekommen?
Sollte man das Datum wie unten mit Tag, Monat und Jahr zusammensetzen und dann mit der DB vergleichen?

Wozu mit JavaScript, das kann die Datenbank doch gleich selber machen.

MfG ChrisB

[WernerK]

Hallo

Wozu mit JavaScript, das kann die Datenbank doch gleich selber machen.

Wie meinst du das?
Gleich eine solche Funktion in der MySQL Abfrage einbauen?
Geht das denn mit MySQL alleine?

Gruss
Werner

[Quincunx]

Hallo Werner,

Geht das denn mit MySQL alleine?

kenne zwar nicht die mySQL Variante doch schau dir mal hier bei datdiff den Code an.

gruesse qx

[ChrisB]

Hi,

Wie meinst du das?
Gleich eine solche Funktion in der MySQL Abfrage einbauen?
Geht das denn mit MySQL alleine?

Na klar geht das … schau dir mal die Datums- und Zeitfunktionen an – ADDDATE/SUBDATE kannst du in DATEDIFF „einbauen“ … und wenn du das dann noch mit einer Control Flow Function wie CASE kombinierst, kannst du dir damit gleich ein simples „Flag“ zurück liefern lassen, sowas wie bspw. -1/0/1, anhand dessen deine Ausgabelogik (JavaScript, oder serverseitige Sprache) dann entscheiden kann, welcher Fall vorliegt.

MfG ChrisB

[Gunnar Bittersmann]

@@WernerK:

nuqneH

in einer DB SPalte (date) liegt ein Datum in der Form 2014-09-03.

Woraus sich problemlos ein Date-Objekt erstellen lässt.

Sollte man das Datum wie unten mit Tag, Monat und Jahr zusammensetzen und dann mit der DB vergleichen?

Nein.

Oder könnte man es über einen Zeitstempel besser hinbekommen?

Ja.

Qapla'

[WernerK]

Hallo,

Oder könnte man es über einen Zeitstempel besser hinbekommen?

Ja.

Kannst du mir das bitte etwas näher erläutern?
Meinst du aus dem DB Datum und dem aktuellen Datum einen Unix Zeitstempel machen?
Wie aber kann man dann diesen vergleichen?

Gruss
Werner

[Gunnar Bittersmann]

@@WernerK:

nuqneH

Meinst du aus dem DB Datum und dem aktuellen Datum einen Unix Zeitstempel machen?
Wie aber kann man dann diesen vergleichen?

Nein, aus beiden Daten jeweils einen Zeitstempel machen. Und nicht UNIX-, sondern JavaScript-Zeitstempel.

Wie du aus dem Datum aus der DB ein JavaScript-Date-Object machst, hatte ich dir verlinkt. Wenn als Parameter nur das Datum angegen ist, wird die Uhrzeit auf 00:00 UTC gesetzt.

Ohne Parameter erhältst du ein Date-Objekt für den aktuellen Zeitpunkt. Wenn du nur mit ganzen Tagen rechnen willst, müsstest du die Uhrzeit dafür ebenfalls <http://de.selfhtml.org/javascript/objekte/date.htm#set_utc_hours@title=auf 00:00 UTC setzen>.

Die Daten vergleichen heißt, die Differenz der http://de.selfhtml.org/javascript/objekte/date.htm#parse@title=Zeitstempel zu bilden.

So ginge es mit JavaScript. Das brauchst du aber gar nicht, weil der Ansatz, das mit MySQL zu machen, sicher der bessere ist.

Qapla'

[hotti]

Oder könnte man es über einen Zeitstempel besser hinbekommen?

Ja.

Nein. Bei Datumsberechnungn über den Zeitstempel muss die Zeitzone berücksichtigt werden und die Zeitzone ist länderspezifisch (Sommerzeit, DST).

MfG

[Gunnar Bittersmann]

@@hotti:

nuqneH

Oder könnte man es über einen Zeitstempel besser hinbekommen?

Ja.

Nein.

Doch.

Bei Datumsberechnungn über den Zeitstempel muss die Zeitzone berücksichtigt werden und die Zeitzone ist länderspezifisch (Sommerzeit, DST).

Nein.

Durch Nachdenken kommt man drauf, dass man sinnvollerweise in UTC rechnet. Bei UTC gibt’s keine Sommerzeit.

Qapla'

[hotti]

hi,

Durch Nachdenken kommt man drauf, dass man sinnvollerweise in UTC rechnet. Bei UTC gibt’s keine Sommerzeit.

Weder UTC noch Sommerzeit:

  
<script src="/Scaliger.js"></script>  
<script>  
var date = Scaliger.neu(16,11,1932);  
var heute = Scaliger.neu();  
console.log(heute.jd - date.jd); // 29876 Differenz in Tagen  
</script>  

MfG, Horst (durch Nachdenken darauf gekommen, eine kleine Library dafür einzusetzen)

[hotti]

hi,

Bin für jede Idee dankbar.

Falls Du zum Kalkulieren von Datumsdifferenzen nicht die DB-Engine einsetzen und das nur mit JS machen willst, hier drin ist eine kleine Lib von mir verlinkt: Scaliger.js
Funktional vorerst nur für die Gregorianische Epoche, erlaubt diese Lib das Rechnen mit fortlaufenden Tagen, wenn Du Lust hast, kannst Du das Teil weiterentwickeln ;)

MfG

[Gunnar Bittersmann]

@@hotti:

nuqneH

hier drin ist eine kleine Lib von mir verlinkt: Scaliger.js

Warum verlinkst du die Lib hier nicht direkt?

wenn Du Lust hast, kannst Du das Teil weiterentwickeln ;)

Für die unnötig umständlich implementierte Methode isleap() hätte ich einen Einzeiler.

Qapla'

[hotti]

Moin,

hier drin ist eine kleine Lib von mir verlinkt: Scaliger.js

Warum verlinkst du die Lib hier nicht direkt?

die ist noch nicht fertig (1).

wenn Du Lust hast, kannst Du das Teil weiterentwickeln ;)

Für die unnötig umständlich implementierte Methode isleap() hätte ich einen Einzeiler.

Dein Einzeiler funktioniert nur in der Gregorianischen Epoche.

Und jetzt denken WIR mal ein bischen nach mein Lieber:
Wenn es eine Formel gibt, welche die Schaljahresregelung sowohl für die Gregorianische als auch für die Julianische Epoche einbezieht zum Berechnen fortlaufender Tage (sog. Julianische Tage nach J.J. Scaliger berechnet), dann ist es unnötig, für eine Prüfung auf Schaltjahr eine weitere extra Formel zu entwickeln, denn die Prüfung beschränkt sich ganz einfach darauf, zu prüfen, ob für den 29.2. und 1.3. derselbe Tag rauskommt. Das heißt: Der Code ist bereits vorhanden.

Desweiteren ist die Validierung von benutzerabhängigen Datum-Eingaben ebenfalls ganz einfach: Es wird der Scaliger-Tag berechnet, mit diesem Tag zurück zum Datum gerechnet und geprüft, ob dabei dasselbe Datum rauskommt.

Das sind so grundlegende Überlegungen, die ein Programmierer anstellt, so ist die Berechnung des Wochentages auch nur ein einfaches Modulo 7.

1. Da kommt noch rein:
   a) Erweiterung auf die Julianische Epoche unter Einbeziehung der Gregorianischen Reform für einen nahtlosen Übergang zum Berechnen forlaufender Tage auch für vorchristliche Datierungen,
   b) Validierung von Benutzereingaben,
   c) Berechnung der Kalenderwoche,
   d) die Gauss'sche Osterformel zum Berechnen aller Feiertage, die sich vom Osterdatum ableiten.

MfG

[Tabellenkalk]

Hallo,

unter Einbeziehung der Gregorianischen Reform

wo und wie wird da berücksichtigt, dass diese Reform in verschiedenen Ländern zu unterschiedlichen Zeiten eingeführt wurde?

Gruß
Kalk

[hotti]

Hallo,

unter Einbeziehung der Gregorianischen Reform
wo und wie wird da berücksichtigt, dass diese Reform in verschiedenen Ländern zu unterschiedlichen Zeiten eingeführt wurde?

Überhaupt nicht. Während das Datum der Gregorianischen Reform eindeutig feststeht, ist deren Umsetzung länderabhängig.

Die Gregorianische Kalenderreform ist festgehalten in der päpstlichen Bulle "Inter gravissimas...", die im Archiv des Vatikan aufbewahrt wird. Die Reform selbst ordnete Papst Gregor XIII bereits am 24. Februar 1582 an. Außerdem wurde anläßlich der Reform eine Medaille geprägt: Die Vorderseite zeigt Gregor XIII und die Inschrift "GREGORIUS XIII PONT OPT MAXIMUS", die Rückseite zeigt das Tierkreiszeichen "Widder" sowie die Inschrift "ANNO RESTITUTO MDLXXXII".

In Fakt müssen einige Annahmen getroffen werden, wenn das ums Rechnen mit dem Datum geht, und Datierungen vor der Greg. Reform sind allesamt mit Vorsicht zu genießen. So begründen sich Berechnungen fortlaufender Tage (Scaliger) u.a. darauf, dass:

a) die 7-Tage-Woche durchgängig Verwendung fand
b) vor der Greg. Reform der Julianische Kalender bestand

womit das Berechnen Julianischer Tage überhaupt möglich wird. Diesbezügliche Berechnungen spielen beim Dokumentieren astronomischer und globaler Ereignisse eine Rolle, so wird heutzutage der Julianische Tag auch dezimal weiter untersetzt (Astronomisches Datum) und die Scaliger-Epoche in Richtung Vergangenheit insofern erweitert, als dass mit negtiven Julianischen Tagen operiert wird für astronomische Ereignisse, die weit vor 4713 BC bspw. von den Maya dokumentiert wurden. Was die Korrelationen verschiedener Kalender betrifft, nunja, da streiten sich die Gelehrten, wobei es da nicht nur um Tage geht sondern u.U. um einige tausend Jahre Differenzen bspw. beim Spekulieren der Korrelation zum Kalender der Maya.

Um die Verwirrung komplett zu machen: In USA ist der Begriff Old-Style/New-Style gebräuchlich, das habe ich bei meinen umfangreichen Recherchen zum Maya-Kalender festgestellt, heißt, dass auch für vorchristliche Datierungen der Gregorianische Kalender angewandt wird, obwohl es die Gregorianische Reform noch gar nicht gab, wass sehr oft zu Missverständnissen führt, letztendlich jedoch daran liegt, dass es in der alten Welt keine einheitliche Zeitrechnung gab.

Gerade Letzteres macht ja den Maya-Kalender so interessant: Er zählt einfach nur die Tage über Jahrtausende hinweg; das wusste auch J.J. Scaliger welcher im 16. Jh den Vorschlag machte, es in Europa genauso zu tun. Scaliger wusste bestimmt noch mehr und im Umkehrschluss auch über Unzulänglichkeiten bzw. Lücken in der Christlichen Zeitrechnung. Meine Module, welche seine Formeln anwenden, habe ich Scaliger.pm, Scaliger.php, Scaliger.c und Scaliger.js genannt, um ihm ein Denkmal zu setzen.

MfG

[Gunnar Bittersmann]

@@hotti:

nuqneH

Und jetzt denken WIR mal ein bischen nach mein Lieber:
Wenn es eine Formel gibt, welche die Schaljahresregelung sowohl für die Gregorianische als auch für die Julianische Epoche einbezieht zum Berechnen fortlaufender Tage (sog. Julianische Tage nach J.J. Scaliger berechnet),

Eine solche gibt es nicht. Aus dem von Tabellenkalk schon angeführten Grund.

Deine Bibliothek funktioniert nur für einen kleinen Teil der Welt.

Und wenn du 1582 als Jahr der Einführung des gregorianischen Kalenders festsetzen willst, ist das in den Einzeiler auch schnell eingebaut:

function isLeapYear(x) {  
  return (!(x % 4) && (x <= 1582 || !(x % 400) || !!(x % 100)));  
}

dann ist es unnötig, für eine Prüfung auf Schaltjahr eine weitere extra Formel zu entwickeln, denn die Prüfung beschränkt sich ganz einfach darauf, zu prüfen, ob für den 29.2. und 1.3. derselbe Tag rauskommt. Das heißt: Der Code ist bereits vorhanden.

Ein kleines bisschen Arithmetik dürfte weitaus perfomanter sein als die Erstellung zweier Objekte. Zumal es auch mit einem ginge.

Du du willst ernsthaft dem OP das Einbinden einer Bibliothek empfehlen, deren Funktionsumfang er nie und nimmer braucht?

Qapla'

[hotti]

hi,

Deine Bibliothek funktioniert nur für einen kleinen Teil der Welt.

Immerhin ermöglichen meine Bibliotheken das Rechnen mit fortlaufenden Tagen über einige tausend Jahre hinweg und somit beispielsweise das Umrechnen von Datierungen verschiedener Kalender (Beispiel: Maya-Kalender).

Wie klein die Welt ist: In Sekunden und einer 32-Bit-Umgebung kommst Du auf maximal 50767 Tage, was rundgerechnet 139 Jahre sind.

print 0xffffFFFF/84600;

MfG

[1UnitedPower]

Meine Herren!

Wie klein die Welt ist: In Sekunden und einer 32-Bit-Umgebung kommst Du auf maximal 50767 Tage, was rundgerechnet 139 Jahre sind.

print 0xffffFFFF/84600;

JavaScript ist keine solche Umgebung:

Number.MAX_SAFE_INTERGER === 9007199254740991

Mit der Sekunden-Interpretation sind damit immerhin 106468076297 Jahre darstellbar.

[hotti]

hi,

Mit der Sekunden-Interpretation sind damit immerhin 106468076297 Jahre darstellbar.

Die Formeln von J.J. Scaliger gibt es, sie rechnen mit ganzen Tagen. Wäre es für Dich als Programmierer ein Grund, auf bewährte Algorithmen zu verzichten und dafür eine Sekundenbasierte Berechnung einzuführen, nur weil es die Umgebung ermöglicht?

MfG

[1UnitedPower]

Meine Herren!

Mit der Sekunden-Interpretation sind damit immerhin 106468076297 Jahre darstellbar.

Die Formeln von J.J. Scaliger gibt es, sie rechnen mit ganzen Tagen. Wäre es für Dich als Programmierer ein Grund, auf bewährte Algorithmen zu verzichten und dafür eine Sekundenbasierte Berechnung einzuführen, nur weil es die Umgebung ermöglicht?

Wenn ich nicht gerade eine Geschichts-, Zeitleisten-, oder Kalendar-App programmiere, würde ich das Problem einfach ignorieren. In diesem Fall erst Recht, weil trivialer Weise alle Tage der julianischen Epoche länger als fünf Tage in der Vergangenheit liegen ;) Für die meisten Anwendungen ist das wohl eine so kleine Nebensächlichkeit, dass es sich nicht lohnt so viel zusätzliche Komplexität als Overhead mit ins Boot zu nehmen.

[hotti]

Wenn ich nicht gerade eine Geschichts-, Zeitleisten-, oder Kalendar-App programmiere, würde ich das Problem einfach ignorieren. In diesem Fall erst Recht, weil trivialer Weise alle Tage der julianischen Epoche länger als fünf Tage in der Vergangenheit liegen ;) Für die meisten Anwendungen ist das wohl eine so kleine Nebensächlichkeit, dass es sich nicht lohnt so viel zusätzliche Komplexität als Overhead mit ins Boot zu nehmen.

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen. Mit Scaliger ist das ganz einfach, hier der Algorithmus.

Aber prüfe um Gottes Willen, ob Dein Rechner nicht in die Knie geht, wenn Du overheadige Libraries einbindest ;)

weil trivialer Weise alle Tage der julianischen Epoche länger als fünf Tage in der Vergangenheit liegen

Diese Aussage ist totaler Unfug.

[Gunnar Bittersmann]

@@hotti:

nuqneH

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen.

Einen regulären Ausdruck etwa?

Qapla'

[hotti]

hi,

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen.

Einen regulären Ausdruck etwa?

Oh Backe, den muss ich mal ausprobieren :)
Btw., 4713 BC ist ein Schaltjahr, wenn wir den Julianischen Kalender annehmen…

@1UP: Zwei Kalender in eine Klasse zu fassen, ist tatsächlich nicht einfach. In Sachen JS mache ich das nicht noch einmal, das werden zwei Klassen, bin grad dran ;)

MfG, Horst

[Tabellenkalk]

Hallo,

Btw., 4713 BC ist ein Schaltjahr, wenn wir den Julianischen Kalender annehmen…

mit Sicherheit nicht. Damals gabs den noch nicht.

Gruß
Kalk

[hotti]

Hallo,

Btw., 4713 BC ist ein Schaltjahr, wenn wir den Julianischen Kalender annehmen…

mit Sicherheit nicht. Damals gabs den noch nicht.

Die Berechnung des Astronomischen Datums (Fortlaufende Tage) basiert auf der Annahme s.o. So ergibt sich vom Tag = 0 (1.1.4713BC) bis heute der fortlaufende Tag zu 2456913

Erster Entwurf für Datei ScaligerClass.js:

  
    function ScaligerJuli() {} /* coming soon */  
    function ScaligerGreg(day, month, year){  
        if(!day || !month || !year){  
            var d = new Date();  
            day   = d.getDate();  
            month = d.getMonth() + 1;  
            year  = d.getFullYear();  
        }  
  
        /* Scaliger-Tag gregorianisch */  
        this.dmy2jd = function(day, month, year){  
            if(year < 0){ year++; }  
            var a = Math.floor((14 - month)/12);  
            var y = Math.floor(year + 4800 - a);  
            var m = (month + 12 * a - 3);  
            var jd = Math.floor(day + (Math.floor(153 * m + 2)/5) + Math.floor(365 * y) + Math.floor(y/4) - Math.floor(y/100) + Math.floor(y/400) - 32045);  
            return jd;  
        };  
  
        /* Setter: Die Instanz wird neu berechnet */  
        this.jd2dmy = function(jd){  
            // Gregorian  
            var a = jd + 32044;  
            var b = Math.floor( ( a * 4 + 3)/146097);  
            var c = a - Math.floor((146097 * b/4));  
  
  
            var d = Math.floor((4 * c + 3)/1461);  
            var e = c - Math.floor(1461 * d/4);  
            var m = Math.floor(((e * 5) + 2)/153);  
  
            var day = e - Math.floor((153 * m +2)/5) + 1;  
            var month = m + 3 - Math.floor(m/10) * 12;  
            var year = 100 * b + d - 4800 + Math.floor(m/10);  
  
            if(year < 0){ year--; }  
            if(year == 0){ year = -1; }  
  
            this.hash.day   = day;  
            this.hash.month = month;  
            this.hash.year  = year;  
            this.hash.jd = jd;  
        };  
  
        /* Setter, die Instanz wird neu berechnet */  
        this.add = function(days){  
            days = new Number(days);  
            if(isNaN(days)){  
                alert("To add days must be numeric");  
                return;  
            }  
            this.jd2dmy(this.hash.jd + days);  
        };  
  
        /* Liegt ein Schaltjahr vor? */  
        this.isleap = function(){  
            return this.dmy2jd(1, 3, this.hash.year) == this.dmy2jd(29, 2, this.hash.year) ? false : true;  
        };  
  
        /* Validate Date */  
        this.isvalid = function(){  
            var jd_in = new Number(this.hash.jd);  
            if( isNaN(jd_in) ) return false;  
            var clone = new ScaligerGreg();  
            clone.jd2dmy(jd_in);  
            return clone.hash.day == this.hash.day && clone.hash.month == this.hash.month && clone.hash.year == this.hash.year ? true : false;  
        };  
  
        /* Anzahl der Tag in einem Monat */  
        this.ultimo = function(){  
            var month = this.hash.month;  
            var year = this.hash.year;  
            var hunt = {  
                1: 31,  
                2: this.isleap(year) ? 29 : 28,  
                3: 31,  
                4: 30,  
                5: 31,  
                6: 30,  
                7: 31,  
                8: 31,  
                9: 30,  
                10: 31,  
                11: 30,  
                12: 31  
            };  
            return hunt[month];  
        };  
  
        /* Constructor */  
        this.hash = {  
            jd: this.dmy2jd(day, month, year),  
            day: day,  
            month: month,  
            year: year,  
        };  
  
        return this;  
    }  
  
    var greg = new ScaligerGreg(1,2,1904);  
    console.log(greg.hash.jd, greg.hash.day, greg.hash.month, greg.hash.year, greg.ultimo());  
    //greg.add(13);  
    //console.log(greg.hash.jd, greg.hash.day, greg.hash.month, greg.hash.year);  

[Gunnar Bittersmann]

@@hotti:

nuqneH

Btw., 4713 BC ist ein Schaltjahr, wenn wir den Julianischen Kalender annehmen…

Mit „heutige Schaltjahrregel auf gesamten Bereich angewandt“ wollte ich ausgedrückt haben, dass der Ausdruck den julianischen Kalender nicht annimmt, sondern so tut, als hätte der gregorianische schon immer gegolten.

Qapla'

[hotti]

Hi,

Btw., 4713 BC ist ein Schaltjahr, wenn wir den Julianischen Kalender annehmen…

Mit „heutige Schaltjahrregel auf gesamten Bereich angewandt“ wollte ich ausgedrückt haben, dass der Ausdruck den julianischen Kalender nicht annimmt, sondern so tut, als hätte der gregorianische schon immer gegolten.

Ja, klar, irgendeine Annahme muss immer getroffen werden. Für den nahtlosen Übergang über die Greg. Reform zum Berechnen fortlaufender Tage müssen wir annehmen:
 01.01.4713 BC hat den Tag 0
 04.10.1582 AD hat den Tag 2299160
In diesem Zeitraum gilt der Julianische Kalender mit der entsprechenden Schaltjahresregelung.

Datumsangaben 05.10.1582 AD bis 14.10.1582 AD sind ungültig. Der Monat Oktober 1582 hat 21 Tage, auf Do, 4.10. folgt Fr, 15.10.
Der 15.10.1582 AD hat den fortlaufenden Tag 2299161 und ab diesem Tag gilt der Gregorianische Kalender mit der entsprechenden Schaltjahresregelung.

Das Jahr 0 gibt es nicht, so folgt auf den 31.12.1 BC der 1.1.1 AD.

Interessant ist, dass es einen Zeitraum gibt, in dem J. Kalender und G. Kalender übereinstimmem, würden wir sie übereinander legen (1.3.200 AD bis 28.2.300 AD) und auf den 1.1.4713 BC gerechnet ergibt sich eine Differenz von -38 Tagen. Zuletzt hat sich die Differenz von +12 auf +13 Tage erhöht im Jahr 1900. Die Differenz ist also auch noch vorzeichenbehaftet.

Der Maya-Kalender ist wesentlich einfacher, das Berechnen fortlaufender Tage, z.B. aus dem (heutigen) Maya-Datum 13.0.1.13.10 kann jedes Kind und der Tzolkin ist einfach nur ein sich wiederholender Tageszyklus mit 260 Tagen, aus diesem Zyklus eine außerirdische Herkunft des Maya-Kalenders herzuleiten ist unsinnig, sorry EvD. Anhand des Maya-Kalenders können wir jedoch mit hoher Wahrscheinlichkeit ableiten, dass mit unserer Zeitrechnung einiges im Argen liegt ;)

Zum Umrechnen von Datierungen zwischen verschiedenen Kalendern ist eine Formel zum Berechnen fortlaufender Tage unerläßlich und es muss die Korrelation bekannt sein. Nach Goodmann-Martinez-Thompson gilt eine Differenz von 584283 Tagen (+- 1 Tag) als wahrscheinliche Korrelation zum Kalender der Maya.

Von Thompson hatte ich mal ein schönes Buch, eine Originalausgabe Maya Hyroglyphic Writing der Oklahoma Press. Leider nur leihweise, aber Informationen aus erster Hand. Den Pariser Codex muss ich mir unbedingt mal anschauen, das sind Original Schriften der Maya, die im Paris aufbewahrt werden, analog gibt es noch den Dresdener Codex und eine Schriftenrolle in Madrid.

Für EvD, Erich von Däniken, den ich auch persönlich kenne, breche ich trotzdem eine Lanze: Die Steinzeit war ganz anders! Indes, die Datierung 11. August 3114 BC (Maya 0.0.0.0.0 Long Count, Korrelationszahl 584283) ist eine Angabe nach dem Gregorianischen Kalender und entspricht dem 6. September 3114 BC.

In Maya Hyroglyphic Writing (Thompson) gibt es eine ganze Menge von Datierungen nach dem Gregorianischen Kalender für Datierungen BC (before Christ) obwohl es die G. Reform da noch gar nicht gab. Newstyle, Oldstyle sind die gebräuchlichen Begriffe in USA.

Maya-Datierung umrechnen heißt umrechnen zwischen 3 Kalendern.

MfG

[hotti]

hi,

Maya-Datierung umrechnen heißt umrechnen zwischen 3 Kalendern.

Der Haken an der Sache ist der: Wenn zwischen 2 Kalendern umgerechnet werden soll, muss die Korrelationszahl bekannt sein, diese Zahl gibt die Differenz in Tagen an. Unglücklicherweise ist die Korrelationszahl zwischen dem Greg. und dem Jul. Kalender nicht konstant, sondern abhängig vom Datum (heute sind es 13 Tage, am 1.1.4713 BC waren es -38 Tage).

Mit der Annahme, dass JK und GK in bestimmten Zeiträumen (Epoche) gelten, einschließlich der Greg. Reform, ergibt sich beim Addieren von 1 Tag zum 4.10.1582 der 15.10.1582 und der fortlaufende Tag ändert sich von 2299160 zu 2290161. Programmiertechnisch ist bei einem vorgegebenen Julianischen Tag also nur zu prüfen, ob dieser <= 2299160 ist und die gute Nachricht: Nach den Formeln von J.J. Scaliger sind in diesem Fall nur zwei weitere Variablen zu ändern, welche in seinem Algorithmus zum Einsatz kommen.

Die komplette JavaScript-Library stelle ich auf meiner Seite vor.

"use strict";

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen.

Einen regulären Ausdruck etwa?

Nochmal fürs Archiv die Warnung, dass ich damit nur die Möglichkeit aufzeigen wollte. Man sollte den regulären Ausdruck zur Datumsprüfung keinesfalls wirklich einsetzen.

Qapla'

[hotti]

hi,

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen.

Einen regulären Ausdruck etwa?

Nochmal fürs Archiv die Warnung, dass ich damit nur die Möglichkeit aufzeigen wollte. Man sollte den regulären Ausdruck zur Datumsprüfung keinesfalls wirklich einsetzen.

Jetzt mach Dich nicht fertig ;)
Mit meiner Fehlerbehandlung bin ich hier auch noch nicht ganz im Grünen, am Besten wir überschlafen das mal ;)

PS: Neulich im Freibad hat mich meine Frau belächelt, weil ich meine Sachen immer zu einem Päckchen baue, alles schön auf Kante und ausgerichtet...

[hotti]

hi,

Jetzt mach Dich nicht fertig ;)
Mit meiner Fehlerbehandlung bin ich hier auch noch nicht ganz im Grünen, am Besten wir überschlafen das mal ;)

PS: Neulich im Freibad hat mich meine Frau belächelt, weil ich meine Sachen immer zu einem Päckchen baue, alles schön auf Kante und ausgerichtet...

Isset jetze auch in der Lib, Link s.o.

Steht frei zum Testen, gerne Feedback.

MfG

[1UnitedPower]

Meine Herren!

Ich räum das Pferd mal von hinten auf, denn jetzt ist mir einiges klarer geworden:

weil trivialer Weise alle Tage der julianischen Epoche länger als fünf Tage in der Vergangenheit liegen

Diese Aussage ist totaler Unfug.

Stimmt, ich habe mich hier von den vielen Begrifflichkeiten die sich um diesen gewissen Julius scharen wohl entgültig verwirren lassen. Julianisher Kalendar, julinanisches Datum, julianische Epoche, julianische Periode. Was ich hier eigentlich ausdrücken wollte, kann ich selbst nicht mehr rekonstruieren. Tun wir so, als hätte ich das nie gesagt.

Ein Datum auf Gültigkeit prüfen, da habe ich schon die tollsten Sachen gesehen. Mit Scaliger ist das ganz einfach, hier der Algorithmus.

Und mit Zeitstempeln ist das noch viel einfacher: Ist der Zeitstempel eine Zahl? Dann ist er gültig. Zeitstempel sind genau wie die julianische Tageszählung unabhängig von Schaltjahren und anderen Unregelmäßigkeiten.

Aber prüfe um Gottes Willen, ob Dein Rechner nicht in die Knie geht, wenn Du overheadige Libraries einbindest ;)

Mein Argument war hier nicht Ressourcen-Knappheit. Ich finde den Overhead an dieser Stelle aus architektonischer Sicht nicht tragbar. Ich würde hier nach dem Vogelstrauß-Algorithmus vorgehen.

[1UnitedPower]

Meine Herren!

Mit der Sekunden-Interpretation sind damit immerhin 106468076297 Jahre darstellbar.

Da habe ich mich verechnet, die Zahl muss noch durch Anzahl der Tage in einem Jahr geteilt werden, dann ergibt sich grob eine Spanne von 291693359 Jahren. Das dürfte immernoch ausreichen.

Interessante Entdeckung, die ich gerade in der Spezifikation gemacht habe. JavaScripts Date-Objekte nutzen nicht den vollen Safe-Integer-Wertebereich aus:

„The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000
days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives
a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.“

Das ergibt eine Spanne von grob 547945 Jahren. Auch das sollte locker ausreichen. Das Aussterben der Dinosaurier lässt sich damit zwar nicht mehr erfassen, aber wir können ja heute sowieso nicht mehr nachvollziehen, ob der Asteorid uns an einem Montag oder Dienstag getroffen getroffen hat.

[hotti]

Moin,

hier drin ist eine kleine Lib von mir verlinkt: Scaliger.js

Warum verlinkst du die Lib hier nicht direkt?

die ist noch nicht fertig (1).

Fertig ist jedoch das Perlmodul

MfG

[hotti]

hier drin ist eine kleine Lib von mir verlinkt: Scaliger.js

Warum verlinkst du die Lib hier nicht direkt?

Warum nicht direkt nicht ;)