Joda Time's LocalDate beschreibt sich selbst als:
LocalDate ist eine unveränderbare Datetime-Klasse, die ein Datum ohne a darstellt Zeitzone.
Dennoch gibt es ein LocalDate(Object instant, DateTimeZone zone) Konstruktor, der die Zeitzone akzeptiert. Wenn das Objekt zeitzonenlos ist, was ist der Zweck des Zeitzonenkonstruktors?
Der Konstruktor JavaDocs gibt Folgendes an:
Konstruiert eine Instanz aus einem Objekt, das eine Datetime darstellt, erzwingt die Zeitzone auf den angegebenen Wert.
Ich weiß nicht, was mit "Erzwingen der Zeitzone auf den angegebenen Wert" gemeint ist, da das Objekt keine Zeitzone hat. Vielleicht wird es intern in UTC konvertiert, dann wird die Zeit gelöscht (behält das Datum bei).
Sie können nicht von einem Zeitpunkt zu einem lokalen Datum oder einer lokalen Uhrzeit konvertieren, ohne die Zeitzone (oder zumindest den Offset von UTC / Greenwich) zu kennen. Da das erste Argument ein Instant ist (z. B. Long oder java.util.Date , wird das zweite Argument benötigt, um die zu verwendende Zeitzone anzugeben.
Beachten Sie, dass es auch einen Konstruktor LocalDate(Object) gibt, der intern die Standardzeitzone verwendet.
Ein Instant ist ein Konzept aus dem Bereich der Physik. Es ist ein Zeitpunkt , gut definiert, unabhängig davon, wie Sie es darstellen. Es hat nichts mit Konzepten von Zeitzonen, Kalendern oder irgendwelchen Konventionen der menschlichen Kultur zu tun.
Beispiele: Der Moment, in dem die Apollo XI auf Mond landete , oder der Moment, als J. Kennedy erschossen wurde , sind Augenblicke. Jeder von ihnen könnte auf verschiedene Arten dargestellt werden: ein Julianischer Kalender, Sekunden, die verstrichen sind, seit die Titanic den Eisberg getroffen hat, ein Kalender, der von Außerirdischen benutzt wird, der auf dem Mars lebt ... all das wären unterschiedliche Darstellungen, aber der Augenblick wäre eine einzige (genau wie 1903 , 0x76F oder MCMIII sind verschiedene Darstellungen der gleichen Zahl).
Wenn Sie nun den "Zeitpunkt der Apollo XI Mondlandung" in ein LocalDate (ein Tag-Monat-Jahr, wie es in den Gregorianischen Kalendern auf der Erde verwendet wird) umwandeln wollen, werden Sie es tun ein völlig anderer Bereich, und - für eine Sache - müssen Sie die Zeitzone kennen, denn in einigen Ländern entspricht dieser Zeitpunkt (20. Juli 1969, 20:17:40 UTC) dem 20. Juli 1969, in anderen bis zum 21. Juli
Sie sollten den gesamten JavaDoc lesen:
Wenn das Objekt keine Chronologie enthält, wird ISOChronology verwendet. Wenn die Die angegebene Zeitzone ist null, die Standardzone wird verwendet. Einmal das Konstruktor ist abgeschlossen, die Zone wird nicht mehr verwendet.
Die erkannten Objekttypen werden in ConverterManager und definiert umfassen ReadablePartial, ReadableInstant, String, Calendar und Date. Die String-Formate werden beschrieben durch ISODateTimeFormat.localDateParser (). Der Standard-String-Konverter ignoriert die Zone und analysiert nur die Feldwerte.
Auf diese Weise geben die Darstellungen des Datums (String, Kalender, Datum usw.) zusammen mit der angegebenen Zeitzone die Ortszeit an.
Wenn Sie beispielsweise eine java.util.Date -Darstellung des Datums haben, hängt die lokale Zeit von der Zeitzone ab. Durch Angabe der Zeitzone definieren Sie die lokale Zeit.
(Als Antwort auf Joda Stephen)
Beachten Sie, dass es auch einen Konstruktor
LocalDate(Object)gibt, der intern die Standardzeitzone verwendet.
Beachten Sie, dass, wenn Sie die Konstruktoren mit einem java.util.Date als Instant verwenden, diese "Standardzeitzone" UTC und NICHT die JVM-Standardzeitzone ist, wie manche erwarten würden . (Ich nahm an, dass das Erstellen eines LocalDate von einem java.util.Date oder seine native "yyyy-MM-dd" -Darstellung dasselbe bedeuten würde, und da java.util.Date.toString() die JVM-Standardzeitzone verwendet ...)
Um ein java.util.Date korrekt zu konvertieren, das erstellt wurde, ohne über Zeitzonen nachzudenken (z. B. einfach von einem "yyyy-MM-dd" -String) zu einem LocalDate , müssen Sie Folgendes tun:
Dies gilt zumindest für JodaTime 2.2; wir haben in den Code debugged.