Funktion mit Rückgabe des Datums vor 365 Tagen

[stefan]

Hallo zusammen,

kann mir jemand einen Tipp geben was ich hierbei noch falsch mache. Ich möchte eine Funktion erstellen die als Paramater z.B. den wert 20080227 übergeben bekommt und soll von dieser 365 Tage abziehen. Meine Funktion schaut bis jetzt so aus.

function nDate(datum) {
  var Zeit = new Date(datum);
  var Aktuell = Zeit.getTime();
  var Danach = Math.floor(Aktuell - (365 * 24 * 60 * 60 * 1000));
  Zeit.setTime(Danach);
  var Jahr = Zeit.getFullYear();
  var Monat = Zeit.getMonth() + 1;
  Monat= ((Monat<10) ? "0" : ".") + Monat;
  var Tag = Zeit.getDate();

//return Tag + "." + Monat + "." + Jahr;
  return Jahr + Monat + Tag;
}

es klappt aber leider nicht, was mache ich noch falsch ???

Viele Grüße
Stefan

[Harlequin]

Yerf!

es klappt aber leider nicht, was mache ich noch falsch ???

Du hast vergessen zu beschreiben *was* nicht geht...

unabhängig davon, wenn du 365 Tage zurück willst, warum dann nicht so:

function nDate(datum) {
   var Zeit = new Date(datum);
   var Zeit.setDate(Zeit.getDate()-365);
   alert(Zeit);
}

Oder auch: wann war der -337. Februar 2008? ;-)

Gruß,

Harlequin

[stefan]

Du hast vergessen zu beschreiben *was* nicht geht...

hupps, ja hatte ich vergessen.
Also ich will ein Datum im Parameter (wird aus DB gezogen) mit einem Wert z.B. 20080227 übergeben und als Rückgabe will ich 20070227 erhalten und das klappt hier nicht.

[Harlequin]

Yerf!

Also ich will ein Datum im Parameter (wird aus DB gezogen) mit einem Wert z.B. 20080227 übergeben und als Rückgabe will ich 20070227 erhalten und das klappt hier nicht.

Hm, klar. SelfHTML weis auch wieso: du musst das Datum erst in ein Format bringen, dass zum erstellen eines Date-Objektes beutzt werden kann. Entweder änderst du die DB-Abfrage, so dass das passende Format kommt oder du zerlegst das Datum in der Javascriptfunktuion in die Einzelteile und übergibst die dann an new Date().

Gruß,

Harlequin

[stefan]

Yerf!

Also ich will ein Datum im Parameter (wird aus DB gezogen) mit einem Wert z.B. 20080227 übergeben und als Rückgabe will ich 20070227 erhalten und das klappt hier nicht.

Hm, klar. SelfHTML weis auch wieso: du musst das Datum erst in ein Format bringen, dass zum erstellen eines Date-Objektes beutzt werden kann. Entweder änderst du die DB-Abfrage, so dass das passende Format kommt oder du zerlegst das Datum in der Javascriptfunktuion in die Einzelteile und übergibst die dann an new Date().

Gruß,

Harlequin

also spliten und mit komma zusammenfügen.

hier wird Objektname = new Date("Monat Tag, Jahr Stunden:Minuten:Sekunden"); beschrieben geht es auch so ? Objektname = new Date("Monat Tag, Jahr");

erst mal vielen Dank an Dich, werde es einfach mal versuchen.

Gruß
Stefan

[molily]

Hallo,

also spliten und mit komma zusammenfügen.

Wieso so umständlich?

Wenn du drei Variable mit Jahr, Monat und Tag hast, kannst du einfach new Date(Jahr, Monat, Tag) notieren.

hier wird Objektname = new Date("Monat Tag, Jahr Stunden:Minuten:Sekunden"); beschrieben geht es auch so ? Objektname = new Date("Monat Tag, Jahr");

Wenn es da nicht steht, nein, aber da stehen ohnehin sinnvollere Aufrufweisen.

Mathias

[Horst]

Hi,

kann mir jemand einen Tipp geben was ich hierbei noch falsch mache. Ich möchte eine Funktion erstellen die als Paramater z.B. den wert 20080227 übergeben bekommt und soll von dieser 365 Tage abziehen.

Sowas rechnest Du besser über den Julianischen Tag: Der Julianische Tag (Julian Day) ist gleich der Zahl der seit dem 1.1. -4713 (bezogen auf den Gregorianischen Kalender) abgelaufenen Tage.

Formeln zur Berechnung findest Du mit der Suchmaschine.

Viele Grüße,
Hotte

[molily]

Hallo,

kann mir jemand einen Tipp geben was ich hierbei noch falsch mache. Ich möchte eine Funktion erstellen die als Paramater z.B. den wert 20080227 übergeben bekommt und soll von dieser 365 Tage abziehen.

Sowas rechnest Du besser über den Julianischen Tag: Der Julianische Tag (Julian Day) ist gleich der Zahl der seit dem 1.1. -4713 (bezogen auf den Gregorianischen Kalender) abgelaufenen Tage.

Warum eigentlich, was hat das für Vorteile? (Ernsthafte, keine zweifelnde Frage, würde mich halt interessieren.)

Ich kann in JavaScript einem Unix-Timestamp einfach 365 Tage abziehen, was ist daran nicht ausreichend? (Vor der Unix-Epoch wird der Timestamp halt negativ, Daten sind aber darstellbar.)

Mathias

[Horst]

Hallo,

kann mir jemand einen Tipp geben was ich hierbei noch falsch mache. Ich möchte eine Funktion erstellen die als Paramater z.B. den wert 20080227 übergeben bekommt und soll von dieser 365 Tage abziehen.

Sowas rechnest Du besser über den Julianischen Tag: Der Julianische Tag (Julian Day) ist gleich der Zahl der seit dem 1.1. -4713 (bezogen auf den Gregorianischen Kalender) abgelaufenen Tage.

Warum eigentlich, was hat das für Vorteile? (Ernsthafte, keine zweifelnde Frage, würde mich halt interessieren.)

Diffrenzen (ich meine solche auch abweichend von genau 365 Tagen) von Datumsangaben über längere Zeiträume lassen sich gar nicht anders berechnen. Btw., dieses Jahr hat 366 Tage.

Ich kann in JavaScript einem Unix-Timestamp einfach 365 Tage abziehen, was ist daran nicht ausreichend? (Vor der Unix-Epoch wird der Timestamp halt negativ, Daten sind aber darstellbar.)

Naja, Du meinst die Unix-Epoch und 365 Tage.

Viele Grüße,
Hotte

[molily]

Hallo,

Diffrenzen (ich meine solche auch abweichend von genau 365 Tagen) von Datumsangaben über längere Zeiträume lassen sich gar nicht anders berechnen. Btw., dieses Jahr hat 366 Tage.

Hmm, gut, wenn ich wissen will, welcher Tag vor einem Jahr war, dann mache ich natürlich nicht d.setDate(d.getDate() - 365), sondern
d.setFullYear(d.FullYear() - 1).
new Date(2007, 1, 29, 12)
gibt mir sinnigerweise
Thu Mar 01 2007 12:00:00 GMT+0100

Wenn ich zehn Monate in die Vergangenheit will, nehme ich d.setMonth(d.getMonth() - 10) und so weiter. Das dürfte doch für die meisten solcher Berechnungen reichen, oder übersehe ich etwas?

Mathias

[Horst]

Hallo,

Wenn ich zehn Monate in die Vergangenheit will, nehme ich d.setMonth(d.getMonth() - 10) und so weiter. Das dürfte doch für die meisten solcher Berechnungen reichen, oder übersehe ich etwas?

Mach den Lackmustest ;)

Wieviele Tage liegen zwischen dem 12.10.1476 und den 11.9.1945 ??

Kriegse das mit Javascript hin?

Viele Grüße,
Hotte

[Jens Holzkämper]

Tach,

Wieviele Tage liegen zwischen dem 12.10.1476 und den 11.9.1945 ??
Kriegse das mit Javascript hin?

(new Date(1945,8,11).getTime()-new Date(1476,9,12).getTime())/(1000*60*60*24)
ergibt 171267

Dabei gehe mal davon aus, dass beide Daten im gregorianischen Kalender angegeben sind (sollte das erste Datum julianisch sein, muß man halt noch 10 Tage abziehen), ein anderer ist in Javascript nicht vorgesehen; für solche Zeiträume ist eine Datumsklasse, die mit milisekundengenauen Timestamps arbeitet, sowieso eher überdimensioniert.

mfg
Woodfighter

[Gunnar Bittersmann]

@@Jens Holzkämper:

für solche Zeiträume ist eine Datumsklasse, die mit milisekundengenauen Timestamps arbeitet, sowieso eher überdimensioniert.

Und sowieso unsinnig, wenn sie nicht auch Schaltsekunden berücksichtigt.

Live long and prosper,
Gunnar

[molily]

Hallo,

für solche Zeiträume ist eine Datumsklasse, die mit milisekundengenauen Timestamps arbeitet, sowieso eher überdimensioniert.

Und sowieso unsinnig, wenn sie nicht auch Schaltsekunden berücksichtigt.

Ja, »Leap seconds are ignored.« (ECMAScript 15.9.1.1)

Aber meine Frage war eher, was man mit JavaScript machen kann und was nicht und welchen Vorteile Berechnungen über den Julianischen Tag haben, also in welchen Fällen sie genauer sind und warum. Werden da denn Schaltsekunden beachtet?

Mathias

[Gunnar Bittersmann]

@@molily:

Aber meine Frage war eher, was man mit JavaScript machen kann und was nicht und welchen Vorteile Berechnungen über den Julianischen Tag haben, also in welchen Fällen sie genauer sind und warum.

Für die Berechnung der Differenz zweier Zeitpunkte ist natürlich völlig belanglos, wo der Nullpunkt auf der Zeitachse liegt.

Man muss nur wissen, in welcher Einheit das Ergibnis vorliegt: Tage (Julianisches Datum, Excel), Sekunden (PHP) oder Millisekunden (JavaScript).

Werden da denn Schaltsekunden beachtet?

Kommt drauf an. „Wird ein Julianisches Datum verwendet, das auf einer ungleichförmigen Zeitskala beruht (z. B. UTC), so ist bei der Berechnung von Zeitdifferenzen gegebenenfalls eine Korrektur nötig (im Beispiel UTC: Berücksichtigung von Schaltsekunden).“ [Wikipedia]

Live long and prosper,
Gunnar

[Christian Seiler]

Hallo Gunnar,

für solche Zeiträume ist eine Datumsklasse, die mit milisekundengenauen Timestamps arbeitet, sowieso eher überdimensioniert.

Und sowieso unsinnig, wenn sie nicht auch Schaltsekunden berücksichtigt.

Nein, nicht unbedingt. Es hängt stark von der verwendeten Zeitskala ab. Einigt man sich darauf, dass eine Sekunde als 86400ter Bruchteil eines Tages anzusehen ist und keine konstante Länge hat (UT1 wäre ein Beispiel für so eine Zeitskala), dann benötigt man keine Schaltsekunden. Verwendet man dagegen eine Zeitskala, in der man nur mit SI-Sekunden rechnet, aber einen Tag immer als 86400faches einer Sekunde definiert und dabei in Kauf nimmt, dass es durch die Ungenauigkeiten in der Erdrotation eben mit der Zeit drastische Abweichungen geben wird (TAI wäre ein Beispiel für so eine Zeitskala), benötigt man ebenfalls keine Schaltsekunden. Nur, wenn man sowohl eine konstante Sekundendefinition UND die Anpassung an die Erdrotation haben will (Zeitskala UTC), DANN benötigt man Schaltsekunden.

Wobei es akademisch ist, über Schaltsekunden zu sprechen, wenn man Daten vor 1970 betrachtet, da zu diesem Zeitpunkt (etwa) Schaltsekunden "erfunden" wurden. Die Notwendigkeit für Schaltsekunden hat es jedoch mit Sicherheit auch zwischen 1476 und 1945 gegeben - man hat damals jedoch nicht die Möglichkeit gehabt, so genau zu messen, weswegen man ausschließlich eine unregelmäßige Sekundendefinition (d.h. immer 86400ter Bruchteil eines Tages) für alle Zeiten vor 1970 zu Grunde legen kann - alles andere ist einfach nicht sinnvoll.

Daher ist es für diese konkrete Rechnung in Ordnung, dass JS keine Schaltsekunden verwendet, da es diese zu der Zeit noch gar nicht gab. Eine Software, die Schaltsekunden berücksichtigt, wird Dir für diese Daten das gleiche Ergebnis liefern, wie diese JS-Rechnung.

Viele Grüße,
Christian

[Horst]

Tach,

auch

Wieviele Tage liegen zwischen dem 12.10.1476 und den 11.9.1945 ??
Kriegse das mit Javascript hin?

(new Date(1945,8,11).getTime()-new Date(1476,9,12).getTime())/(1000*60*60*24)
ergibt 171267

Das ist leider falsch. 171258 wäre richtig. Beide Datumsangaben oben beziehen sich auf den greg. Kal., sorry, hatte ich vergessen zu posten.

Viele Grüße,
Hotte

[molily]

Hallo,

(new Date(1945,8,11).getTime()-new Date(1476,9,12).getTime())/(1000*60*60*24)
ergibt 171267

Das ist leider falsch. 171258 wäre richtig. Beide Datumsangaben oben beziehen sich auf den greg. Kal., sorry, hatte ich vergessen zu posten.

Erklärst du mir das?

Mathias

[Christian Seiler]

Hallo!

(new Date(1945,8,11).getTime()-new Date(1476,9,12).getTime())/(1000*60*60*24)
ergibt 171267

Das ist leider falsch. 171258 wäre richtig. Beide Datumsangaben oben beziehen sich auf den greg. Kal., sorry, hatte ich vergessen zu posten.

Ist aber dummerweise beides falsch.

Der 11. August 1945 hatte die julianische Tageszahl 2431679. Der 12. September 1476 die julianische Tageszahl 2260413 (proleptischer gregorianischer Kalender, d.h. ISO 8601, angenommen). Die Differenz beider Werte ist 171266 Tage. Die JavaScript-Lösung verrechnet sich hier also um einen Tag. Meine Vermutung ist hier jedoch, dass - da die JS-Lösung in Millisekunden rechnet - dies durch mangelnde Präzision verursacht wird (oder in den Datumsroutinen der Browser ist ein Bug, kann natürlich auch sein).

Wenn man nun keinen proleptischen gregorianischen Kalender annimmt, sondern für Daten bis einschließlich dem 4. Oktober 1582 den julianischen Kalender und für Daten ab einschließlich dem 15. Oktober 1582 den gregorianischen Kalender, dann bleibt 2431679 die jul. Tageszahl des 11. August 1945 (nach 1582), aber der 12. September 1476 besitzt dann (vor 1582) die jul. Tageszahl 2260422 - was einer Differenz von 171257 Tagen entspricht, was nur um 1 von Deiner genannten Zahl abweicht. Du hast also nicht den gregorianischen Kalender verwendet, sondern sowohl gregorianischen als auch julianischen in Abhängigkeit des Datums (was zwar prinzipiell in Ordnung ist, weil das in jedem Geschichtsbuch genauso gemacht wird, aber nicht dem entspricht, was Du hier behauptet hast). Außerdem ist Deine Rechnung ebenfalls um 1 daneben.

Viele Grüße,
Christian

[Christian Seiler]

Hallo nochmal,

Meine Vermutung ist hier jedoch, dass - da die JS-Lösung in Millisekunden rechnet - dies durch mangelnde Präzision verursacht wird (oder in den Datumsroutinen der Browser ist ein Bug, kann natürlich auch sein).

Ich habe das ganze gerade nochmal überprüft, die JS-Lösung liefert mir für die getTime()/1000-Werte folgendes:

11. August 1945: -767062800
12. September 1476: -15564531600

Und siehe da - schon der erste Timestamp liefert mir incht den 11. August 1945, sondern den 10. September 1945 um 23:00 UTC, da Date in JS in Lokalzeit arbeitet [1] also den 11. September 1945 Lokalzeit. Jetzt lese man sich mal den Abschnitt in SELFHTML zum Date-Objekt durch und siehe da:

| Wenn Sie einen Monat als Zahlenwert übergeben, so wie in den Varianten 3
| und 4, müssen Sie bei 0 zu zählen beginnen. Für Januar müssen Sie also 0
| übergeben, für Februar 1, und für Dezember 11. Dies ist auch der Grund,
| warum für den Monat Oktober nicht 10 sondern 9 übergeben wird.

Und wenn man nun das Date-Objekt richtig nutzt, liefert JS das korrekte Ergebnis:

(new Date(1945,7,11).getTime()-new Date(1476,8,12).getTime())/(1000*60*60*24)

Ergibt: 171266

Und nun stimmt wieder alles.

Viele Grüße,
Christian

[1] Und Zeitzonendaten vor einem bestimmten Datum wohl nicht kennt, weswegen es für diese Daten einen GMT-Offset von 1h annimmt bei Deutscher Zeit.

[Jens Holzkämper]

Tach,

Und siehe da - schon der erste Timestamp liefert mir incht den 11. August 1945, sondern den 10. September 1945 um 23:00 UTC, da Date in JS in Lokalzeit arbeitet [1] also den 11. September 1945 Lokalzeit.

verdammt, die Zeitzonen sollten abgeschafft werden (ceterum censeo cingulo temporis esse delendo).

Und wenn man nun das Date-Objekt richtig nutzt, liefert JS das korrekte Ergebnis:

(new Date(1945,7,11).getTime()-new Date(1476,8,12).getTime())/(1000*60*60*24)

Ergibt: 171266

Und nun stimmt wieder alles.

nö, du hast nur meinen Fehler (den mit der Uhrzeit) wiederholt und zusätzlich die falschen Monate verwendet (die Javascripteigenheit Monate ab 0 zu zählen hatte ich bereits beachtet).
(new Date(1945,8,11,12,0).getTime()-new Date(1476,9,12,12,0).getTime())/(1000*60*60*24)
sollte das Problem mit den Zeitzonen lösen, liefert aber wieder 171267, das minus der 9 Tage(danke für die 1500er Korrektur) Differenz von julianisch zu gregorianisch, ergibt wieder Horsts 171258, der also mit einem julianischen und einem gregorianischen Datum gerechnet hat.

mfg
Woodfighter

[Christian Seiler]

Hallo Jens,

nö, du hast nur meinen Fehler (den mit der Uhrzeit) wiederholt

Nein, das mit der Uhrzeit war in dem Moment kein Fehler, weil der UTC-Offset für beide Daten gleich ist (vor 1970 haben die Browser wohl keine genauen Zeitzonen-Offset-Informationen, denn eigentlich war zumindest 1945 der Offset zu dem Zeitpunkt sogar +3h in Deutschland und nicht nur +1h, JS nimmt bei mir im Browser aber für <1970 immer +1h an).

Aber:

und zusätzlich die falschen Monate verwendet (die Javascripteigenheit Monate ab 0 zu zählen hatte ich bereits beachtet).

*argh* Verdammter Mist, mea culpa, mea maxima culpa. Ich habe in meinem ersten Posting Deine JavaScript-Parameter als richtige Daten angeommen und selbst das mit dem Monat nicht berücksichtigt. Deine JS-Rechnung war also doch korrekt.

Wenn Du Zeitzonen berücksichtigen willst, dann bitte richtig und nicht über 12 Uhr Mittags (dann müsstest Du nämlich auch noch runden):

(Date.UTC(1945,8,11)-Date.UTC(1476,9,12))/(1000*60*60*24)

Gut, hier ist's wie bereits erwähnt egal, weil JS den gleichen Offset annimmt.

Jetzt stimmt's hoffentlich vollständig.

Viele Grüße,
Christian

[molily]

Hallo,

(Date.UTC(1945,8,11)-Date.UTC(1476,9,12))/(1000*60*60*24)

Noch mal für Dumme wie mich zum Mitschreiben:
Rechnet JavaScript das jetzt korrekt (wenn man es sinnvoll und korrekt einsetzt)?

Mathias

[Christian Seiler]

Hallo Mathias,

(Date.UTC(1945,8,11)-Date.UTC(1476,9,12))/(1000*60*60*24)

Noch mal für Dumme wie mich zum Mitschreiben:
Rechnet JavaScript das jetzt korrekt (wenn man es sinnvoll und korrekt einsetzt)?

Ja.

Viele Grüße,
Christian

[MudGuard]

Hi,

verdammt, die Zeitzonen sollten abgeschafft werden (ceterum censeo cingulo temporis esse delendo).

Akkusativ mit Infinitiv, nicht Dativ oder Ablativ mit Infinitiv, also

Ceterum censes cingulum temporis esse delendum.

cu,
Andreas

[Jens Holzkämper]

Tach,

verdammt, die Zeitzonen sollten abgeschafft werden (ceterum censeo cingulo temporis esse delendo).

Akkusativ mit Infinitiv, nicht Dativ oder Ablativ mit Infinitiv, also

wah, Akkusativ gedacht und Ablativ gebildet.

mfg
Woodfighter

[Horst]

Hallo!

(new Date(1945,8,11).getTime()-new Date(1476,9,12).getTime())/(1000*60*60*24)
ergibt 171267

Das ist leider falsch. 171258 wäre richtig. Beide Datumsangaben oben beziehen sich auf den greg. Kal., sorry, hatte ich vergessen zu posten.

Ist aber dummerweise beides falsch.

Schau mal:
Beide Kalender, Julianischer und Gregorianischer stimmen überein im Zeitraum vom 1.3.200 - 28.2.300

In der gregorianischen Kalenderreform wurde festgelegt, dass auf den 4.10.1582 der 15.10.1582 folgt, weil bis dahin 10 Tage Differenz zum Julianischen Kalender aufgelaufen sind.

Wenn über den Julian Day gerechnet wird, ist also der Unterschied zwischen Beiden keine Konstante. Btw. die Differenz beträgt mittlerweile 13 Tage:

Die Eidgenossen haben ihr letztes Silvester dieses Jahr am 13.1.2008 gefeiert.

Viele Grüße,
Hotte

[Christian Seiler]

Hallo!

Ist aber dummerweise beides falsch.

Schau mal:
Beide Kalender, Julianischer und Gregorianischer stimmen überein im Zeitraum vom 1.3.200 - 28.2.300

Ohne nachgerechnet zu haben: Ja, klingt plausibel.

In der gregorianischen Kalenderreform wurde festgelegt, dass auf den 4.10.1582 der 15.10.1582 folgt, weil bis dahin 10 Tage Differenz zum Julianischen Kalender aufgelaufen sind.

Ja.

Wenn über den Julian Day gerechnet wird, ist also der Unterschied zwischen Beiden keine Konstante.

Ja.

Btw. die Differenz beträgt mittlerweile 13 Tage:

Ja, weil's 3 Jahrhundertwenden seit 1582 gab, die im GC kein Schaltjahr waren, im JC schon: 1700, 1800 und 1900, also 3 Tage mehr Differenz.

Die Eidgenossen haben ihr letztes Silvester dieses Jahr am 13.1.2008 gefeiert.

Der 1. Januar 2008 JC entspricht dem 14. Januar 2008 GC, weil 13 Tage nach dem 1. Januar eben der 14. Januar ist!

Daher bleibt meine Aussage: Beide Rechnungen sind falsch. Die JS-Rechnung, weil die falschen Parameter in die Funktion gesteckt wurden (September statt August etc.), Deine Rechnung, weil Du zum einen behauptet hast, den gregorianischen Kalender auch für das 1400er-Datum verwendet zu haben, obwohl Du den julianischen Kalender verwendet hast und zum anderen hast Du irgendwo Dich um 1 verrechnet.

Viele Grüße,
Christian

[Christian Seiler]

Hallo,

Daher bleibt meine Aussage: Beide Rechnungen sind falsch. Die JS-Rechnung, weil die falschen Parameter in die Funktion gesteckt wurden (September statt August etc.), Deine Rechnung, weil Du zum einen behauptet hast, den gregorianischen Kalender auch für das 1400er-Datum verwendet zu haben, obwohl Du den julianischen Kalender verwendet hast und zum anderen hast Du irgendwo Dich um 1 verrechnet.

Ok, das ziehe ich zu 2/3 zurück: Die JS-Rechnung stimmt, ich hatte bloß die falschen Tage angenommen (siehe meine Antwort auf Jens), Deine Rechnung stimmt für den julianischen Kalender für das 1400er-Datum. Ich bleibe aber weiterhin dabei, dass Deine Rechnung nicht korrekt ist, wenn man annimmt, dass beide Daten im gregorianischen Kalender sind.

Viele Grüße,
Christian

[Christian Seiler]

Hallo Jens,

Dabei gehe mal davon aus, dass beide Daten im gregorianischen Kalender angegeben sind (sollte das erste Datum julianisch sein, muß man halt noch 10 Tage abziehen),

Nein, 10 Tage abziehen ist nicht korrekt, da der proleptische gregorianische Kalender auch in die Vergangenheit hinein seine andere Schaltjahresregelung fortsetzt. Weil zwischen 1476 und 1582 noch das Jahr 1500 liegt, das im julianischen Kalender ein Schaltjahr ist, im gregorianischen aber nicht, darfst Du bei 1476 nur noch 9 Tage abziehen.

Viele Grüße,
Christian

[Christian Seiler]

Hallo Mathias,

Hmm, gut, wenn ich wissen will, welcher Tag vor einem Jahr war, dann mache ich natürlich nicht d.setDate(d.getDate() - 365), sondern
d.setFullYear(d.FullYear() - 1).
new Date(2007, 1, 29, 12)
gibt mir sinnigerweise
Thu Mar 01 2007 12:00:00 GMT+0100

Wenn ich zehn Monate in die Vergangenheit will, nehme ich d.setMonth(d.getMonth() - 10) und so weiter. Das dürfte doch für die meisten solcher Berechnungen reichen, oder übersehe ich etwas?

Ja, wenn man explizit mit diesen Methoden arbeitet, dann ist man aus dem Schneider (auch bzgl. der Lokalzeitproblematik, die nimmt einem JS dann ab). Problematisch wird's eben nur, wenn man Vielfache von 86400 Sekunden als Tag betrachtet und in Lokalzeit rechnet.

Viele Grüße,
Christian

[Christian Seiler]

Hallo Mathias,

kann mir jemand einen Tipp geben was ich hierbei noch falsch mache. Ich möchte eine Funktion erstellen die als Paramater z.B. den wert 20080227 übergeben bekommt und soll von dieser 365 Tage abziehen.

Sowas rechnest Du besser über den Julianischen Tag: Der Julianische Tag (Julian Day) ist gleich der Zahl der seit dem 1.1. -4713 (bezogen auf den Gregorianischen Kalender) abgelaufenen Tage.

Warum eigentlich, was hat das für Vorteile? (Ernsthafte, keine zweifelnde Frage, würde mich halt interessieren.)

Ich kann in JavaScript einem Unix-Timestamp einfach 365 Tage abziehen, was ist daran nicht ausreichend? (Vor der Unix-Epoch wird der Timestamp halt negativ, Daten sind aber darstellbar.)

Naja, es gibt da zwei Vorteile:

1. Kleinere Zahlen: Wenn man Sekunden oder Millisekunden nimmt, dann kann
   es sehr gut sein, dass man das nicht mehr als Ganzzahl darstellen kann.
   Dann gibt's in einigen Programmiersprachen überläufe, was extrem häßlich
   ist und andere Programmiersprachen greifen dann auf Gleitkommazahlen
   zurück - was aber zu einem Verlust in Genauigkeit führt (was aber im
   Gegensatz zu Überläufen im Zweifel noch verschmerzbar ist).

2. Sommer- und Winterzeit: Das Problem ist, das man immer dazu neigt,
   Lokalzeit zu betrachten - die ist aber nicht kontinuierlich, weil ein
   Tag durchaus mal 25 oder nur 23 Stunden haben kann wegen Umstellungen
   von Sommer- auf Winterzeit. Dies führt dann bei Berechnungen zu
   Problemen.

Als Beispiel: Zwischen dem 25. Oktober 2008 12:00 Lokalzeit Berlin und
   dem 27. Oktober 2008 12:00 Lokalzeit Berlin liegen 49 Stunden und nicht
   bloß 48 Stunden. Wenn man also auf den 25. Oktober 2008 00:00 Lokalzeit
   Berlin 48 Stunden addiert und sich dann nur den Datumsteil ausgeben
   lässt, landet man nicht mehr beim 27. Oktober 2008, sondern nur beim
   26. Oktober 2008 (halt um 23:00, aber die Information schmeißt man ja
   weg).

Man kann das umgehen, wenn man immer in UTC rechnet. Dann ist nämlich
   auch die Zeitskala kontinuierlich (Schaltsekunden werden in JS sowieso
   nicht berücksichtigt) und man kann wirklich mit Vielfachen von 86400
   Sekunden arbeiten. Wenn man das berücksichtigt und sich in Bereichen
   bewegt, in denen die Zahlen nicht zu groß werden, spricht also nichts
   gegen die Verwendung von Timestamps auf Sekunden/Millisekundenbasis.
   Man muss aber immer aufpassen, dass man nie in die Lokalzeitfalle tappt.

Viele Grüße,
Christian

[Christian Seiler]

Hallo!

Der Julianische Tag (Julian Day) ist gleich der Zahl der seit dem 1.1. -4713 (bezogen auf den Gregorianischen Kalender) abgelaufenen Tage.

Nein, nicht bezogen auf den gregorianischen, sondern auf den juliansichen Kalender! Deswegen heißt's auch julianischer Tag!

Der gregorianische Kalender beginnt offiziell am 15. Oktober 1582, der dem 5. Oktober 1582 in dem damals gebräuchlichen julianischen Kalender entspricht. Davor gab es den Kalender schlichtweg nicht. Man definiert sich jedoch auch einen sogenannten proleptischen gregorianischen Kalender (das ist auch der Kalender, den ISO 8601 definiert), den man einfach zurückrechnet auf Daten vor dem 15. Oktober 1582. Wenn Du also von einem Datum 1.1.4713 v.u.Z. im gregorianischen Kalender sprichst, meinst Du den 18.2.4713 v.u.Z. im julianischen Kalender!

[Strenggenommen gab's den julianischen Kalender in der jetztigen Form auch nicht vor der Zeit von Kaiser Augustus, allerdings hat es sich eingebürgert, den julianischen Kalender grundsätzlich proleptisch zu betrachten, den gregorianischen jedoch nicht!]

Zudem: Wenn man Kalenderberechnungen anstellt, dann bezeichnet -4712 das Jahr 4713 v.u.Z., genauso wie -1000 das Jahr 1001 v.u.Z. oder 0 das Jahr 1 v.u.Z. bezeichnet. Hintergrund ist der, dass es ein Jahr 0 in der Umgangssprache nicht gibt, der Computer aber gerne eine kontinuierliche Jahresskala hat. Daher ist der julianische Tag definiert als die Anzahl der Tage seit ENTWEDER dem 1.1.4713 v.U.Z. JC ODER dem 1. Januar -4712 JC, aber NICHT als die Anzahl Tage seit dem 1. Januar -4713 JC!

Viele Grüße,
Christian