Eigenartige Datumsberechnung über GregorianCalendar

kodela

Bekanntes Mitglied
Hallo,

für eine App, die an besondere Ereignisse erinnern soll, habe ich die Differenz zwischen dem aktuellen Tag und dem Tag des auszuwertenden Ereignisses über folgende Funktion berechnet:

Java:
    private int getDiff2heute(int jr, int mn, int tg) {

        GregorianCalendar jubeltag = new GregorianCalendar (jr, mn, tg);
        GregorianCalendar is_heute = new GregorianCalendar (jahr, monat, tag);

        long jt = jubeltag.getTimeInMillis();
        long ht = is_heute.getTimeInMillis();

        return (int) ((jt - ht) / 1000 / 60 / 60 / 24);
    }
Mit jr, mn, und tg werden das Jahr, der Monat und der Tag des auszuwertenden Ereignisses übergeben. Auf das aktuelle Datum wird über die global definierten Variablen Jahr, monat und tag zurückgegriffen.

getTimeInMillis() soll für die jeweiligen Tage die Zeit in Millisekunden zurück liefern. Aus der Differenz der beiden Werte wird über den Ausdruck (int) ((jt - ht) / 1000 / 60 / 60 / 24) die Differenz in Tagen berechnet und der aufrufenden Funktion übergeben. Das hat bisher immer funktioniert.

Nun habe ich einen Fall, der möglicherweise mit dem Schaltjahr (2016) zusammenhängt, in dem das Ergebnis falsch ist. Für ein Beispiel habe ich als aktuellen Tag den 02.02.2016 eingestellt. Auszuwerten waren ein Ereignis am 12.02.2016 (Differenz 10 Tage) und eines am 02.03.2016 (Differenz 30 Tage).

Ich denke, dass ich mich nicht verrechnet habe, denn sowohl CALC wie auch Excel kommen zum selben Ergebnis. Hier ein Bild von CALC:

differenz_calc-png.8591

und hier nun ein Bild von dem Ergebnis, zu dem die Funktion getDiff2heute() kommt.

differenz_n-png.8593


Die Differenz für Konrad ist richtig, die für Demetrio dagegen falsch.

Setze ich den aktuellen Tag zum Beispiel auf den 01.03.2016 ist das Ergebnis dagegen auch für Demetrio wieder richtig.

Wer hat dafür eine Erklärung und wer weiß, ob dieser Fehler eventuell verhindert werden kann?

MfG, kodela
 

Anhänge

  • differenz_CALC.png
    differenz_CALC.png
    2,2 KB · Aufrufe: 82
  • differenz_n.png
    differenz_n.png
    23,4 KB · Aufrufe: 81
Zuletzt bearbeitet:
Ka ob es damit zusammen hängt aber Dein Ergebnis wird so oder so falsch sein, wenn zwischen den Daten die Umstellung von Sommer- auf Winterzeit, bzw anders herum liegt.

Tatsächlich scheint es in Java da nicht viel zu geben. Das einzige was ich auf die schnelle gefunden habe ist wohl JodaTime zu benutzen.

Gruß

Claus
 
Hallo Claus,

da die Umstellung auf die Sommerzeit erst am 27.03. stattfindet, kann ich mir nur schwer vorstellen, dass diese ursächlich für die falsche Rückgabe des Wertes für den 02.03. sein soll. Außerdem wird mit der Sommerzeit ja nur eine Stunde und kein ganzer Tag umgestellt.
Danke für Deinen Hinweis auf JodaTime. Damit muss ich mich aber erst noch näher befassen.

MfG, kodela
 
Also ich bei meinen Versuchen bin ich auf folgende Ursache gekommen. Das Monatsfeld im GregorianCalendar ist 0-basiert. Also musst du, wenn du die Methode aufrufst "immer 1 abziehen".
Code:
getDiff2heute(2016, 1, 2); //2016.02.02
getDiff2heute(2016, 2, 2); //2016.03.02

Und natürlich bei (ich nehme an deiner Instanzvariablen): "monat", ebenfalls.
 
Moin,

ich würde Dir auf Fall nur noch JodaTime empfehlen! Date oder GregorianCalendar haben immer mal wieder so ihre Probleme!
JodaTime erkennt sogar, wenn ein DateTime innerhalb der Lücke beim Wechsel von Winter- auf Sommerzeit erstellt wird!

Zu deinem Problem: wenn es am 1.3. läuft scheint da IMHO irgendein Problem mit dem Schalttag vorzuliegen ...

Gruß Klaus
 
Also musst du, wenn du die Methode aufrufst "immer 1 abziehen".
Hallo X5-599,

das kann nicht sein. Nimm nur das Beispiel. Da wird die Differenz im ersten Fall ja richtig berechnet und in den vielen anderen Fällen ja auch. Einzig dann, wenn zwischen den beiden Zeiten der 29. Februar liegt, kommt es zu dem Fehler.

MfG, kodela
 
@kodela

Dass es bei dem ersten Beispiel funktioniert liegt daran, dass er den Unterschied vom 02.03.2016 und 12.03.2016 berechnet. Denn wie gesagt ist der Kalendar 0 basiert (für Monate). Wenn du also tatsächlich das Monatsfeld des Kalendars als "2" für Februar setzt ist das falsch. 2 == März.
 
Hallo InfectedBytes,

hast Du schon
Dass es bei dem ersten Beispiel funktioniert liegt daran, dass er den Unterschied vom 02.03.2016 und 12.03.2016 berechnet. Denn wie gesagt ist der Kalendar 0 basiert (für Monate). Wenn du also tatsächlich das Monatsfeld des Kalendars als "2" für Februar setzt ist das falsch. 2 == März
Hallo X5-599,

da will ich Dir jetzt nicht widersprechen. Ich werde das auf jeden Fall noch prüfen.

Ich habe jetzt aber Dank des Hinweises von InfectedByts über die neue java-time Api eine eindeutig bessere Lösung. Damit sieht die eingangs gezeigte Funktion so aus:
Java:
private static int getDiff2heute(int jr, int mn, int tg) {
  LocalDate today = LocalDate.now();
  LocalDate jubeltag = LocalDate.of(jr, mn, tg);
  long dif = java.time.temporal.ChronoUnit.DAYS.between(today, jubeltag);

  return (int) dif;
}
Allen die mir geholfen haben, vielen Dank.

MfG, kodela
 
Hallo X5-599,

ja, es ist so, wie Du geschrieben hast. Wenn man die Zählung der Monte bei Null beginnt, dann ist das Ergebnis mit der zuerst von mir gezeigten Version ebenfalls richtig. Wie kann man aber nur einen solchen Fallstrick einbauen, für die Tage und Jahre beginnt die Zählung bei Eins und für die Monate bei Null.

Nochmals danke für Deinen Hinweis.

Mfg, kodela
 
Kann ich dir nicht beantworten. Ist halt schon immer so gewesen... Irgendeinen Grund wird's wohl gehabt haben. Ich bin mir aber sicher, dass schon eine ganze Menge Leute dieses Problem gehabt haben (mich eingeschlossen). Und die neue API LocalDate.of() gibt die Monate von 1 - 12 vor. Sieht also so aus als wenn sie aus ihren Fehlern gelernt hätten 🙂
 

Zurück
Oben