Java Datum vs. Kalender

Question

Könnte bitte jemand die derzeitige "beste Praxis" in Bezug auf Date y Calendar Typen.

Ist es am besten, beim Schreiben von neuem Code immer die Calendar über Date oder gibt es Umstände, unter denen Date der geeignetere Datentyp ist?

Answer 1

Ich verwende im Allgemeinen Date, wenn möglich. Obwohl es veränderbar ist, sind die Mutatoren eigentlich veraltet. Am Ende umhüllt es im Grunde einen Long, der das Datum/die Uhrzeit darstellen würde. Umgekehrt würde ich Calendars verwenden, wenn ich die Werte zu manipulieren haben.

Sie können sich das so vorstellen: Sie verwenden StringBuffer nur dann, wenn Sie Strings benötigen, die Sie leicht manipulieren und dann mit der Methode toString() in Strings umwandeln können. Auf die gleiche Weise verwende ich Calendar nur, wenn ich zeitliche Daten verarbeiten muss.

Als Best Practice neige ich dazu, unveränderliche Objekte so oft wie möglich außerhalb der Domänenmodell . Dadurch wird das Risiko von Seiteneffekten erheblich reduziert, und der Compiler erledigt dies für Sie, anstatt einen JUnit-Test durchzuführen. Sie verwenden diese Technik, indem Sie private Endrunde Felder in Ihrer Klasse.

Und um auf die StringBuffer-Analogie zurückzukommen. Hier ist ein Code, der zeigt, wie man zwischen Kalender und Datum konvertiert

String s = "someString"; // immutable string
StringBuffer buf = new StringBuffer(s); // mutable "string" via StringBuffer
buf.append("x");
assertEquals("someStringx", buf.toString()); // convert to immutable String

// immutable date with hard coded format.  If you are hard
// coding the format, best practice is to hard code the locale
// of the format string, otherwise people in some parts of Europe
// are going to be mad at you.
Date date =     new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2001-01-02");

// Convert Date to a Calendar
Calendar cal = Calendar.getInstance();
cal.setTime(date);

// mutate the value
cal.add(Calendar.YEAR, 1);

// convert back to Date
Date newDate = cal.getTime();

// 
assertEquals(new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2002-01-02"), newDate);

Answer 2

Date s sollten als unveränderliche Zeitpunkte verwendet werden; Calendar s sind veränderbar und können weitergegeben und geändert werden, wenn Sie mit anderen Klassen zusammenarbeiten müssen, um ein endgültiges Datum zu finden. Betrachten Sie sie analog zu String y StringBuilder und Sie werden verstehen, wie sie meiner Meinung nach verwendet werden sollten.

(Und ja, ich weiß, dass Date technisch gesehen nicht unveränderbar ist, aber die Absicht ist, dass es nicht veränderbar sein sollte, und wenn nichts die veralteten Methoden aufruft, dann ist es so).

Answer 3

Mit Java 8, dem neuen java.time-Paket verwendet werden sollte.

Objekte sind unveränderlich, Zeitzonen und Sommerzeit werden berücksichtigt.

Sie können eine ZonedDateTime Objekt aus einer alten java.util.Date Objekts wie dieses:

    Date date = new Date();
    ZonedDateTime zonedDateTime = date.toInstant().atZone(ZoneId.systemDefault());

Answer 4

Ich plädiere immer für Joda-Zeit . Hier ist der Grund dafür.

1. die API ist konsistent und intuitiv. Anders als die java.util.Date/Calendar-APIs
2. es leidet nicht unter Threading-Problemen, im Gegensatz zu java.text.SimpleDateFormat usw. (ich habe zahlreiche Client-Probleme gesehen, die darauf zurückzuführen sind, dass die Standardformatierung von Datum und Uhrzeit nicht thread-sicher ist)
3. ist die Grundlage der neuen Java-Datum/Zeit-APIs ( JSR310 , geplant für Java 8. Sie werden also APIs verwenden, die zu Kern-Java-APIs werden.

EDIT: Die mit Java 8 eingeführten Java Datum/Zeit-Klassen sind jetzt die bevorzugte Lösung, wenn Sie auf Java 8 migrieren können.

Answer 5

Ein bisschen spät, aber Java hat eine neue Date Time API in JDK 8. Sie möchten vielleicht Ihre JDK-Version aktualisieren und den Standard übernehmen. Kein chaotisches Datum/Kalender mehr, keine 3rd-Party-Jars mehr.