Gibt es Nachteile bei der Verwendung von Joda-Time?

Ich möchte den Architekturmanager davon überzeugen, die einzubeziehen Joda-Zeit Glas in unserem Produkt.

Kennen Sie Nachteile bei der Verwendung?

Ich denke, Joda-Time muss wegen der darin enthaltenen Dateien ständig aktualisiert werden. Und das ist ein Nachteil. Vielleicht liege ich falsch.

Können Sie etwas Klarheit in das Thema bringen?

Ich habe mit Joda Time fast durchweg positive Erfahrungen gemacht. Mein einziges Problem war, als ich versuchte, meine eigene Zeitzone zu konstruieren (aus legitimen Gründen, das versichere ich Ihnen 🙂 Ich bekam einige sehr seltsame Ausnahmen, und die Dokumentation war für diesen speziellen Anwendungsfall nicht sehr gut.

Zum größten Teil war es jedoch eine Freude, es zu verwenden – Unveränderlichkeit macht es viel einfacher, über Code nachzudenken, und Thread-Sicherheit für Formatierer ist äußerst nützlich.

Ja, es gibt Dateien, die Sie auf dem Laufenden halten müssen – aber zumindest Sie kann halte sie auf dem Laufenden. Es ist nicht so, dass sie Dinge enthalten, die mit Javas eingebautem Zeug unnötig wären, es ist nur so, dass Sie mit Javas Mechanismus Informationen wie Zeitzonen ohne erhebliche Hackerangriffe nicht auf dem neuesten Stand halten konnten!

Grundsätzlich +1 für die Verwendung von Joda Time. Die Java-Datums-/Uhrzeit-API ist meiner Meinung nach eines der schlimmsten Teile der Java-Plattform.

Meiner Meinung nach liegt der wichtigste Nachteil von Joda-Time in der Genauigkeit: Viele Datenbanken speichern Zeitstempel mit Mikrosekunde (oder auch Nanosekunde) Genauigkeit. Joda-Zeit geht nur um Millisekunden. Dies ist für mich nicht akzeptabel: Alle “Datenmodell” -Klassen, die ich verwende, müssen die volle Genauigkeit der Daten in meiner Datenbank widerspiegeln. Annäherungen oder Kürzungen meiner Daten durch eine Bibliothek reichen einfach nicht aus.

Hier ist die Begründung für die Wahl der Millisekunden-Präzision, entnommen aus der JSR310 Mailingliste:

“Joda-Time hat sich für die Verwendung von Millisekunden entschieden, da dies die Konvertierung in Datum und Kalender erleichtert.” – S. Colebourne

Einfacher für wen? Der Autor der Bibliothek, würde man vermuten … Falsche Designentscheidung, meiner Meinung nach, wenn fast alle Datenbanken Zeiten mit einer Genauigkeit von Mikrosekunden / Nanosekunden speichern. Die Missachtung von Datenbankwerten ist besorgniserregend.

Das größte Problem, das wir bei der Verwendung von Joda Time hatten, war die Integration mit Spring und Tapestry, da beide das integrierte Datum und die integrierte Uhrzeit verwenden wollten. Wir haben ständig Wrapper in Getter/Setter für Datum und Uhrzeit geschrieben: Entweder haben wir es als Joda Time gespeichert und ein Set von Getter/Setter hat es durchgereicht und das andere hat es spontan konvertiert, und einige Klassen haben es intern als Java gespeichert Datum/Uhrzeit, und der Joda-Getter/Setter musste es spontan umschalten.

Im Grunde war es ein Problem, weil die Klassen ähnlich benannt sind, und wenn Sie Ihre gesamte Architektur (einschließlich anderer Bibliotheken, die Sie integrieren) nicht dazu bringen können, auf Joda Time umzusteigen, werden Sie mehr Wrapper-Code schreiben, als Sie wahrscheinlich sparen werden durch Verwendung der Joda-Bibliotheken.

Parleys-Gastgeber eine Präsentation von Stephen Colebourne über JSR-310, Herr Colebourne, der Autor von Joda-Time und JSR-310. Er erklärt zunächst die Schwächen der standardmäßigen Datums-/Uhrzeitunterstützung in Java und erklärt, warum Sie eine Alternative verwenden sollten. Es kann hilfreich sein, diese Präsentation Ihrem Architekturmanager zu zeigen. Ich kann anscheinend nicht tief verlinken

Der Grund, warum Joda-Time seine Zeitzonendatei ziemlich oft aktualisiert, ist, dass sich Zeitzonendaten ständig ändern, oft kurzfristig (heute auf slashdot: Schaltsekunde hinzugefügt am 31.12.2008) und nicht immer wissenschaftlich motiviert (z. B. ich erinnere mich, dass ein pazifischer Inselstaat seine Zeitzone geändert hat, um als erstes Land das Jahr 2000 einzuführen).

In der Vergangenheit bin ich auf Unternehmen gestoßen, die keine Open-Source-Software von Drittanbietern integrieren wollten oder zumindest vom Anwalt des Unternehmens eine Bestätigung verlangten, dass die Lizenz sie keiner Art von Haftung aussetzen oder einen Virus verursachen würde Wirkung auf ihr Produkt.

Wie bei allen Bibliotheken von Drittanbietern sollten Sie sie wahrscheinlich in die Quellcodeverwaltung stellen, damit Sie die Version finden können, die Sie mit bestimmten Versionen Ihres Codes geliefert haben, falls etwas schief geht.

Die Wahl von Millisekunden für das zugrunde liegende Zeitkontinuum ist gut für die Implementierung von Kalendern der Antike und speziellen Kalendern. Im Gegensatz zu vielen Zählern hat der 64-Bit-Millisekundenzähler eine gute Bereichsabdeckung für Kalender der Antike mit Rollover-Eigenschaften von mehr als +/- 260 Millionen Jahren.

Es verarbeitet keine Schaltsekunden. Das ist eine gute Sache. Ein sanfter Übergang wird von den Atomuhrleuten vorgeschlagen, damit Systeme, die keine Schaltsekunden verwenden, ihre Uhren schrittweise über 100 Sekunden anpassen können, um die Schaltsekundenkorrektur aufzunehmen.

Auch die Pflege von Zeitzonentabellen wird ein Thema sein.

Das zugrunde liegende Kontinuum ermöglicht auch einen alten französischen Kalender und eine Uhr, die einen Tag in 10 Intervalle namens metrische Zeit anstelle von 24 Stunden unterteilten. Der klassische chinesische Kalender unterteilt einen Tag in 100 Schritte von jeweils etwas mehr als 14 Minuten Länge. Alle diese Kalender können auf dem zugrunde liegenden Millisekunden-Zeitkontinuum implementiert und koordiniert werden.

Das Hauptproblem dabei ist die Herstellerbindung, zumindest bis sie Teil des Standards wird.

Zum größten Teil würde ich Longs verwenden, um Informationen zu Geschäftsdaten in einer Datenbank zu speichern. Dies gibt mir die Flexibilität, die Präzision so anzupassen, wie ich es für richtig halte. In den meisten Fällen konvertiere ich sie einfach in java.util.Date.

Zeitzonen würde ich als ein Problem auf Präsentationsebene und nicht als ein Datenproblem behandeln. Dies vereinfacht die Datenbank und erhöht die Übertragbarkeit, da Datenbanken Zeitangaben auf unterschiedliche Weise darstellen können.

Die Standard-Kalenderklasse bietet mir einige Datumsmanipulationsfunktionen, die ich in Millisekunden seit Epochendaten umwandele.

Was die Nanosekunden-Präzision betrifft, würde ich das als Offset von 0 als separate lange Spalte speichern.