Eigenartige Datumsberechnung über GregorianCalendar

[kodela]

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:

    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:

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

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

 

[Thallius]

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

 

[kodela]

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

 

[X5-599]

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".

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.

 

[VfL_Freak]

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

 

[InfectedBytes]

ansonsten hat Java8 endlich auch mal eine brauchbare time API
http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

schon traurig, dass es 20 Jahre dauerte bis Java eine nutzbare Zeit API hat...

 

[kodela]

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]

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

Hallo Klaus,

ja, das sehe ich auch so.

MfG, kodela

 

[kodela]

ansonsten hat Java8 endlich auch mal eine brauchbare time API

Hallo InfectedBytes,

die habe ich mir einmal angesehen, für mich scheint alles sehr kompliziert zu sein, ist es vermutlich ja auch, aber vielleicht kapiere ich es doch noch.

MfG, kodela

 

[VfL_Freak]

Moin,

habe eben noch gefunden, dass der GregorianCalendar die Methode "IsLeapYear(Int32, Int32)" gibt, die bestimmt, ob das angegebene Jahr im angegebenen Zeitraum ein Schaltjahr ist ....

https://books.google.de/books?id=fj...nepage&q=GregorianCalendar Schaltjahr&f=false

Vielleicht Dir ja auch das weiter

Gruß Klaus

 

[X5-599]

@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.

 

[kodela]

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:

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

 

[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

 

[X5-599]

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

 

[kodela]

Kann ich dir nicht beantworten.

Hallo X5-599,

das habe ich auch nicht erwartet. Siehst Du irgend wo ein Fragezeichen?

Trotzdem nochmals ein großes DANKE, denn es war doch noch sehr wichtig für mich, da man für Apps unter Android Java 8 (noch) nicht einbinden kann.

MfG, kodela

 

[VfL_Freak]

Moin,

Siehst Du irgend wo ein Fragezeichen?

Im Prinzip schon: Wie kann man aber nur einen solchen Fallstrick einbauen
"WIE" ist halt ein Fragewort - auch wenn's hier vlt. nur rhetorisch gemeint war ....

Gruß Klaus